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>

monitoring/values-kube-prometheus-stack.yaml

@@ -8,9 +8,17 @@
 #   helm upgrade kube-prometheus-stack prometheus-community/kube-prometheus-stack \
 #     --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
-# significar nada — ver el bloque kubeControllerManager/kubeScheduler/kubeProxy
-# y defaultRules.disabled al final.
+# 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:
@@ -21,6 +29,10 @@ defaultRules:
     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