Alerting

Configura le notifiche di allarme e monitora i problemi attivi su tutte le tue organizzazioni e sistemi.

:::info ALPHA L'interfaccia di alerting è attualmente in alpha. Alcune funzionalità e schermate potrebbero cambiare nelle versioni future. :::

Panoramica

La funzionalità di Alerting fornisce una vista centralizzata di tutti gli allarmi attivi dai tuoi sistemi gestiti e ti permette di configurare come vengono consegnate le notifiche. Si integra con Grafana Mimir Alertmanager per una gestione degli allarmi affidabile e multi-tenant.

Dalla pagina Alerting puoi:

• Visualizzare gli allarmi attivi e restringerli per gravità, tipo di allarme, sistema, azienda, stato di silenziamento o assegnatario
• Configurare notifiche email, webhook e Telegram per la tua organizzazione
• Marcare ogni destinatario con le severità da ricevere (critical, warning, info, oppure tutte)
• Limitare un destinatario agli allarmi di organizzazioni o sistemi specifici
• Scegliere lingua e formato del corpo email per ogni destinatario
• Consultare lo storico degli allarmi di ciascun sistema

Accesso

La pagina Alerting è accessibile dal menu laterale alla voce Alerting. I due tab hanno permessi diversi:

• Tab Allarmi — richiede read:systems (admin, support, reader). Per creare o rimuovere silences serve manage:systems.
• Tab Notifiche — richiede read:alerts (solo admin/super); manage:alerts per salvare o rimuovere una configurazione.

Selezione organizzazione

Il filtro Azienda in cima al tab Allarmi restringe la lista a una o più organizzazioni della tua gerarchia. Lo vedono Owner, distributori e reseller; i customer vedono solo i propri allarmi, quindi per loro il filtro non compare. Il tab Notifiche invece opera sempre sulla propria organizzazione — non mostra mai la configurazione di un'altra organizzazione, indipendentemente dal valore del filtro.

Allarmi attivi

Il tab Allarmi mostra tutti gli allarmi attualmente attivi per le organizzazioni nel tuo perimetro, recuperati in tempo reale da Alertmanager.

Campi dell'allarme

Ogni riga della tabella mostra:

Colonna	Descrizione
Gravità	Badge colorato: Critical (rosso), Warning (arancione), Info (blu)
Allarme	Tipo di allarme (es. ServiceDown, BackupFailed) con il suo riepilogo; il badge Silenziato segnala gli allarmi silenziati
Sistema	Sistema che ha generato l'allarme
Azienda	Organizzazione a cui appartiene il sistema
Iniziato	Quando l'allarme ha iniziato a scattare, come tempo relativo e assoluto
Assegnato a	Utente che sta gestendo l'allarme, se presente

Dettagli apre un pannello laterale con la descrizione completa, il sistema, l'ora di inizio, l'assegnatario e, per gli allarmi silenziati, la scadenza del silenziamento. Il menu della riga contiene le azioni descritte in Lavorare sugli allarmi.

Livelli di severità

Livello	Significato	Uso tipico
Critical	Sistema down o perdita dati imminente	Azione immediata richiesta
Warning	Stato degradato o soglia in avvicinamento	Azione necessaria a breve
Info	Evento informativo	Nessuna azione immediata

Filtri

I filtri in cima alla pagina si combinano tra loro: i valori scelti dentro uno stesso filtro sono alternativi, filtri diversi devono valere tutti.

• Gravità: uno o più tra Critical, Warning, Info
• Allarme: uno o più tipi di allarme (es. ServiceDown, BackupFailed), con casella di ricerca
• Sistema: uno o più sistemi, con casella di ricerca
• Azienda: una o più organizzazioni della tua gerarchia (non compare ai customer)
• Stato: Non silenziato, Silenziato o entrambi; di default sono elencati solo gli allarmi non silenziati
• Assegnato a: Non assegnato, te stesso o utenti specifici (richiede read:users)

Ordina dispone la lista per ora di inizio (default, i più recenti prima), gravità, nome dell'allarme o assegnatario. Reimposta filtri ripristina i valori di default. La lista si aggiorna da sola ogni 20 secondi mentre il tab è visibile.

Lavorare sugli allarmi

Ogni allarme attivo offre un set di strumenti di collaborazione, disponibili dalla riga dell'allarme:

Presa in carico

Assegna a me indica che stai lavorando sull'allarme. Un solo assegnatario per allarme: assegnarsi un allarme già preso da qualcun altro esegue un subentro (il precedente assegnatario resta registrato nella timeline delle attività). Non esiste la rimozione manuale dell'assegnazione: viene rilasciata automaticamente quando l'allarme si risolve. L'assegnatario corrente è mostrato sulla riga dell'allarme, così il team sa sempre chi se ne sta occupando.

L'assegnazione è solo self-service (assegni sempre te stesso) e richiede manage:systems.

Silenziamenti

Un allarme può essere silenziato per una durata a scelta con un commento opzionale: le notifiche si fermano mentre l'allarme resta visibile come silenziato. Modificando il silenziamento se ne aggiorna la scadenza o il commento; rimuovendolo le notifiche riprendono. I silenziamenti richiedono manage:systems.

Note

È possibile aggiungere note libere a un allarme in qualsiasi momento, indipendentemente dai silenziamenti — utili per registrare osservazioni o passaggi di consegne. Le note compaiono nella timeline come eventi note_added.

Timeline delle attività

Ogni allarme conserva una timeline con l'intera cronologia di collaborazione: silenziato / silenziamento aggiornato / riattivato, assegnato / rilasciato (incluso il rilascio automatico alla risoluzione) e note, ciascuno con autore e data.

Notifiche

Il tab Notifiche ti permette di definire chi viene notificato quando un allarme scatta nella tua organizzazione. Quello che salvi qui è il tuo layer — il server lo unisce ai layer di tutte le organizzazioni sopra di te nella gerarchia (Owner → Distributor → Reseller → Customer) e pusha la YAML Alertmanager risultante a Mimir.

Cosa vedi tu vs. cosa vede Mimir

Quello che vedi in questo tab è sempre e solo il tuo layer. Non vedi mai i layer delle organizzazioni sopra di te, e le organizzazioni sotto di te non vedono mai il tuo. La configurazione effettiva mergiata viene calcolata server-side al momento del render e non lascia mai il backend; non oltrepassa mai il confine del tenant.

Questo isolamento è intenzionale: confina URL dei webhook, token Telegram e indirizzi email destinatari all'organizzazione che li ha digitati.

Contratto additivo

I layer sono additivi. Un discendente può aggiungere destinatari su quanto configurato dall'antenato, ma non può rimuovere o disabilitare canali che un antenato ha abilitato. Per esempio:

• L'Owner abilita email globalmente e aggiunge noc@msp.example → ogni tenant sotto eredita entrambi.
• Un Reseller può aggiungere noc@reseller.example sopra — ora entrambi gli indirizzi ricevono gli allarmi che li riguardano.
• Lo stesso Reseller non può spegnere email per il proprio sottoalbero. Solo l'Owner può disabilitare globalmente un canale; per i ruoli non-Owner, un false esplicito su un toggle viene normalizzato a null ("nessuna opinione") al salvataggio.

Forma della configurazione

Il layer è un oggetto JSON flat con tre toggle di canale e tre liste di destinatari:

{
  "enabled": { "email": true, "webhook": null, "telegram": null },
  "email_recipients": [
    { "address": "noc@org.example", "severities": ["critical","warning"], "language": "it", "format": "html" }
  ],
  "webhook_recipients": [
    { "name": "ops-slack", "url": "https://hooks.slack.com/services/T000/B000/XXX", "severities": ["critical"] }
  ],
  "telegram_recipients": [
    { "bot_token": "123456789:ABCDEFabcdef...", "chat_id": -1001234567890, "severities": [] }
  ]
}

Toggle dei canali (enabled)

Ogni canale è tri-stato:

Valore	Significato
true	Canale abilitato a questo layer
false	Canale disabilitato a questo layer (solo Owner; per i non-Owner false viene normalizzato a null al salvataggio)
null	Nessuna opinione a questo layer; lo stato effettivo eredita da un eventuale antenato che ha preso posizione. Se nessun layer abilita il canale, resta off.

Destinatari email (email_recipients)

Campo	Tipo	Descrizione
address	string	Indirizzo email che riceve la notifica
severities	string[]	Sottoinsieme di ["critical","warning","info"]. Array vuoto = "tutte le severità"
language	string	en o it. Determina lingua del subject e del body del template renderizzato
format	string	html (default, multipart HTML primario + text fallback) o plain (body solo testo)
scope	object	Opzionale. Limita il destinatario ad alcune organizzazioni e/o sistemi, vedi Destinatari limitati a organizzazioni e sistemi. Se omesso, tutti i sistemi

Destinatari webhook (webhook_recipients)

Campo	Tipo	Descrizione
name	string	Etichetta descrittiva del target (mostrata nella UI)
url	string	Endpoint HTTPS/HTTP. Validato lato server: loopback, RFC1918, RFC6598 CGNAT, link-local, multicast e metadata cloud sono rifiutati
severities	string[]	Stessa semantica delle email
scope	object	Stessa semantica delle email

Destinatari Telegram (telegram_recipients)

Campo	Tipo	Descrizione
bot_token	string	Token ottenuto da @BotFather
chat_id	integer	Id numerico della chat (positivo per utenti, negativo per gruppi/canali)
message_thread_id	integer	Opzionale. Topic di un supergruppo con i topic abilitati in cui pubblicare; l'id del topic è il numero in fondo al link del topic (t.me/c/<chat>/<topic_id>). Se omesso, il bot scrive nel topic General
severities	string[]	Stessa semantica delle email
scope	object	Stessa semantica delle email

Scope per severità

L'array severities di ciascun destinatario controlla quali severità riceve:

• Vuoto ([]) — il destinatario riceve ogni severità. È il default per un indirizzo "catch-all".
• Sottoinsieme (es. ["critical"]) — il destinatario riceve solo quelle severità.

Mimir Alertmanager espande un receiver per severità, con un nome per tenant (<org_id>-severity-critical-receiver, -warning-, -info-); un destinatario con severities=[] finisce in tutti e tre.

Destinatari limitati a organizzazioni e sistemi

Di default un destinatario riceve gli allarmi di tutti i sistemi raggiunti dal tuo layer: la tua organizzazione e tutto ciò che sta sotto. Nelle impostazioni del destinatario, Allarmi di restringe questo insieme:

• Tutti i sistemi — il default, nessuno scope.
• Solo aziende o sistemi specifici — scegli una o più organizzazioni in Aziende e/o sistemi in Sistemi.

Di default un'organizzazione scelta copre solo i sistemi assegnati all'organizzazione stessa: scegliendo un distributore si coprono i suoi sistemi, non quelli dei suoi rivenditori e clienti. Selezionando Includi anche i sistemi delle aziende gestite ogni organizzazione scelta si estende alle organizzazioni che gestisce: un distributore copre allora i suoi rivenditori e i loro clienti, un rivenditore i suoi clienti. La scelta vale per tutte le organizzazioni scelte insieme.

I clienti non gestiscono altre organizzazioni, quindi vedono Solo sistemi specifici e scelgono solo sistemi.

Un allarme arriva al destinatario se il suo sistema è tra quelli scelti oppure rientra in una delle organizzazioni scelte. Lo scope si combina con le severità: un destinatario limitato a un cliente con ["critical"] riceve solo gli allarmi critici di quel cliente.

"scope": {
  "managed_organization_ids": ["<logto id del rivenditore>"],
  "assigned_organization_ids": ["<logto id del distributore>"],
  "system_ids": ["<id sistema>", "<id sistema>"]
}

managed_organization_ids contiene le organizzazioni scelte con Includi anche i sistemi delle aziende gestite, assigned_organization_ids le altre; la UI scrive l'una o l'altra lista, uno scope salvato tramite API può usarle entrambe. Le tre liste sono opzionali, ma uno scope deve indicare almeno un'organizzazione o un sistema (al massimo 100 organizzazioni per lista e 500 sistemi). Uno scope vuoto o assente significa tutti i sistemi. La vecchia chiave organization_ids è ancora accettata in ingresso come managed_organization_ids.

Uso tipico: un distributore o l'Owner segue su un indirizzo dedicato un singolo cliente di un rivenditore grande, o pochi sistemi critici, senza ricevere tutto il resto.

Cosa puoi scegliere. Solo organizzazioni e sistemi della tua gerarchia. Salvare uno scope che indica altro fallisce con out_of_scope sul campo scope di quel destinatario.

Quando le cose si spostano. Lo scope memorizza degli id, e l'instradamento segue i sistemi ovunque si trovino:

• Un sistema spostato in un'altra organizzazione dentro la tua gerarchia continua ad arrivare al destinatario.
• Un sistema spostato fuori dalla tua gerarchia, o cancellato, smette di arrivare. L'id resta nello scope e compare come non più disponibile; salvando di nuovo il layer viene mantenuto, e puoi rimuoverlo quando vuoi. Se il sistema torna sotto di te (spostato indietro o ripristinato), i suoi allarmi tornano ad arrivare.
• Lo stesso vale per le organizzazioni, compreso un rivenditore promosso a distributore: quando non è più sotto di te, lo scope su di lui smette di valere.

Lo stesso indirizzo può comparire sia con sia senza scope (o con scope diversi): un allarme che corrisponde a più copie viene comunque consegnato una volta sola.

Merge nella gerarchia

Quando il server renderizza la configurazione effettiva per un tenant, percorre la catena da Owner fino al tenant e unisce i layer con queste regole:

• Toggle dei canali — OR logico: se un qualunque layer della catena abilita un canale, il canale è on per il tenant.
• Destinatari — union con dedup stabile. Chiavi di dedup: address per email, url per webhook, (bot_token, chat_id, message_thread_id) per Telegram. In caso di collisione di language o format, vince la prima occorrenza (più vicina all'Owner).
• severities per destinatario — union; se una qualunque copia che contribuisce ha severities=[] (tutte), la copia mergiata si allarga a [] (lo scope più largo vince sempre).
• scope per destinatario — una copia limitata non viene mai unita a una senza scope (la allargherebbe a tutti i sistemi); copie con lo stesso scope si uniscono come sopra.

Esempio: layer di livello customer che aggiunge notifiche

Supponi che l'Owner abbia già abilitato l'email con noc@msp.example per tutte le severità. Un Customer aggiunge questo layer per la propria organizzazione:

{
  "enabled": { "email": null, "webhook": null, "telegram": null },
  "email_recipients": [
    { "address": "oncall@customer.example", "severities": ["critical"], "language": "en", "format": "plain" },
    { "address": "manager@customer.example", "severities": [], "language": "it", "format": "html" }
  ],
  "webhook_recipients": [],
  "telegram_recipients": [
    { "bot_token": "123456789:ABCDEFabcdef...", "chat_id": -1001234567890, "severities": ["critical","warning"] }
  ]
}

Cosa consegna Mimir per questo customer:

• oncall@customer.example riceve solo gli allarmi critical come email in inglese plain text.
• manager@customer.example riceve tutti gli allarmi come email HTML in italiano.
• noc@msp.example dell'Owner continua a ricevere tutti gli allarmi (ereditato).
• La chat Telegram riceve gli allarmi critical e warning (il toggle telegram dell'Owner non era on, quindi questi telegram_recipients non scattano finché un antenato non abilita il canale Telegram — solo l'Owner può abilitare globalmente un canale).

Salvare e rimuovere un layer

• Salva configurazione persiste il tuo layer e triggera un re-render + push a Mimir per ogni tenant della tua gerarchia. Fino a 10 tenant il push avviene subito: la response riporta affected_tenants e propagated_to, ed eventuali fallimenti per tenant compaiono come warning senza rollback del salvataggio. Le gerarchie più grandi (Owner, distributori grandi) vengono aggiornate in background (propagation: async): i tenant falliti vengono ritentati in automatico, il tab Notifiche mostra l'avanzamento e al termine compare una notifica. Se alcune organizzazioni non sono state aggiornate, salva di nuovo per riprovare.
• Un destinatario che aggiungi riceve subito gli allarmi già attivi nel suo ambito, non solo quelli nuovi. Limita i destinatari personali ad aziende o sistemi specifici.
• Rimuovi questa configurazione cancella il tuo layer per intero. Il tuo contributo sparisce dalla config mergiata; i layer degli antenati (Owner / Distributor / Reseller) restano intatti e continuano a scattare. Per silenziare completamente un tenant, ogni layer della sua catena deve eliminare il proprio contributo.

Allarmi a livello di sistema

Nella pagina di dettaglio di ciascun sistema trovi due widget aggiuntivi:

note

LinkFailed è l'alert interno per l'heartbeat creato da Collect. Segue il timeout heartbeat configurato (10 minuti di default), separato dalla soglia di stato del sistema usata in Sistemi, e può restare attivo fino a 10 minuti dopo che il sistema torna a inviare heartbeat.

Card Allarmi attivi

Mostra gli allarmi attualmente attivi per quel sistema specifico, filtrati per la system key. Ogni voce mostra nome allarme, severità, stato, riepilogo e ora di inizio. Se il sistema non ha allarmi attivi, viene mostrato un messaggio di stato vuoto.

Pannello Storico allarmi

Mostra una tabella paginata degli allarmi risolti per il sistema, con colonne per nome, severità, stato, riepilogo, inizio e fine. Lo storico viene recuperato dal database locale dove gli allarmi risolti vengono salvati tramite i webhook di Alertmanager.

Puoi cambiare la dimensione della pagina (5, 10, 25, 50, 100) e navigare tra le pagine usando i controlli di paginazione in fondo alla tabella.

Accesso ad Alertmanager circoscritto alla macchina

Ogni sistema (macchina) ha un accesso isolato alle API di Alertmanager. Quando un sistema si autentica con HTTP Basic Auth (credenziali di sistema), può soltanto:

• Vedere i propri allarmi - Il proxy filtra automaticamente i risultati per mostrare solo gli allarmi con la label system_key del sistema
• Creare silenziamenti per i propri allarmi - I silenziamenti vengono automaticamente circoscritti al system_key del sistema, anche se nella richiesta viene passato un valore diverso
• Gestire i propri silenziamenti - Il sistema può leggere, modificare o eliminare solo i silenziamenti che puntano esplicitamente al proprio system_key

Questo impedisce a un sistema di interferire con gli allarmi o i silenziamenti di altri sistemi della stessa organizzazione.

Notifiche email

Quando le notifiche email sono abilitate, gli allarmi vengono consegnati da Alertmanager usando template personalizzati per la piattaforma. Ogni email include:

• Il nome e la severità dell'allarme
• La system key e l'eventuale label service
• Riepilogo e descrizione localizzati (nella lingua scelta per ciascun destinatario)
• Il timestamp di firing o risoluzione
• Un pulsante Visualizza sistema che linka direttamente alla pagina di dettaglio del sistema

I template sono disponibili in inglese e italiano. La lingua viene scelta per destinatario tramite il campo language di ogni voce in email_recipients[] — destinatari diversi della stessa organizzazione possono ricevere rendering in lingue diverse. Allo stesso modo, ogni destinatario sceglie il proprio format: html per un corpo multipart con HTML primario, plain per un corpo solo testo (utile per sistemi di ticketing o bridge mail-to-chat).

Notifiche Telegram

Quando le notifiche Telegram sono abilitate, gli allarmi vengono inviati come messaggi formattati a un bot Telegram. Ogni messaggio porta gli stessi campi delle email, impaginati per lo schermo del telefono: un'intestazione con stato e severità (ogni messaggio ha una sola severità, perché il routing è per severità), poi per ogni allarme nome, servizio, riepilogo e dettagli, l'orario di inizio o di inizio/risoluzione nel fuso dell'alerting, l'ultimo contatto quando noto, l'organizzazione con P.IVA, il nome del sistema, la sua chiave in monospazio e FQDN o IP, e il link al sistema su My Nethesis. I testi liberi sono protetti dall'escape HTML. I messaggi sono in inglese.

note

I messaggi Telegram sono limitati a 4096 caratteri. Per descrizioni di allarme molto lunghe, il messaggio potrebbe essere troncato. Per allarmi con metadati estesi, considera di usare email o webhook.

Passaggio 1 — Crea un bot Telegram

1. Apri Telegram e avvia una conversazione con @BotFather
2. Invia il comando /newbot
3. Segui le istruzioni: scegli un nome visualizzato e un username univoco (deve terminare con bot, es. MyAlertsBot)
4. BotFather risponde con un bot token nel formato 123456789:ABCDEFabcdef... — copialo

Passaggio 2 — Ottieni il chat ID

Il chat_id è l'identificatore numerico della destinazione (un utente privato, un gruppo o un canale).

Per una chat privata con te stesso o un utente specifico:

1. Apri Telegram e avvia una conversazione con il tuo nuovo bot (cerca il suo username)

2. Invia qualsiasi messaggio al bot (es. /start)

3. Apri il seguente URL nel browser, sostituendo <BOT_TOKEN> con il tuo token:

   https://api.telegram.org/bot<BOT_TOKEN>/getUpdates

   Eventualmente, potresti trovare il chat_id anche nell'URL della conversazione con il bot, nel formato https://web.telegram.org/z/#-<CHAT_ID> (nota il segno negativo per le chat private)

4. Trova il campo "id" all'interno dell'oggetto "chat" nella risposta JSON — quello è il tuo chat_id (un intero positivo, es. 123456789)

Per un gruppo o canale:

1. Aggiungi il tuo bot al gruppo o canale come amministratore
2. Invia un messaggio nel gruppo in modo che Alertmanager abbia qualcosa da leggere
3. Chiama getUpdates come sopra — il chat_id per gruppi e canali è un numero negativo (es. -1001234567890). Eventualmente, potresti trovare il chat_id anche nell'URL della conversazione con il bot, nel formato https://web.telegram.org/z/#-<CHAT_ID> (nota il segno negativo per gruppi/canali)

Per un topic di un gruppo con gli Argomenti attivi:

Gli allarmi possono essere pubblicati in un topic specifico invece che in quello General. Attivare gli Argomenti trasforma il gruppo in un supergruppo, quindi il suo chat_id cambia: rileggilo dopo averli attivati (inizia con -100).

1. Crea il topic e assicurati che il bot sia amministratore del gruppo
2. Dentro il topic, invia un messaggio che menziona il bot (es. @MyAlertsBot ciao)
3. Chiama getUpdates come sopra — il messaggio contiene "message_thread_id", cioè l'ID del topic, accanto a "chat"

In alternativa copia il link del topic da Telegram: ha la forma https://t.me/c/<ID>/<TOPIC_ID>, dove il chat_id è -100<ID> e l'ultimo numero è l'ID del topic.

Passaggio 3 — Aggiungi il destinatario Telegram al tuo layer

Aggiungi una voce a telegram_recipients; abilitare il canale con enabled.telegram = true è necessario solo a livello Owner (il canale si propaga additivamente verso il basso).

Campo	Tipo	Descrizione
bot_token	string	Il token fornito da BotFather
chat_id	integer	L'ID numerico della chat Telegram (positivo per utenti, negativo per gruppi/canali)
message_thread_id	integer	Opzionale. L'ID del topic ricavato al passaggio 2, per gruppi con gli Argomenti attivi. Se omesso, il bot scrive nel topic General
severities	string[]	Sottoinsieme di ["critical","warning","info"]. Array vuoto = tutte le severità

Nell'interfaccia, l'ID del topic va nel campo opzionale ID topic del canale Telegram.

Esempio (layer Owner che abilita Telegram per tutto l'albero, con gli allarmi critici pubblicati anche in un topic dedicato):

{
  "enabled": { "email": null, "webhook": null, "telegram": true },
  "email_recipients": [],
  "webhook_recipients": [],
  "telegram_recipients": [
    { "bot_token": "123456789:ABCDEFabcdef...", "chat_id": -1001234567890, "severities": [] },
    { "bot_token": "123456789:ABCDEFabcdef...", "chat_id": -1001234567890, "message_thread_id": 42, "severities": ["critical"] }
  ]
}

È possibile definire più destinatari per inviare gli allarmi a più bot o chat contemporaneamente. I messaggi Telegram sono attualmente sempre renderizzati in inglese.

Argomenti correlati

• Gestione Sistemi
• Registrazione Sistema
• Documentazione per sviluppatori: Guida integrazione alerting (per integrare nuovi sistemi con l'API Alertmanager)