Afinal, o que é observabilidade? Para que serve? Quais são os seus pilares? Neste artigo, vamos apresentar conceitos, stacks e a importância da observabilidade nas jornadas de um sistema. Prepare-se para mergulhar no tema!
O que é observabilidade?
Para entender o que é observabilidade, vamos utilizar uma analogia: imagine que você vai fazer uma viagem de avião que vai atravessar todo o oceano atlântico.
No meio do voo, acontece uma pane a bordo e a pessoa piloto não sabe qual a altitude do avião nem a velocidade. O sistema de navegação também não funciona, então o avião está totalmente à deriva no ar.
Como se não bastasse, ele está perdendo velocidade e as pessoas que o pilotam também não possuem informações sobre o sistema mecânico da aeronave.
Em resumo, você sabe que existe um problema, quem pilota sabe que existe um problema, mas ninguém tem idéia do que está gerando esse impasse.
Talvez seja algo simples, que seja possível resolver rapidamente, mas sem essas informações é muito provável que o avião acabe caindo.
Mas será mesmo que um avião seria colocado no ar nessas condições críticas? Certamente que não. Nesse exemplo, acabamos de descobrir o que é não ter observabilidade e entender a importância dela em um sistema.
Observabilidade em desenvolvimento
Quando pensamos em microsserviços, aumentamos ainda mais a criticidade, uma vez que um problema ocorrido em um microsserviço A, pode estar gerando outro problema em um microsserviço B, C e/ou D.
E aí eu lhe pergunto… é possível resolver sem observabilidade?
Dependendo do problema, talvez até seja possível, mas e as lições aprendidas? E o tempo gasto para a resolução? Esse problema foi decorrente de uma ação recente ou estourou após uma série de falhas que vinham acontecendo há muito mais tempo?
Entende que não é apenas resolver o problema? Existe o negócio envolvido, uma série de fatores de responsabilidades, de dores causadas em clientes, de prejuízos que podem ser medidos e não medidos… Talvez você possa se perguntar:
- Isso não é monitoramento?
- Qual a diferença entre observabilidade e monitoramento?
- Ou o que seria de fato a observabilidade e como isso iria me ajudar no dia a dia?
- Quais são os pilares da observabilidade?
- Quais são as ferramentas que eu posso utilizar para que eu tenha observabilidade nos meus sistemas?
É sobre tudo isso que se refere essa publicação, então fique comigo até o final, que você vai tirar a maioria das suas dúvidas sobre o tema e vai saber como a observabilidade vai fazer uma grande diferença na sua carreira e garantir que você não suba seu sistema como um avião à deriva.
Observabilidade X monitoramento
A primeira coisa que precisamos entender é que o monitoramento é um complemento da observabilidade. São coisas diferentes, mas que acabam se complementando.
A observabilidade garante entender o estado interno de um sistema complexo com base em suas saídas externas, possibilitando que pessoas usuárias identifiquem a causa raiz de um problema de desempenho, observando os dados que ele produz sem testes ou codificações adicionais.
Por sua vez, o monitoramento irá avaliar a integridade desse sistema, coletando e analisando dados com base em um conjunto predefinido de métricas e logs, possibilitando, por exemplo, a medição da integridade do aplicativo ou a criação de uma regra de alerta quando o aplicativo alcançar um determinado estado que possa ajudar a evitar o tempo de inatividade.
Com isso, o monitoramento acaba mostrando não apenas como um aplicativo está funcionando, mas também como está sendo usado ao longo do tempo.
Quando se trata de monitoramento versus observabilidade, a diferença depende de identificar os problemas que você sabe que vão acontecer e ter uma maneira de antecipar os que podem acontecer.
Em sua forma básica, o monitoramento é reativo e a observabilidade é proativa. Ambos usam o mesmo tipo de dados de telemetria, conhecidos como os três pilares da observabilidade:
- Logs: um registro do que está acontecendo em seu software;
- Métricas: uma avaliação numérica do desempenho do aplicativo e da utilização de recursos;
- Rastreios/tracing: como as operações se movem em um sistema, de um nó para outro.
Com isso, vamos falar um pouco mais sobre esses três pilares a seguir.
Pilares da observabilidade
Os pilares da observabilidade criam as condições necessárias para que exista a observância completa de todas as jornadas do sistema. Os pilares são 3: métricas, logs e tracing.
Uma vez que consigo reunir todas elas de forma funcional eu crio um ecossistema que gera o que precisamos: a observabilidade.
Métricas
Conceitualmente, seria correto dizer que as métricas são ações ordenadas de análise do sistema, que quantificam, qualificam e transformam os eventos ocorridos em uma determinada linha de tempo, em informações que facilitam a tomada de decisão.
Porém, além disso, ainda é possível concluir que teremos dois tipos de métricas, as métricas que trazem números relacionados ao negócio e as métricas que trazem números relacionados a um contexto técnico.
Para exemplificar e facilitar o seu entendimento sobre esses dois tipos de métricas, vamos imaginar, de forma hipotética, que eu tenha uma escola e quero saber:
- quantas matrículas ocorreram nos últimos três anos no mesmo período;
- qual a época do ano que o custo de energia costuma aumentar, considerando os três últimos anos,
- qual a média de consumo de água nos últimos seis meses.
Todos esses números estão relacionados à métricas de negócio.
Agora imagine que você seja uma liderança técnica de um time de devs que trabalham em uma arquitetura de microsserviços e precisa saber como está a saúde de um dos seus clusters principais, informações como o nível de uso da memória ram, utilização dos processadores, tempo de leitura, etc.
Além disso, você quer saber quantas vezes as suas PODs reiniciaram nos últimos 30 dias e qual o capacity atual de sua estrutura de containers. Todos esses números estão implicitamente ligados a área técnica e, portanto, constatamos que se tratam de métricas técnicas.
Logs
Enquanto as métricas mostram números, os logs, por sua vez, vão nos mostrar o comportamento.
Os logs estão ligados diretamente a um evento e ele tem a prerrogativa de nos entregar o resultado desse evento. Quando eu subo um serviço NGINX, inicia-se o disparo de uma sequência de logs, mostrando o comportamento de todo processo de inicialização do servidor.
Uma prática comum no mundo da programação é o uso de logs para determinar o início e o fim de determinadas rotinas na aplicação; para trazer uma informação inteligível quando ocorre uma exceção; para fornecer informações de origem, data e hora da ocorrência; e muito mais.
Talvez você pense, “puts! Eu já sei o que são logs…”, mas, calma, não é apenas sobre o conceito de logs que eu quero falar aqui.
Pra dizer a verdade, o que eu quero mesmo te apresentar nesse contexto é sobre uma boa prática, que talvez você já até tenha aprendido lá no ensino primário durante a construção de um texto, e que hoje nós vamos usar para aprender a montar um log super da hora.
E o que eu quero dizer com montar um log super da hora?
Primeiro vamos pensar…
Qual a finalidade do log?
O log quer comunicar algo para alguém, concorda comigo?
Beleza… agora quais são os princípios da comunicação?
Fazendo uma breve pesquisa, eu descobri que a comunicação é carregada de princípios, mas alguns que me chamaram a atenção foram:
- A comunicação precisa ser assertiva;
- A comunicação precisa ser direcionada (conheça a pessoa interlocutora);
- A comunicação precisa ser objetiva (onde você quer chegar?);
- A comunicação precisa ser clara;
- A comunicação precisa entregar ou transmitir algo.
Pensando no que acabamos de ler, não seria legal que os nossos logs acompanhassem princípios como esses? Afinal de contas, quando criamos uma mensagem de log, queremos comunicar algo.
Então, vamos lá: responda comigo a essas quatro perguntinhas básicas: O log precisa…
- ser assertivo?
- ser direcionado?
- ter clareza?
- entregar ou transmitir algo?
Se sua resposta foi sim, acertou! Agora vou te ensinar um pouco mais sobre os 5 Ws do logging. Trata-se de uma regrinha básica que vai te ajudar a montar um log que comunica adequadamente na hora que é acionado.
O primeiro W: WHO (QUEM)
Esse é o ponto em que você se pergunta: “eu serei capaz de saber de onde veio esse log daqui a 30 dias? Como eu vou saber quem fez esse log?”.
E, para conseguir ter essas respostas, uma boa prática é utilizarmos identificadores que possibilitem buscar por elas em nossa base de dados. Por exemplo:
- AccountId;
- UserId;
- ProcessId;
- OrderId.
O segundo W: WHAT (O QUE)
Esse é aquele momento que você bate o olho no log e consegue saber exatamente o que ele quer transmitir…
- É um warn?
- É uma exceção?
- É uma entidade?
- É um evento?
Você já pegou algum log do tipo… “ops, aconteceu algo errado” ? Faz algum sentido isso?
Eu não sei onde aconteceu, quem gerou isso, que tipo de erro foi…mas agora vamos imaginar que, ao invés dessa mensagem, estivesse assim:
“2024-10-01,22:30:00 Acao=Pagamento, processarPagamentoDafatura: Ops, aconteceu um erro ao processar o pagamento. OrderId: $OrderId, Erro: $Error”
Quem comunica melhor?
Entende o que eu quero dizer?
Um log não é apenas uma simples mensagem, ele precisa vir carregado de informações que comuniquem de fato o que está ocorrendo e direcione a pessoa analista para a resolução do problema.
O terceiro W: WHEN (QUANDO)
Atualmente, acabamos não nos preocupando tanto com o “quando”, pois as plataformas de logging já trazem para nós um timestamp com data e hora da chamada do logging.
Contudo é importante pensarmos em possibilidades: talvez a plataforma não traga a informação no formato que precisamos ou exista um acordo no time que necessite você adicionar manualmente algum incremento a esse valor.
O importante é saber que seria impossível identificar quando ocorreu um problema sem essa informação.
O quarto W: WHERE (ONDE)
O uso de determinadas ferramentas de log são imprescindíveis para sabermos onde ocorreu.
Atualmente, podemos utilizar o StackTrace e identificadores que também vão nos ajudar a entender onde ocorreu o log, mas se você puder utilizar uma ferramenta de tracing, vai conseguir ter um poder maior de rastreabilidade e vai otimizar bastante o seu tempo.
O quinto W: WHY (POR QUE)
Saber o porquê do log ter acontecido é uma ciência, exige previsibilidade, análise crítica, percepção de contextos e ambientes que o seu código será submetido, e ele precisa estar implícito na mensagem que você vai transmitir.
Vamos tomar como exemplo o log anterior:
“2024-10-01,22:30:00 Acao=Pagamento, processarPagamentoDafatura: Ops, aconteceu um erro ao processar o pagamento. OrderId: $OrderId, Erro: $Error”
Perceba que tenho o quando, sei quem gerou o log, informo o que aconteceu, de onde ele veio, só que o porque não está claro na mensagem.
Aqui é uma visão minha de que, nem sempre, vamos conseguir saber o porquê, simplesmente por existir algo inesperado, no entanto é preciso nutrir o seu log com informações que possam facilitar a identificação desse motivo. No caso de uma exception, pegar a mensagem do erro, o tipo da exception já é uma boa forma de identificar o porquê.
Cuidados essenciais
Já conseguimos perceber o quão importante é termos um log que comunica adequadamente no momento em que ele é acionado, mas ainda existem outras preocupações que devemos ter ao criar um log.
Dependendo do tipo de sistema, existem regulamentações que obrigam o armazenamento de logs por um determinado período, o que nos mostra que os logs também estão ligados não só a área técnica, mas podem ter vínculos fortes ao próprio negócio.
Outro ponto importante sobre logs é a preocupação com LGPD (Lei Geral de Proteção de Dados), é necessário ter todo um cuidado em expor dados que sejam de fato necessários, que não sejam dados sensíveis e que sejam utilizados única e exclusivamente para um determinado fim.
Tracing
Me parece fazer muito sentido que para ter de fato a observabilidade, além de ter os números (Métricas) e as mensagens (Logs), é importante que eu saiba também a ordem desses acontecimentos.
É disso que se trata o tracing. Perceba, que um erro de forma isolada, não vai me dizer muita coisa, pois ele pode ter sido gerado por uma série de eventos anteriores e é nesse ponto que esse novo conceito vai nos ajudar.
Tracing vem de rastreamento e é exatamente o que ele faz. Ele mapeia toda a vida do evento ou processo do começo ao final.
Exemplo de tracing
Para ser mais claro, imagine que você trabalha em uma arquitetura com vários microsserviços – poderia ser qualquer outra arquitetura, mas resolvi trazer o exemplo de microsserviços, primeiramente para te incentivar a olhar um pouco para esse mundo que tem crescido nos últimos anos caso ainda não conheça, e segundo por ser uma arquitetura onde conseguimos perceber o poder do tracing no dia a dia.
Se quiser aprender mais sobre microsserviços, tem um vídeo muito legal de um cara fera, o Rafael Ponte. Ele traz uma explicação bem didática sobre sistemas monolíticos e microsserviços no Zup Clipes:
Voltando ao exemplo, sabemos que os microsserviços são regidos por eventos. Um evento pode começar em um microsserviço, gerar uma informação quebrada que não afeta ele e esse evento vai ser distribuído entre diversos outros microsserviços, mas digamos que durante a distribuição desse evento, ele venha a quebrar apenas no final do fluxo.
Confira o exemplo na imagem abaixo:
Digamos que um sistema tem uma jornada de faturamento, onde existem três microsserviços (na imagem acima): um cuida do faturamento; outro dá baixa no estoque e gera um identificador do pedido; e o último pega esse identificador e gera uma nota fiscal para a pessoa cliente.
Até aí tudo certo! Agora imagine que a pessoa desenvolvedora esqueceu de criar um tratamento para que, caso não existisse o item no estoque, o faturamento fosse cancelado e isso acabou causando o seguinte problema:
Toda vez que clientes tentavam faturar um determinado produto, ele seguia todo o fluxo e no final não conseguia emitir a nota, dando um erro de que não identificou o produto, porém o faturamento aconteceu.
Uma outra pessoa programadora, que acabou de chegar na empresa, pega o incidente para tratar, só que não existe uma ferramenta para rastrear o fluxo, onde vai ser o primeiro lugar que ela vai procurar o problema?
Isso mesmo, pelo gerador de notas…. sendo que o problema aconteceu lá no meio do fluxo quando a gestão de estoque não identificou o produto.
Se existisse uma ferramenta de tracing implementada, seria possível identificar facilmente onde o problema havia ocorrido e evitaria a perda de horas de análise, talvez dias, dependendo do tamanho da empresa, para identificar e sanar o problema.
Estamos falando aqui de um exemplo bem simples, mas imagine isso acontecendo em uma loja on-line, que vende para o mundo todo e que seus microsserviços estão distribuídos entre diversas localidades.
Se eu não tiver rastreabilidade, como eu vou identificar essa falha apenas com o log? Vai ser uma tarefa bem difícil, se não até impossível! Diria que poderia até quebrar a empresa.
Apenas para arquitetura grandes?
Então, estou dizendo que o tracing só é necessário em arquiteturas grandes? De jeito nenhum, durante o desenho da aplicação é necessário que a observabilidade seja um dos requisitos desde a concepção do projeto e ela irá ganhar maturidade ao passo que o produto for ganhando escala.
Com isso, uma vez que eu tenho métricas, logs e tracing, eu tenho observabilidade e ainda nessa publicação vamos conhecer alguns stacks que vão nos ajudar a implementar esses três pilares.
Stacks de observabilidade
Existem diversos stacks disponíveis no mercado para todo tipo e tamanho de arquitetura. O mais importante na hora de escolher a sua stack de observabilidade é entender que ela precisa ser vista simplesmente como um meio para atingir seu objetivo, que no final será a observabilidade.
O que quero dizer é que você não deve se apegar a popularidade de uma determinada ferramenta, pois ela pode ser muito boa para entregar valor em um tipo de arquitetura e não ser a ideal para o seu tipo de arquitetura.
Então a primeira coisa antes de escolher a sua stack é conhecer a sua necessidade, seu capacity técnico e financeiro, definir de fato onde você quer chegar. Não coloco isso como regra, provavelmente existam metodologias diversas para isso, mas eu diria que um bom começo é olhar para os pilares da observabilidade e implementá-los um a um de forma individual até alcançar o resultado desejado.
Uma das stacks mais conhecidas no mercado é o Elasticstack, por isso vou focar nele nesse artigo, mas lembre-se que não existe um parâmetro único para a escolha da stack, são muitas variáveis que vão determinar a sua estrutura de observabilidade.
Para entender melhor o que é o Elasticstack, vamos voltar alguns anos atrás, quando tínhamos o seu irmão que se chamava ELK STACK.
ELK STACK: história e evolução
“E” de Elasticsearch
Segundo o site elastic.co, Elasticsearch é um mecanismo de busca e análise de dados distribuído, gratuito e aberto para todos os tipos de dados, incluindo textuais, numéricos, geoespaciais, estruturados e não estruturados.
Em poucas palavras, nada mais é do que um search engine analytics, ou seja, você vai jogar dados lá e ele vai conseguir fazer uma busca e análise de forma muito rápida. É claro que na prática, ele é muito mais que isso e é interessante entender um pouco mais sobre ele na sua documentação.
Para lhe ajudar a direcionar suas pesquisas sobre o Elasticsearch, eu trouxe algumas das suas principais características:
- É um Search Engine e Analytics;
- É extremamente rápido;
- É escalável;
- Possui uma API REST, todas as requisições funcionam por meio de uma interface REST;
- Consegue trabalhar com análise e visualização geoespacial;
- Consegue fazer Application Search, website search e enterprise search;
- Armazena e analisa logs do sistema;
- Trabalha de forma distribuída através de shards (índices) que possuem redundância de dados;
- Pode trabalhar com milhares de servidores e manipular petabyte de dados.
De fato, o Elasticsearch é uma ferramenta incrível e acabamos de ver o motivo de estar entre as principais ferramentas de análise de dados que temos atualmente. Com ele, conseguimos armazenar uma quantidade enorme de logs, de tracing e prover a tão falada observabilidade.
“L” de Logstash
O Logstash é um pipeline de processamento de dados do lado do servidor, que realiza a ingestão de dados de várias fontes, os transforma e os envia para seu “stash” favorito, que na grande maioria dos casos vai para o Elasticsearch.
Basicamente, o Logstash consegue pegar dados de onde você precisa analisar, seja de um webserver ou dos logs de algum cluster de contêineres. Depois é possível analisar tudo isso dentro de um Elasticsearch da vida.
Para te ajudar a entender um pouco mais sobre Logstash, também separei algumas características sobre ele:
- É uma engine coletora de dados em tempo real;
- Trabalha com pipelines;
- Recebe dados de múltiplas fontes;
- Normaliza e transforma os dados de modo que o Elasticsearch consiga visualizá-los;
- Envia dados para múltiplas fontes;
- Trabalha com uma série de plugins que possibilita realizar inúmeras manipulações nos dados.
“K” de Kibana
O Kibana é uma interface de user gratuita e aberta que permite visualizar seus dados do Elasticsearch e navegar no Elasticstack. Com ele, é possível rastrear a carga de consulta, entender como as solicitações fluem pelos seus aplicativos e muito mais.
Segue também algumas características importantes sobre o Kibana:
- É uma ferramenta de visualização e exploração de dados;
- Pode ser usados com:
- Logs;
- Análise de séries;
- Monitoramento de aplicações;
- Inteligência operacional;
- Detecção de anomalias por meio de machine learnings;
- Integrado com o Elasticsearch;
- Permite criar agregadores e filtragem de dados;
- Possui dashboards;
- Possui gráficos interativos;
- Possui mapas;
- Entre outros.
De fato, o Kibana tem muita, mas muita coisa mesmo. É natural se perder no começo, mas vá devagar, mapeando suas necessidades. Você não precisa e não vai usar tudo que o Kibana entrega, mas certamente vai encontrar tudo o que precisa nele.
Muito bom, mas até agora falamos apenas do ELK Stack e ainda não falamos nada sobre o Elasticstack. Então, qual a diferença entre eles?
Para explicar melhor essa diferença, vamos falar sobre um projeto da elastic, que foi anunciado em 2015: o BEATS.
Beats
O Beats é definido como um “lightweight data shipper”, um entregador de dados leve.
Ao longo do tempo, profissionais de engenharia da elastic perceberam que o número de locais de onde puxamos dados de análise aumentam mais a cada dia e, por padrão, a família ELK Stack trabalhava apenas com o Logstash, que é muito bom, mas dá muito trabalho para coletar dados em vários locais diferentes.
Então, foi lançado o Beats, que faz a mesma coisa do Logstash de forma muito mais rápida, se tornando um novo agente coletor de dados. O Beats pode ser segmentado pelo tipo de dado que você quer trabalhar.
Em resumo, com ele é possível coletar logs, métricas, network data, Audit Data, Uptime e Monitoring. No final das contas, a adição desta nova ferramenta no conjunto de stacks da elastic, deu origem ao Elasticstack.
Elasticstack
Dessa forma, quando falamos de Elasticstack, estamos falando do ELK STACK com a adição do Beats. Ela é uma solução paga e que pode gerar dados tanto para o Logstash quanto para o próprio Elasticsearch, que hoje está quase substituindo totalmente o Logstash.
Inclusive, normalmente veremos mais empresas trabalhando com o Elasticstack do que ELK STACK.
Prometheus: uma rápida descrição
Já falamos um pouco sobre o Elasticstack, que nos traz um conjunto de stacks capazes de entregar muito valor ao negócio e montar de fato uma estrutura completa de observabilidade, não poderíamos deixar de falar um cara que é muito conhecido e utilizado no mercado que é o Prometheus.
Ele é uma solução open-source que traz uma proposta de trabalhar com métricas, alertas e outras soluções de monitoramento. Em resumo, quando você pensar em Prometheus, lembre-se de métricas e alertas.
Conheça algumas características interessantes do Prometheus:
- Trabalha com dados dimensionais;
- Possibilita consultas poderosas;
- Fácil visualização de dados em conjunto com o Grafana;
- Storage eficiente;
- Simples;
- Alertas inteligentes;
- Diversidade de clientes e integrações.
A ideia não é detalhar completamente as stacks nesse artigo, se não acabaria deixando de ser um artigo e passaria a ser um livro, e por isso, você sempre pode se aprofundar um pouco mais na documentação da ferramenta Prometheus.
Grafana
O Grafana é uma outra ferramenta muito conhecida, open-source e muito utilizada por grandes empresas. Ele foi construído com base no princípio de que os dados devem ser acessíveis a todo mundo em sua organização, não apenas a uma única pessoa de operações.
Ao democratizar os dados, o Grafana ajuda a facilitar uma cultura em que os dados podem ser facilmente usados e acessados pelas pessoas que precisam, ajudando a quebrar silos de dados e capacitar as equipes.
Uma coisa bem legal no Grafana é que ele não exige que você realize ingestão de dados. Em vez disso, adota uma abordagem única para fornecer um “painel único” unificando os dados existentes, onde quer que estejam.
Você pode pegar qualquer um dos dados existentes – seja do seu cluster Kubernetes, raspberry pi, diferentes serviços de nuvem ou até mesmo do Google Sheets – e visualizá-los como quiser, tudo em um único painel.
Além disso, o interessante é que você consegue fazer isso por meio de simples consultas, que são possíveis graças a um número expressivo de plugins disponibilizados para integração com diversas plataformas, inclusive AWS.
Se alguém perguntasse para mim quais motivos teria para usar o Grafana, eu diria:
- Porque facilita a criação de dashboards unificados com dados de origens diferentes;
- Cria dashs mais flexíveis e versáteis;
- Possibilita compartilhamento de dashs com outras pessoas da equipe.
Se você deseja criar um dashboard com métricas de altíssimo nível, com uma ferramenta testada pelo mercado, open-source e muito confiante, o diria para começar com o Grafana.
Sugestões de conteúdo
Para complementar seus estudos, gostaria de compartilhar ainda um conteúdo da AWS, que traz alguns conceitos relevantes sobre o tema e é uma referência por oferecer um ambiente completo de observabilidade.
Além disso, deixo a seguir uma lista com algumas stacks usadas no mercado, além das que já foram citadas nesta publicação.
- ELK
- DYNATRACE (MACHINE LEARNING, APM)
- PROMETHEUS
- GRAFANA* | ALERT MANAGER
- GRAYLOG
- KIBANA
- JAEGER (Traços distribuídos)
- Proxy(envoy, Traefik, Kong)
- APM (Application performance management) (Kiali)
Conclusão
Bom, até aqui conhecemos algumas das stacks mais utilizadas para termos observabilidade, falamos sobre seu conceito, diferenças entre observabilidade e monitoramento, sua importância para análise e tomada de decisões técnicas e de negócio.
De qualquer forma, é importante ressaltar que ainda existe muito mais a ser estudado em termos culturais e funcionais, uma vez que o contexto de negócio de cada organização poderá demandar níveis diferentes de observabilidade e influenciar diretamente na forma como programamos.
Programar orientado a observabilidade é se preocupar não apenas com o agora, mas também com o depois. Isso é algo que deve acontecer desde a concepção do software, para que possamos garantir que ele estará pronto para suprir a necessidade dos três pilares da observabilidade, atrelado às tecnologias de inteligência artificial, detecção de anomalias e muito mais.
Espero que esse conteúdo tenha sido relevante para o que você estava buscando. Enquanto isso, curta os estudos, aprenda sempre, não pare nunca.
Se ainda não se inscreveu na newsletter, não perca tempo. A ideia é compartilhar dicas e trazer cada vez mais informação de qualidade para a comunidade de devs. Até o próximo artigo. =D
Referências
- Centralize, transforme e oculte seus dados – O “L” vem de Logstash
- Curso FullCycle – Mas, o que é observabilidade; Pilares da observabilidade
- Observability vs. Monitoring: What’s the Difference? – Observabilidade x monitoramento
- O coração do Elastick Stack gratuito e aberto – ELK Stack sua história e evolução
- O que é a observabilidade – Mas, o que é observabilidade; Pilares da observabilidade
- Whats is observability – O que é observabilidade e sua importância no tempo de vida do sistema
- What is Prometheus? – PROMETHEUS, uma rápida descrição
