# Valores del release Helm kube-prometheus-stack (chart 83.2.0, ns monitoring).
#
# Este namespace NO está bajo ArgoCD: se gestiona a mano. Este fichero es la
# fuente de verdad del release; para aplicarlo:
#
#   helm upgrade kube-prometheus-stack prometheus-community/kube-prometheus-stack \
#     --version 83.2.0 -n monitoring -f values-kube-prometheus-stack.yaml
#
# 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. Reconstruir el release desde este fichero se
#   habría llevado por delante TODO el alerting, en silencio.
# rev 4 (2026-07-21): grafana.admin.existingSecret y FUERA adminPassword.
#   El valor en git era "admin", que no abría nada: la cuenta admin local se
#   configuró el 26-abr y no se ha usado desde entonces (se entra por Authentik).
#   Los sidecars de dashboards y datasources SÍ la usaban y recibían 401 al
#   intentar recargar por API. Ahora la contraseña es aleatoria, vive solo en el
#   Secret grafana-admin (creado fuera del chart, nunca en git) y la cuenta queda
#   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:
  create: true
  disabled:
    PrometheusNotConnectedToAlertmanagers: true
  rules:
    alertmanager: false
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
    name: grafana-alerting
  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
  sidecar:
    datasources:
      alertmanager:
        enabled: false
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