O que é uma boa prática de log para tarefas distribuídas?

Eu tenho a seguinte configuração:

Crie vários trabalhadores, faça um cálculo e finalize-os após o término da computação.

Portanto, sempre que houver uma instância diferente executando a tarefa, cada host terá seu próprio arquivo de log, o que resultará em uma enorme lista de arquivos.

É uma boa prática? Caso contrário, qual seria a melhor maneira de registrar o processamento da tarefa nesse caso de uso específico?

PS: Minha infraestrutura não possui servidor. Então, por enquanto, estou efetuando login no (AWS) CloudWatch. Mas, responda à pergunta independentemente da AWS e adequando ao máximo uma configuração sem servidor.

"Sem servidor" significa apenas que você tem microsserviços relativamente simples, geralmente apenas um pequeno aplicativo da web ou uma única função que é automaticamente conectada a um front-end REST. Os mesmos conceitos se aplicam aos serviços da Web mais tradicionais: geralmente alguma mistura de syslog remoto e gravadores ElasticSearch.

O syslog em rede ou remoto existe há muito tempo e possui um conjunto de ferramentas bastante robusto. Você precisaria executar o servidor syslog central, mas o protocolo é muito simples e existem bibliotecas de clientes puras em todos os idiomas que você pode usar para enviar logs. Um problema comum com o syslog remoto é que ele tradicionalmente se baseia no UDP. Isso significa que, sob carga pesada, algumas mensagens de log podem ser perdidas. Isso pode ser uma coisa boa, ajudando a evitar uma sobrecarga em cascata, mas é algo para estar ciente. Alguns daemons syslog mais recentes também suportam um protocolo baseado em TCP, mas o suporte ao cliente é menos unificado, assim como sua pesquisa.

Mais recente, mas muito popular, é o logon no ElasticSearch. Isso é útil principalmente devido ao painel do Kibana e ao Logstash com iluminação (geralmente chamado ELK, ElasticSearch + Logstash + Kibana). A Amazon ainda oferece uma opção hospedada do ElasticSearch, tornando um pouco mais fácil começar. O ES usa uma API REST relativamente simples; portanto, qualquer idioma com um cliente HTTP (leia-se: todos eles) deve estar bem com o log no ES, mas certifique-se de ter cuidado ao bloquear as operações de rede em casos de interrupções parciais do sistema (por exemplo, verifique se o o aplicativo não ficará preso em uma chamada de log que nunca será bem-sucedida e deixará de atender às solicitações do usuário).

Topologias de log mais complexas são limitadas apenas pela sua imaginação, embora atualmente você veja muito o banco de dados / fila Kafka / o que você quiser chamá-lo como um ponto de conexão em sistemas de distribuição de logs muito complexos .

No lado "sem servidor", geralmente você deseja integrar-se a esses sistemas diretamente no nível da rede, enviando dados de log diretamente para o syslog ou ES a partir do seu serviço / função, em vez de gravar em arquivos locais (embora talvez ecoe para aqueles também para depuração e desenvolvimento local).

Esta resposta é mais sobre considerações de escalabilidade - se o número de trabalhadores puder ser alto e / ou vários deles puderem produzir logs em alta taxa ao mesmo tempo.

Sim, usar vários arquivos de log simultaneamente é uma boa prática.

Tentar combinar em um único logfile de vários trabalhadores em tempo real levantará problemas:

• o uso de mecanismos de bloqueio para evitar a perda de mensagens desacelerará os trabalhadores
• as mensagens de log podem aparecer fora de ordem no arquivo de log combinado
• Se um recurso de registro centralizado que combina os registros puder ser sobrecarregado devido à velocidade de gravação limitada, as mensagens serão perdidas

Os arquivos de log de compartilhamento (usando vários arquivos de log ativos ao mesmo tempo) são uma técnica usada por alguns provedores de hospedagem que oferecem serviços de log centralizados e escaláveis ​​de alto desempenho. Por exemplo, ao exportar logs para arquivos O StackDriver Logging do Google produz vários arquivos de log fragmentados. Nas entradas de log no Google Cloud Storage :

Quando você exporta logs para um bucket do Cloud Storage, o Stackdriver Logging grava um conjunto de arquivos no bucket. Os arquivos são organizados em hierarquias de diretórios por tipo e data de log. O tipo de log pode ser um nome simples como syslogou um nome composto como appengine.googleapis.com/request_log. Se esses logs fossem armazenados em um intervalo nomeado my-gcs-bucket, os diretórios seriam nomeados como no exemplo a seguir:

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

Um único bucket pode conter logs de vários tipos de log.

Os diretórios folha ( DD/) contêm vários arquivos, cada um contendo as entradas de log exportadas por um período especificado no nome do arquivo. Os arquivos são fragmentados e seus nomes terminam em um número de fragmento, Snou An(n = 0, 1, 2, ...). Por exemplo, aqui estão dois arquivos que podem ser armazenados dentro do directory my-gcs-bucket/syslog/2015/01/13/:

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

Esses dois arquivos juntos contêm as syslogentradas de log para todas as instâncias durante a hora que começa às 0800 UTC. Para obter todas as entradas de log, você deve ler todos os shards para cada período - nesse caso, shards de arquivo 0 e 1. O número de shards de arquivo gravados pode mudar para cada período de tempo, dependendo do volume de entradas de log.

Esses serviços de log de alto desempenho também podem oferecer alternativas ao log de arquivos, portanto, o gerenciamento de arquivos de log pode ser totalmente evitado se isso for interessante:

• inserindo logs diretamente em um banco de dados. Por exemplo, o Stackdriver Logging pode enviar logs diretamente para o Google BigQuery
• enviando logs diretamente para um mecanismo de processamento. Por exemplo, o Stackdriver Logging pode enviar logs para os tópicos de publicação / publicação do Google

Por fim - se a mesclagem de arquivos de log em tempo real não for um requisito, ter vários arquivos de log pode ajudar no gerenciamento de logs offline:

• fácil de criar esquemas progressivos de backup, compactação, arquivamento e eventual descarte de log
• é possível o processamento paralelo de vários conjuntos de logs (arquivos de log), reduzindo / evitando efeitos de gargalo
• não é necessário dividir e reescrever arquivos