chemavxandClaude Opus 4.8
d9d616fd26
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>
61 lines
1.7 KiB
YAML
61 lines
1.7 KiB
YAML
# 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
|