Oi!
Esta é a parte 3 de uma série de posts dedicados a documentar minhas experiências ao adotar o Node.js na empresa, para que as pessoas possam aprender com meus erros e ter uma boa vantagem em seus próprios esforços. Se você gostaria de ver as postagens anteriores, visite-as aqui , aproveite e deixe-me saber o que você pensa!
Logar é extremamente importante, isso você já sabia. Eu passei os últimos 10 anos de minha carreira lidando com ferramentas de integração que não eram exatamente de alto desempenho, não eram exatamente tolerantes com o seu dinheiro em infraestrutura e especialmente em licenciamento, mas cara, elas podem logar. Tanto que a maioria das equipes de banco de dados que lida com esses produtos possuem batches de limpeza semanais, se não diários, para que possam acompanhar a quantidade de informações, a maior parte delas, na verdade, desnecessárias, que esses produtos criam.
Lidar com codificação convencional exige que sua equipe esteja sempre ciente de o quão importante é registrar os passos de seus processos e, considerando que a equipe era, assim como eu, proveniente da linguagens de produtos privados, levou um pouco de tempo para perceber exatamente quanto log era muito básico e quanto era demais. Você vai encontrar vários artigos sobre isso na web, mas no final o seu negócio quem irá na maioria das vezes ditar o que você pode registrar, o que você deveria e o que você definitivamente deve registrar. Nosso negócio realmente exige bastante registro de logs pesados e eles devem ser mantidos por alguns anos, então precisávamos de uma ferramenta simples, mas de alta capacidade para aceitar nossos logs e armazená-los com segurança.
É exatamente quando winston logging chegou ao nosso playground, como eles mesmos dizem, um logger para quase tudo. Winston é uma ferramenta de registro muito confiável, mas há algumas coisas que você deve considerar antes de instalar no npm e forçá-lo ao seu ambiente de produção, e essas são as opções que eu quero lhe contar.
Logo de cara, você verá que o winston lhe apresenta exemplos muito bons e simples de registro em arquivos, e mesmo que isso possa atender a maioria, quando você está lidando com os micro-serviços de alta concorrência apresentados em soluções corporativas, o log de arquivos provavelmente não será a melhor escolha para você.
Ao longo da minha carreira, vi muitas empresas confiarem apenas na solução de registro de arquivos, levando-as a verem seus sistemas não apenas sobrecarregados com alta throughput, mas também sendo forçados a investir em dispositivos de armazenamento incrivelmente caros, porque falharam em prever esta situação ou simplesmente em rever a estratégia.
Provedores na nuvem são especialmente inflexíveis com esse tipo de estratégia, se você é preguiçoso em definir como você usa seus recursos, espere GRANDES faturas no final do mês.
O Winston, no entanto, está preparada para que a maioria das pessoas não o considere uma solução pronta para a empresa, por isso desenvolveram o conceito de Transportes. Então, quando você importa o seu winston no código assim:
const winston = require ("winston");
[/código]
Você também terá que assinar um ou mais transportes, como o de arquivos neste exemplo:
const logger = winston.createLogger({
level: 'debug',
format: winston.format.json(),
transports: [
new winston.transports.File({ filename: 'output.log' })
]
});
E essa é a beleza disso, neste momento você pode escolher a ferramenta favorita que receberá seus dados. E eles têm uma ampla variedade de Transportes disponíveis para você escolher aqui . No entanto, foi o meu caso que o desenho da solução não se encaixaria a nenhum desses, não que eles não fossem bons, mas como eu disse, essa ferramenta permite uma grande flexibilidade e como eu tinha um modelo de solução que exigiria um servidor de mensagens recebendo o logs, eu não tive que mudar a ideia, só tinha que personalizar o meu próprio transporte, e eu o fiz para o RabbitMQ.
Esse caminho foi escolhido porque pretendia uma pequena transformação de dados nos logs antes do armazenamento e não queria ver meu desempenho de serviços degradado por elas, então meus logs foram direcionados para uma instância RabbitMQ. Se você acha que sua solução pode precisar disso, faça o download aqui mesmo , se precisar um pouco de personalização, sinta-se à vontade para fazer um fork aqui.
Caso você esteja se perguntando onde é o último local de descanso dos meus logs, é uma instância do MongoDB, onde é muito fácil pesquisar. Você, no entanto, pode precisar de uma solução diferente! Deixe-me saber como você resolveu isso comentando!
Esse foi outro episódio da nossa cruzada para a migração Node.js, para saber mais e manter-se atualizado sobre esta série, por favor, siga-me no twitter em @vrsbrazil .
Obrigado!
vrsbrazil 