From 9d903775ac3c7a82d9de03ea901c544cfc60d6c8 Mon Sep 17 00:00:00 2001
From: chemavx <chemavx@git.chemavx.xyz>
Date: Sat, 25 Jul 2026 15:36:13 +0000
Subject: [PATCH] monitoring: Fase 1 bajo ArgoCD (solo los manifiestos propios)

Hasta ahora las alertas de Grafana se aplicaban a mano con kubectl apply,
asi que dependian de que alguien se acordara (se vio hoy al anadir las de B2).

Lista blanca explicita en vez del directorio entero: monitoring/ mezcla tres
duenos y solo uno es nuestro. Fuera quedan los ~40 renderizados del chart
kube-prometheus-stack (release Helm viva -> dos duenos del mismo objeto) y los
generados por controladores (rulefiles-0 del prometheus-operator, etc).
Adoptar el chart via source Helm queda como Fase 2.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---
 monitoring/argocd-app.yaml | 56 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 monitoring/argocd-app.yaml

diff --git a/monitoring/argocd-app.yaml b/monitoring/argocd-app.yaml
new file mode 100644
index 0000000..99376b6
--- /dev/null
+++ b/monitoring/argocd-app.yaml
@@ -0,0 +1,56 @@
+# Fase 1 de meter monitoring/ bajo ArgoCD (2026-07-25).
+#
+# Por qué una lista blanca de ficheros y no el directorio entero: monitoring/
+# mezcla TRES dueños distintos y solo uno es nuestro.
+#
+#   A) Lo que escribimos nosotros  -> el include de aquí abajo, ArgoCD manda.
+#   B) Lo que genera el chart      -> kube-prometheus-stack (release Helm viva).
+#      Meterlo aquí daría DOS dueños al mismo objeto y reproduciría la deriva
+#      del three-way merge que ya se comió el alerting y el token de Telegram.
+#      Adoptarlo va aparte (source Helm + values-kube-prometheus-stack.yaml,
+#      borrando de git los ~40 renderizados). Pendiente = Fase 2.
+#   C) Lo que fabrican los controladores solos -> serviceaccount-default,
+#      configmap-kube-root-ca.crt y el rulefiles-0 (lo genera el
+#      prometheus-operator desde los PrometheusRule). En git no pintan nada;
+#      si ArgoCD los gestionara pelearía con el operator sin parar.
+#
+# OJO: ingress-kube-prometheus-stack-grafana.yaml NO está en la lista a
+# propósito — ese ingress lo gestiona Helm (managed-by=Helm). Es grupo B.
+#
+# Y OJO 2: este fichero DEBE vivir dentro de monitoring/ y estar en el include.
+# Es el patrón de la casa (cada app lleva su argocd-app.yaml en su directorio).
+# Si la Application no está dentro del path que ella misma vigila, el primer
+# sync con prune:true la ve como recurso huérfano y SE BORRA A SÍ MISMA
+# (pasó el 2026-07-25 al dejarla solo en argocd/, que es un volcado, no fuente).
+#
+# Motivo de la Fase 1: hasta hoy las alertas de Grafana se aplicaban a mano con
+# kubectl apply, así que dependían de que alguien se acordara. Ahora git manda.
+apiVersion: argoproj.io/v1alpha1
+kind: Application
+metadata:
+  name: monitoring
+  namespace: argocd
+  annotations:
+    notifications.argoproj.io/subscribe.on-sync-failed.telegram: "5138407666"
+    notifications.argoproj.io/subscribe.on-health-degraded.telegram: "5138407666"
+spec:
+  project: default
+  source:
+    repoURL: https://git.chemavx.xyz/chemavx/k8s-manifests
+    targetRevision: HEAD
+    path: monitoring
+    directory:
+      recurse: false
+      # Lista blanca explícita. Al añadir un fichero nuestro a monitoring/ hay
+      # que añadirlo AQUÍ o ArgoCD lo ignora. Y al revés: sacar un fichero de
+      # esta lista con prune:true activo BORRA el recurso del cluster.
+      include: "{argocd-app.yaml,configmap-grafana-alerting.yaml,configmap-chemavx-homelab-overview.yaml,deployment-uptime-kuma.yaml,service-uptime-kuma.yaml,pvc-uptime-kuma-pvc.yaml,ingress-uptime-kuma.yaml,ingress-uptime-kuma-redirect.yaml,ingress-prometheus.yaml,infisical-grafana-telegram.yaml}"
+  destination:
+    server: https://kubernetes.default.svc
+    namespace: monitoring
+  syncPolicy:
+    automated:
+      prune: true
+      selfHeal: true
+    syncOptions:
+      - CreateNamespace=true