I downtime sono una parte importante per la creazione corretta e l’interpretazione di un report sugli SLA. Mentre i downtime e i cambiamenti di stato possono essere pianificati, i cambiamenti inaspettati devono essere fissati e corretti retroattivamente.
Vi darò un esempio pratico per spiegare meglio il significato:
Pensate a un Internet Service Provider che ha definito certi SLA con i propri clienti, ad esempio il 99.8% di disponibilità del servizio. L’ISP è sicuro di fornire un servizio eccellente al suo cliente e di raggiungere la disponibilità concordata. Ad un certo punto, però, la connessione internet del cliente viene interrotta e la disponibilità impattata. Ma l’interruzione non è stata causata da un disservizio, ma da attività svolte da terze parti come per esempio, lavori stradali, che hanno accidentalmente danneggiato i cavi in fibra. In questo caso, l’interruzione non dovrebbe influenzare il calcolo dello SLA, perché l’interruzione non è da attribuire all’Internet Service Provider. Per offrire dati con maggior trasparenza ai propri clienti, l’ISP dovrebbe avere la possibilità di escludere i downtime dal report e aggiungere alcune informazioni per la tracciabilità future.
Il nostro approccio per i problemi di questo tipo non è quello di correggere il report, ma di correggere direttamente i log e successivamente calcolare il report sugli SLA con i dati corretti.
L’Event Correction è diviso in due diverse parti: la creazione di Event Correction e la sua applicazione sui log.
Creare una Event Correction richiede informazioni rilevanti come:
L’idea è di definire un periodo, durante il quale lo status viene sostituito con un nuovo status, o un downtime viene conseguentemente definite oppure rimosso.
Le Correzioni sugli eventi (Event Correction) possono essere create utilizzando il plug-in dedicato, o utilizzando i links sulla pagina per calcolare la disponibilità di Host/Servizi nel modulo Thruk.
Una volta che esistono delle event correction, vengono inserite all’interno del log aggiungendo nuove informazioni, o sostituendo le informazioni errate mantenendo comunque la struttura corretta dei log. In questo modo, i report possono essere generati sia con i dati originali sia con quelli corretti.
Per poter visualizzare o gestire queste correzioni sugli eventi è necessario definire le configurazioni corrispondenti sul profilo utente.