Conteúdo original em https://twitter.com/zanfranceschi/status/1642197411853643776
Ei dev,
Discussão sobre a resolução do Desafio 4/9 dos 10 Desafios Simples de System Design que postei recentemente.
"Instrumentar Serviços para Métricas de Negócio em Tempo Real"
↓
https://twitter.com/zanfranceschi/status/1638232593400487936
Essa desafio pode ser difícil dependendo do que e qual precisão necessária do monitoramento. Por exemplo, usar ferramentas de métricas como o Prometheus pra monitorar valores financeiros precisos não é uma boa ideia porque a coleta das métricas pode não ser completa (amostragem).
Usar ferramentas convencionais de coleta de métricas para métricas de negócio pode ser útil para detecção de anormalidades com base em valores aproximados. Por exemplo, a quantidade aproximada de pedidos por hora em um e-commerce.
Esse desafio cita o termo "instrumentar". Geralmente, a gente instrumenta aplicações (e/ou contêineres, servidores, etc.) para métricas que não são de negócio e sim para métricas mais técnicas como uso de CPU, espaço em disco, memória, etc.
Por isso, se você tem alguma experiência nesse área, pode ter questionado prudentemente a frase "instrumentar para métricas de negócio".
Uma abordagem comum para métricas de negócio em quase tempo real é fazer polling em bancos de dados e/ou se conectar a hubs de eventos.
Polling em banco de dados pode ser uma abordagem um pouco mais intrusiva pois pode gerar concorrência significativa de recursos computacionais da operação do negócio.
Se conectar a hubs de eventos, como p.ex. Kafka ou RabbitMQ, não é intrusivo, mas pode ser bem mais complexo.
Monitorar seu negócio te coloca em grande vantagem pois pode diminuir muito o tempo de resolução de problemas.
No passado, fiz uma thread sobre observabilidade que fala, entre outras coisas, sobre métricas e o porquê de não se usar logs para métricas – dá uma olhada.
https://twitter.com/zanfranceschi/status/1547350969070936064
Aproveitando sua atenção, um assunto relacionado que pode ser interessante nesse domínio é SRE. Existe um livro bem clássico sobre o assunto – "Site Reliability Engineering".
É isso! Espero que tenha curtido a thread!
Top comments (0)