Na maioria das vezes, a resposta para essa pergunta do título é “pouco” ou “nada”. O problema se agrava com a popularização da computação na nuvem, quando mudamos de um ambiente operacional estático para um que escala dinamicamente.
Nesse novo cenário, armazenar logs localmente torna-se pouco eficaz pela complexidade para analisar diversas fontes de informações espalhadas nos diversos servidores, que muitas vezes não persistem em informações de logs após seu desligamento.
Por outro lado, manter uma infraestrutura na qual todos os logs são armazenados em um local compartilhado pode se tornar uma tarefa árdua, à medida que precisamos gerenciar grandes massas de dados, reservar espaço para novos arquivos de logs e implementar políticas de ciclo de vida da informação – regras que definem quando informações devem ser movidas para sistema de backup ou simplesmente descartadas.
Existem diversas iniciativas, tanto no mundo open quanto em ferramentas comerciais, que visam a auxiliar a coleta de dados e a agregação deles, a estruturação de informações a e criação de alertas para tomada de ação em caso de falhas. Esses alertas, mesmo que ocorram com baixa frequência, sempre representam oportunidades para aumentar a confiabilidade do seu sistema e também para melhorar a experiência do cliente. Exemplos dessas ferramentas não faltam: logstash, loggly, splunk, Sentry, Graylog2, Scribe, entre outras.
AWS entra no mercado
Recentemente, a Amazon Web Services (AWS) entrou nesse mercado com o lançamento de uma solução para gestão de logs dentro de seu serviço Amazon CloudWatch. As ferramentas listadas anteriormente ainda representam uma solução mais completa, pois muitas delas possuem módulos gráficos e customizáveis para análise histórica e preditiva de informações para auxílio nas tomadas de decisão. Algumas podem até ser usadas em conjunto com soluções de Big Data para uma análise mais complexa. Toda essa flexibilidade vem atrelada com uma complexidade de implantação ou custos mais elevados. É justamente nesse aspecto que o CloudWatch representa uma solução simples e acessível para gestão de ciclo de vida de informação e para criar alertas para monitorar determinado tipo de entradas.
As opções existentes para envio de informações para o CloudWatch Logs são:
- Agente – Alternativa mais usada para ambientes Linux. Esta foi a opção que selecionamos para detalhar neste artigo, mas vale reforçar que ela possui os seguintes pré-requisitos:
- Python versão 2.6, 2.7, 3.0 ou 3.3
- Amazon Linux versão 2014.03.02
- Ubuntu Server versão 12.04 ou 14.04
- CentOS versão 6, 6.3, 6.4 ou 6.5
- Red Hat Enterprise Linux (RHEL) versão 6.5 ou 7.0
- EC2Config – Opção para ambientes Windows. Mais informações aqui.
- Command Line Interface (CLI) – Aqui o acesso é feito via interface de linha de comando e a automatização poderá ser implementada com a utilização de scripts. Mais informações neste link.
- Software Development Kit (SDK) – Alternativa indicada para quem quer ter acesso às funções do CloudWatch Logs usando sua linguagem de programação favorita. O SDK também é comumente usado na fase de extração de dados para análise. Mais informações aqui.
Antes de prosseguirmos ao passo a passo de instalação, precisamos deixar claros alguns conceitos que são fundamentais para compreensão e uso da solução de gestão de logs da AWS. São eles:
- Log Events – Evento registrado pelo aplicativo ou recurso que está sendo monitorado. Cada registro de log é composto por um timestamp (quando ocorreu o evento) e uma mensagem em si (string UTF-8).
- Log Streams – Conjunto de eventos de log de uma mesma origem – instância ou aplicativo que está sendo monitorado. Exemplo: log de acesso do Apache de um host específico.
- Log Groups – Log streams que compartilham as mesmas configurações de retenção, monitoramento e controle de acesso. Cada log stream precisa estar vinculado a um log group.
- Metric Filters – Forma de expressar como o serviço deve extrair informações dos eventos de log para serem usados como métricas de monitoria e alerta do CloudWatch.
- Retention Policies – São as políticas de retenção de dados de log armazenados na AWS. Essas regras são atribuídas a Log Groups e aplicam-se a todo os Log Streams deste grupo.
Instalando e configurando o CloudWatch Logs
Passo 01 – Permissões AIM
Para que o agente possa enviar informação para AWS, é necessário ter um usuário ou role que possua as permissões de acesso ao CloudWatch Logs. Como roles só podem ser atribuídas no momento de criação de uma nova instância e aqui estamos considerando o caso de servidor já existente, vamos na opção de criação de um usuário para utilizar suas credenciais de acesso no agente. Para isso:
- Acesse o módulo Identity and Access Management (AIM) de sua conta. Link direto: https://console.aws.amazon.com/iam
- Crie um usuário (ex: cw.logger). Lembre-se de selecionar a opção “Generate an access key for each user” para que o sistema crie as chaves de acesso para o novo usuário.
- Copie (ou faça download) as credenciais de acesso do novo usuário.
- Anexe a seguinte Policy ao usuário recém-criado:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["logs:*"], "Resource": ["arn:aws:logs:us-east-1:*:*"] } ] }
Passo 02 – Agente
Acesse a instância na qual o agente será instalado e execute os seguintes comandos:
wget https://s3.amazonaws.com/aws-cloudwatch/downloads/latest/awslogs-agent-setup.py
sudo python ./awslogs-agent-setup.py –region us-east-1
Após o segundo comando, o instalador do agente irá requisitar a configuração de alguns parâmetros. São eles:
- AWS Access Key ID – Dado de acesso do usuário que criamos no passo anterior.
- AWS Secret Access Key – Dado de acesso do usuário que criamos no passo anterior.
- Default region name – Coloque us-east-1. Por enquanto, essa é a única região que suporta o serviço e é a mesma que configuramos no Policy do usuário.
- Default output format – Deixar essa opção em branco. Pressione Enter para prosseguir.
- Path of log file to upload – Aqui você coloca o path do arquivo de log que deseja usar no CloudWatch logs. O instalador irá sugerir um pra você (ex.: /var/log/syslog).
- Destination Log Group name – O nome do log group. O instalador irá sugerir um pra você. (ex.: /var/log/syslog).
- Destination Log Stream – Geralmente o nome do host é usado como nome do log stream.
- Timestamp format – Formato do timestamp dos eventos de log.
- Initial position – Aqui você deverá optar entre subir dados retroativos (start_of_file), ou seja, toda a informação que já existe no arquivo de log selecionado, ou subir apenas novos eventos de log (end_of_file).
Veja abaixo o output do comando de instalação do agente no nosso servidor de exemplo:
Launching interactive setup of CloudWatch Logs agent ... Step 1 of 5: Installing pip ...DONE Step 2 of 5: Downloading the latest CloudWatch Logs agent bits ... DONE Step 3 of 5: Configuring AWS CLI ... AWS Access Key ID [None]: USER_ACCESS_KEY AWS Secret Access Key [None]: USER_SECRET_ACCESS_KEY Default region name [None]: us-east-1 Default output format [None]: Step 4 of 5: Configuring the CloudWatch Logs Agent ... Path of log file to upload [/var/log/syslog]: /var/log/syslog Destination Log Group name [/var/log/syslog]: /var/log/syslog Choose Log Stream name: 1. Use EC2 instance id. 2. Use hostname. 3. Custom. Enter choice [1]: 1 Choose Log Event timestamp format: 1. %b %d %H:%M:%S (Dec 31 23:59:59) 2. %d/%b/%Y:%H:%M:%S (10/Oct/2000:13:55:36) 3. %Y-%m-%d %H:%M:%S (2008-09-08 11:52:54) 4. Custom Enter choice [1]: 3 Choose initial position of upload: 1. From start of file. 2. From end of file. Enter choice [1]: 1 More log files to configure? [Y]: n Step 5 of 5: Setting up agent as a daemon ...DONE
Após a instalação, o agente inicia o envio das informações de logs dos arquivos selecionados e só para a execução quando explicitamente requisitado. Para ter acesso às informações, basta ir na área de logs do CloudWatch de sua conta.
Para configurar o ciclo de vida da informação e alertas, basta selecionar os links das colunas Expire Events After e Metric Filters na tela de lista de logs do CloudWatch. Ao selecionar a opção para configurar o ciclo de vida, surgirá uma tela onde você poderá, por exemplo, escolher a opção 30 dias caso queira armazenar somente as informações de log do último mês.
Por último, para criar alertas caso uma determinada entrada de log aconteça (ex.: exceção de aplicação, login como root, warning de espaço em disco etc.). No nosso exemplo, colocamos para sermos alertados toda vez que o SO inserir um warning em seu log.
Vale lembrar que o CloudWatch logs ainda está disponível somente para região Norte da Virginia, mas isso é somente onde os dados de logs ficam armazenados. Instâncias de qualquer região podem configurar o agente para enviar informações para uma região que suporta essa funcionalidade.
Apesar de bastante novo e com as limitações que descrevemos, o ClouWatch Logs é uma alternativa simples e acessível para criar o mínimo de controle de logs consolidados em seus servidores. Além de armazenamento de dados, você pode criar alertas para controles de segurança (ex.: quando o usuário root entra no sistema ou quando IPs bloqueados tentam acessar o servidor) ou até mesmo para controle de qualidade do ambiente de produção (ex.: ser avisado caso o servidor de produção registre mais de 5 exception em menos de uma hora).
A página de documentação oficial do produto contém informações atualizadas sobre funcionalidades, limitações e regiões que suportam a solução. Lá também está detalhado como configurar o CloudWatch logs com Opsworks e Cloud Formation.
Referências:
- http://aws.amazon.com/blogs/aws/cloudwatch-log-service/
- https://www.linkedin.com/groups/What-are-you-doing-your-49531.S.5908304775769767936
- http://www.elasticsearch.org/overview/
- https://www.loggly.com/plans-and-pricing/
- http://www.splunk.com/
- https://www.cloudlytics.com
- http://www.sumologic.com/
- http://logstash.net/
- http://www.fullstackpython.com/logging.html
- http://ctoinsights.trendmicro.com/
- http://countermeasures.trendmicro.eu/
- http://searchcloudcomputing.techtarget.com/
- https://www.linkedin.com/today/post/article/20140824000956-246665791-risks-of-cloud-computing-explained-both-sides
***
Artigo publicado na Revista iMasters. Você pode assinar a Revista e receber as edições impressas em casa, saiba mais.