Olá, tudo bem? Vamos falar agora das principais ferramentas. E algo que acho que talvez eu não tenha deixado claro no vídeo anterior, acho que é pra dar um reforço, antigamente era comum você ter aplicações rodando em servidores que você cuidava ali com... que se você tinha um cuidado maior, enfim, a aplicação era mais perene. Hoje as aplicações são mais voláteis. Por exemplo, um container rodando no AWS CS, por exemplo, ou rodando no Kubernetes, tem uma vida útil de nem dias, às vezes tem uma vida útil de horas. Então o container pode aparecer, rodar por algumas horas e desaparecer. Vou até piorar esse cenário. Soluções hoje serverless, como por exemplo AWS Lambda, Azure Functions, a vida útil desse componente é pelo tempo de execução daquele código que você implementou. Então, está falando de minutos de duração até segundos. E se esse componente falhar, ter uma ferramenta de login apropriada é crítico naquele ponto que eu trouxe sobre a aplicação falhar ou parar de rodar ou ela terminar de fato a execução e acabar abrindo mão e disponibilizando de volta a infraestrutura, acabar deixando, enfim, não precisa mais daquela infraestrutura que ela tinha alocado e devolver para o gerenciador de infraestrutura, ela precisa pelo menos ter gravado os logs, as métricas que ela utilizou em algum lugar para que você consiga consultar futuramente. E usar uma ferramenta apropriada é importantíssimo. Existem muitas ferramentas de observabilidade no mercado. Minha ideia é passar as principais que eu particularmente já vi, já comentei, já trabalhei, inclusive, com, e vamos usar algumas aqui para fazer o rendizão vou começar com a mais comum mais conhecida que é o é o o LK stack e é o que stack ou elástico stack stack de três ferramentas é conhecidas como elástico logstash para captura de logs, o Elasticsearch, que é a camada de persistência, e você consegue rodar as carries dos logs dos eventos que chegam, e o Kibana, que é uma camada de visualização, especializada em visualização de dados, para você montar seus dashboards, etc. Uma outra ferramenta que também é bastante utilizada é o Splunk. O Splunk era muito fortemente utilizado para captura de logs, mas ele tem funcionalidade de tracing, por exemplo. Então pode ser uma ferramenta muito interessante para você utilizar, só que ela é uma ferramenta paga. Duas ferramentas que geralmente andam em parzinho, mas elas têm propósitos diferentes. Sempre que você geralmente falar de Prometheus, você vai ter geralmente o Grafana de mão dada ou vice-versa, mas são ferramentas diferentes, com propósitos diferentes e você pode utilizar com outras ferramentas. O Prometheus é a camada de persistência de de métricas por exemplo ele consegue armazenar métricas e você consegue utilizar o promíteros para realizar queres dessas métricas o grafana camada de visualização dos dados e o grafana ele consegue interpretar os eventos ali outras palavras ele fala a língua do promíteros para para disponibilizar as métricas que você capturou em dashboards sofisticados e otimizados para você. Mas o Grafana se integra com várias outras ferramentas, com a AWS, por exemplo, do Watchmetrics e assim por diante. Aí você tem, por exemplo, as ferramentas de observabilidade dos fornecedores de cloud específicos. Por exemplo, se você estiver utilizando a AWS, pode ser interessante você utilizar, se você não tem preocupação em buscar uma solução híbrida ou multi-cloud, você pode utilizar a solução nativa que é o CloudWatch. O CloudWatch entrega para você ferramentas de métricas, de tracing e de logs, que é o mais comum, que é o CloudWatch Logs. E tem solução de alarme, inclusive eu esqueci de comentar, a Promete, a Grafana, também tem uma solução de alarme e tal. E você tem um Azure Monitor, que é a solução nativa de monitoramento e observabilidade do Azure. Se você quiser uma solução especializada em tracing, essa solução, por exemplo, CloudWatch tem o X-Ray, Splat tem solução de tracing, mas se você quiser uma aplicação que entrega apenas tracing, você pode utilizar, por exemplo, o mais comum, conhecido hoje é o Jaeger, tem o Zipkin também, que são ferramentas especializadas em tracing. Se você quiser partir para uma ferramenta que te entrega um conjunto de features e consegue te ajudar até correlacionar esses eventos, esses elementos, com uma experiência única de observabilidade, você pode recorrer aos conhecidos APMs, ou Application Performance Monitoring. Os conhecidos APMs, ou Application Performance Monitore, os conhecidos aqui, o Dynatrace, o DataRog, o New Relic, o AppDynamics, eles entregam ali para vocês soluções de métricas, de tracing, logs, e você consegue correlacionar esses eventos, por exemplo, criar alertas a partir de logs, enfim, etc. E não posso deixar de falar do OpenTelemetry. O OpenTelemetry não é necessariamente a ferramenta específica X de observabilidade, mas ele é um consórcio, praticamente, é um framework que tem um consórcio de vários provedores de observabilidade, enfim, cloud computing e ele integra essas ferramentas, ou seja, ele minimiza a complexidade para a integração de diversas ferramentas buscando uma experiência única. Ele não é um APM, mas ele é um framework que busca te entregar uma experiência única, independente da ferramenta específica que você utilizar. Vamos falar um pouquinho no detalhe dos APMs hoje. A Application Performance Monitoring, como eu falei, ele vai buscar uma entrega ali, uma experiência única para você utilizar. Então, ele vai entregar para você, por exemplo, uma camada de logs, Eles vão entregar para você, por exemplo, uma camada de logs, de métricas, de tracing. São os pilares comuns de observabilidade, mas tem conceitos novos que estão surgindo que não estão diretamente relacionados ali. Conceitos que ainda não estão 100% difundidos, mas estão sendo considerados hoje, por exemplo, como outros pilares de observabilidade, levando o nível de outros pilares de observabilidade, levando ao nível de maturidade de observabilidade, que é profiling e error tracking. O error tracking é interessante porque, por exemplo, quando você loga uma exception, vamos ver isso na prática no hands-on, mas quando você loga uma exception na camada de log, é comum que uma exception seja logada com múltiplas linhas, e o log é comum que o mais certo ela seja alugada com múltiplas linhas e o log orientado a linha do cada evento de log uma linha e aí para você fazer um troubleshooting facilitar a pesquisa fica difícil você conseguir enxergar a excepção e conseguir tratar tá então além disso ele consegue te ajudar por exemplo a fazer tracking de diversão se tem uma aplicação com a versão X, ela começou a apresentar um erro, você consegue ter um tracking para saber se foi a versão, enfim, ou se foi alguma coisa externa. Por exemplo, a biblioteca que você utiliza tem um upgrade, mas ela começou a apresentar uma exceção e por conta disso, sua aplicação está sendo impactada. E o profiling, que permite você olhar é consegue fazer um preço a nível de código é como se fosse um trem sim mas no nível da aplicação é só aplicação é composta por vários métodos submétricos várias funções o functions que chama outras funções eventualmente serviços externos mas olhando para dentro da sua aplicação o profile Profiling te ajuda a identificar, por exemplo, se um método ou uma função específica está custando mais caro do ponto de vista de CPU, memória e tempo de execução do que deveria. Se está tendo algum tipo de threading, de lock de threading, enfim, ele pode te ajudar a olhar e fazer o Profiling da aplicação, ele pode te ajudar se um método, uma função está custando mais do que deveria e você conseguir atuar especificamente naquele ponto, buscando uma otimização da sua aplicação. Então, por que é interessante citar essas ferramentas? Às vezes você está olhando aqui do lado de métricas, que você está tomando muitos erros de timeout, a latência está aumentando, e às vezes, só olhando pelas métricas, é difícil saber qual é a causa raiz. Às vezes é do lado da aplicação, voltando atrás aqui, às vezes as pessoas têm até a atitude de aumentar o recurso computacional daquele container, aumentar a memória, a RAM, e às vezes é um método ou um conjunto de funções, de métodos dentro do código que está mal implementada ou está mal otimizada e você precisa melhorar a complexidade ali daquele código, a complexidade funcional daquele código, visando melhoria de performance, tá? As vezes o problema está dentro, não fora. E essas são as ferramentas que entregam isso para você, são as quatro das ferramentas que entregam para você uma experiência unificada. Tem ferramentas exclusivas de error tracking, por exemplo, o Sentry. Tem ferramentas exclusivas de profiling. Você pode usar, inclusive, o profiling integrado à IDE, mas essas ferramentas conseguem entregar uma experiência única para vocês, já olhando para esses pilares. Eu não posso também deixar de falar do OpenTelemetry, como eu falei. O OpenTelemetry é um framework, ele entrega uma experiência unificada, ele não é uma ferramenta específica, mas ele, a sua especificidade, o seu objetivo, a entrega de valor dele, está em entregar vários componentes de observabilidade, infraestrutura de forma que você consiga como dizia, plug and play ele se adequa se adapta àquela ferramenta, àquela solução que você está utilizando com o menor esforço então por exemplo aqui você consegue integrá-lo ao Splunk ao Elastic Stack aqui, ele se integra ao Jager, ele se integra ao Grafana, ele se integra até as ferramentas de EPM, por exemplo, da Trace, etc. Ele se integra até as ferramentas de Cloud, e aí são mais de 40 fornecedores de infraestrutura, provedores de Cloud e de observabilidade que contribuem com esse framework, de forma que você consiga utilizar da melhor forma.