monitoring: fuera los restos de polymarket y la datasource Alertmanager

El dashboard «ChemaVX Homelab Overview» tenía 4 paneles Infinity apuntando a
api.polymarket-bot.svc.cluster.local:8000, decomisado el 2026-07-17, más dos
stat de servicios cuyos namespaces ya no existen (polymarket-bot, open-webui)
que se veían como un 0 sospechoso en vez de como ausencia. 24 -> 17 paneles, y
la rejilla de servicios reempaquetada (arrastraba huecos de borrados viejos).

La datasource Alertmanager apuntaba a un servicio inexistente (alertmanager
está desactivado a propósito) y devolvía 500. Dos sorpresas: no la apaga
alertmanager.enabled, sino grafana.sidecar.datasources.alertmanager.enabled; y
quitarla del provisioning NO la borra de grafana.db — hace falta una directiva
deleteDatasources de un solo uso. Igual para la Infinity, creada por UI.

Auditando el Deployment contra el render aparecieron dos campos puestos a mano
que el chart no genera y que sólo seguían vivos por el three-way merge de Helm,
el mismo agujero que 0501aab: GF_INSTALL_PLUGINS (ya sin uso, retirado junto al
plugin de 48 MB) y TELEGRAM_BOT_TOKEN/CHAT_ID, que sí son críticos — el contact
point usa ${TELEGRAM_BOT_TOKEN}, así que reconstruir el release desde cero
habría dejado las alertas mudas. Declarados ya en values.

Verificado: render == desplegado salvo defaults del API server; Grafana
reiniciada y arrancando sin errores, 1 datasource, 25 dashboards, 5 reglas y el
contact point de Telegram con token resuelto.

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

monitoring/values-kube-prometheus-stack.yaml

@@ -23,6 +23,19 @@
 #   como acceso de emergencia. Leerla:
 #     kubectl get secret grafana-admin -n monitoring \
 #       -o jsonpath='{.data.admin-password}' | base64 -d; echo
+# rev 5 (2026-07-22): fuera la datasource Alertmanager. OJO: NO la apaga
+#   alertmanager.enabled=false — el chart la provisiona igual, apuntando a un
+#   servicio que no existe (error 500 al consultarla). El interruptor real es
+#   grafana.sidecar.datasources.alertmanager.enabled. Y quitarla del fichero de
+#   provisioning NO la borra de grafana.db: hay que provisionar el borrado con
+#   una directiva deleteDatasources de un solo uso (se hizo y se retiró).
+# rev 6 (2026-07-22): grafana.envValueFrom. Mismo caso que rev 3, encontrado al
+#   auditar el Deployment contra el render: TELEGRAM_BOT_TOKEN y TELEGRAM_CHAT_ID
+#   estaban puestas A MANO y el chart no las generaba. El contact point de
+#   alerting usa ${TELEGRAM_BOT_TOKEN}: reconstruir el release desde cero habría
+#   dejado las alertas de Telegram mudas. Se declaran aquí sin tocar nada vivo.
+#   (CHAT_ID hoy no lo usa nadie —el chatid del contact point va literal— pero se
+#   deja para que el render coincida exactamente con lo desplegado.)
 alertmanager:
   enabled: false
 defaultRules:
@@ -34,6 +47,15 @@ defaultRules:
 grafana:
   admin:
     existingSecret: grafana-admin
+  envValueFrom:
+    TELEGRAM_BOT_TOKEN:
+      secretKeyRef:
+        key: TELEGRAM_BOT_TOKEN
+        name: grafana-telegram-infisical
+    TELEGRAM_CHAT_ID:
+      secretKeyRef:
+        key: TELEGRAM_CHAT_ID
+        name: grafana-telegram-infisical
   extraConfigmapMounts:
   - configMap: grafana-alerting
     mountPath: /etc/grafana/provisioning/alerting
@@ -57,6 +79,10 @@ grafana:
     enabled: true
     size: 5Gi
     storageClassName: local-path
+  sidecar:
+    datasources:
+      alertmanager:
+        enabled: false
 kubeControllerManager:
   enabled: false
 kubeProxy: