Um Ode ao Graylog

[English Version]

Métricas são a chave para qualquer coisa que você queira fazer, provar ou mudar.

Não há espaço em um negócio competitivo para mudança de plataforma de forma aventureira ou mudança de código injustificável. As mudanças devem acontecer rapidamente e elas precisam resultar em uma atualização de qualidade precisa e mensurável para clientes e partes interessadas, além de qualquer dúvida razoável.

Como você pode ter seguido nos últimos posts, atualmente faço parte de uma mudança de tecnologia na empresa em que trabalho e, embora tenhamos tido sucessos palpáveis, nada é sem alguns problemas ao longo do caminho, é claro. Nos últimos meses, estamos mudando de um produto em que mesmo que precisássemos de muita infraestrutura pesada para ser executado, ele oferecia algumas boas ferramentas incorporadas para métricas que, uma vez que você deixasse essas plataformas para o que pode ser considerado “codificação regular” parece que deixou algo valioso para trás. Não fomos exceção a essa sensação.

Não muito antes de nossos serviços entrarem em produção, enfrentamos uma clara dificuldade em obter dados confiáveis ​​de nossos registros e métricas, dependendo da opinião de alguns desenvolvedores experientes e analistas de processos que passavam horas de mineração em logs de erros desconectados constantemente terminando em falha de determinar a causa correta, dolorosamente atrasando o tempo para uma solução.

No meio desse caos, um dos nossos colegas de equipe, enquanto tentávamos buscar soluções sobre como facilitar nossas vidas, mencionou o GrayLog. Estávamos plenamente conscientes no momento da existência de algumas ferramentas que poderiam nos ajudar, mas como nossa filosofia atual é primeiro olhar para as soluções de código aberto, muitas ferramentas estavam sendo analisadas que até aquele dia nós estávamos ficando aquém em obter boas histórias de sucesso sobre qualquer uma das ferramentas ou a percepção de que o custo de propriedade de algumas dessas ferramentas poderiam fazer com que todo o esforço de conversão de tecnologia ficasse sem sentido.

Após um processo de configuração bastante indolor, pudemos iniciar o upload de dados de registro no Graylog. Os dados são armazenados em Elastic Search e, apesar de definitivamente se parecer muito com o Kibana, existem diferenças sutis que permitirão que você torne sua atuação mais rápida, como por exemplo, a versão gratuita vem com um sistema de usuário / senha e roles que podem se conectar LDAP facilmente, isso vai deixar você com um gerenciamento de usuário e controle de uso muito aceitável, a comunidade é muito ativa e você (provavelmente) nunca ficará sem uma resposta, apesar de que quando estamos falando de uma comunidade de código aberto você não pode sempre acabar com as respostas mais educadas, mas eles vão ajudá-lo de qualquer maneira. Dependendo do seu ambiente, você pode ficar por um bom tempo usando apenas a versão gratuita, uma vez que você só precisa de uma licença depois de enviar mais de 5GB de dados por dia, eu entendo que algumas empresas isso pode parecer poucos dados, mas para nós isso realmente nos deu um grande espaço para expansão! Imaginamos que em breve estaremos registrando a conta premium, mas o simples fato de que eles nos deram tanto espaço para testes e adaptação é plausível.

Não demorou muito até que fosse tomada a decisão de implantar nosso primeiro cluster de produção e levamos apenas algumas horas em execução para que ele nos apresentasse dados suficientes para não apenas diagnosticar e corrigir com êxito alguns erros difíceis, mas também nos apresentasse suficientes informações para erros mais sutis e igualmente desconfortáveis ​​no sistema que, uma vez corrigidos, aumentaram a satisfação geral do cliente com o produto final.

No final do dia, nos vimos com uma ferramenta mais rica, confiável e vasta para o controle de logs do que com o produto anterior do qual estávamos nos afastando, com dados mais concretos, obtidos de forma mais rápida e muito mais bonito de uma forma a facilmente conquistar nossos clientes.

 

Série Node.js: Rodando suave…

Olá!

[English Version]

Esta é a parte 5 da minha série Node.js, dê uma olhada nos posts anteriores!

Até agora na série, determinamos que há muitas vantagens em migrar para o Node.js, desde a facilidade de adoção da equipe de programadores até o desempenho, mas ele precisa de algumas ferramentas.

Ao executar seu código diretamente do node ou do do npm, como acontece em qualquer outra linguagem, ocorrerão erros, e você não quer que seus serviços sejam interrompidos sempre que alguém esquecer de tratar alguma exceção. Você também desejará fornecer continuamente atualizações de código sem que os clientes experimentem o tempo fora do ar ou a redução do desempenho.

Para conseguir isso, você deveria verificar o PM2 , da Keymetrics.

Essa ferramenta não apenas manterá seu código em execução, mas também fornecerá ferramentas profissionais para monitorar, gerenciar e até mesmo debugar seu código de execução.

Se você já tem o Node.js instalado, tudo o que você precisa fazer é executar isso no seu console:

npm install pm2 -g

Uma vez que você o tenha, é fácil rodar o seu primeiro código, se você tiver um arquivo javascript que roda com o Node, digamos que seja chamado myservice.js, você pode iniciá-lo executando o código abaixo. Para este exemplo, estou usando o código que eu postei anteriormente, dê uma olhada!

pm2 start myservice.js

Se o seu console retornar algo assim, você está no caminho certo:

[PM2] Starting /myservice.js in fork_mode (1 instance)
[PM2] Done.
⇆  PM2+ activated | Web: https://app.pm2.io/#/r/MY_ID | Server: vrsbrazil | Conn: Axon
PM2+ on-premise link: root.keymetrics.io
┌───────────┬────┬──────┬──────┬────────┬─────────┬────────┬─────┬───────────┬──────────┬──────────┐
│ App name  │ id │ mode │ pid  │ status │ restart │ uptime │ cpu │ mem       │ user     │ watching │
├───────────┼────┼──────┼──────┼────────┼─────────┼────────┼─────┼───────────┼──────────┼──────────┤
│ myservice │ 0  │ fork │ 7398 │ online │ 0       │ 0s     │ 0%  │ 12.8 MB   │ vrsbrazil│ disabled │
└───────────┴────┴──────┴──────┴────────┴─────────┴────────┴─────┴───────────┴──────────┴──────────┘
 Use `pm2 show ` to get more details about an app

Então essa é a parte em que fica interessante. Se você fizer olhar a linha 3, você verá uma URL, o ID aqui está obviamente alterado, mas uma vez que você o execute em sua máquina e acessar este link, você chegará à página de monitoramento em nuvem, que se parecerá com isto:

Captura de tela de 2018-08-02 11-43-21

Como você pode ver, este é obviamente um recurso pago, mas pode realmente melhorar a sua vida. Se você tem até 4 processos, você pode usar a versão gratuita e, na verdade, há muito a fazer com ela, o monitoramento em tempo real oferecido é bastante útil, mas há muitos recursos que você pode obter com o pago.

Captura de tela de 2018-08-02 11-59-15

De volta ao console, como eu mencionei no começo, você vai querer ter seu serviço à prova de falhas e este é um dos recursos pré-construídos, caso seu código falhe, o PM2 irá reiniciar automaticamente para você. É claro que é necessário ter uma maneira de garantir que seus processos sejam iniciados automaticamente, caso você precise reiniciar o servidor. Para fazer isso, tudo o que você precisa fazer é executar isso em seu console:

pm2 startup

O console retornará o próximo comando que você precisa para executar, a fim de permitir que ele inicie em tempo de boot, no meu caso, é isso que eu recebi:

[PM2] Init System found: systemd
[PM2] To setup the Startup Script, copy/paste the following command:
sudo env PATH=$PATH:/usr/bin /home/vrsbrazil/.npm-global/lib/node_modules/pm2/bin/pm2 startup systemd -u vrsbrazil --hp /home/vrsbrazil

Garanta que você rodou o comando sugerido e tudo deverá funcionar bem.

Bem, é isso para este post. Espero que você goste e, se puder, deixe-me saber o que você está construindo nos comentários.

Ainda há muito o que falar nessa série do Node.js, então, por favor, siga-me no twitter @vrsbrazil para que você possa ser notificado no próximo post.

Muito obrigado!

Série Node.js: Conectando ao Oracle DB

Oi!

[English Version]

Esta é a parte 4 da minha série Node.js, veja os posts anteriores e deixe-me saber o que você pensa!

Então, sabíamos que chegaria a esse ponto, conexão com o Oracle DB. Primeiro de tudo, funciona, então o que eu vou fazer aqui é que a primeira parte do post falarei como você faz isso, a segunda parte é a minha experiência geral e o que você deve esperar de seus próximos passos. Vamos lá:

Adquirindo as ferramentas

A Oracle fornece a você um módulo de código semi aberto para sua conexão aqui . E funciona para o Node 6, 8 e 10, portanto, verifique sua instalação primeiro. Eu usei com o Node.JS versão 10.7.0 e funcionou bem.

O processo de instalação é um pouco complicado, mas está bem documentado na sua página github. Tenha em mente que a ferramenta exige a instalação de bibliotecas do cliente Oracle em seu computador que executará o código, portanto, esteja avisado que um simples npm i oracledb não funcionará!

Então aqui está o meu código de exemplo:


var oracledb = require('oracledb');

oracledb.getConnection(
  {
    user          : "usr",
    password      : "pwd",
    connectString : "host:port/orcl"
  },
  function(err, connection) {
    if (err) {
      console.error(err.message);
      return;
    }
    connection.execute(
      `SELECT *
       FROM dual`,
      [],  
      function(err, result) {
        if (err) {
          console.error(err.message);
          doRelease(connection);
          return;
        }
        console.log(result.rows);
        doRelease(connection);
      });
  });

function doRelease(connection) {
  connection.close(
    function(err) {
      if (err)
        console.error(err.message);
    });
}


Este código é basicamente uma cópia do código que pode ser encontrado em sua página github, como você pode ver, há muito espaço para melhorias na transformação deste código em componentes, então tenha isso em mente ao construir sua versão pronta para produção.

O código acima não funcionou na primeira vez, e eu tomei um erro:

ORA-24454: client host name is not set

Tudo o que você precisa fazer é executar isso no seu console Linux:

sudo /bin/bash -c "echo '127.0.1.1 ${HOSTNAME}' >> /etc/hosts"

Então, sim, isso foi tudo que eu tive que fazer para conectar ao Oracle DB.

Funciona, MAS…

Eu acho que esta solução está incompleta. Como prometido, essa é a segunda parte com minha opinião pessoal sobre ela.

Estamos agora vivendo em um ambiente em que a alta tendência é nem mesmo conhecer a máquina em que seu código está sendo executado, portanto, oferecer uma solução que precise de configuração de máquina local para conectar é, no mínimo, questionável. Eu pensei que nós tínhamos resolvido isso quando os thin clients JDBC nasceram. A maioria dos clientes Node.js está planejando, se já não implantou suas primeiras versões em provedores de nuvem serverless, eu acredito que esta estratégia deva ser revista.

Minha recomendação pessoal aqui é que você, caso ainda não tenha feito, deva começar a planejar o uso de bancos de dados intermediários NoSQL como MongoDB em vez de ir direto para o banco de dados SQL. Há um monte de vantagens no desempenho e até mesmo nos domínios de segurança para esta estratégia que podemos até mesmo falar em um futuro post.

Ainda há muito o que falar sobre o Node.js e coisas novas estão chegando todos os dias, por favor, siga-me no twitter @vrsbrazil para acompanhar esta série e mais.

Obrigado!