bom pessoal por último aqui e não menos importante sobre observabilidade eu quero falar pra vocês sobre um projeto que ele é muito promissor já dá pra usar diversas partes dele em produção em algumas linguagens de programação e que na minha opinião é o futuro da observabilidade. Esse projeto é chamado de Hotel ou Open Telemetry. Ele é um projeto muito sério, ele é um projeto também mantido pela CNCF, a Cloud Native Computing Foundation, e a ideia do Open Telemetry é a seguinte, vamos falar sobre isso, é um CNFSS project, e ele é baseado no Open Tracing e no Open Census. Antigamente, existia um projeto chamado Open Tracing que fazia o quê? Gerava um padrão para essa parte de rastreamento. Por quê? Porque daí todos os vendors, todas as empresas, todas as soluções que querem ter rastreamento implementam essa especificação e daí fica fácil fazer o switch. Mesma coisa que com o OpenCensus. E o OpenTelemetry é a ideia dessa junção. Aí o que acontece? O OpenTelemetry é baseado no quê? Em especificações, eu acho que uma das coisas mais importantes é, quando você vai falar sobre a observabilidade, você tem diversas ferramentas, você tem diversos players. Esses players têm agentes que mandam informações do seu sistema para eles. Agora, essas informações, se elas seguirem a mesma especificação, o que acontece? Essas informações, se elas seguirem a mesma especificação, o que acontece? As coisas ficam muito mais padronizadas e fica muito mais fácil, inclusive, você mudar de um player para o outro e isso acaba sendo vantagem para todo mundo. Um outro ponto importante é especificar também protocolos. Eles criam protocolos específicos para a parte de telemetria. protocolos específicos para a parte de telemetria. E também, além disso, eles geram um SDK, ou seja, kits de desenvolvimento para diversas linguagens. Então, imagina que eu quero utilizar o OpenTelemetry para mandar informações de tracing que eu estou trabalhando. Então, ao invés de eu ter que olhar especificação, criar minha biblioteca, sei lá, em Go, para a linguagem Go, por exemplo, eu pego a biblioteca pronta, que a galera da OpenTelemetry fez, e faço o quê? Eu importo e já saio utilizando. Mesma coisa com as principais linguagens. Java, JavaScript, Python, C, C++, Ruby e assim por diante. Então você tem esses sdk uma outra coisa interessante também são ferramentas de integração como assim às vezes tá você não quer ficar customizando a sua aplicação para que para que a sua aplicação fique gerando esses dados para mandar para o seu vendo então esses sdk se mais algumas ferramentas elas ajudam gerar esses dados de telemetria tá a de forma automática isso a gente chama de instrumentação. Ou seja, vamos imaginar que eu tenho um software em Java, e o que eu faço? Na hora de eu subir Java, menos já, etc., eu passo um parâmetro falando que eu quero que ele passe para a instrumentação do OpenTelemetry. Então, ele já fica ali, esse sistema de instrumentação, em tempo de execução, fica escutando a sua aplicação, pegando todos os dados dela para enviar. Agora, o grande ponto é enviar para onde? E é por isso que a gente fala de integração. As ferramentas, quando você trabalha com esses SDKs do OpenTelemetry, a gente tem duas opções. Uma opção é mandar os dados diretamente para o back-end, e o back-end que eu digo é um vendor, tipo Elastic Stack, New Relic, Datadog, ou mandar os dados para um coletor. O coletor é um cara intermediário que recebe essa informação, trata essa informação e depois manda para um back-end. Legal? A gente vai falar sobre isso agora. Olha só que interessante. Está vendo ali que você tem uma aplicação, aplicação do lado... Deixa eu pegar meu mouse, fica melhor aqui para eu ver. Essa minha aplicação está usando uma biblioteca do OpenTelemetry, uma SDK. Legal? Então, tudo o que está acontecendo com essa minha aplicação os dados são enviados por um coletor esse coletor é um agente ou seja ele pega essas informações e joga para um becky and o que é um becky and um da inatrice um deitado g um Elastic Stack e etc. Legal? Então, esse coletor, ele funciona como agente, manda para esse back-end ou manda para esse back-end. Essa é uma opção. Legal? Outra opção que você tem aqui também é o seguinte. Eu tenho essa outra aplicação que utiliza o OpenTelemetry, a library do OpenTelemetry e depois o que acontece? Ela manda essa informação para um coletor, para um agente e esse coletor manda a informação para um outro coletor que é um serviço. Então aqui é um agente e aqui é um service, um sistema de coletor. Imagina, um outro servidor pode estar em uma outra instância rodando, um outro pod, sei lá, do Kubernetes. E aí, o que acontece aqui? Esse coletor pega esses dados e manda para o back-end. Legal? Também tem a opção, não está aqui, eu posso pegar a minha aplicação e jogar direto para o meu serviço de coletor. Também há essa opção, apesar de ela não estar nesse desenho aqui para vocês. Agora, eu não sei se vocês já perceberam uma coisa. Olha só que interessante. Você conseguiu perceber que essa aplicação está dentro de um host? Ela está dentro de um servidor? que essa aplicação ela está dentro de um rosto ela está dentro de um servidor e junto dessa aplicação a gente tem esse coletor esse coletor aqui tá dentro do mesmo rosto aqui dessa aplicação não tá e ele está se comunicando com essa aplicação concorda Esse padrão aqui que você está vendo é chamado de Sidecar. A gente falou sobre Sidecar na parte de Design Patterns. Legal? Olha só que interessante. Então, o que você está vendo aqui é um Sidecar. Legal? Ou seja, o coletor do OpenTelemetry aqui é considerado um Sidecar. Ou seja, ele fica do lado da sua aplicação se comunicando eu poderia dar um coletor de métricas que nem a gente está fazendo agora eu poderia ter um coletor é quer dizer um outro site de card alguma outra coisa mas olha só que interessante legal então uma outra coisa importante sobre as esses coletores aqui do open telemetry é o seguinte, ele não só pega o dado e joga para o coletor, e daí o coletor manda, sei lá, para o Elastic, mas esse coletor funciona como um serviço de tratamento dessa informação. Legal? Então eu posso pegar essa informação, transformar essa informação no meio do caminho, dentro desse serviço, e o serviço pegar essa informação dentro de um padrão para jogar para o back-end. Então você consegue criar uma espécie de transformação aqui dentro para você conseguir fazer isso. Uma coisa, uma grande vantagem que você tem de conseguir fazer e utilizar esses coletores ou mandar os dados com essas bibliotecas, é que como os backends implementam o padrão da especificação do OpenTelemetry, vamos imaginar que esse backend 1 é o Elastic Stack e vamos imaginar que esse outro cara aqui é o WS CloudWatch. E você uma hora está mandando os dados por Elastic Stack e daí você fala, não, eu fiz um acordo com a WS, eu quero pegar esse cara e jogar o Elastic Stack no CloudWatch. Eu mudo a configuração do meu coletor, o endpoint, e ao invés dele mandar para o Elastic, ele manda para cá e eu não precisei mudar o código da minha aplicação legal então é isso que é o ponto importante eu não tenho que fazer uma implementação para cada vendedor para cada back-end ou seja eu simplesmente muda os endpoints obviamente muda uma configuração no meu coletor e daí essa informação já vai então isso gera um poder muito grande na mão tá dos desenvolvedores e também facilita muito essa integração entre vendas lembrando uma coisa interessante inclusive lembra que eu falei pra vocês que tem algumas empresas que trabalham com logs, joga no Elastic, e o tracing joga, sei lá, no Datadog, dá para fazer isso por aqui. Eu posso falar que esse meu coletor vai pegar todas as métricas e jogar no Backend 1. Está vendo? Métricas e tracing. E eu quero pegar só métricas também e jogar no Backend 2. Então, eu jogo aqui. Então eu consigo fazer com que o meu coletor se comunique com diversos back-ends e mande as informações que eu quiser para cada um dos back-ends de uma vez só. Mas o mais interessante é que a sua aplicação não precisa necessariamente ficar se comunicando com cada back-end. Você manda a sua aplicação se comunicar só com esse sidecar porém você sim tem a opção de fazer a sua aplicação mandar informação direto para o beckens dá para fazer isso também não necessariamente você precisa ficar usando o collector todas as vezes mas é mais recomendável porque porque o collector ele usa o tempo dele para mandar essas informações ao invés de você ficar fazendo chamadas sincronizadas aqui direto um beckham legal então essa que é a ideia aqui desse projeto do Open telemetry é importante você saber que esse projeto existe no momento que eu tô gravando tá já existem linguagens de programação que já tem os sdk as métricas e patrícia existem também linguagens que têm só três sim e os métricas não estão implementadas existem linguagens que têm métricas de tracing que estão em alpha e logs estão em alpha. Ou logins não estão implementados. Então, o que eu recomendo? Sempre, se você quiser olhar o OpenTelemetry, entra no site do OpenTelemetry. Eu acho que é o OpenTelemetry.io. Lá tem as linguagens. Você clica na linguagemagem ele vai mostrar pra vocês o status de implementação dos sdk tanto para três em blogs e métricas e daí ele mostra isso já está estável e etc você sabe quando e qual você pode utilizar somente uma dica aí pra vocês beleza então era isso aí que eu queria falar pra vocês tá galera principalmente sobre? Então era isso aí que eu queria falar pra vocês, tá galera? Principalmente sobre essa parte de observabilidade. Então, vamos seguindo aí.