logging / captura de STDERR / STDOUT no Amazon EC2

Question

Estou procurando uma solução que me permita capturar automaticamente o STDOUT / STDERR de um processo em execução no Amazon EC2 e enviá-lo (remotamente) para outro servidor.

Som simples, exceto:

1. Eu usarei instâncias pontuais, o que significa que não controlo exatamente quando elas são iniciadas, e elas podem terminar a qualquer momento (sem o desligamento adequado)
2. Como não há desligamento, não posso gravar em um arquivo local e transmiti-lo (por exemplo, para s3) quando o processo é concluído.
3. A saída não está bem estruturada (por exemplo, não há campos tabulados em um arquivo de log), portanto, as soluções de log de nuvem "padrão" não são triviais e o uso de um dos bancos de dados em nuvem não é ideal.

Algumas ideias que considerei, mas cada uma delas tem um problema:

1. O acréscimo a um arquivo em "s3" não é possível e a regravação de arquivos é muito lenta para o registro em log.
2. O compartilhamento de volumes do EBS (como unidades) não é possível, tanto quanto é do meu conhecimento.
3. O uso de "simple_db" é muito lento (e "simple_db" está na versão Beta há anos, então não tenho certeza se é utilizável).
4. O uso do SQS (por exemplo, uma mensagem por linha de saída?) é muito lento.
5. O redirecionamento para um soquete de rede falhará se a conexão cair por um segundo (por exemplo, "myprogram 2 > & 1 | nc my.log.server 7070"

Talvez exista uma solução "syslog" com registro remoto? mas isso exigirá uma instância "sob demanda" separada para coletar as informações?

Todas as dicas e ideias serão bem-vindas.

Obrigado  -g

    

Answer 1

I was hoping there's is some "append only" or "mostly append" service by amazon that is designed for logging.

Como o Amazon Kinesis, talvez?

With Amazon Kinesis you can have producers push data directly into an Amazon Kinesis stream. For example, system and application logs can be submitted to Amazon Kinesis and be available for processing in seconds. This prevents the log data from being lost if the front end or application server fails. Amazon Kinesis provides accelerated data feed intake because you are not batching up the data on the servers before you submit them for intake."

^{— http://aws.amazon.com/kinesis}

Eu ainda não tentei isso, porque eu tenho um processo supervisório homebrew que usa S3 e SQS ... no início de um fluxo, ele cria nomes exclusivos para os arquivos temporários (na instância) que irão capturar o arquivo. registra e envia uma mensagem via SQS que resulta na informação sobre o processo e seus locais de arquivo de log serem armazenados em um banco de dados; quando o processo é interrompido (estes são planejados ou orientados a eventos, em vez de executar continuamente tarefas), outra mensagem SQS é enviada, que contém informações redundantes sobre onde os arquivos temporários estavam e me fornece o status de saída do processo; então ambos os logs (out e error) são compactados e enviados para o S3, com cada um desses processos gerando mensagens SQS adicionais relatando o status de upload do S3 ...

As mensagens do SQS, como você pode observar, são em grande parte redundantes, mas isso é projetado para praticamente eliminar a chance de que eu não conheça algo sobre a existência do processo, já que todas as 4 mensagens (start, stop, stdout-upload-info, stderr-upload-info) contêm informações suficientes para identificar o host, o processo, os argumentos e para onde os arquivos de log irão, se foram ou deveriam ter sido, no S3. É claro que toda essa redundância foi quase totalmente desnecessária, já que o processo e o SQS / S3 são muito estáveis, mas a redundância existe se for necessária.

Eu não preciso de registro em tempo real para esses trabalhos, mas se o fizesse, outra opção seria modificar o coletor de logs para que, em vez de salvar os logs e enviá-los em bloco para o S3, eu pudesse, para cada "x" bytes de log coletados ou a cada "y" segundos de tempo de execução - o que ocorrer primeiro - "liberar" os dados acumulados em uma mensagem SQS ... não haveria necessidade de enviar uma mensagem SQS para cada linha.

    

Answer 2

Primeiro, não há nada excessivamente especial no fato de você estar usando o EC2. Com qualquer infraestrutura de registro centralizada, você deseja minimizar as chances de perda de registro e, como tal, precisa enviar os registros o mais rápido possível.

Segundo, não espere magia aqui. Você precisa persistir suas mensagens de log em algum lugar , então é provável que você precise executar uma instância de execução demorada (seja no EC2 ou em outro lugar) para coletar e armazenar suas mensagens.

Veja o que eu recomendo:

1. Execute seu aplicativo usando o supervisord . Isso não apenas fornecerá a você alguns recursos rudimentares de monitoramento / reinicialização de processos, mas, o mais importante, o supervisord gerenciará a coleta de seus fluxos de saída e a gravação em arquivos de log.
2. Em cada servidor de aplicativos, use encaminhador logstash para ler os arquivos de log que o supervisord grava e envie-os para ...
3. Um servidor logstash / elasticsearch , em qual logstash recebe logs de seus nós, organiza-os (se necessário) e os envia ao elasticsearch para armazenamento e pesquisa de longo prazo.

Alguns comentários extras:

• O encaminhador Logstash é capaz de criptografar suas comunicações com o logstash, para que você possa enviar seus registros através de redes públicas, se necessário, sem se preocupar com o vazamento de informações.
O
• Elasticsearch é bastante simples de implementar, e faz um incrível trabalho de indexação de suas mensagens
• O Elasticsearch fornece uma interface REST que você pode usar para emitir consultas, mas se você quiser uma GUI da Web, Kibana3 é uma excelente opção.
• Se você precisar monitorar seus logs e alertar / notificar sobre determinados padrões, o logstash poderá ser configurado para fazer isso