DEV Community: Pedro Paulo Silva

Observabilidade 101 - Entendendo o que acontece no seu sistema

Pedro Paulo Silva — Tue, 09 May 2023 22:08:20 +0000

Observabilidade

As aplicações, por muito tempo, eram construídas de maneira centralizada, os famosos monólitos, entretanto, ao longo dos últimos anos, a área de tecnologia vem mudando bastante.

As aplicações usam cada vez mais ferramentas e abordagens distribuídas, como Containers, Kubernetes, Microservices e Serverless, por exemplo. Essas tecnologias proporcionam diversas vantagens, a escalabilidade sendo uma das mais relevantes. Porém, introduziram complexidade adicional, fazendo com que as falhas sejam mais difíceis de prever, detectar e solucionar problemas.

Buscando resolver esse problema surge, na Engenharia de Software, o conceito de Observabilidade, buscando fornecer um nível de introspecção e ajudar as pessoas a raciocinar sobre os estados internos de seus sistemas.

Observabilidade é a habilidade de entender o que está acontecendo dentro do seu sistema com base em suas saídas. Isso significa que você deve saber explicar qualquer estado em que seu sistema possa entrar. Por exemplo: estado de falha, estado de lentidão etc. Busca alcançar uma melhor compreensão de como o software está operando.

Pilares da Observabilidade

Para tentar alcançar o maior entendimento do que está acontecendo no seu sistema, existem 3 principais pilares que, por si só, não fazem um sistema observável, mas relacionando eles se tem um entendimento muito bom dos processos do seu sistema.

Logs

Os logs são registros imutáveis que possuem data/hora de eventos que ocorrem em um sistema, eles fornecem contexto sobre o que está acontecendo no sistema e podem ser utilizados para identificar problemas e rastrear sua origem.

Podemos considerar então que as mensagens de logs representam os vários eventos que ocorrem nos sistemas, podendo ser informativos ou até mesmo registrar um problema que aconteceu em seu sistema.

Métricas

Quando pensamos em métricas para arquitetura de microservices, devemos conhecer o método RED. Esse método define as três principais métricas que devemos medir em microservices. São as métricas básicas que recebemos por padrão nas principais soluções de APM do mercado. As métricas RED são:

RATE

Número de requisições por segundo que seu serviço está atendendo.

ERROR

Número de requisições com falha por segundo.

DURATION

Tempo médio que o serviço gasta para processar cada requisição.

Tracing

Rastreamento distribuído (ou Distributed tracing) é um conjunto de técnicas, padrões e práticas que tem como principal objetivo mostrar o fluxo por onde passou uma requisição, se ela foi atendida e quanto tempo levou para a requisição ser atendida.

Vamos imaginar que esse usuário está enfrentando uma lentidão para receber a resposta de sua requisição. Sem usar distributed tracing (por exemplo, olhando os logs isolados de cada microservice) ficará difícil identificar rapidamente onde está ocorrendo o gargalo, onde podem ocorrer erros etc.

Com muitos serviços envolvidos em apenas uma única requisição, é difícil também você reportar as equipes responsáveis por esses componentes sem saber identificar o problema, gerando lentidão na resolução do problema.

Exemplo de tracing no New Relic:

Ferramentas de Observabilidade

Existem diversas ferramentas para lidar com cada pilar da observabilidade, umas fazem melhor uma coisa, outras tem melhor desempenho, etc. Você deve avaliar qual se encaixa melhor para o seu cenário e combiná-las.

A seguir listei algumas das ferramentas de observabilidade mais utilizadas no mercado

New Relic - https://newrelic.com/

Grafana - https://grafana.com/

Prometheus - https://prometheus.io/

Data Dog - https://www.datadoghq.com/

Conclusão

Esses são os conceitos básicos sobre observabilidade, seguem alguns links caso queira se aprofundar nesse assunto de extrema importância.

O que é observabilidade? - https://www.opservices.com.br/o-que-e-observabilidade/
8 dicas de como implementar uma boa estratégia de observabilidade - https://www.opservices.com.br/como-implementar-uma-boa-estrategia-de-observabilidade/
Qual a diferença entre monitoramento e observabilidade? - https://www.opservices.com.br/diferenca-entre-monitoramento-e-observabilidade/

Múltiplas validações com o Laravel Pipeline

Pedro Paulo Silva — Mon, 07 Mar 2022 21:54:48 +0000

É quase certo que você já esteve na situação de ter que validar um objeto através de diversas condições. Nessas situações o comum é ir adicionando if's, cada um validando uma condição específica. E não há nada de errado nisso, é uma maneira prática e você resolveu seu problema inicial.

Contudo, com o passar do tempo mais condições vão aparecendo e o que eram 3 if's agora são 15 e seu código começa a ficar muito complexo (se você usa alguma ferramenta para inspecionar o código como o PHP Mess Detector, ele literalmente irá reclamar do seu código dizendo que está complexo demais).

Para diminuir essa complexidade de um trecho de código, podemos aplicar um pattern chamado Pipeline Pattern.
Resumidamente esse pattern cria uma "linha de montagem" com várias etapas sequenciais e passa seu objeto através dessas etapas, retornando o resultado ao final. Essa "linha de montagem" pode, por exemplo, manipular seu objeto, adicionando, atualizando ou removendo atributos. E também pode realizar validações nesse objeto, que é o que faremos aqui.

No Laravel temos uma implementação desse pattern (Illuminate\Pipeline\Pipeline) e é ela que vamos usar hoje para refactor o trecho de código a seguir.

Exemplo

Refatoração

Primeiramente vamos criar 3 classes para fazer as validações isoladamente.

E agora vamos usar a implementação da Pipeline que existe Laravel.

Dessa forma o objeto $usuario irá passar por todas as validações e ao final será retornado.

Você pode, também, reaproveitar as validações já existentes e organizá-las de outras formas, criando outras validações, por exemplo, uma que só valide os meios de contato do usuário. Como abaixo:

Conclusão

Como podemos ver, com o uso desse pattern as reponsabilidades de cada validação ficam separadas e muito melhor organizadas. Assim permitindo que a adição, exclusão e manutenção das validações seja feita de maneira muito mais fácil.

Gerenciando Tarefas Agendadas do Laravel no Banco de Dados

Pedro Paulo Silva — Fri, 18 Jun 2021 20:55:04 +0000

Tarefas agendadas são uma ótima maneira de executar processos repetitivos de maneira automatizada em nossos projetos, basta definir as tarefas e escolher os momentos em que elas serão executadas e pronto, pode deixar o resto do trabalho com o cron do servidor.

Geralmente essa definição dos momentos em que as tarefas irão rodar fica dentro do projeto e acaba sendo suficiente em muitos casos, porém, essa maneira de gerenciamento acaba sendo um empecílio quando se precisa alterar o horário em que as tarefas serão executadas. Gerenciando dessa maneira, será necessário uma alteração no arquivo, e uma nova release do projeto para as alterações terem efeito. Isso também restringe que o ajuste no horário da tarefa seja feito somente por um desenvolvedor.

Para resolver esse problema, podemos gerenciar as tarefas agendadas no banco de dados, fazendo com que apenas a alteração de um registro já altere o funcionamento da tarefa.

No Laravel temos o pacote: Laravel Database Schedule, que permite o gerenciamento das tarefas no banco de dados e ainda fornece uma interface para que a alteração das tarefas possa ser feita de maneira mais simples e por alguém sem tanto conhecimento de programação.

Instalação

Para instalar a biblioteca vamos rodar:

composer require robersonfaria/laravel-database-schedule

Após a instalação precisamos rodar as migrations para criar as tabelas usadas pela biblioteca:

php artisan migrate

Por último, exportar o arquivo de configurações:

php artisan vendor:publish --provider="RobersonFaria\DatabaseSchedule\DatabaseSchedulingServiceProvider" --tag="config"

No arquivo de configurações vamos alterar o restricted_access para false para o teste.

OBS: essa configuração deixa o dashboard de tarefas agendadas público, para restringir o acesso somente à usuários autorizados deixe a propriedade como false e consulte a documentação para definir quem poderá acessar.

Criando a Tarefa Agendada

Para exemplo vamos criar uma tarefa rodando:

php artisan make:command NovoComando

E configuramos o comando dessa maneira:

protected $signature = 'comando:novo-comando';

protected $description = 'Novo comando teste';

public function handle(): int
{
    $this->info('Comando rodando!');
    return 0;
}

Normalmente, agora seria o momento em que iríamos cadastrar esse comando que criamos, no Kernel.php e configurariamos o horário para a tarefa rodar, mas usando o database schedule não faremos isso.

Agendando a Tarefa no Banco de Dados

Após iniciar o servidor com:

php artisan serve

Vamos acessar http://localhost:8000/schedule para entrar no dashboard.

No formulário, vamos escolher o comando que queremos agendar, a expressão cron que vai definir quando ocorrerá a execução e marcar a opção de envio de email caso ocorra uma falha na execução, para isso também vamos definir um email.

Para entender todas as opções e parâmetros que podem ser configurados na tarefa agendada visite a documentação.

Após essa configuração podemos ver no dashboard nosso comando cadastrado.

Executando as tarefas agendadas

Para testar localmente vamos rodar o comando:

php artisan schedule:run

E depois do comando rodar, se acessarmos o email cadastrado e a sessão de Histórico no dashboard veremos o resutado.

Caso ocorra algum erro, o email e histórico continuam sendo registrados.

Referências

https://github.com/robersonfaria/laravel-database-schedule

Melhorando a performance dos seus testes em PHP/Laravel

Pedro Paulo Silva — Thu, 06 May 2021 21:49:29 +0000

O problema

Você já se encontrou na situação em que tinha que fazer um deploy ou subir sua atualização urgente e teve que ficar esperando os testes terminarem para finalizar pipeline? Nessa hora qualquer minuto é uma eternidade.

Eu estava enfrentando esse problema, meus testes demoravam cerca de 6 minutos para rodar e esse tempo seguia aumentando a cada nova feature entregue.

A solução

Para resolver isso encontrei o pacote Paratest, basicamente, esse pacote adiciona suporte a testes paralelos ao PHPUnit, fazendo com que seus testes rodem simultaneamente.

Instalação

Primeiro começamos instalando o pacote:

composer require --dev brianium/paratest

Após isso, sua aplicação já tem suporte aos testes em paralelo. 🥳

Para começar a usar vamos rodar o comando:

vendor/bin/paratest -p4 --runner=WrapperRunner

Opções usadas:

-p4

A opção -p é referente ao número de processos simultâneos que irão rodar os testes.

--runner=WrapperRunner

Por padrão, o PHPUnit inicia um novo processo para cada arquivo de testes que irá rodar, utilizando o --runner=WrapperRunner cada processo -p irá iniciar apenas uma vez e manter tudo o que é preciso para rodar todos os arquivos de testes.

Para saber todas as opções disponíveis e ter mais detalhes sobre as usadas aqui, acesse a documentação do pacote.

Resultados

Para efeitos de comparação vamos rodar modo sequencial, apenas com o PHPUnit e no modo paralelo, com o Paratest. Serão 646 testes com 75442 asserções, a maioria desses testes sendo de integração, com acesso ao banco de dados e outras dependências.

Testes Sequenciais:

O tempo levado pelo PHPUnit para rodar todos esses testes foi de aproximadamente 5 minutos e 39 segundos. Agora, lembre-se da situação em que você está esperando a pipeline terminar para finalmente fazer um deploy, esses quase 6 minutos se tornam uma eternidade.

Testes Paralelos:

Já o tempo levado pelo Paratest foi de aproximadamente 1 minuto e 11 segundos. Um tempo muito melhor para você que está ansioso esperando.

Nem tudo são flores 😓

Quando estamos trabalhando com paralelismo um grande problema é controlar o acesso de cada processo aos recursos e dados do sistema, e nesse caso não é diferente. Em testes que devem acessar o banco de dados, modificar e consultar registros pode ocorrer de dois testes acessarem o mesmo dado simultaneamente causando possíveis deadlocks no banco de dados e assim, também, um desses testes acabará falhando.

Uma possível solução para esses casos é o isolamento de cada teste no acesso ao banco de dados. É possível fazer isso rodando os testes dentro de uma transaction assim fazendo com que todos os registros modificados e/ou consultados estejam isolados e tudo que foi feito pelo teste é desconsiderado após seu término.

O Laravel disponibiliza a Trait DatabaseTransactions, com ela no seu TestCase (classe na qual seus testes irão extender), seus testes irão por padrão rodar dentro de uma transaction.

Caso use SQLServer, outra possível solução é habilitar a opção READ_COMMITTED_SNAPSHOT, ela ajuda com esses casos de dados sendo acessados e modificados simultanemente. Para mais detalhes acesse: https://www.mssqltips.com/sqlservertip/6368/sql-server-readcommittedsnapshot-database-option-and-read-commited-transaction-isolation-level/

Observação: no meu caso as duas opções foram usadas.

Conclusão

Com a necessidade de cobrir sua aplicação com testes aumentando a cada dia, rapidamente você começa a se sentir incomodado com a demora na finalização dos testes. Para ajudar nesse ponto, a opção de rodar seus testes em paralelo é muito bem vinda, ela está aí para aumentar a performance e produtividade do seu time nos deploys e no dia a dia.

Se você ainda não usou, deveria dar uma chance e ver o tempo que você está perdendo (literalmente rs).

Fontes

Paratest: https://github.com/paratestphp/paratest
Laravel Doc: https://laravel.com/docs/8.x/testing#running-tests-in-parallel