Quale sarebbe l'architettura per un servizio di monitoraggio basato sul polling?

Question

Quale sarebbe l'architettura per un servizio di monitoraggio basato sul polling?

#1 da (1 voti)

0

Ho una lista di 75000 siti web che devono essere monitorati per i tempi di attività. Il monitoraggio dei siti Web comporta l'esecuzione di una richiesta HTTP per il sito Web ogni minuto e il sito Web viene definito "attivo" o "inattivo" in base al fatto che è possibile eseguire correttamente una richiesta HTTP e ricevere una risposta HTTP. Questo tipo di "polling" è l'unica cosa che posso fare, perché non ho il controllo degli host che gestiscono i siti web.

Inizialmente, pensavo di avere un paio di nodi, ognuno dei quali avrebbe il compito di monitorare un sottoinsieme dei siti web. Ogni nodo eseguirà un programma progettato in questo modo:

isServerUp(httpClient, url) {
    time = Time.now()

    try {
        httpClient.get(url)
        status = true
    }
    catch (e) {
        status = false
    }

    // do some other stuff, like saving the
    // status to a database.
}

websiteChecker(url) {
    httpClient = HttpClient()
    t = Thread(isServerUp, httpClient, url)

    while (true) {
        t.run()
        sleep(60)
    }
}

main() {
    for (website in websiteList) {
        t = Thread(websiteChecker, url)
        t.run()
    }
}

Fondamentalmente, il programma crea i thread "websiteChecker" per ogni sito web da controllare. Ognuno di questi thread "websiteChecker" genera un nuovo thread "isServerUp", che controlla se il sito web è attivo.

Tuttavia, tale architettura funzionerebbe a malapena, in quanto l'enorme numero di thread "websiteChecker" causerebbe un elevato consumo di memoria e un conflitto estremamente elevato di risorse.

Come posso progettare un'architettura che funzioni bene in questo scenario e sia anche scalabile?

architecture polling scalability monitoring

posta user2064000 14.02.2018 - 15:41

fonte

1 risposta

Leggi altre domande sui tag architecture polling scalability monitoring

REST API Design per ottenere giorni senza risorse Come inserire il codice in un metodo in una classe derivata [duplicato]

score 1 · Answer 1

Quando lavori con una grande coda di siti come questa, ti consigliamo una combinazione di I / O non bloccanti e una coda di thread finita. Scoprirai che il numero esatto di thread che sarebbe ottimale è una funzione del numero di core nella tua CPU. I test ti permetteranno di trovare il rapporto ottimale. Anche in questo caso, potresti dover distribuire il lavoro su più macchine.

Detto questo, quello che ti serve è:

Una coda di lavoro principale protetta da thread
Più thread per elaborare le attività
Un meccanismo per la comunicazione asincrona
Un modo per sospendere le attività finché non ottengono una risposta o un timeout

A seconda dell'implementazione, i dettagli saranno leggermente diversi. Ad esempio, le librerie NIO di Java hanno un modo diverso di gestire l'interazione rispetto alle chiamate% C_de% / async .

Architettonicamente, ciò che sta accadendo è qualcosa del genere:

Address pulled off queue
  ^       |
  |  Task Starts
  |       |   \
  |       |    Request started
  |       v            |
  |_More capacity?   Passively wait for response or timeout event
       ^               |
       |           Determine success and report
       |        ___/
       Task Ends

Non potrai generare un thread per URL. La maggior parte dei sistemi operativi ha un limite al numero di thread che possono essere generati per utente, e quindi c'è il limite pratico in cui il processore impiega più tempo per il cambio di contesto di quello che fa il lavoro.

Puoi efficace fare migliaia di connessioni allo stesso tempo quando non stai bloccando. I tuoi compiti sono in modalità standby fino a quando l'evento che fornisce i dati li riattiva.

Passare attraverso 75.000 siti web ogni minuto sarà una sfida. Dovrai o meno eseguire la richiesta meno spesso o distribuire il lavoro tra più client di polling che si coordinano tra loro. In pratica, il polling una volta ogni 15 minuti è probabilmente sufficiente per il 90% dei bisogni delle persone.