El commit 22ae5d7 (15-abr) fijó estos tags EN GIT pero nunca se aplicó al
cluster: estos namespaces no están en ArgoCD, así que un cambio en git no llega
solo. Tres meses después git decía 1.25.5 y gitea corría 1.27.0, subido en algún
reinicio sin que nadie lo decidiera. Ahora se fija a los dos lados.
gitea gitea/gitea:latest -> gitea/gitea:1.27.0
gitea (init) busybox -> busybox:1.38.0
gitea-runner gitea/act_runner:latest -> gitea/act_runner:0.6.1
gitea-runner docker:24-dind -> docker:24.0.9-dind
authentik-redis redis:alpine -> redis:8.8.0-alpine
uptime-kuma louislam/uptime-kuma:1 -> louislam/uptime-kuma:1.23.17
homarr homarr:latest -> homarr@sha256:80ee593c...
Los seis primeros se fijan a la MISMA imagen que ya corría: verificado
comparando el repoDigest del tag flotante con el del tag candidato, así que el
reinicio no cambió de versión. Homarr va por digest porque su "latest" es una
build de la rama main (org.opencontainers.image.version=main): no existe un tag
de release que describa lo que corre. Moverlo a una release es otra decisión.
Trampa que casi me come, anotada para la próxima: el imageID de un pod NO
siempre es el digest del registro. Si viene como "repo@sha256:..." lo es; si es
un "sha256:..." pelado es el id local de containerd y NO se puede descargar.
Fijar uptime-kuma a ese id dio ImagePullBackOff; el pod viejo aguantó sirviendo
(maxUnavailable 0 para 1 réplica) y se revirtió sin corte. La comparación buena
es repoDigest contra repoDigest.
De paso, al regenerar gitea-runner desde lo vivo quedan documentados el volumen
buildkitd-config y su montaje, que existían en el cluster y no en git.
Verificado tras cada cambio: rollout completo, versión de la app dentro del pod,
y los cinco servicios respondiendo desde fuera (git 200, home 200, status/auth/
grafana 302 por Authentik). El runner se ha vuelto a registrar en Gitea. Sigue
sin haber pods fuera de Running y las 18 apps de ArgoCD Synced+Healthy.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Grafana llevaba ~15 días sin SSO: ignoraba la cabecera X-authentik-username, de
modo que Authentik te dejaba pasar y Grafana te pedía credenciales igual. El
último acceso de akadmin (el usuario que crea auto_sign_up) es de hace 15 días.
El bloque [auth.proxy] estaba en el ConfigMap vivo en abril — así consta en el
export de git de aquel momento — pero el chart NUNCA lo ha generado en ninguna
de sus 7 revisiones, así que era un retoque a mano que se perdió por el camino.
Ahora va declarado en values y sobrevive a una reconstrucción.
Aparecida al arreglarlo, otra pieza del mismo tipo: la anotación
router.middlewares que engancha el forward-auth de Authentik al Ingress. Vivía
sólo por el three-way merge de Helm, igual que el montaje de alerting (0501aab)
y el token de Telegram (28f1631). Reconstruir el release habría dejado Grafana
en internet SIN autenticación de Authentik, con sólo su formulario delante.
NO se restaura disable_login_form, que sí traía la config de abril: el
formulario local se queda como puerta de emergencia, con la contraseña del
secret grafana-admin. Que el SSO fallara en silencio es justo lo que pasó aquí.
Verificado: con la cabecera, autentica como akadmin; sin ella sigue dando 401;
una petición externa a grafana.chemavx.xyz redirige (302) al authorize de
Authentik; el formulario local responde 200 y la contraseña de emergencia entra;
0 errores en el arranque. Exports regenerados: el auditor deja monitoring en 2
hallazgos, ambos conocidos (una anotación del controlador y el tag de
uptime-kuma, pendiente de decidir con el resto de tags flotantes).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Los paneles heredados preguntaban "cuántos pods hay Running en el namespace".
Para n8n u ollama da igual, pero el panel llamado "grafana" contaba los 7 pods
de monitoring y el de "argocd" los suyos: se habrían quedado en verde con
Grafana muerta mientras Prometheus siguiera en pie. Lo mismo en "authentik" y
"gitea", que sumaban su Postgres, su Redis y el runner.
Ahora los 12 usan la misma forma: ¿están en pie TODOS los componentes de los
que depende el servicio?
min((kube_deployment_status_replicas_available{SEL} >= bool 1)
or (kube_statefulset_status_replicas_ready{SEL} >= bool 1)) or vector(0)
El selector define qué es el servicio: el namespace entero cuando el namespace
ES el servicio (argocd, authentik); acotado cuando alberga varias cosas
(grafana dentro de monitoring, researchowl/searxng); y en gitea sólo el
StatefulSet, porque si cae el runner se paran los builds pero Gitea sigue
sirviendo — pintarlo "Down" sería una falsa alarma.
Cambio invisible salvo cuando algo falla: los 12 mapean 0 -> "Down" y >=1 ->
"Running", así que en pantalla nunca se vio el número. Y además exige réplicas
*disponibles*, no pods en fase Running: un pod arrancado pero que no pasa el
readiness ya no cuenta como sano.
Verificado los 12 en verde y los 12 en rojo (simulando escasez de réplicas), y
el caso que de verdad importa: UN solo componente caído entre sanos arrastra el
panel a 0 (probado con dex-server en argocd y con el Postgres de authentik).
Después, los 12 otra vez a través del proxy de datasource de Grafana.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Faltaban justo los servicios de cara al público. Se añaden cuatro estados de
pod (ghost-en, zona-exclusion, researchowl, searxng), que completan la fila de
servicios, y una fila nueva con memoria, CPU y la antigüedad de la última copia
correcta de researchowl.db (CronJob diario de las 03:00 con integrity_check).
Los stat nuevos preguntan por kube_deployment_status_replicas_available del
deployment concreto, no por "todos los pods del namespace" como los antiguos:
esa consulta heredada hace que el panel llamado "grafana" cuente en realidad
los 7 pods de monitoring, y el de "argocd" todos los suyos. No los toco aquí.
Descartado a propósito un panel de uso de PVC: con local-path todos los
volúmenes de un nodo reportan el disco entero (ghost-en, zona-exclusion y
researchowl marcan los mismos 78 GB), así que habría mentido.
La primera versión de los cuatro stat estaba mal: "métrica{...} or vector(0)"
sobre una métrica CON etiquetas no sustituye, añade — devolvían 2 series y el
panel podía pintar un Down falso. Los paneles viejos se libran porque su sum()
deja la serie sin etiquetas. Corregido envolviendo en sum().
Verificado consulta a consulta contra Prometheus, incluido el caso "deployment
inexistente" (da 0 -> Down en rojo), y luego las 7 a través del proxy de
datasource de Grafana, no por fuera.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
Los sidecars de dashboards y datasources autentican contra la API de Grafana con
las credenciales del secret del chart, y recibían 401 en cada recarga. El valor
en values era adminPassword: admin, que no es la contraseña de nadie.
Lo que apareció al investigarlo cambia el diagnóstico que traíamos anotado. La
cuenta admin local se configuró el 26-abr y NO se ha usado desde entonces
(last_seen_at y updated, ambos de esa fecha): no hubo ninguna rotación reciente
en la UI. El acceso real a Grafana es por Authentik — de ahí el usuario akadmin
—, así que la contraseña de esa cuenta no la sabía nadie y era irrecuperable,
por ser un hash bcrypt.
Conservar la contraseña existente era por tanto imposible: no había ninguna que
conservar. Se genera una aleatoria de 28 caracteres, se escribe en el Secret
grafana-admin y se resetea la de Grafana para que coincidan (leyendo del secret
por stdin: nunca pasa por argv ni se imprime). La cuenta queda como acceso de
emergencia; nadie tiene que memorizarla. Para leerla:
kubectl get secret grafana-admin -n monitoring \
-o jsonpath='{.data.admin-password}' | base64 -d; echo
El secret se crea FUERA del chart y se referencia con grafana.admin.existingSecret,
en vez de parchear el secret que genera Helm: con adminPassword en values, el
siguiente upgrade lo habría revertido a "admin". Es la misma trampa que el
montaje del alerting de hace un rato, y por eso adminPassword desaparece de git.
Verificado por el camino real y no por deducción: creando un ConfigMap de prueba
con la etiqueta grafana_dashboard, el sidecar escribe el fichero y la recarga
responde 200 OK "Dashboards config reloaded" — antes 401. ConfigMap de prueba
eliminado. Grafana sano tras el rollout (database ok, 12.4.2), las 5 reglas de
alerta provisionadas siguen activas, 25 dashboards y los 3 ficheros de alerting
en su sitio.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
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>
- Elimina manifests openclaw/ y argocd/application-openclaw.yaml
- backup-system: fuera del backup diario, crown-jewels, expected y retain;
fuera el mount hostPath del cronjob y la fila de RESTORE.md
- monitoring: eliminado panel openclaw del dashboard homelab-overview
- n8n: openclaw y polymarket fuera del health-check (espejo del workflow vivo)
- cluster-wide/namespaces.yaml: fuera openclaw + añadidos separadores '---'
que faltaban (el archivo era un único doc YAML donde ganaba el último ns)
Cluster ya limpio: app ArgoCD, namespace, PVC/PV, RBAC cluster-scoped y
monitor de Uptime Kuma. Backup final: ~/decommissioned/openclaw-final-2026-07-18.tar.gz
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Regla homelab-backup-job-failed (kube_job_status_failed{namespace="backup-system"} > 0)
en el grupo homelab-infra; cubre backup, rclone-mega-backup y backup-verify.
Aplicado con kubectl replace + rollout restart de Grafana (namespace manual).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
7th and final copy of the Telegram bot token leaving git. monitoring is
out-of-band (not ArgoCD-managed), so the live secret is pruned manually with
kubectl. Grafana already reads grafana-telegram-infisical (from /telegram).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Each alert rule's summary annotation now renders a formatted Telegram
message with emoji and multiline context. The contact point passes the
pre-rendered summary through, adding "✅ Resuelto" on resolution.
Also restores the == 1 filter on Pod Failed/Unknown lost in prior rebase.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Grafana threshold expression requires a scalar input, not a raw time
series. Added explicit reduce step (type: reduce, reducer: last) as
refId B between the Prometheus query (A) and the threshold check (C).
All 4 rules updated: CrashLoopBackOff, Disco >80%, RAM >85%, Pod Failed.
condition field changed from B → C on each rule.
Grafana env var substitution of a numeric TELEGRAM_CHAT_ID caused
json unmarshal error (number into string field). chatid is not sensitive
so hardcode it directly; only bottoken uses ${TELEGRAM_BOT_TOKEN}.
- Delete 26 secret manifests containing REDACTED placeholder values
(15 cert-manager TLS + 11 app secrets across 8 namespaces)
- REDACTED is valid base64 that decodes to non-UTF-8 bytes — ArgoCD
applying these manifests corrupts live secrets in the cluster
- Add .githooks/pre-commit that rejects any .yaml with REDACTED
- Add README.md documenting secret management policy and manual
creation commands for each service
- n8n secret manifests already fixed in previous commits (618b1e8, db04fd2)
chemavxandClaude Opus 4.8