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:
@@ -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
|
||||||
|
|||||||
Reference in New Issue
Block a user