Qual è una buona pratica di registrazione per le attività distribuite?

Ho la seguente impostazione:

Creare più lavoratori, eseguire un calcolo e terminarli al termine del calcolo.

Quindi, ogni volta che verrà eseguita un'istanza diversa, quindi ogni host avrà un proprio file di registro, questo comporterà un enorme elenco di file.

È una buona pratica? In caso contrario, quale sarebbe un modo migliore per registrare l'elaborazione delle attività in questo particolare caso d'uso?

PS: la mia infrastruttura è senza server. Quindi, per ora, sto accedendo a (AWS) CloudWatch. Tuttavia, rispondi alla domanda indipendentemente da AWS e adatta il più possibile un'installazione senza server.

"Serverless" significa principalmente che hai microservizi relativamente semplici, generalmente solo una piccola webapp o una singola funzione che viene automaticamente connessa a un frontend REST. Si applicano gli stessi concetti che utilizzeresti per un servizio web più tradizionale: di solito un mix di syslog remoti e scrittori ElasticSearch.

Il syslog in rete o remoto esiste da molto tempo e ha un set di strumenti abbastanza robusto. Dovresti eseguire i server syslog centrali ma il protocollo è molto semplice e ci sono librerie client pure in ogni lingua che puoi usare per inviare i log. Un problema comune con il syslog remoto è che è stato tradizionalmente basato su UDP. Ciò significa che, sotto un carico pesante, alcuni messaggi di registro potrebbero andare persi. Questa potrebbe essere una buona cosa, aiutando ad evitare un sovraccarico a cascata, ma è qualcosa di cui essere consapevoli. Alcuni demoni syslog più recenti supportano anche un protocollo basato su TCP, ma il supporto client è meno unificato, quindi fai solo le tue ricerche.

Più recente ma molto popolare è l'accesso a ElasticSearch. Ciò è utile soprattutto a causa della dashboard di Kibana e del Logstash Takelit (spesso chiamato ELK, ElasticSearch + Logstash + Kibana). Amazon offre anche un'opzione ElasticSearch ospitata, che rende un po 'più facile iniziare. ES utilizza un'API REST relativamente semplice, quindi qualsiasi lingua con un client HTTP (leggi: tutti) dovrebbe andare bene con l'accesso a ES ma assicurati di stare attento a bloccare le operazioni di rete in caso di interruzioni parziali del sistema (ad esempio assicurati che l'app non si bloccherà in una chiamata di registrazione che non avrà mai successo e smetterà di servire le richieste dell'utente).

Topologie di logging più complesse sono limitate solo dalla tua immaginazione, anche se in questi giorni vedrai un grande uso del database / coda di Kafka / come-vuoi-chiamarlo come punto di nesso in sistemi di distribuzione dei log molto complessi .

Sul lato "senza server", in genere vorrai integrarti con questi sistemi direttamente a livello di rete, quindi inviando i dati di registro direttamente a syslog o ES dal tuo servizio / funzione, piuttosto che scrivere su file locali (anche se forse fare eco a quelli anche per il debug e lo sviluppo locale).

Questa risposta riguarda maggiormente le considerazioni sulla scalabilità: se il numero di lavoratori può essere elevato e / o più di essi possono produrre registri ad alta velocità contemporaneamente.

Sì, è consigliabile utilizzare più file di registro contemporaneamente.

Il tentativo di combinare in un unico registro file di log da più lavoratori in tempo reale solleverà problemi:

• l'uso di meccanismi di blocco per prevenire la perdita di messaggi rallenterà i lavoratori
• i messaggi di registro possono apparire non ordinati nel file di registro combinato
• una funzione di registrazione centralizzata che combina i registri può essere sovraccaricata a causa della velocità di scrittura limitata, i messaggi andrebbero persi

Lo sharding dei file di log (utilizzando più file di log attivi contemporaneamente) è di per sé una tecnica utilizzata da alcuni provider di hosting che offre servizi di logging centralizzati scalabili ad alte prestazioni. Ad esempio, quando si esportano registri in file, la registrazione StackDriver di Google produce più file di registro. Dalle voci del registro in Google Cloud Storage :

Quando si esportano i log in un bucket di archiviazione cloud, Stackdriver Logging scrive un set di file nel bucket. I file sono organizzati in gerarchie di directory per tipo di registro e data. Il tipo di registro può essere un nome semplice come syslogo un nome composto come appengine.googleapis.com/request_log. Se questi registri fossero memorizzati in un bucket denominato my-gcs-bucket, le directory verrebbero denominate come nell'esempio seguente:

my-gcs-bucket/syslog/YYYY/MM/DD/
my-gcs-bucket/appengine.googleapis.com/request_log/YYYY/MM/DD/

Un singolo bucket può contenere log di più tipi di log.

Le directory foglia ( DD/) contengono più file, ognuno dei quali contiene le voci di registro esportate per un periodo di tempo specificato nel nome del file. I file sono suddivisi e i loro nomi terminano con un numero di frammento, Snoppure An(n = 0, 1, 2, ...). Ad esempio, qui ci sono due file che potrebbero essere memorizzati all'interno di directory my-gcs-bucket/syslog/2015/01/13/:

08:00:00_08:59:59_S0.json
08:00:00_08:59:59_S1.json

Questi due file insieme contengono le syslogvoci di registro per tutte le istanze durante l'ora che inizia 0800 UTC. Per ottenere tutte le voci del registro, è necessario leggere tutti i frammenti per ogni periodo di tempo, in questo caso, i frammenti di file 0 e 1. Il numero di frammenti di file scritti può cambiare per ogni periodo di tempo a seconda del volume delle voci di registro.

Tali servizi di registrazione ad alte prestazioni possono anche offrire alternative alla registrazione in file, pertanto la gestione dei file di registro può essere evitata del tutto se ciò è di interesse:

• inserimento dei log direttamente in un database. Ad esempio, Stackdriver Logging può inserire i log direttamente in Google BigQuery
• spingendo i log direttamente in un motore di elaborazione. Ad esempio, Stackdriver Logging può inserire i log negli argomenti di Google Pub / Sub

Infine, se l'unione di file di log in tempo reale non è un requisito con più file di log può aiutare con la gestione dei log offline:

• facile da progettare schemi di backup, compressione, archiviazione ed eventuale smaltimento progressivo dei log
• è possibile l'elaborazione parallela di più set di log (file di registro), riducendo / evitando gli effetti del collo di bottiglia
• nessuna suddivisione e riscrittura dei file necessarie