monitoring: silencia 4 alertas que llevaban meses sin significar nada

Tres eran falsos positivos de k3s: KubeControllerManagerDown, KubeSchedulerDown
y KubeProxyDown llevaban 92 DÍAS disparadas en severidad critical. En k3s esos
tres componentes van embebidos en el proceso del servidor y no exponen las
métricas que espera el chart, así que sus ServiceMonitors nunca conectaban: la
alerta no medía la salud de nada, solo la ausencia de un target imposible.

La cuarta, PrometheusNotConnectedToAlertmanagers, llevaba disparada desde el
reinicio del máster del 16-jul. La causa es de diseño: alertmanager.enabled es
false y los avisos van por Grafana→Telegram y Kuma→Telegram. Ya se había
desactivado el grupo de reglas `alertmanager`, pero esta alerta vive en el
grupo `prometheus`, así que sobrevivió; se quita por nombre con
defaultRules.disabled.

Tres "critical" permanentes no son un aviso, son entrenamiento para ignorar el
panel: cuando algo se rompa de verdad, se perderá entre el ruido.

Hecho por Helm y no a mano (rev 1 → 2, mismo chart 83.2.0), que es lo único que
sobrevive a un futuro upgrade. Verificado ANTES de aplicar renderizando el chart
con y sin los valores nuevos: el diff quita exactamente esas 4 alertas (141 →
137) y ningún recurso nuevo aparece. Comprobado además que el render reproduce
el manifiesto ya desplegado, o sea que no había ediciones a mano que el upgrade
fuese a aplastar.

Después: 1 sola alerta disparada (Watchdog, el latido intencionado del chart,
severity none) y los 15 targets de scrape en up — antes 3 fallaban siempre.
Grafana sano (api/health ok, 12.4.2) y su contraseña rotada intacta, porque
GF_SECURITY_ADMIN_PASSWORD solo aplica en el primer arranque.

Se añade values-kube-prometheus-stack.yaml: este namespace no está bajo ArgoCD y
hasta hoy los valores del release solo vivían dentro de Helm, sin forma de saber
cómo estaba configurado sin interrogarlo. Se refresca el export del ConfigMap de
reglas y se borran 3 dashboards que el upgrade eliminó del cluster.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

monitoring/values-kube-prometheus-stack.yaml

@@ -0,0 +1,60 @@
+# 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
+#
+# 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.
+alertmanager:
+  enabled: false
+defaultRules:
+  create: true
+  disabled:
+    PrometheusNotConnectedToAlertmanagers: true
+  rules:
+    alertmanager: false
+grafana:
+  adminPassword: admin
+  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