Tempo di attività
Monitoraggio

Xitoring supporta HTTP, HTTPS, Ping (ICMP), DNS, TCP, UDP, FTP, SMTP, IMAP e POP3. È possibile monitorare praticamente qualsiasi servizio connesso a Internet da un'unica dashboard.

Grazie agli intervalli di controllo di 1 minuto, riceverai un avviso immediatamente dopo il rilevamento di un'interruzione. I controlli di conferma effettuati da più nodi eliminano i falsi positivi prima dell'invio dell'avviso.

Xitoring gestisce oltre 15 nodi di monitoraggio distribuiti tra Nord America, Europa, Asia-Pacifico, Sud America e Medio Oriente. Ogni controllo viene eseguito simultaneamente da più sedi.

Il monitoraggio dell'uptime è pensato per i servizi accessibili al pubblico. Per i servizi interni, utilizza il nostro agente di monitoraggio dei server oppure il monitoraggio Heartbeat per i servizi protetti da firewall.

È possibile configurare le finestre di manutenzione per disattivare gli avvisi durante i periodi di inattività programmati. La percentuale di operatività viene adeguata in modo da escludere tali periodi dai calcoli dello SLA.

Sì. Xitoring offre la migrazione con un solo clic da Pingdom, Uptime.com e BetterStack. Tutte le configurazioni dei controlli, le impostazioni degli avvisi e i contatti vengono importati automaticamente.

Il monitoraggio dell'uptime secondo gli standard del settore viene eseguito a intervalli di un minuto da almeno tre aree geografiche diverse, per distinguere le interruzioni effettive dai semplici cali di rete locali. Raggiungere un uptime annuo del 99,99% comporta meno di 53 minuti di inattività all'anno; il 99,999% ne comporta poco più di cinque. Un monitoraggio efficace dell'uptime va oltre i semplici controlli ping per verificare che le risposte contengano il contenuto previsto, siano complete entro una latenza accettabile e presentino certificati TLS validi, individuando le interruzioni parziali e gli stati di degrado che i semplici controlli di disponibilità non rilevano.

La combinazione di protocolli è importante tanto quanto l'intervallo di controllo. I controlli HTTP e HTTPS sono il pilastro di qualsiasi endpoint esposto al web, con verifiche di corrispondenza dei contenuti per individuare il caso di errore in cui "la pagina restituisce un codice 200 ma in realtà non funziona". I controlli delle porte TCP coprono i servizi non HTTP come SSH, MySQL o le porte di applicazioni personalizzate. I controlli DNS confermano che i record vengono risolti correttamente dai resolver effettivamente utilizzati dagli utenti, individuando i casi di errore lento in cui un singolo resolver restituisce NXDOMAIN mentre tutto il resto sembra funzionare correttamente. I controlli del protocollo di posta (SMTP, IMAP, POP3) garantiscono il flusso delle e-mail transazionali. Una configurazione seria per il monitoraggio dell'uptime utilizza il tipo di controllo corretto per ogni livello di servizio, non l'HTTP per tutto.

Il monitoraggio multiregionale è la scelta configurativa più importante in assoluto. Un sistema di monitoraggio in esecuzione da un'unica postazione rischia di confondere un semplice picco di traffico sulla rete locale con un'interruzione effettiva del servizio, e gli avvisi risultano indistinguibili: nel giro di una settimana, il team di reperibilità impara a ignorare le notifiche. Effettuare controlli di conferma da almeno due regioni aggiuntive prima di generare un avviso elimina la stragrande maggioranza dei falsi positivi senza compromettere la velocità di rilevamento. Xitoring esegue ogni controllo da oltre 15 nodi di monitoraggio in Nord America, Europa, Asia-Pacifico, Sud America e Medio Oriente, e un avviso viene generato solo quando più regioni concordano sul fatto che il servizio è inattivo.

L'instradamento delle chiamate di emergenza è ciò che distingue uno strumento di monitoraggio da uno di allerta. L'utilità di un segnale generato da un controllo dipende interamente dal percorso che compie fino a raggiungere il tecnico in grado di risolvere il problema. Un monitoraggio efficace dell'uptime instrada gli avvisi in base a livelli di gravità (info → avviso → critico → avvisa tutti), rispetta la rotazione dei turni di reperibilità in modo che la persona giusta venga svegliata alle 3 del mattino, supporta la conferma e l'escalation quando il responsabile principale non risponde e si disattiva in modo pulito quando l'incidente è risolto. Le notifiche multicanale tramite SMS, notifiche push, Slack, Microsoft Teams, PagerDuty, OpsGenie e webhook garantiscono che nessun percorso di allerta sia un singolo punto di errore.

Le pagine di stato pubbliche trasformano i dati di monitoraggio dell'uptime in un elemento di fiducia rivolto ai clienti. Il fatto di ricavare la pagina di stato direttamente dagli stessi dati di monitoraggio che alimentano gli avvisi interni garantisce che i due non siano mai in disaccordo: i clienti vedono ciò che vede il personale di turno. Ospitare la pagina di stato su un dominio o sottodominio separato la mantiene accessibile anche quando il servizio principale è inattivo, e i team di approvvigionamento aziendali si aspettano sempre più spesso una cronologia dell'uptime su base mobile di 12 mesi. Xitoring pubblica sia pagine di stato pubbliche con il marchio dell'azienda per la comunicazione con i clienti, sia pagine di stato private protette da password per il monitoraggio interno degli SLA, utilizzando gli stessi dati di uptime, senza alcuna configurazione aggiuntiva.

Il monitoraggio dell'uptime è uno dei livelli di uno stack di osservabilità completo, non un sostituto degli altri. L'uptime controlla dall'esterno del perimetro: l'endpoint pubblico risponde? Il monitoraggio dei server controlla dall'interno del sistema operativo: qual è lo stato della CPU, della memoria, del disco e dei processi dell'host che ospita quell'endpoint? La maggior parte dei team di produzione ha bisogno che entrambi i livelli funzionino insieme: l'uptime ti dice quando un servizio è interrotto; il server ti dice perché, prima che gli utenti se ne accorgano. Xitoring esegue entrambi i livelli nello stesso prodotto con un motore di allerta unificato, in modo che un guasto al database e un controllo HTTP mancato passino attraverso le stesse regole di notifica e finiscano nella stessa cronologia degli incidenti.