Amministrazione e configurazione
Tutta la configurazione di otwatch è gestita come codice in un sistema di controllo delle versioni e distribuita tramite una pipeline. Le modifiche vengono revisionate, testate in QA e rilasciate in produzione; ogni modifica è tracciabile con autore, data e ora e contenuto.
Controlli e soglie
Ogni controllo dispone di un ID stabile. L'ID collega la regola di allarme, l'allarme, il pannello della dashboard e il runbook con significato, cause probabili e prime azioni. Il catalogo dei controlli e i runbook sono disponibili per i clienti nel portale HID di otwatch.
- Le soglie sono definite per singolo controllo e possono variare per ambiente (ad es. PROD più restrittivo di TEST) e per cliente.
- Un guasto deve persistere per una durata definita (di norma 1–2 minuti) prima che venga generato un allarme, per evitare falsi allarmi.
- I controlli possono essere graduati, ad es. Warning all'80 % e Critical al 95 % di occupazione del disco.
Gravità e priorità
| Gravità | Priorità | Significato | Notifica |
|---|---|---|---|
| Critical | P1 / P2 | Produzione compromessa o a rischio immediato | Immediata, reperibilità (push, SMS, chiamata), ripetuta fino alla presa in carico |
| Warning | P3 / P4 | Funzione compromessa, soluzione alternativa disponibile, o soglia in avvicinamento | Ticket ed e-mail durante gli orari di servizio |
| Information | P5 / P6 | Evento rilevante senza impatto diretto | Dashboard e report |
Instradamento degli allarmi e canali
Alertmanager instrada gli allarmi in base a gravità, ambiente, componente, team e orario. Canali supportati:
- Jira Service Management (ticket, turni di reperibilità, escalation, presa in carico)
- E-mail e Microsoft Teams
- Webhook / REST verso piattaforme ITSM e di event management (ad es. ServiceNow, Jira, Splunk)
Gli allarmi correlati vengono raggruppati e deduplicati; le regole di dipendenza sopprimono gli allarmi conseguenti (ad es. allarmi di Content Server mentre il database è fuori servizio), in modo che venga notificata per prima la causa principale. Un allarme watchdog segnala un guasto del monitoraggio stesso.
Finestre di manutenzione
- Singole: un silence con ora di inizio e di fine, creato in anticipo o al momento.
- Ricorrenti: intervalli di tempo per giorno della settimana, orario e giorno del mese (ad es. ogni lunedì 06:00–08:00).
- Ambito: un intero ambiente, un server, un componente o singoli controlli.
Durante una finestra di manutenzione le notifiche sono soppresse, ma le metriche continuano a essere registrate. Gli allarmi ancora attivi al termine della finestra vengono notificati normalmente. Ogni finestra viene registrata con autore, motivo e durata.
Utenti e ruoli
| Ruolo | Permessi |
|---|---|
| Viewer | Visualizzare dashboard, allarmi e report |
| Editor | Creare e modificare dashboard, esplorare metriche e log, gestire le finestre di manutenzione |
| Admin | Utenti, team, sorgenti dati e configurazione |
Gli utenti accedono tramite single sign-on (Microsoft Entra ID, OTDS o Active Directory); i ruoli vengono assegnati in base ai gruppi della directory. L'autenticazione a più fattori è imposta dall'identity provider.
Dashboard e report
- Dashboard predefinite per ogni componente OpenText, personalizzabili per cliente e ruolo.
- Drill-down dalla panoramica dei servizi a componenti, nodi, processi, allarmi e log.
- Report periodici (disponibilità, prestazioni, capacità, SLA) in formato PDF, Excel o CSV, distribuiti via e-mail.
Conservazione dei dati
Metriche e log vengono conservati per almeno 12 mesi; il periodo di conservazione è configurabile per installazione e per sorgente di log.
Approfondimenti
- Regole di allarme di Prometheus
- Alertmanager
- Fondamenti di PromQL
- Utenti, team e permessi in Grafana
handel gmbh · Documentazione otwatch · Ultimo aggiornamento: 19 ottobre 2026