Monitoraggio Server: Controlli del Carico CPU, RAM e Disco
Il monitoraggio server di HostTracker traccia il carico di CPU, RAM e disco rigido in tempo reale. Monitora il carico della CPU, l'utilizzo della memoria e il carico del disco, aiutando a ottimizzare le prestazioni del server e l'esperienza utente.
Individua i problemi di risorse prima che causino downtime
Monitoraggio del Carico CPU
HostTracker monitora l'utilizzo della CPU per mantenere i server efficienti e stabili. Traccia l'utilizzo della CPU del tuo server, individuando i problemi e avvisandoti in caso di picchi anomali. Il monitoraggio del carico CPU aiuta gli amministratori a mantenere i server funzionanti senza intoppi e a prevenire il downtime.
Andamento dell'Utilizzo della Memoria
HostTracker monitora l'utilizzo della memoria per aiutare a mantenere le prestazioni del server. Questa funzione traccia l'utilizzo della memoria e individua gli andamenti che potrebbero causare rallentamenti o crash. Report e avvisi aiutano gli amministratori a migliorare l'uso della memoria. Un buon monitoraggio della RAM significa applicazioni performanti e nessuna sorpresa dovuta a problemi di memoria.
Avvisi sullo Spazio su Disco
Il monitoraggio del disco rigido di HostTracker previene i problemi di archiviazione che influiscono sulle prestazioni del server. Questo servizio traccia l'utilizzo dello spazio su disco e avvisa gli amministratori per prevenire problemi come spazio insufficiente o guasti al disco. Monitoraggio e reportistica ti aiutano a tenere sotto controllo i problemi di spazio su disco, così il tuo server ha sempre spazio sufficiente per funzionare senza intoppi. Questo contribuisce all'affidabilità dei server e previene la perdita di dati dovuta a problemi di archiviazione.
Come i numeri arrivano a HostTracker - senza alcun agente sul tuo server
La maggior parte dei prodotti di monitoraggio server ti chiede di installare un agente: un processo in background con accesso a livello di sistema che gira permanentemente sulla tua macchina e invia dati in streaming. HostTracker deliberatamente non lo fa. È un servizio di monitoraggio esterno, e un controllo del carico del server funziona al contrario - il tuo server espone un piccolo endpoint di sola lettura che restituisce un singolo numero, e HostTracker lo interroga secondo la pianificazione che imposti tu.
Quell'inversione è l'intero progetto. Non c'è nessun demone da tenere in vita, nessun software con privilegi che non hai scritto tu in esecuzione in produzione, nessuna credenziale consegnata a terzi e nessuna porta di gestione in entrata. Ciò che esponi è un URL che non accetta comandi, non cambia nulla e restituisce un solo valore.
Il collettore PHP
Uno script già pronto per un host Linux o Unix che esegue già PHP. Depositalo in una directory servita dal web e punta il monitor verso quell'URL di base. Legge localmente i valori di CPU, memoria e disco della macchina stessa e risponde con il numero.
Il collettore ASP.NET
L'equivalente per Windows, per un host che esegue IIS. Stessa idea, con in più l'accesso a qualsiasi contatore di prestazioni di Windows per categoria, nome e istanza - così tutto ciò che Performance Monitor ti mostra localmente può essere monitorato da remoto.
Il tuo endpoint personale
Punta il monitor verso qualsiasi URL desideri e rispondi con un piccolo oggetto JSON. Una decina di righe in qualsiasi linguaggio, nulla sul tuo server che tu non abbia scritto, e decidi tu esattamente quali numeri vengono esposti. Questa è l'opzione preferita dalla maggior parte dei team di ingegneria.
Nulla viene mai inviato in push alla tua macchina. Il collettore lo distribuisci tu, quando vuoi, e HostTracker si limita a inviargli richieste. Se lo rimuovi, il monitoraggio si interrompe - non ha altro modo per entrare.
Cosa può misurare un monitor server
Ogni monitor osserva un solo valore, quindi un server tipico finisce per averne tre o quattro - e ciascuno ha la propria soglia, la propria cronologia e il proprio avviso. I tipi di valore sono:
| Metrica | Riportata come | A cosa serve |
|---|---|---|
| CPU | Percentuale di utilizzo | Saturazione prolungata, processi fuori controllo, istanze sottodimensionate, il carico aggiunto da un rilascio |
| RAM | Percentuale di utilizzo | Memory leak, consumo crescente tra un riavvio e l'altro, la pressione che precede una terminazione per esaurimento memoria |
| Disco | Percentuale di utilizzo per un percorso o un'unità che indichi | Log, upload e backup che riempiono un volume - l'interruzione più lenta e più prevedibile che esista |
| Porta TCP | Tempo di connessione in millisecondi | Se un servizio sulla macchina accetta ancora connessioni, e quanto velocemente |
| SQL Server | Tempo di connessione in millisecondi | Raggiungibilità e autenticazione del database dal punto di vista del server stesso |
| MySQL | Tempo di connessione in millisecondi | Lo stesso, per MySQL |
| Contatore prestazioni Windows | Qualsiasi cosa riporti il contatore | Tutto ciò che Performance Monitor espone, per categoria, nome del contatore e istanza - lunghezza delle code, handle, valori per processo |
Se ciò di cui hai bisogno è il database dietro il server piuttosto che il suo tempo di connessione, si tratta di un controllo diverso e più approfondito: un monitor delle query al database si connette, si autentica, esegue una query che scrivi tu e confronta il valore restituito con una soglia.
Scrivere il tuo collettore personalizzato
Il contratto è deliberatamente banale, perché il punto è che tu possa leggerlo in una sola seduta e implementarlo in qualsiasi linguaggio già usato dal tuo team. HostTracker interroga il tuo URL; il tuo endpoint risponde con un oggetto JSON che contiene il valore:
{ "v": 42.7 }Questa è l'intera superficie richiesta. Due membri opzionali rendono il risultato più utile:
e contiene una stringa di errore quando il valore non è stato possibile leggerlo in
quell'occasione - un risultato molto migliore che riportare uno zero fuorviante - e vs
contiene una tua stringa di versione, che compare nel risultato così puoi sapere quale build del
collettore ha risposto.
{ "v": 91.4, "e": "", "vs": "collector-2.1" }Poiché scrivi tu il lettore, non sei limitato a ciò che un agente generico sa raccogliere. Profondità della coda, tasso di successo della cache, numero di job in attesa, età del record non elaborato più vecchio, inode liberi, dimensione di una directory che non deve mai crescere - qualsiasi cosa tu possa esprimere come numero diventa un valore monitorato con soglie, cronologia e avvisi collegati.
Proteggi l'endpoint. Deve essere raggiungibile dai checker che lo interrogano, quindi trattalo come qualsiasi altro URL pubblico: mettilo su un percorso non indovinabile, tienilo di sola lettura, ed esponi solo i numeri che sei disposto a far leggere. Non accetta parametri che cambiano qualcosa, il che limita l'esposizione a un solo valore.
Impostare una soglia che abbia senso
Un numero grezzo è un dato; una soglia è ciò che lo trasforma in monitoraggio. Ogni monitor ha una condizione e uno o due limiti, così puoi esprimere la forma di "sbagliato" invece di un semplice tetto massimo:
- maggiore di o minore di un limite - la forma quotidiana. CPU sopra 90. Disco libero sotto 10.
- uguale a o diverso da un limite - per un valore che è in realtà uno stato: un numero di worker che deve restare a 4, un flag che deve restare a 0.
- dentro un intervallo o fuori da un intervallo, con due limiti - la forma giusta per qualsiasi cosa con una fascia sana invece di un massimo sano. Una coda che sta normalmente tra 10 e 500 ti dice qualcosa quando legge 0, e qualcos'altro quando legge 5.000.
- nessuna condizione - raccogli e visualizza in grafico il valore senza mai far fallire il controllo. Utile per una metrica su cui vuoi cronologia prima di sapere come appare "male".
Il debounce è l'impostazione che ferma il rumore
Accanto alla soglia c'è un conteggio di controlli consecutivi in sovraccarico prima che il monitor passi a down, regolabile da zero fino a venti. È la manopola più preziosa della pagina ed è anche quella più spesso lasciata invariata. Un server all'95% di CPU per un singolo campione durante un backup notturno non è un incidente. Un server al 95% per cinque controlli consecutivi lo è. Imposta il conteggio in base a quanto tempo il tuo carico di lavoro può legittimamente essere occupato, e un'intera categoria di falsi allarmi delle 3 del mattino sparisce senza che la tua soglia diventi meno rigorosa.
Questo conta più qui che su un controllo web, perché una metrica server viene letta da un'unica fonte autorevole - il tuo stesso collettore - anziché confermata su più postazioni indipendenti come avviene per un controllo di disponibilità. Non c'è una seconda opinione a mediare un picco momentaneo, quindi è il conteggio del debounce a svolgere quel ruolo.
Cosa ti avvisa ciascuna metrica
Le tre metriche principali falliscono in modi genuinamente diversi, e sapere quale stai osservando ti dice quanto tempo hai a disposizione.
| Metrica | Come arriva il guasto | Quanto preavviso ottieni |
|---|---|---|
| CPU | Nulla si rompe. Tutto rallenta - ogni richiesta, ogni query, ogni job in background - e il sito si degrada molto prima di crollare. | Di solito abbondante, se stai osservando. Una salita prolungata è visibile per ore o giorni prima di diventare visibile agli utenti. |
| RAM | Improvviso e violento. Le applicazioni vengono terminate dal sistema operativo per recuperare memoria, si riavviano, e vengono terminate di nuovo - producendo esattamente l'interruzione intermittente e non riproducibile più difficile da diagnosticare. | Poco, alla fine. Ma la lenta salita di un memory leak tra un riavvio e l'altro è uno dei segnali più leggibili nel monitoraggio, se la cronologia esiste. |
| Disco | Tutto in una volta. I log smettono di scrivere, il database rifiuta le scritture, le sessioni falliscono, i file temporanei non possono essere creati - e la causa è invisibile dai messaggi di errore dell'applicazione stessa. | Il più preavviso di tutti, e il più spesso ignorato. Un volume che si riempie a velocità costante è prevedibile con giorni di anticipo. |
| Tempo di connessione | Una dipendenza da cui il server dipende è diventata lenta o irraggiungibile, prima che ciò emerga come un'interruzione completa. | Spesso il primo segnale che qualcosa a valle non va. |
Il disco merita la sua reputazione di classica interruzione evitabile. È l'unico guasto che un monitor con una soglia e una settimana di cronologia riuscirà sempre a intercettare per primo, ed è anche quello più imbarazzante da spiegare in seguito.
Leggi l'andamento, non solo l'avviso
Ogni lettura viene salvata, così ogni monitor server ha un proprio grafico del valore nel tempo con media, minimo e massimo per la finestra che stai osservando. Le percentuali vengono rappresentate come percentuali e i tempi di connessione in millisecondi, così un monitor CPU e un monitor di latenza del database si leggono ciascuno nel modo che ti aspetti.
L'avviso ti dice che qualcosa ha superato una linea; il grafico ti dice le due cose di cui hai davvero bisogno subito dopo. È una novità? - un picco che sembra allarmante isolatamente è spesso lo stesso picco che si verifica ogni martedì alle 2 del mattino da un anno. E verso dove sta andando? - un valore di memoria che sale costantemente tra un riavvio e l'altro è un leak, qualunque sia il suo valore attuale, e un disco che sale del due percento a settimana ha una data associata.
Quella seconda domanda è l'uso del monitoraggio server per la pianificazione della capacità, ed è il motivo per iniziare a raccogliere una metrica prima ancora di sapere quale soglia impostarle. Puoi aggiungere la soglia tra un mese, una volta che la cronologia ti avrà detto come appare la normalità. La cronologia che non hai raccolto è quella che non puoi recuperare.
Il monitoraggio server e il monitoraggio uptime rispondono a domande diverse
Sono complementari, non alternativi, e la distinzione è abbastanza netta da valere la pena dichiararla apertamente.
| Monitoraggio uptime | Monitoraggio server | |
|---|---|---|
| La domanda a cui risponde | Un visitatore può raggiungere il sito in questo momento? | La macchina sottostante è abbastanza sana da continuare a rispondere? |
| Da dove guarda | Dall'esterno - oltre 300 postazioni in 158 città | Dall'interno - un valore letto sulla macchina stessa |
| Tempistica tipica | Ti avvisa nel momento del guasto | Ti avvisa prima del guasto, se imposti la soglia sotto il baratro |
| Controllo dei falsi allarmi | Un'osservazione di fallimento viene ricontrollata da altre postazioni e confermata da un quorum | Un'unica lettura autorevole, con un conteggio di sovraccarichi consecutivi come debounce |
| Individua un memory leak | No - finché non fa infine crashare qualcosa | Sì - come andamento, settimane prima |
| Individua un guasto di instradamento tra i tuoi utenti e te | Sì | No - la macchina è perfettamente serena |
Usarne solo uno lascia un vero divario in ciascuna direzione. La combinazione su cui si stabilizzano la maggior parte degli account è un controllo di disponibilità a un minuto da più postazioni più una manciata di monitor server su CPU, memoria e il volume più a rischio di riempirsi.
SNMP, per l'hardware che non eseguirà mai un collettore
Router, switch, firewall, gruppi di continuità e stampanti non possono ospitare uno script, ma quasi tutti parlano già SNMP. Un controllo SNMP separato legge un valore numerico direttamente dal dispositivo tramite OID - contatori di interfaccia, temperatura, carico, uptime, carica della batteria - su SNMP v1, v2c o v3, incluso v3 con autenticazione e privacy così le credenziali non vengono inviate in chiaro.
Per essere onesti su dove si trova oggi questa funzionalità: un controllo SNMP legge e registra il valore riportato dal dispositivo. L'avviso basato su soglia su un valore SNMP non è ancora disponibile - quando hai bisogno che un numero generi davvero un incidente, usa un monitor di carico server contro un collettore, che ha il modello completo di condizioni e debounce descritto sopra.
Configurare il monitoraggio server
- Decidi cosa esporre. Se il tuo server esegue già PHP o IIS, il collettore già pronto corrispondente è la strada più veloce; in caso contrario scrivi tu stesso l'endpoint - deve restituire un numero.
- Distribuiscilo sul server che vuoi monitorare e verifica di poterlo interrogare tu stesso. Mettilo su un percorso non indovinabile. Se la macchina è nuova, il controllo gratuito della porta TCP e il test ping gratuito sono un modo rapido per confermare che sia raggiungibile dal mondo esterno prima di procedere oltre - senza bisogno di accesso.
- Aggiungi un monitor di tipo Monitor CPU, RAM, HDD, scegli quale valore legge, e dagli l'URL del collettore. Per un monitor del disco, indica il percorso o l'unità; per un monitor del tempo di connessione al database, fornisci i dettagli di connessione che il collettore deve utilizzare.
- Imposta la condizione e i limiti - e imposta deliberatamente il conteggio dei sovraccarichi prima del down invece di lasciarlo al valore predefinito. È l'impostazione che decide se il monitor sarà utile o ignorato.
- Scegli un intervallo, da un minuto a 24 ore. Un minuto è adatto a una macchina che esegue qualcosa di business-critical; 5 o 10 minuti sono più che sufficienti per un andamento come l'uso del disco.
- Ripeti per ogni valore rilevante su quell'host - CPU, memoria e il volume più a rischio di riempirsi sono un buon set di partenza - poi aggiungi i contatti da avvisare.
- Lascialo girare una settimana prima di regolare qualcosa. La prima settimana di cronologia è ciò che ti dice se la tua soglia è corretta, ed è una prova molto migliore di un'ipotesi fatta il primo giorno.
Limiti che vale la pena conoscere
- Il collettore deve essere raggiungibile. Un host senza alcun accesso in entrata non può essere interrogato. Ciò che deve essere esposto è un unico URL di sola lettura, non una porta di gestione - ma deve comunque essere esposto.
- Un monitor osserva un solo valore. CPU, memoria e disco sono tre monitor, ciascuno con la propria soglia e la propria cronologia. È questo che rende l'avviso preciso, e significa anche che un server impegnato occupa più slot monitor.
- I contatori di prestazioni Windows richiedono il collettore ASP.NET. La tripletta categoria / nome / istanza viene letta localmente da quel collettore; un host PHP riporta invece CPU, memoria, disco e tempi di connessione.
- Non c'è conferma multi-postazione. A differenza di un controllo di disponibilità, una metrica server proviene da un'unica fonte autorevole, quindi una singola lettura anomala è una lettura reale. Il conteggio dei sovraccarichi consecutivi è lo strumento per questo, e vale la pena impostarlo.
- Riporta ciò che il collettore riporta. Se il tuo endpoint personalizzato ha un bug, il monitor avvisa fedelmente sul numero sbagliato - motivo per cui il membro di errore opzionale nella risposta conta: riporta un errore invece di uno zero.
- Nessun contatore di banda di rete. I valori disponibili sono CPU, memoria, utilizzo del disco, tempi di connessione e contatori di prestazioni Windows; la banda non è tra questi. Per un dispositivo che riporta la banda tramite SNMP, un controllo SNMP può leggerla e rappresentarla in grafico.
Domande frequenti
Il monitoraggio server è il tracciamento continuo dell'utilizzo delle risorse principali del tuo server - carico CPU, utilizzo della RAM (memoria) e carico dell'HDD (disco) - così puoi vedere come si sta effettivamente comportando la tua infrastruttura, non solo se il sito web che gira sopra di essa risponde. Il monitoraggio server di HostTracker controlla queste tre metriche e segnala andamenti e picchi nel tempo, il che è importante perché l'esaurimento delle risorse è una delle cause principali più comuni dietro prestazioni lente, crash e downtime vero e proprio. Un server può essere tecnicamente "attivo" ed essere comunque a un passo dal guasto se l'utilizzo della CPU è al massimo, la memoria è quasi esaurita o lo spazio su disco è criticamente basso - nessuno di questi problemi verrebbe necessariamente rivelato da un semplice controllo di disponibilità finché non causa effettivamente un'interruzione visibile.
Un server può rimanere raggiungibile e tecnicamente online pur funzionando pericolosamente vicino ai propri limiti di risorse, il che significa che un elevato utilizzo di CPU o RAM è spesso un segnale di allarme precoce di un problema, più che il problema stesso. Un carico CPU elevato e prolungato rallenta ogni richiesta gestita dal server, peggiorando l'esperienza di ogni visitatore anche se il sito non va mai completamente giù. La pressione sulla memoria è ancora più pericolosa - man mano che l'utilizzo della RAM si avvicina alla capacità massima, le applicazioni possono iniziare a bloccarsi, riavviarsi o essere terminate dal sistema operativo per liberare memoria, il che spesso provoca interruzioni intermittenti e difficili da diagnosticare, che sembrano anomalie casuali piuttosto che un guasto evidente. Individuare un utilizzo elevato di CPU o RAM tramite il monitoraggio server, prima che degeneri in un crash, dà agli amministratori il tempo di indagare e aggiungere capacità in modo proattivo.
Quando il monitoraggio di CPU, RAM o carico del disco rileva un'attività anomala - un picco prolungato, la memoria che si avvicina alla capacità massima o lo spazio su disco in esaurimento - HostTracker invia una notifica tramite uno dei 9 canali di avviso che hai configurato, tra cui email, SMS, chiamata vocale, webhook, Slack e app di messaggistica come Telegram, Discord e Viber. Questo significa che il responsabile dell'infrastruttura del server viene informato direttamente di un problema di risorse in sviluppo, invece di scoprirlo solo dopo che ha già causato un rallentamento o un crash notato dai clienti. Poiché report e avvisi vengono generati automaticamente dai dati monitorati, gli amministratori ottengono uno storico documentato degli andamenti delle risorse insieme alla notifica in tempo reale, il che aiuta a distinguere un picco isolato da un vero problema di capacità che richiede una soluzione a lungo termine.
Il monitoraggio uptime risponde a una domanda più circoscritta: il sito web o il servizio è raggiungibile e risponde in questo momento. Il monitoraggio server guarda sotto quella superficie, all'infrastruttura che fa effettivamente funzionare il sito - carico CPU, utilizzo della memoria e spazio su disco - che sono spesso la causa principale di un guasto di uptime, e non un problema separato e scollegato. Un server con poca memoria o spazio su disco può comunque superare un controllo di uptime per un po', prima di andare in crash o rallentare drasticamente, quindi affidarsi solo al monitoraggio uptime significa scoprire il problema solo dopo che è già diventato un'interruzione. Combinare entrambi offre un quadro più completo: il monitoraggio uptime conferma che il sito è attualmente raggiungibile, mentre il monitoraggio server traccia gli andamenti sottostanti delle risorse che indicano se è probabile che rimanga tale.
La frequenza dei controlli è configurabile in base alla rapidità con cui hai bisogno di conoscere un problema di risorse in sviluppo. I piani a pagamento di HostTracker supportano intervalli di monitoraggio fino a una volta al minuto, utile per i server che eseguono applicazioni business-critical dove un picco di risorse deve essere individuato e affrontato rapidamente. I server meno critici o con traffico più basso possono usare un intervallo più lungo, e il piano gratuito permanente controlla due monitor ogni 30 minuti, il che è spesso sufficiente per individuare un andamento prolungato, come lo spazio su disco che si riempie gradualmente nell'arco di giorni, anche se non riuscirebbe a rilevare un picco di CPU molto breve. Una prova gratuita di 30 giorni con tutte le funzionalità e senza carta di credito ti permette di provare intervalli di controllo più rapidi e vedere quanto dettaglio offrono i dati risultanti, prima di scegliere un piano.
No - non c'è nessun agente HostTracker da installare, nessun demone da tenere in esecuzione e nessuna credenziale da consegnare. Un controllo del carico del server funziona al contrario: il tuo server espone un piccolo endpoint di sola lettura che restituisce un singolo numero, e HostTracker lo interroga secondo la pianificazione che imposti tu. Hai tre modi per fornirlo. Due sono script collettori già pronti che depositi su un server che gestisci già - uno per PHP su Linux o Unix, uno per ASP.NET su IIS - e il terzo consiste nello scrivere tu stesso l'endpoint, il che richiede una decina di righe in qualsiasi linguaggio: leggi il valore come preferisci e rispondi con un piccolo oggetto JSON che lo contiene. Questa terza opzione è quella che molti team preferiscono, perché significa che sulla loro macchina non gira mai nulla che non abbiano scritto loro stessi, e decidono esattamente quali numeri vengono esposti. Nulla viene mai inviato automaticamente al tuo server, e HostTracker non apre mai una sessione di gestione su di esso.
L'endpoint del collettore deve essere raggiungibile dai checker di HostTracker, quindi un server dietro un firewall senza alcun accesso in entrata non può essere interrogato direttamente. In pratica è un ostacolo più piccolo di quanto sembri, perché ciò che deve essere esposto è un singolo URL di sola lettura che restituisce un numero - non SSH, non una porta di gestione, non un protocollo di monitoraggio. Gli approcci abituali sono pubblicare l'endpoint su un percorso non indovinabile, limitarlo agli indirizzi che lo interrogano, oppure ospitarlo su una macchina della stessa rete già esposta a internet e farla riportare per conto dell'host privato. Qualunque cosa tu scelga, l'esposizione è deliberatamente minima: l'endpoint non accetta comandi, non cambia nulla e restituisce un singolo numero. È una conversazione sulla sicurezza molto diversa dall'installare un agente di terze parti con accesso a livello di sistema, ed è esattamente per questo che il controllo è progettato così.
Il monitoraggio del carico del server - controlli di CPU, RAM e HDD - è uno dei 13 tipi di controllo disponibili nel prodotto HostTracker, e il piano gratuito permanente ti permette di monitorare due server o siti senza costi, con controlli ogni 30 minuti. HostTracker nel suo complesso non è un prodotto solo gratuito - è un servizio di monitoraggio a pagamento con un livello gratuito incluso - quindi il piano gratuito è ideale per provare il monitoraggio server su un paio di macchine o come opzione leggera per progetti più piccoli, non come offerta principale. Per monitorare più server, intervalli di controllo più brevi o infrastrutture business-critical dove il rilevamento rapido è importante, i piani a pagamento partono da circa 5$ al mese, e una prova gratuita di 30 giorni con tutte le funzionalità e senza carta di credito ti permette di testare gli intervalli più rapidi prima di decidere.
Continua a esplorare il monitoraggio di HostTracker
Monitora le connessioni al database e i risultati delle query
Esegui controlli periodici delle connessioni e convalida i risultati delle query su MySQL, PostgreSQL, SQL Server e altri, così un problema silenzioso del database non passa mai inosservato.
Scopri tutte le funzionalità di monitoraggio di HostTracker
Confronta tutti gli 8 tipi di monitoraggio fianco a fianco e combina i controlli più adatti al tuo sito.
Individua il sovraccarico del server prima che ti metta fuori gioco
Inizia una prova gratuita e ricevi un avviso quando il carico di CPU, RAM o disco supera le tue soglie.
Fa parte del servizio di monitoraggio di siti web di HostTracker.