Vai al contenuto

Monitoring (Grafana, Prometheus, Loki, Tempo, Alertmanager)

Analisi del 29/10/2026 sul repository monitoring (main del 21/05/2026, dev del 18/06/2026) e sulla risorsa monitoring-dev di Coolify dev.

Cos'è

Stack di osservabilità per qAlarm e midserver ("Moni Core" nel README):

Servizio Porta Cosa fa
Grafana 3000 dashboard e ricerca di log, metriche e tracce
Prometheus 9090 legge le metriche (/metrics) ogni 30 s e valuta gli allarmi
Alertmanager 9093 invia gli allarmi su Telegram
Loki 3100 riceve e conserva i log
Tempo 3200, OTLP 4317/4318 riceve e conserva le tracce; genera metriche di servizio per Prometheus

Dashboard incluse: qAlarm backend, log (Loki), Redis, tracce (Tempo), midserver backend, Redis del midserver. Grafana è configurato per essere incorporato in un iframe con accesso anonimo in sola lettura (README; variabili GF_AUTH_ANONYMOUS_* e GF_SECURITY_ALLOW_EMBEDDING presenti su Coolify).

Cosa controlla

Allarmi in configs/prometheus/alerts.yml (branch dev): - qAlarm: backend giù, errori HTTP 5xx, Redis giù; - midserver v3: backend giù, errori 5xx, impianti offline (installations_offline_total), errori interni e richieste fallite verso le installazioni, Redis giù, connessioni rifiutate e comandi sugli stream falliti; - log: righe con error/exception/failed/critical (configs/loki/rules/fake/qalarm-log-alerts.yml); - qualsiasi bersaglio non raggiungibile per più di 2 minuti (TargetDown).

Bersagli su Coolify dev (configs/prometheus/prometheus-coolify-dev.yml): - qAlarm backend (mdm.dev.qalarm.backend) e il suo Redis; - midserver v3 (mdm.dev.midserver) e il suo Redis.

Non controlla pfSense, VPN, ServerIT, il midserver v2 di produzione, OME, ewelink, i box, né lo spazio disco: per queste parti R1 resta aperto.

Chi manda i dati

Servizio Metriche Log Tracce
qAlarm backend (qAlarm2_be, branch development/deploy_dev) /metrics con autenticazione base (app/core/prometheus_metrics.py) JSON strutturati (app/core/logging/structured_logging.py); Promtail nel compose (docker-compose-dev.yml, docker-compose-prod.yml) OTLP verso mdm.dev.monitoring.tempo.otlp (app/config/dev.yml)
Midserver v3 (refactor/v1) /metrics (app/core/prometheus_metrics.py) JSON strutturati; invio a Loki previsto (loki.push_url, in dev punta a localhost) previste, disattivate in dev (tracing.enabled: false)
Box (mdm_installation) no no no (il README descrive come aggiungerle via MQTT)
Pannello MDM — — — (ha un link a Grafana in configurazione, M12)

Dove gira

  • Coolify dev, progetto Monitoring, applicazione monitoring-dev: branch dev, avvio con docker-compose.base.yml + deploy/compose/coolify/dev.yml.
  • Indirizzi (environments.md): Grafana mdm.dev.monitoring.bsqdev.uk, Loki mdm.dev.monitoring.loki.bsqdev.uk, Tempo mdm.dev.monitoring.tempo.bsqdev.uk, ingresso OTLP mdm.dev.monitoring.tempo.otlp.bsqdev.uk.
  • Produzione: nessuna istanza.

Problemi

  • Token e chat del bot Telegram scritti nel repository (configs/alertmanager/alertmanager.yml, uguale su main e dev). Vanno revocati e spostati in una variabile (M28).
  • Grafana dev pubblico con accesso anonimo e Loki esposto su un dominio pubblico: chi conosce l'indirizzo può leggere log che contengono dati degli impianti. Il valore effettivo delle variabili anonime su Coolify è da verificare (M30).
  • Credenziali di prova nei file versionati: autenticazione base delle metriche e del Redis exporter (test/valore di esempio) in prometheus.yml e nel README.
  • Immagini latest per Prometheus, Alertmanager, Grafana e Loki (docker-compose.base.yml): un riavvio può cambiare versione senza preavviso. Tempo è fissato (2.4.1).
  • Branch: dev contiene le modifiche per Coolify; main è più vecchio di un mese.

Soluzione ideale

Un solo monitoraggio per tutto il servizio di produzione: lo stesso stack, in un'istanza di produzione separata dal dev, che controlla tutte le parti critiche e avvisa di notte su un canale che qualcuno legge.

  • Cosa controlla:
  • qAlarm e midserver, con le metriche che ci sono già;
  • pfSense e VPN, OME, ewelink, spazio disco di ServerIT e dell'host;
  • box online/offline, dalla metrica installations_offline_total del midserver v3.
  • Segreti fuori dal repository: token Telegram, password delle metriche, accesso a Grafana.
  • Grafana con login, oppure con accesso anonimo solo dalla rete interna; Loki e Tempo non pubblici, tranne l'ingresso OTLP protetto.
  • Versioni delle immagini fissate, e dev unito in main con la convenzione dei branch.

Cosa dobbiamo fare

Il monitoraggio è fuori dal piano attuale (P6, R1: va segnalato). Queste due cose però riguardano la sicurezza già oggi:

# Passo Quando
1 Revocare il token del bot Telegram, spostarlo in una variabile di Coolify, togliere il valore dal repository subito (M28)
2 Verificare e, se serve, chiudere l'accesso anonimo a Grafana dev e l'esposizione pubblica di Loki subito (M30)
3 Fissare le versioni delle immagini; unire dev in main con il passo 1
4 Istanza di produzione con i controlli della soluzione ideale quando si riprende R1 (P6)