Prometheus e Alertmanager per l'alerting su OpenTelemetry

OpenTelemetry non si occupa di alerting. Per scelta: raccoglie e trasporta log, metriche e trace, e si ferma lì. Gli allarmi sono delegati a un backend di observability. Per gli allarmi, in uno stack OpenTelemetry, continua a piacermi la classica accoppiata Prometheus + Alertmanager.

La compatibilità oggi è molto buona: la SIG congiunta OTel-Prometheus ci lavora da anni e il collector OpenTelemetry invia le metriche a Prometheus via remote write. In Prometheus 3.0 c'è anche un ricevitore OTLP nativo (questo però non l'ho ancora testato).

L'architettura è semplice. Il collector manda tutto a ClickStack per analisi e debugging e manda le metriche a Prometheus, che uso solo come motore di regole di alerting con retention corta. Alertmanager riceve gli alert e fa grouping, routing, inhibition e silence.

Quello che mi piace: è tutto testo. Regole in YAML e PromQL, routing in YAML. Infrastructure as code al cento per cento, e questo lo rende perfetto per gli agenti: Claude scrive la regola, la valida con promtool check e la verifica sui dati reali. L'interfaccia grafica di Prometheus e Alertmanager è molto scarna, ma la uso pochissimo in ogni caso.

Le librerie di regole come awesome-prometheus-alerts non si copiano pari pari: si aspettano la semantica di node_exporter e kube-state-metrics, non quella di OTel. Ma sono una traccia per capire cosa monitorare, con soglie e durate. Tradurle in regole OTel-native è un lavoro piuttosto meccanico, e un agente lo fa bene.

Il limite: Prometheus vede solo metriche. Per fare alert sui log vanno ricavate delle metriche sintetiche nel collector.