E como que ficam os logs?

julho 27, 2016 5:00 pm Publicado por Deixe um comentário

Oi, pessoal!

Uma das coisas que atormentam tanto a vida do pessoal de desenvolvimento, quanto de Ops, é saber o que está acontecendo com o seu ambiente. Como se resolve isso? Existem duas formas que devem sempre andar juntas; são elas: monitoramento, para saber se vai dar problema antes do problema ocorrer; e gerência de logs, para saber, depois de ocorrer algum problema, o que aconteceu com sua aplicação ou ambiente que ocasionou o comportamento inesperado.

Essa mesma abordagem deve ser utilizada quando se trabalha com containers também, para monitoria (você já viu aqui e aqui algumas formas de como pode ser feito esse monitoramento). Para a gerencia de logs, você deve pensar antes qual será a criticidade dessas informações para o debug de sua aplicação e resolução de algum imprevisto. Outro ponto é: como preciso ou como gostaria de visualizar essas informações?

Tendo resolvido essas duas questões, você pode então optar:

  • Utilizar o comando docker logs: Com isso, você terá as informações do que está sendo enviado para a console do container, ou seja, somente irá visualizar aquilo que estiver passando na console. Você deve fazer com que sua aplicação envie as informações necessárias para a console do container. Caso sua aplicação salve o debug em arquivo de log, você não conseguirá visualizar de forma fácil essa informação;
  • Utilizar plugins de log: Utilizando plugins, você pode fazer com que qualquer log do container seja enviado para um serviço externo. Isso garante que você poderá ter acesso a qualquer informação (seja do container ou app) de um único lugar.

O que vamos ver hoje é como você pode utilizar alguns dos plugins de logs mais conhecidos e isso é claro na prática.

Fluentd

Um dos drivers de log mais fácil de se utilizar. Com ele você pode enviar tanto o stderr, quanto o stout para o serviço de logs externo, para isso basta você rodar:

docker run --log-driver=fluentd

É claro que você precisa passar alguns parâmetros, como por exemplo: “–log-opt fluentd-address=”, onde você define qual será o destino de seus logs (geralmente será um host onde estará rodando o servidor Fluentd ou o endereço que esse serviço lhe fornecer). Por padrão, a tag de busca será o id do container. Com isso, quando você precisar consultar algum log, deverá fazê-lo pelo id do container que desejar.

Splunk

O Splunk é talvez uma das ferramentas para gerenciamento de log mais completa que se pode ter; e da mesma forma que o Fluentd, você precisa apenas definir esse driver como sendo de log:

docker run --log-driver=splunk

Você precisa definir algumas coisas antes. Veja a lista:

  • splunk-token: Token utilizado para autenticação do container na API http;
  • splunk-url: Endereço do servidor de Splunk disponível, seja ele local ou na solução de cloud da Splunk;
  • splunk-source: Origem do log (se não definido ele coletará tudo);
  • splunk-sourcetype: Tipo do log (app, debug, etc);
  • splunk-index: Índice para os logs;
  • splunk-capath: Caminho do certificado;
  • splunk-caname: Nome para validação do certificado, por padrão ele pega pelo nome do splunk-url;
  • splunk-insecureskipverify: Desativa a verificação ssl para o seu host Splunk;
  • tag: Identificação do log na base, no caso do Docker você pode definir qualquer informação do container como tag, por exemplo: ID, Nome, Região, etc;
  • labels: Facilita a consulta do log posteriormente, você pode por exemplo consultar logs do container x que pertence a região Sul;
  • env: Pode classificar por Dev, Test, Prod etc.

Veja um exemplo prático:

docker run --log-driver=splunk --log-opt splunk-token=SEUTOKENAQUI --log-opt splunk-url=https://servidor-splunk:8088 --log-opt splunk-capath=/etc/cert/cacert.pem --log-opt splunk-caname=SplunkDefaultCert --log-opt tag="{{.Name}}/{{.FullID}}" --log-opt labels=location --log-opt env=TESTE --env "TESTE=false" --label location=sul nginx

AWS Logs

Claro que não poderia faltar a opção de enviar seus logs para o CloudWatch da AWS, e é o mais simples de se utilizar, por um motivo: basta você ter conta na AWS e ativar o CloudWatch. Não é necessário contratar um serviço de cloud de terceiro ou subir um servidor de log local. Veja como você pode utilizá-lo:

docker run --log-driver=awslogs --log-opt awslogs-region=sa-east-1

Você deve definir para qual grupo de log deseja enviar os logs do container. E tenha cuidado, pois dependendo do tipo de logs e quantidade, pode prejudicar a visualização do mesmo, então, preste atenção no formato de log que estará enviando:

docker run --log-driver=awslogs --log-opt awslogs-region=sa-east-1 --log-opt awslogs-group=MeuGrupodeLog nginx

A autenticação é bem simples, você montar o seguinte volume: aws:~/.aws, dentro dessa pasta deve ter um arquivo chamado credentials com o seu AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, e AWS_SESSION_TOKEN. Lembre-se que o usuário utilizado para isso deve ter no mínimo as seguintes permissões: logs:CreateLogStream e logs:PutLogEvents.

Espero ter ajudado. Tendo alguma dúvida, pode me enviar por e-mail ou deixe nos comentários.

Abraços!

Source: IMasters

Categorizados em:

Este artigo foi escrito pormajor

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *