Os logs são os resíduos indispensáveis da TI. Eles são o vínculo entre desenvolvimento e operações, o herói anônimo da solução de problemas e, geralmente, o juiz supremo da verdade em designar uma causa raiz complexa. Eles também são difíceis de gerenciar. Eles podem ser concisos demais ou profundamente detalhados, evaporar com o término de recursos efêmeros, como contêineres, ou ficar inacessíveis em arquiteturas altamente distribuídas, como a Internet das coisas.
Embora ambientes de produção consolidados acabem resolvendo esses problemas, o trabalho com o registro em log desvia os desenvolvedores de seu principal objetivo: criar novos aplicativos rapidamente. O Registro em log como serviço (LaaS, Logging as a Service) torna os desenvolvedores mais eficientes e as operações mais confiáveis, pois atende aos três requisitos mais importantes: acesso, agregação e emissão de alertas.
console.log ("Hello World")
Antes de colocar sua obra-prima de serviços de unikernel/microsserviços/DockerSwarm/Kubernetes nativos da nuvem e descontruídos na glória da produção com entrega contínua, você precisa criá-la. No caso da execução no local, antes de dar a bênção para aplicativos de terceiros prontos para produção, você precisa de uma quantidade razoável de conhecimento, configuração e teste. Seja qual for o caso, há muita coisa a se fazer durante a fase de pesquisa e desenvolvimento/teste, e os logs são a ferramenta imprescindível a qual recorremos para saber o que realmente está acontecendo.
Quantas vezes você trabalhou grudado no computador em um momento de inspiração possivelmente decisivo, mas acabou perdendo a oportunidade para reimplementar mais um componente de base e teve que recomeçar? Claro que você pode escolher o exportador de logs de sua preferência, configurá-lo para analisar os arquivos que são relevantes para você, acessar o systemd, definir uma instância de coletor, configurar a rede para transferência e realizar o teste. Porém, isso tudo parece ser muito trabalhoso para testar um microsserviço. Talvez você esteja tentando coletar erros de solicitação MySQL para ajudar a equipe de desenvolvimento a depurar um aplicativo ou precise que os eventos da Segurança do Windows sejam armazenados fora do seu local. Uma infinidade de janelas de console separadas é uma opção, mas não é boa. Não é tão ruim quando converter tudo em syslog, mas chega perto.
E se o registro em log fosse um serviço? E se os desenvolvedores, os administradores de sistema e a equipe de rede pudessem se dedicar ao trabalho transformador, e não aos pré-requisitos? O LaaS permite que as equipes padronizem a coleta, a persistência e a análise dos eventos e acelerem a entrega sem prejudicar a qualidade. Ele também trata das questões relacionadas à solução de problemas dos aplicativos em recursos efêmeros, como contêineres, ou de transferência de hosts, como VMs.
Acessando
Em um servidor, os logs são ótimos, mas dentro de algum lugar no servidor, são complicados. Os perímetros do contêiner intencionalmente limitam o acesso, e os recursos dimensionados em massa de maneira automática não se intimidam em levar os logs com eles ao seu término. Você poderia executar o SSH em seu contêiner e extrair externamente, mas isso não seria muito legal da sua parte. No caso dos aplicativos empacotados, os fornecedores costumam recomendar ferramentas específicas, que eles convenientemente incluem nas faturas. Isso resulta em mais integração ou experiência em ferramenta ineficiente entre as equipes.
Ao configurar os serviços de exportação de logs em imagens de contêiner ou usar a automação do agente do sistema operacional da VM, os administradores podem acabar com a necessidade de vasculhar todas as instâncias em execução, juntamente com inúmeros problemas de acesso privilegiado e/ou de auditoria. Os processos autônomos, máquinas que realizam os trabalhos sozinhas, devem publicar todos os eventos sem distinção, o que facilita manter, observar, pesquisar e tomar medidas.
Os logs também são essenciais para a IoT (na verdade, para qualquer coisa na rede), mas também são especificamente difíceis de serem acessados. Cada elemento com CPU, sistema operacional ou aplicativos, por menor que seja, despeja detalhes em um pequeno armazenamento. Quando os dados que eles geram são enviados para um servidor (e pelo bem da segurança, eles devem ser), não há possibilidade de consulta externa. Mas não é porque eles são pequenos e baratos que seus detalhes operacionais sejam descartáveis. Os dados de log do microssistema distribuído são muito importantes para depuração, e o LaaS oferece um meio eficiente de transportar com segurança milhares ou até milhões de logs distintos para análise.
Agregando todas as coisas
Se você é uma organização de TI grande e de alto desempenho, talvez já tenha usado um agregador de logs centralizado. Porém, para a maioria de TI e, certamente, para os desenvolvedores individuais que executam serviços de prova de conceito, o gerenciamento das tecnologias de agregação é um constante desafio. O orçamento para disponibilidade de aplicativo, durabilidade de dados e compatibilidade com vários padrões já é limitado o suficiente, ainda mais para registro em log.
Por outro lado, se a coleta de logs for simplificada em um único sistema operacional múltiplo/protocolo/pilha, a agregação será uma consequência natural e recomendada da redução da complexidade para administradores e desenvolvedores. Como profissionais de TI, ficamos sempre satisfeitos em acabar com o trabalho duro e nos motivamos com a integração e redução de carga, gerando uma pilha gigantesca de dados úteis nos servidores das pessoas. Trata-se de uma comodidade que favorece a qualidade. O gerenciamento também é beneficiado. Uma única fonte da verdade de eventos é indispensável para a eficiência da equipe e até para a redução de riscos quando a conformidade é um problema.
Alertas úteis
Na verdade, as plataformas de LaaS se destacam no controle de uma dualidade impossível: coleta detalhada, mas alertas concisos. A configuração de log manual inconsistente ou demorada é o único aspecto mais frustrante da solução de problemas. Quase sempre, mesmo quando os logs são coletados, os níveis de log são definidos com valores muito altos para capturar eventos que revelam erros operacionais confusos, infrequentes ou inusitados. A solução é aumentar os detalhes e esperar a nova captura, enquanto os sistemas de arquivos locais são preenchidos com eventos de depuração ou de rastreamento desnecessários. Segundo passo: tire seu manual de RegEx do fundo do baú e treine grep na hora do almoço.
Por outro lado, as plataformas de LaaS incentivam o contrário: enviar todos os detalhes e deixar que um mecanismo de emissão de alertas faça o trabalho. Primeiramente, elas oferecem aos administradores ferramentas de pesquisa otimizadas, muito mais eficientes do que pesquisar em dezenas de arquivos. Análises na memória, marcação, normalização e pesquisas salvas acabam com o trabalho repetitivo e também possibilitam a reutilização entre as equipes. É muito prático para um desenvolvedor de aplicativos reutilizar um padrão mágico diferenciado e específico da plataforma criado por um especialista em operações.
Melhor ainda, os mecanismos de análise de consulta do LaaS são executados continuamente, o que permite que os engenheiros definam alertas em tempo real abrangendo todos os sistemas no pool. Os usuários podem examinar atentamente os dados de interesse deles e decidir por conta própria o que é mais significativo e como desejam consumi-los. Os administradores operacionais podem enviar mensagens de falha específicas aos seus dispositivos móveis, enquanto os desenvolvedores podem enviar um conjunto maior de linhas de log filtradas de teste ou de preparação a um arquivo para análise futura. O principal benefício é converter dados que antes eram diferentes, isolados e, geralmente, perdidos em uma fonte disponível de eventos distintos abrangentes. Ele fornece detalhes proativos sob demanda, sem enviar spams de alertas para todos da equipe.
Diversão com a camada gratuita
Se você ainda não usou o Registro em log como serviço, recomendo enfaticamente que faça isso, mesmo como um projeto separado. Depois de conhecê-lo, você verá que o registro em log centralizado oferece liberdade para fazer o que realmente lhe atraiu para a área da tecnologia: criar. Particularmente, eu comecei com a camada gratuita do Papertrail para projetos separados do Docker, do Raspberry Pi e da AWS. No geral, você perceberá que a criação de um exportador de tópicos SNS de uso único, a configuração de uma linha extra no Winston para Node e a disponibilização de seus eventos journalctl do systemd de forma que possam ser úteis são mais fáceis do que você imagina. Além disso, ele traz benefícios fantásticos que aprimoram a qualidade das operações, reduzem o tempo de implantação e podem até tornar seus fins de semana mais longos.
Patrick Hubbard, Head Geek da SolarWinds.
