Histórico da Página
Informações | ||
---|---|---|
| ||
Observabilidade, neste contexto, refere-se à análise de saídas do sistema para determinar seu comportamento. Esta página tem como objetivo fornecer insumos para clientes que não possuam uma equipe de infraestrutura dedicada para desenvolver este conceito. A seguir, os links que foram utilizados como referência ou podem auxiliar no entendimento do conteúdo como um todo: Teoria Geral da Observabilidade (pdf, em inglês) • Mean Time to Repair • Mean Time Between Failures • High Availability (HA) • Disaster Recovery (DR) |
Observabilidade é um conceito criado na área da Engenharia, sendo um termo recente para o setor de tecnologia. O conceito inicial foi desenvolvido pelo engenheiro elétrico, matemático e inventor Rudolf E. Kálmán. De maneira extremamente resumida e , para facilitar o entendimento sobre a Teoria Geral da Observabilidade, Kalman a define com a frase “um sistema é completamente observável se todo constate for observável”. A leitura da teoria é recomendada caso queira se aprofundar no assunto.
De acordo com esta definição, temos de maneira menos formal o seguinte resumo sobre observabilidade:
Resumidamente, é possível dizer, de maneira informal, que "A partir de saídas do sistema é possível determinar o comportamento de todo o sistema.".
Para o nosso dia a dia, vamos ousar resumir esse novo conceito no âmbito da tecnologia, da seguinte forma: "Observabilidade é um conceito que se utiliza de ferramentas para manter um ecossistema funcionando, através de dados (métricas, logs, traces, ...) que possam ser coletados e analisados para mantê-lo."
Como desenvolver esse conceito?
Na área de tecnologia , esse conceito tem sido desenvolvido, principalmente, por grandes corporações, onde os sistemas operantes não podem parar, ou o downtime deve ser o mínimo possível em sua extensa gama de serviços e microsserviços. Então, como Como, então, no "Mundo TOTVS", aquelas empresas que ainda não têm uma grande equipe de Infra e não têm um grande ecossistema como a TOTVS, a Amazon ou Google, irão desenvolver esses conceitos?
...
KPI (Key Performance Indicator) - : São os principais indicadores de performance de seu ambiente.
MTTR (Mean Time To Repair) - Tempo : Tempo médio para reparo entre falhas, ou seja: quanto menor o tempo entre falhas, melhor.
MTBF (Mean Time Between Failures) - Tempo : Tempo médio entre falhas, ou seja: quanto maior o tempo entre falhas, melhor.
...
O investimento para manter um sistema disponível 99,99% do tempo ativo , engloba soluções de High Availability (HA) eDesaster e Disaster Recovery (DR).
E para o Protheus, como tudo isso funciona?
Agora vamos à prática, em um cenário hipotético de apenas 100 conexões no Protheus.
Se o seu MTTR for de 24 horas, posso pensar em um dimensionamento com o hardware mínimo recomendável para o ambiente ERP, onde precisamos de 2 servidores físicos, virtualizados ou em nuvem.
Porém, se falamos de um MTTR de 1 min, vamos precisar de no mínimo 4 servidores no cenário básico de HA e DR, e em cenários mais complexos, 8 servidores para atender às mesmas 100 conexões.
Para “cuidar” desses ambientes, seja o formato mais simples ou mais complexo, usando o conceito de observabilidade, vamos começar pelo bom e conhecido monitoramento, depois partimos para análise de logs e tracert.
Na observabilidade, utilizaremos uma tríade muito importante: logs, traces e métricas.
No mercado existem diversas ferramentas que podem coletar e apresentar esses dados; nas documentações relacionadas, exibimos o uso das ferramentas Telegraf, InfluxDB e Grafana.