monitoring: el alerting de Grafana colgaba de un montaje no declarado

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>
This commit is contained in:
2026-07-21 17:09:44 +00:00
co-authored by Claude Opus 4.8
parent d9d616fd26
commit 0501aab6e8
+15 -3
View File
@@ -8,9 +8,17 @@
# helm upgrade kube-prometheus-stack prometheus-community/kube-prometheus-stack \ # helm upgrade kube-prometheus-stack prometheus-community/kube-prometheus-stack \
# --version 83.2.0 -n monitoring -f values-kube-prometheus-stack.yaml # --version 83.2.0 -n monitoring -f values-kube-prometheus-stack.yaml
# #
# Revisión 2 (2026-07-21) silenció 4 alertas que llevaban meses disparadas sin # rev 2 (2026-07-21): silenciadas 4 alertas que llevaban meses disparadas sin
# significar nada — ver el bloque kubeControllerManager/kubeScheduler/kubeProxy # significar nada — ver kubeControllerManager/kubeScheduler/kubeProxy y
# y defaultRules.disabled al final. # 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: alertmanager:
enabled: false enabled: false
defaultRules: defaultRules:
@@ -21,6 +29,10 @@ defaultRules:
alertmanager: false alertmanager: false
grafana: grafana:
adminPassword: admin adminPassword: admin
extraConfigmapMounts:
- configMap: grafana-alerting
mountPath: /etc/grafana/provisioning/alerting
name: grafana-alerting
grafana.ini: grafana.ini:
server: server:
root_url: https://grafana.chemavx.xyz root_url: https://grafana.chemavx.xyz