È possibile innanzitutto memorizzare lo stato di tutti i sistemi connessi a un determinato destinatario, ad es.
[ {
recipient: '[email protected]',
situation: [
{ 'system': 'alnitak',
'failed': [
{ 'subsystem': 'http',
'failures': [
{ 'code': '80701',
'text': 'SYN unacknowledged',
'timestamp': 1375189804,
'alertno': 1,
'nextalert: 1375193404 },
...
},
...
]
},
...
]
},
...
]
Ogni cinque minuti salvi il blocco esistente di ciascun destinatario e ne generi uno nuovo.
Ora hai bisogno di una funzione che gestirà due di questi blocchi e dividi tutti gli elementi in tre blocchi con la stessa struttura del "blocco di stato":
- presente solo in una nuova: aggiungi un nuovo problema al blocco "NUOVE EMISSIONI".
- presente solo in vecchi: aggiungi il vecchio problema al blocco "RISOLTO".
- presente in entrambi: controlla
nextalert e alertno . Se nextalert ha non scaduto, non fare nulla. Se ha scaduto, l'elemento viene aggiunto al blocco "UNRESOLVED", alertno viene incrementato e il suo valore viene utilizzato per decidere quanto aggiungere al timestamp corrente per ottenere il nuovo valore per nextalert .
L'importante è che non faccia nulla nel ciclo precedente. Questo assicura che se non accade nulla, non verrà inviato alcun avviso anche se ci sono problemi in corso.
Questa architettura consente piccole modifiche, ad esempio: se ci sono nessun problema nuovo o risolto (questo è importante, perché entrambi potrebbero richiedere decisioni tempestive, come ad esempio un cliente di un servizio di nuovo in linea), puoi eseguire un'ulteriore passeggiata dei blocchi di stato e approssimare l'ora di "prossimo avviso" nel nuovo blocco al multiplo più vicino di, ad esempio, 15 minuti, prima chiama la funzione che costruisce il blocco non risolto.
Questo ha l'effetto di posticipare tutti gli avvisi in modo che si uniscano ad intervalli di 15 minuti. In questo esempio:
10:05 alert 1 goes out, and is scheduled for 15 minutes from now: 10:20
10:10 alert 2 goes out, and is scheduled for 15 minutes from now: 10:25
10:15 nothing happens
10:20 alert 1 is sent ("Still unresolved") and rescheduled for 10:50
10:25 alert 2 is sent ("Still unresolved") and rescheduled for 10:55
ciò che accadrebbe è che entrambi gli avvisi verrebbero inviati al momento esatto la prima volta, quindi entrambi verranno inviati insieme alle 10:30, inviando quindi tre e-mail anziché quattro. In questo esempio, la riprogrammazione dell'avviso 1 è ritardata di 10 minuti.
(È possibile riprodurre altri trucchi di modifica del tempo). Avviso : se snooze il valore nextalert , ricorda che questo valore è diverso non conta quando si confrontano blocchi di stato vecchi e nuovi.
Ora che abbiamo i tre blocchi (eventualmente vuoti), una terza funzione può comporre un'e-mail camminando sui tre blocchi e spargendo del testo - o semplicemente ritornando se tutti e tre i blocchi sono vuoti:
Dear mr. Serni,
The following issues are now marked SOLVED:
System: albutain
Reason: fail to respond to PING
Alert : 27 Jul 2013, 20:27:33 UTC
The following issues are NEW and require your attention:
...
The following issues are still unresolved:
...
Forse, se tutti e tre i blocchi sono "{}" per un determinato periodo, è possibile che si desideri inviare un'e-mail allo stesso tempo, solo per ricordare che il sistema di controllo è vivo e vegeto. Una riga dell'oggetto potrebbe essere sufficiente. Questa email periodica potrebbe essere inviata anche per gestire problemi irrisolti, che altrimenti verrebbero inviati solo dopo la risoluzione di un problema o la creazione di uno nuovo, e "far morire di fame" altrimenti.