deploy
152 lines
6.1 KiB
YAML
152 lines
6.1 KiB
YAML
# ArgoCD Application: kube-prometheus-stack gerenciado por GitOps (source = Helm repo, versao fixada)
|
|
apiVersion: argoproj.io/v1alpha1
|
|
kind: Application
|
|
metadata:
|
|
name: monitoring
|
|
namespace: argocd
|
|
spec:
|
|
project: default
|
|
source:
|
|
repoURL: https://prometheus-community.github.io/helm-charts
|
|
chart: kube-prometheus-stack
|
|
targetRevision: 86.2.3
|
|
helm:
|
|
values: |
|
|
# ── Alertmanager: LIGADO, e ainda sem canal (2026-09-21) ──────────
|
|
#
|
|
# Ligar antes de escolher o canal NAO e meia-medida. Sem ele, cada regra
|
|
# que dispara vira uma linha na tela do Prometheus e mais nada: sem
|
|
# agrupamento, sem silencio, sem historico, e sem inibicao — o mesmo
|
|
# incidente aparece dez vezes. Com ele, isso passa a existir.
|
|
#
|
|
# O `receiver` padrao e o VAZIO de proposito: nada sai daqui ate alguem
|
|
# escolher o canal. Um receiver meio configurado (SMTP sem senha, webhook
|
|
# sem URL) impede o Alertmanager de SUBIR, e ai nem a tela existe.
|
|
#
|
|
# Para ligar o canal: `AlertmanagerConfig` com o label `release: monitoring`
|
|
# (o seletor abaixo). O modelo, com e-mail e com webhook, esta em
|
|
# `platform/monitoring/alertmanager-config-modelo.yaml.tmpl`.
|
|
alertmanager:
|
|
enabled: true
|
|
alertmanagerSpec:
|
|
# O no e unico e ja tem 78 de 110 pods: o Alertmanager cabe folgado
|
|
# nisto, e a retencao padrao de 120h de historico basta.
|
|
resources:
|
|
requests: { cpu: 10m, memory: 64Mi }
|
|
limits: { memory: 192Mi }
|
|
alertmanagerConfigSelector:
|
|
matchLabels:
|
|
release: monitoring
|
|
config:
|
|
global:
|
|
resolve_timeout: 5m
|
|
# O `InfoInhibitor` do chart existe para isto: quando um alerta de
|
|
# `severity: info` acompanha um `warning`/`critical` do mesmo
|
|
# namespace, so o grave e notificado.
|
|
inhibit_rules:
|
|
- source_matchers: [severity = "critical"]
|
|
target_matchers: [severity =~ "warning|info"]
|
|
equal: [namespace, alertname]
|
|
- source_matchers: [severity = "warning"]
|
|
target_matchers: [severity = "info"]
|
|
equal: [namespace, alertname]
|
|
route:
|
|
# Por alerta e por namespace: o que interessa e "o tenant X esta com
|
|
# o pod Y fora", e nao dez mensagens do mesmo problema.
|
|
group_by: [alertname, namespace]
|
|
group_wait: 30s
|
|
group_interval: 5m
|
|
# 12h: alerta que ninguem resolveu volta a avisar, sem virar spam.
|
|
repeat_interval: 12h
|
|
receiver: sem-canal
|
|
routes:
|
|
# O `Watchdog` dispara SEMPRE, de proposito: ele e o pulso que
|
|
# prova que o caminho do alerta esta vivo. Notificar seria ruido.
|
|
- matchers: [alertname = "Watchdog"]
|
|
receiver: sem-canal
|
|
receivers:
|
|
- name: sem-canal
|
|
grafana:
|
|
admin:
|
|
existingSecret: grafana-admin
|
|
userKey: admin-user
|
|
passwordKey: admin-password
|
|
defaultDashboardsTimezone: America/Sao_Paulo
|
|
ingress:
|
|
enabled: true
|
|
ingressClassName: traefik
|
|
annotations:
|
|
cert-manager.io/cluster-issuer: letsencrypt-prod
|
|
traefik.ingress.kubernetes.io/router.middlewares: monitoring-redirect-https@kubernetescrd
|
|
hosts:
|
|
- grafana.athleticmap.influxdigital.com.br
|
|
tls:
|
|
- secretName: grafana-tls
|
|
hosts:
|
|
- grafana.athleticmap.influxdigital.com.br
|
|
resources:
|
|
requests:
|
|
cpu: 100m
|
|
memory: 256Mi
|
|
limits:
|
|
memory: 512Mi
|
|
prometheus:
|
|
prometheusSpec:
|
|
retention: 7d
|
|
resources:
|
|
requests:
|
|
cpu: 200m
|
|
memory: 512Mi
|
|
limits:
|
|
memory: 1536Mi
|
|
storageSpec:
|
|
volumeClaimTemplate:
|
|
spec:
|
|
storageClassName: local-path
|
|
accessModes: [ReadWriteOnce]
|
|
resources:
|
|
requests:
|
|
storage: 10Gi
|
|
prometheusOperator:
|
|
resources:
|
|
requests:
|
|
cpu: 50m
|
|
memory: 128Mi
|
|
# ── os tres CRITICAL que o k3s faz mentir (2026-09-21) ─────────────
|
|
#
|
|
# `KubeProxyDown`, `KubeSchedulerDown` e `KubeControllerManagerDown`
|
|
# estavam disparando em PERMANENCIA, e sao FALSOS: o k3s roda esses tres
|
|
# componentes EMBUTIDOS no processo do servidor e nao expoe as portas de
|
|
# metrica que o chart procura (10249/10259/10257). Nao ha o que consertar
|
|
# no cluster — o chart e que assume um Kubernetes "de pecas separadas".
|
|
#
|
|
# Por que desligar, e nao conviver: **tres criticos permanentes ensinam
|
|
# todo mundo a ignorar alerta**. No dia em que o Alertmanager existir,
|
|
# eles seriam a primeira coisa a chegar, e chegariam para sempre — e o
|
|
# canal nasceria desacreditado.
|
|
#
|
|
# Isto NAO desliga vigilancia nenhuma de verdade: com o controlador ou o
|
|
# scheduler fora, o no inteiro cai, e disso o `up` do kubelet e o
|
|
# `AthleticMapTenantPodNotReady` falam alto.
|
|
kubeProxy:
|
|
enabled: false
|
|
kubeScheduler:
|
|
enabled: false
|
|
kubeControllerManager:
|
|
enabled: false
|
|
# Mesmo caso: o etcd do k3s e embutido (SQLite/etcd interno) e nao
|
|
# responde na porta que o chart espera. Ja vinha desligado no chart para
|
|
# este arranjo; explicito aqui para nao voltar numa atualizacao.
|
|
kubeEtcd:
|
|
enabled: false
|
|
destination:
|
|
server: https://kubernetes.default.svc
|
|
namespace: monitoring
|
|
syncPolicy:
|
|
automated:
|
|
prune: false
|
|
selfHeal: true
|
|
syncOptions:
|
|
- ServerSideApply=true
|
|
- CreateNamespace=true
|