Guida alla configurazione del monitoraggio database

Prima di iniziare

I controlli Database non girano dalla rete di monitoraggio pubblica e distribuita di HostTracker come fa un controllo Http o Ping, quindi questo form non ha affatto una sezione Postazioni di monitoraggio. Al suo posto, ogni controllo si collega al tuo server dall'infrastruttura di controllo privata di HostTracker, usando due indirizzi sorgente fissi: 4.207.101.172 e 20.107.152.200 (Europa del Nord). Prima di salvare il monitor, aggiungi entrambi gli indirizzi alla allow list del firewall o del security group del tuo server database, e assicurati che il server accetti connessioni sulla sua porta da internet pubblico, o almeno da quei due indirizzi. Se la porta non è raggiungibile, ogni controllo fallisce con un errore di connessione indipendentemente da come è configurato il resto del monitor.

Configura l'account di monitoraggio prima di iniziare: crea un utente database dedicato al controllo, concedigli solo ciò di cui il controllo ha bisogno (tipicamente solo la possibilità di connettersi, più SELECT su qualunque tabella tocchi la tua query), ed evita di riutilizzare un account applicativo o amministrativo. Se la query che intendi eseguire modifica dati, concedi a quell'account l'accesso in scrittura solo alla tabella specifica coinvolta, nient'altro.

Database di destinazione

Tre campi identificano a cosa si connette il controllo, e stanno sopra le sezioni a scomparsa perché sono obbligatori:

• Tipo di server - un menu a tendina dei provider supportati: Microsoft SQL Server, Oracle, MySQL, PostgreSQL e Firebird.
• Server : Porta - l'hostname o l'IP del server database, e la sua porta. Cambiare il tipo di server compila automaticamente la porta predefinita convenzionale di quel provider (1433 per SQL Server, 1521 per Oracle, 3306 per MySQL, 5432 per PostgreSQL, 3050 per Firebird): devi sovrascriverla solo se il tuo server ascolta altrove.
• Database (oppure, per Oracle, Service e Instance name (SID) al posto suo) - il nome del database a cui connettersi. Per Oracle puoi fornire il service name, il SID, o entrambi, a seconda di come è configurato il tuo listener.

Sotto, un campo facoltativo Name ti permette di etichettare il monitor per avvisi, report e widget, utile quando hai più di un controllo database e devi distinguerli a colpo d'occhio.

Main Settings

Questo gruppo contiene la pianificazione e i due interruttori generici che ogni tipo di controllo condivide:

• Interval - ogni quanto gira il controllo, offerto da 10 minuti fino a 24 ore (10, 15, 30, 45 minuti, poi 1, 2, 4, 6, 12 e 24 ore), più un'alternativa a pianificazione cron per tempistiche meno regolari. I controlli Database non offrono gli intervalli sotto i 10 minuti che offrono altri tipi di controllo.
• Tags - etichette libere per raggruppare e filtrare i monitor altrove nella dashboard.
• Full Log - salva ogni singolo risultato di controllo invece dei soli riepiloghi aggregati, utile quando serve vedere tempi di risposta o valori esatti nel tempo invece della sola storia su/giù.
• Open Stats - rende condivisibile la pagina di statistiche e log di questo monitor, incluso con persone non autenticate.

Connection

Con la destinazione già impostata sopra, questa sezione copre come il controllo si autentica e come gestisce un tentativo di connessione fallito:

• DB user name e DB user password - le credenziali dell'account di monitoraggio descritto sopra. Entrambi sono facoltativi: lasciali vuoti se il tuo database consente una connessione trust o anonima da un indirizzo in allow list, come fanno alcune configurazioni interne.
• Il pannello stesso mostra i due indirizzi sorgente da cui vengono effettuati i controlli (4.207.101.172, 20.107.152.200) con un promemoria di includerli nella allow list del firewall del tuo database: è lo stesso requisito trattato in Prima di iniziare, ripetuto qui perché è esattamente dove vivono le credenziali.
• Retry on connect fail - un interruttore, attivo per impostazione predefinita, che riprova una volta il tentativo di connessione prima di segnare il controllo come fallito. Copre solo il passaggio di connessione stesso, non la query.

Response Validation

Questa è la decisione chiave in un controllo Database: se stai testando che la connessione funzioni, oppure che una query specifica si comporti ancora come previsto.

• Query - lasciala vuota e il controllo testa solo la connessione: si apre, si chiude, ed è tutto il controllo. Inserisci qualsiasi SQL che il tuo account di monitoraggio ha il permesso di eseguire, una SELECT, oppure un'istruzione che modifica dati come UPDATE, DELETE o INSERT, e il controllo la esegue a ogni interrogazione e può giudicarne il risultato.
• Query result (mostrato solo una volta inserita una query) - scegli Scalar value per leggere ciò che si trova nella prima colonna della prima riga restituita (la scelta naturale per una SELECT, o per una UPDATE/INSERT che usa una clausola OUTPUT), oppure Row count per leggere quante righe sono state interessate (la scelta naturale per una semplice UPDATE, DELETE o INSERT senza un proprio result set).
• Result verification - un confronto da applicare a quel valore: No verification (la query deve solo eseguire senza errori), Equal to, Not equal to, Greater than, Less than, In range, oppure Out of range. Le opzioni greater/less-than e range aggiungono uno o due campi numerici, con un interruttore incluso/escluso su ciascun confine dell'intervallo.
• Retry query on error - un interruttore, attivo per impostazione predefinita, che riprova una volta l'esecuzione della query se fallisce, separato dal retry a livello di connessione visto sopra.

Scegli solo connessione quando ti serve semplicemente sapere che il database è raggiungibile e accetta connessioni: intercetta le interruzioni totali. Scegli una query con verifica del risultato quando la sola raggiungibilità non basterebbe a cogliere il vero problema: una tabella che ha smesso di ricevere nuove righe, un conteggio memorizzato che esce da un intervallo normale, o un dato specifico che dovrebbe essere sempre presente.

Alert Subscriptions

Scegli quali contatti vengono avvisati su questo monitor e per quali eventi: Up, Down, e Repeat (un promemoria ripetuto mentre il controllo resta giù). Un unico interruttore abbona tutti i contatti a Up/Down in una volta, oppure puoi scegliere contatti ed eventi singoli dalla tabella sottostante.

Report Subscriptions

Separatamente dagli avvisi, scegli chi riceve report periodici di uptime e prestazioni per questo monitor, Daily, Weekly o Monthly, via email.

Esempio pratico

Osservare un database PostgreSQL in produzione da cui dipende un'applicazione: Server type PostgreSQL, Server : Port db.example.com:5432, Database myapp_prod. Un account dedicato di sola lettura viene inserito sotto Connection, ed entrambi gli IP sorgente vengono prima aggiunti al security group del database. Il campo Query contiene SELECT COUNT(*) FROM orders WHERE created_at > now() - interval '1 hour', Query result è Scalar value, e Result verification è Greater than con un limite di 0: se non è stato registrato nessun ordine nell'ultima ora, qualcosa a monte ha smesso di scrivere, e il controllo va Down anche se il database è raggiungibile. L'intervallo è 15 minuti, entrambi gli interruttori Retry restano attivi così un blip transitorio non genera un falso avviso, gli avvisi vanno all'abbonamento Up/Down dell'intero team, e un report settimanale va al proprietario dell'account.

Risoluzione dei problemi

• Ogni controllo fallisce con un errore di connessione. La causa più comune è un firewall che non è stato aperto per i due indirizzi sorgente di HostTracker: conferma che 4.207.101.172 e 20.107.152.200 siano in allow list, e che la porta stessa sia aperta verso di essi.
• La connessione riesce ma l'autenticazione fallisce. Controlla che DB user name e password siano corretti e che l'account abbia il permesso di connettersi al database indicato, non solo al server.
• Una query che funziona bene in uno strumento client qui non restituisce nulla. Una semplice UPDATE, DELETE o INSERT senza clausola OUTPUT non ha un result set da leggere come Scalar value: cambia Query result in Row count, oppure aggiungi una clausola OUTPUT se ti serve indietro il dato della riga.
• Result verification non scatta mai. Conferma che il confronto e i campi numerici corrispondano all'intervallo che ti aspetti: un confine impostato su escluso invece che incluso è un modo facile per far sì che un limite non scatti mai.
• Fallimenti singoli occasionali che sospetti siano transitori. Entrambi gli interruttori Retry sono attivi per impostazione predefinita e già riprovano una volta prima di far fallire il controllo: se i fallimenti restano frequenti, il problema è più probabilmente un vero problema di connettività o di query che rumore di fondo.

Correlati

• Monitoraggio query database - la pagina prodotto per questo tipo di controllo.
• Guida al monitoraggio CPU, RAM e disco - un altro controllo che gira dall'infrastruttura privata di HostTracker invece che dalla rete pubblica, utile accanto a un controllo database sullo stesso server.
• Guida al monitoraggio SNMP - per leggere valori direttamente dall'hardware di rete invece che da un database.
• Modalità asserzione e regole di validazione della risposta - il linguaggio di regole per la validazione della risposta usato altrove nei tipi di controllo di HostTracker.
• Tutte le funzionalità di monitoraggio HostTracker - vedi ogni tipo di controllo fianco a fianco.
• 503 Service Unavailable - lo stato che un sito restituisce quando il database dietro di esso smette di rispondere.
• Tutte le guide al monitoraggio - la guida alla configurazione per ogni altro tipo di controllo.