chemavxandClaude Opus 4.8
0501aab6e8
El ConfigMap grafana-alerting (reglas provisionadas + contact points + política de notificación → Telegram) se monta en el Deployment de Grafana, pero el chart NO generaba ese volumen: se había añadido a mano en algún momento y sobrevivía únicamente por el three-way merge de Helm, que preserva lo que no aparece ni en el render viejo ni en el nuevo. O sea que todo el alerting de Grafana dependía de un accidente afortunado. Un `helm upgrade --force`, un `kubectl replace` desde la salida del chart, un cambio del chart que reestructurase `volumes`, o reconstruir el release desde el fichero de valores que acabo de añadir en el commit anterior — cualquiera de las cuatro se lo habría llevado por delante. Y en silencio: los paneles seguirían pintando igual, solo dejarían de llegar los avisos. Se declara con grafana.extraConfigmapMounts. Comprobado antes de aplicar que el spec renderizado es equivalente al vivo (subPath/readOnly a null y defaultMode 420 son los valores por defecto), así que el pod NO se ha reiniciado: mismo nombre antes y después. Y verificado lo que de verdad importaba: renderizando SOLO desde values-kube-prometheus-stack.yaml, el volumen aparece — el fichero ya basta para reconstruir el release entero sin perder el alerting. Encontrado haciendo el chequeo posterior al upgrade de las alertas de ruido, no por el upgrade en sí: llevaba así desde que se montó. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
73 lines
2.4 KiB
YAML
73 lines
2.4 KiB
YAML
# Valores del release Helm kube-prometheus-stack (chart 83.2.0, ns monitoring).
|
|
#
|
|
# Este namespace NO está bajo ArgoCD: se gestiona a mano. Hasta el 2026-07-21
|
|
# estos valores solo vivían dentro del release, así que no había forma de saber
|
|
# cómo estaba configurado sin interrogar a Helm. Este fichero es la fuente de
|
|
# verdad; para aplicarlo:
|
|
#
|
|
# helm upgrade kube-prometheus-stack prometheus-community/kube-prometheus-stack \
|
|
# --version 83.2.0 -n monitoring -f values-kube-prometheus-stack.yaml
|
|
#
|
|
# rev 2 (2026-07-21): silenciadas 4 alertas que llevaban meses disparadas sin
|
|
# significar nada — ver kubeControllerManager/kubeScheduler/kubeProxy y
|
|
# defaultRules.disabled.
|
|
# rev 3 (2026-07-21): grafana.extraConfigmapMounts. El montaje del ConfigMap
|
|
# grafana-alerting (reglas + contact points + política → Telegram) se había
|
|
# añadido A MANO al Deployment y NO lo generaba el chart: sobrevivía solo por
|
|
# el three-way merge de Helm, que conserva lo que no aparece en ninguno de los
|
|
# dos renders. Un `helm upgrade --force`, un `kubectl replace` desde el chart,
|
|
# o reconstruir el release desde este fichero se habrían llevado por delante
|
|
# TODO el alerting de Grafana, en silencio y sin que los paneles se inmutaran.
|
|
# Declarado en el chart, el spec resultante es idéntico (no reinició Grafana).
|
|
alertmanager:
|
|
enabled: false
|
|
defaultRules:
|
|
create: true
|
|
disabled:
|
|
PrometheusNotConnectedToAlertmanagers: true
|
|
rules:
|
|
alertmanager: false
|
|
grafana:
|
|
adminPassword: admin
|
|
extraConfigmapMounts:
|
|
- configMap: grafana-alerting
|
|
mountPath: /etc/grafana/provisioning/alerting
|
|
name: grafana-alerting
|
|
grafana.ini:
|
|
server:
|
|
root_url: https://grafana.chemavx.xyz
|
|
ingress:
|
|
annotations:
|
|
cert-manager.io/cluster-issuer: letsencrypt-prod
|
|
traefik.ingress.kubernetes.io/router.entrypoints: websecure
|
|
enabled: true
|
|
hosts:
|
|
- grafana.chemavx.xyz
|
|
ingressClassName: traefik
|
|
tls:
|
|
- hosts:
|
|
- grafana.chemavx.xyz
|
|
secretName: grafana-tls
|
|
persistence:
|
|
enabled: true
|
|
size: 5Gi
|
|
storageClassName: local-path
|
|
kubeControllerManager:
|
|
enabled: false
|
|
kubeProxy:
|
|
enabled: false
|
|
kubeScheduler:
|
|
enabled: false
|
|
prometheus:
|
|
prometheusSpec:
|
|
retention: 30d
|
|
storageSpec:
|
|
volumeClaimTemplate:
|
|
spec:
|
|
accessModes:
|
|
- ReadWriteOnce
|
|
resources:
|
|
requests:
|
|
storage: 20Gi
|
|
storageClassName: local-path
|