 Beleza, William. Obrigadão. Vou deixar o palco aqui no JuraCin também. Vou continuar aqui. Beleza, bacana. Obrigado, William. Obrigado, Ricardo. Quanto? Começa a compartilhar. Deixa eu ver se funciona aqui. Já compartilhar na tela. Compartilhar. Eu espero que vocês agora estejam vendo a minha tela. Se não, alguém, por favor, dê um grito. Antes de começar, essa é a nossa conversa que eu queria primeiro agradecer demais aos organizadores desse QBHG10. Eu assisti várias palestras hoje muito interessantes para começar pelo keynote, mas eu acho que o highlight para mim é a chave hoje, o melhor do dia até agora foi a dormitoria. Se você não assistiu à dormitoria, espera chegá-la no YouTube e assista. Vale muito a pena. Muito bacana. Mas é isso, é. Mas agora a gente vai falar tudo o que você precisa saber sobre Open Telemetry. Eu não me juro a ser Baixam Crolling, eu sou engenheiro de software na Grafana Labs e eu sou um antenador no projeto Open Telemetry. O projeto Open Telemetry já é o segundo projeto mais ativo na Cloud Native Computing Foundation, e isso é um reflexo do tamanho do projeto. O projeto é muito grande, tem muita coisa, muitas frentes de trabalho sendo feitas. Então, essa apresentação que hoje, essa próxima meia hora, a gente vai falar não de tudo o que há para saber sobre Open Telemetry, mas de tudo o que você realmente precisa saber sobre Open Telemetry para ser efetivo no seu trabalho. Então, se você é uma pessoa que trabalha como SRE, ou você é uma pessoa que trabalha como DevOps, você vai saber qual o foco que você pode ter com Open Telemetry. Se você é um desenvolvedor, se você é uma pessoa desenvolvedora, dê uma olhada também na parte de instruição que é mais interessante para você. Mas é isso. Então, na próxima meia hora, a gente vai falar um pouco sobre as origens do projeto Open Telemetry e a gente vai, então, falar sobre as três principais frentes de trabalho do projeto. Primeira é sobre os padrões e especificações, e depois nós falamos sobre instrumentação de aplicações, e a terceira parte, a terceira grande parte do projeto Open Telemetry é a partir do middleware, é o conduite ou pipeline para processamento de dados. A gente deve ter alguns minutinhos para falar sobre o futuro do projeto Open Telemetry e, lá no fim, nós devemos ter alguns minutos para perguntas e respostas. Mesmo que nós não temos muito tempo para perguntas e respostas, eu estou aberto a te responder em qualquer canal que você consiga me achar. Então, eu tenho aqui nessa tela se você consegue ver qual é o meu contato no Twitter, você pode me perguntar no Twitter, mas lá no final, no último slide, compartilho também em quais canais do Slack que eu sou mais ativo. Então, vamos começar. É impossível falar sobre Open Telemetry e não falar sobre Open Tracing. Open Tracing era um projeto que tinha como objetivo servir de padrão para arrastamento distribuído, então, alguns anos atrás, acho que agora é um simples, seis anos atrás, talvez, algumas pessoas que já trabalharam com arrastamento distribuído se juntaram para trocar figurinhos, para trocar experiências, para falar como é que funciona essa empresa aqui, como é que funciona aquela empresa ali e as pessoas perceberam que existia uma deficiência na parte de termologia. Então, que uma pessoa falava que era um rastro, um rastreador, outra pessoa tinha um entendimento um pouco diferente. Às vezes, era parecido, mas alguma coisa aqui e uma coisa ali era diferente do que prejudicava o entendimento a implicação do conhecimento. Então, que as pessoas decidiram naquela época, de novo, cinco, seis anos atrás, foi sentar um mês e falar, olha, vão definir quais são os nomes, a quaternologia dessas ferramentas que estão se construindo. Então, criaram a especificação de rastreadamento distribuído, de distributor tracer. Então, criaram ali um documento que você fala o que é um rastreador, o que é um tracer, o que é um rastro, o que é um trase e o que é um trecho, o que é um spam. Ao mesmo tempo, um pouquinho depois desse começo, desse início, as pessoas decidiram, então, criar um outro documento, criar um entendimento na comunidade sobre as convenções. Certo, sobre o que eu devo incluir no meu ponto de dados, na minha informação, na hora que eu estou acolhetando. Então, se eu tenho um requerimento HTTP, por exemplo, chegando em um livro serviço, então eu sei, através das convenções semânticas, eu sei quais são os atributos que eu devo incluir nesse trecho. Então, de novo, se é um requerimento HTTP, eu posso incluir o método HTTP, então, HTTP.method, e aí posso colocar o false path, delete.get. Eu posso colocar as convenções semânticas me dizem também que eu deveria colocar a rota que foi solicitada, qual é a resposta que foi dada, o código de resposta que foi dada para o cliente e por exemplo. Obviamente que essas convenções semânticas não falam somente sobre requerimentos HTTP, eles falam também sobre, por exemplo, comunicação com o banco de dados, com sistemas de mensageria e por exemplo. Uma vez que esses dois documentos, essas duas frentes, estavam já bem avançadas, as pessoas decidiram então criar uma API, uma API para a instrumentação de aplicações. Então, a ideia é que fosse criada uma API, uma API para diversas linguagens, mas que tivessem o mesmo conceito. Ou seja, se eu sou um programador Java e agora estou fazendo uma aplicação em Gol, então eu sei que um tracer, um rastreador em Java, que não tem diferenças semânticas entre elas. Então eu posso ter certeza de que as funções que vou chamar são semelhantes a relação compatíveis entre si. Não há implementação dessas APIs, existe somente a especificação dessa API. Então cada projeto, por exemplo, um Yeager ou Zipkin, ou um fornecedor de serviço, eles são responsáveis por prover uma implementação para essa API. Então eu como desenvolvedor de aplicações, desenvolvedor de produtos, desenvolvedor de uma aplicação corporativa, eu posso então, no momento em que estou curtificando a minha aplicação, eu posso chamar as APIs das APIs de Open Tracing sem me preocupar com implementação, sem preocupar para onde que essa informação vai, para o Zipkin, para o Yeager, para um provedor específico, não importa. Na hora que estou resolvendo a minha aplicação, eu não tenho essa preocupação. Na hora que vou impactar na aplicação, na hora que vou compilar, na hora que eu vou preparar para ser executada, aí sim eu escolho uma implementação. Essa ideia, então, das APIs de Open Tracing. E por final, quando nós já temos as especificações, quando nós já temos as convenções simânicas, quando nós já temos as APIs de instrumentação, as pessoas desse projeto, então, chegaram numa outra ideia, uma outra ideia. Por que a gente não faz um projeto paralelo e começa o que a gente chama na época de instrumentar o mundo? Por que a gente não começa a utilizar as ferramentas que nós já temos e começarmos a instrumentar as bibliotecas que as pessoas já usam? Então, um Spring da vida, um Rails para Ruby e por aí. Então, foi criado, então, esse projeto paralelo, Open Tracing com Trip, onde nós criamos bibliotecas de instrumentação para esses frameworks, para essas bibliotecas muito populares. Então, a ideia é isso, você já tem uma aplicação desenvolvida utilizando Spring, por exemplo, então, você pode utilizar uma biblioteca de instrumentação que vai instrumentar o Spring para você. Então, a ideia é você consegue ter mais informações ou você consegue ter uma boa visibilidade sobre a sua aplicação ao observar, ao visualizar o que o Spring está fazendo. Obviamente que o Spring aqui é um exemplo. Existem bibliotecas de instrumentação para praticamente todos os bibliotecas e frameworks populares para eles. Não só para Java, mas para outras imagens também. O segundo projeto que nós temos que falar de Open Telemetry é Open Census. E Open Census tinha como objetivo ser a biblioteca para a captura de dados de telemetria. Então, a ideia é que seja um só projeto em que você utiliza uma biblioteca, você coloca uma load ou coloca uma sua arquivo de dependências, e seja uma só biblioteca que dissere como a API, como a API e como a implementação. Então, a ideia não é a de que eu troque a implementação na hora de execução ou na hora que eu empaco a tonelificação. A ideia é fornecer uma solução completa. O segundo lado do projeto Open Census é o desenvolvimento de um conduite, de um middleware, que recebe dados de aplicações e sabe como converter esses dados e enviar para diferentes sistemas de armazenamento. A gente vai falar um pouquinho mais sobre essa parte. Então, antigamente, o nome desse projeto é Open Census Service. Ele foi herdado pelo Open Telemetry e a gente sabe até pouquinho também. Talvez a maior diferença entre Open Census e Open Tracing seja de que o projeto Open Census tinha a ideia de ir além de arrastamento distribuído de distributed tracing. A ideia do Open Census era de ser uma biblioteca para a telemetria em geral. Então, havia a promessa de fornecer APIs e implementações SDKs para logs e para métricas também. Para métricas, chegou até lá. Acho que não chegou até o fim. Não chegou a ser estável, mas tinha a biblioteca da água para ser usada mais com logs. Essa promessa nunca se prejudizou. Como a gente vai ver porque em alguns segundos. E, finalmente, o projeto Open Census também tinha as bibliotecas de instrumentação assim como o projeto Open Census. Então, de novo, a ideia é que, se eu consigo visualizar, se eu consigo entender o que o Spring, por exemplo, está fazendo, eu consigo entender o que a minha aplicação está fazendo. Essa é a ideia por trás das bibliotecas de instrumentação. Se você presta atenção nesses últimos cinco, sete minutos, você deve ter feito um paralelo, uma comparação do Open Tracing com Open Census e viu que apesar de serem diferentes em algumas áreas, eles são iguais e outros. Ou seja, eles competem em algumas partes e se complementam em outras. Obviamente que isso era também bem aparente para as pessoas trabalhando nos dois projetos. Muita gente na comunidade, na época, vinha e perguntava com a gente que não despedisse de engenharia. A gente está fazendo as mesmas coisas. No caso das bibliotecas de instrumentação, por exemplo, estávamos fazendo as mesmas coisas com os mesmos objetivos e sem uma colaboração maior. Então há dois, três anos... Não, três anos, não cheia tanto. Mas há dois anos e pouco atrás, as pessoas livres das comunidades Open Tracing e Open Census se juntaram e decidiram formar um projeto. Decidiram se juntar por trás do projeto Open Tracing. Então Open Tracing e Ajunção de Open Tracing e de Open Census. Então esse projeto já nasce grande. Ele nasce com uma parte, a primeira parte aqui nesses slides, em azul, talvez, onde temos a especificação e as convenções simânticas. A segunda parte do projeto Open Telemetry são as APIs de implementação para diversas linguagens. Então, em boa parte, é dada de Open Tracing. A diferença básica aqui é que nós temos APIs e nós temos SDKs e que elas são em um modo separado. Então eu posso, se eu quiser, substituir um SDK por uma outra implementação. É uma coisa que eu não conseguia fazer tão fácil com Open Census e ao mesmo tempo nós provemos um SDK para os usuários uma coisa que Open Tracing não tinha. E obviamente que daí tem todo o trabalho na área de bibliotecas de instrumentação e aí é um trabalho conjunto entre as duas comunitacas. E por fim nós temos o terceiro grande tipo de trabalho dentro da comunidade open-front que é o trabalho na parte de middleware. Então middleware porque ele fica entre seu código de negócio entre suas aplicações de negócio e os sistemas de armazenamento de dados. Então imagina que de um lado você tenha suas centenas de únicos serviços que estão gerando dados de telemetria e enviando esses dados para esse middleware chamado de Open Tracing Collector e Open Tracing Collector então sabe entender que tipo de dados não tem quais tipos de dados persistir e sabe para onde enviar esses dados. Então eu sei que para aquele serviço ali eu tenho que enviar os dados para por míthios, por exemplo. Ou então para outras informações eu preciso identificar para esse provedor de serviços disso. Então a ideia é que seja esse middleware que se sente no meio dessas duas pontas, dessas duas partes e faça a intermitiação. O Open Tracing Collector como você já deve ter imaginado é uma evolução do open-sense service. Então vamos começar falando sobre a primeira parte das especificações e as convenções semânicas nessa parte de padrões e especificações. As duas primeiras partes, os dois primeiros círculos aqui, eles não são assim tão relevantes para a gente, então a gente vai passar bem rapidinho por eles mais o terceiro sim, o terceiro é bem interessante. Então o primeiro nós temos aqui a especificação da IPA. Então o primeiro é a primeira parte, o primeiro tipo de especificação que nós temos, o projeto open telemetry especificação da IPA ou seja, nós temos que ter a certeza de que todas as IPAs dentro do projeto open telemetry seguem o mesmo padrão, seguem a mesma tecnologia e que a semântica por trás dos nomes das funções é a mesma. Então se nós temos uma linguagem nova de programação que sua de pra todo mundo começar a utilizar então quem tem interesse naquela linguagem pode olhar para a especificação da IPA e falar e entender o que é necessário para lidar, para dar suporte de open telemetry para que é a linguagem em termos de biblioteca de instrumentação da IPA e de instrumentação. Bem semelhante nós temos para a especificação do SBK então ainda é exatamente a mesma, talvez com a diferença de que nós temos um segundo tipo de audiência então a primeira audiência são os desenvolvedores que estão ligados ao projeto open telemetry e essas pessoas, desenvolvedores vão olhar para essa especificação e falar e entender o que precisa ser implementado para que esteja em linha com o que existe nas outras linguagens então existe uma lista de funcionalidades que devem ser implementadas uma lista de variáveis de ambiente que devem ser aceitas para configurar devem ser quais tipos de exportadores quais tipos de de componentes que vão exportar esses dados para para sistemas estétricos e por aí vai. Então nós temos um conjunto de itens que devem ser satisfeitos para que essas decadas sejam compatíveis ou que elas sejam compatíveis com a especificação porque tem aquele aquele botãozinho clicado ali quando é compatível mas a segunda audiência que eu mencionei é se eu tenho por exemplo uma aplicação especial se eu tenho uma aplicação que não segue os padrões, que não é muito por exemplo uma aplicação para aplicativos uma aplicação para smartphones ou então uma aplicação sei lá, que roda no Edge, que roda em torres de celular ou então uma aplicação que precise de uma configuração de segurança um pouco maior então eu tenho a possibilidade de olhar para essa especificação do SDK e fazer a minha própria implementação então eu sei o que eu preciso fazer para que eu seja compatível com as aplicações que for utilizadas as APIs então eu vou chamar o SDK por trás dos planos e aí então o que eu preciso fazer para que eu continue compatível com as aplicações mas isso não é uma parte muito interessante para a gente eu imagino que a maioria de nós aqui nessa conferência na Guernariz com a NG10 sejam pessoas que são ou desenvolvedoras, ou que sejam na parte de operações ou que sejam pessoas no meio dessas boas áreas SRE pessoas de que trabalham como DevOps e nesse caso uma especificação que é muito interessante é importante entender a especificação de dados então a especificação de dados é basicamente um arquivo para quem já trabalhou com JPC é só um arquivo protobuf para quem não trabalhou com JPC o padrão é definido de um arquivo um arquivo IDL, um arquivo de interface definition language, uma linguagem de definição de interfaces e esse arquivo ele define quais são os serviços quais são os endpoints que devem ser implementados para que seja compatível com o padrão e nós especificamos também quais são as mensagens que são trocadas por essas interfaces então o que o cliente precisa enviar para que o servidor entenda e o que que o servidor precisa entender quando o cliente envia o tlp, o tlp então OpenTlmp protocol em alguns lugares, também OpenTlmp protocol simplesmente os dois são rápidos o que é importante saber é um arquivo, um conjunto de arquivos que existem em um repositório e que segue o padrão protobuf você talvez tenha pensado por que definir um projeto em um padrão de zero se já existem outros aqui como xkcd 927 se você não lembra qual é o xkcd 927 é esse aqui a situação é que nós temos 14 padrões competindo entre si 14RT que a gente precisa de um padrão porque substitua tudo que cobra todos os casos de uso de todo mundo aí de repente nós temos então 15 padrões que competem entre si e essa é a situação que nós tínhamos a situação que nós temos hoje de novo nós temos agora 15 padrões e 14 e a ideia é as pessoas obviamente que sabiam desse problema que tinha consciência que já existiam 14 padrões entiramente mas pesando todos os fatores ainda assim valeu a pena, valeria a pena teria valido a pena criar um padrão novo a ideia por trás é os três sinais que nós damos suporte hoje métricas, rastros, traces e logs são mais comuns então todos eles entendem a noção de recursos entendem a noção de atributos entendem a noção de eventos e por aí talvez eventos não mas enfim a base é a mesma para todos os tipos de dados e são compartilhados pelos três que nós temos hoje e pelos futuros que virão então essa é a ideia do porquê um novo padrão para todos os tipos de sinais ao invés de lutar padrões para sinais específicos que resultam um padrão para logs um padrão para métricas rastros então é isso essa é a primeira parte do projeto, essa é a parte de padrões e especificações acho que todos iam falar hoje e a segunda parte do projeto a segunda grande parte pelo menos na minha cabeça, é a parte de instrumentação aí nós temos três tipos de instrumentação a base é a primeira a que dá origem a todas as outras é a parte de instrumentação manual então nós temos aqui um conjunto de API um conjunto de API que nós podemos usar para fazer instrumentação manual da nossa aplicação instrumentação manual se o nome não está dizendo muita coisa é só uma questão é fácil de resolver você sabe que é instrumentação manual quando você está no seu código e você coloca lá logra.info no seu código para que seja impressa no arquivo de log isso é instrumentação instrumentação é o código que eu adiciono ao meu código para que eu tenha acesso a informações do runtime então eu posso estar jogando um evento com o social log eu posso estar adicionando um contador no caso de instrumentação de métricas ou posso estar iniciando e fechando um trecho em spam no caso de traces então essa é a base de tudo essa é a API que nós falamos em alguns detalhes atrás na parte de API da API o segundo tipo de instrumentação é das bibliotecas de instrumentação nós falamos sobre bibliotecas de instrumentação antes também então são aquelas bibliotecas que fazem instrumentação os frameworks das bibliotecas então as bibliotecas de instrumentação nós usamos as APIs que nós definimos anteriormente na instrumentação manual desses frameworks de novo usando o caso de spring nós temos uma biblioteca de instrumentação para spring vai fazer a auto configuração de alguns beams definidos a nossa biblioteca de instrumentação vai fazer o auto registro para que nós possamos criar um novo trecho sempre que um requerimento htb chegue no nosso serviço e vai fechar esse spam vai fechar esse trecho quando o requerimento htb é escrito para o cliente então as bibliotecas de instrumentação são oportunísticas elas usam instrumentação ou na hora usam as APIs de instrumentação para instrumentar os frameworks ao nosso redor as bibliotecas ao nosso redor e por final nós temos a instrumentação automática então instrumentação automática é o tipo de instrumentação em que nós não fazemos na hora da compriação na hora do empocotamento como no caso das bibliotecas de instrumentação o que a gente faz na hora de desenvolvimento com o mercado de instrumentação anual a instrumentação automática é aquela que é feita em tempo de execução então se nós estamos utilizando uma aplicação Java e desculpa por usar o Java aqui como exemplo de tudo para essa palestra acho que é o mais fácil a gente entender mas as mesmas técnicas se aplicam para outras linguagens não todas as outras linguagens também mas a instrumentação automática ela faz a instrumentação da aplicação então no caso do Java nós temos um agente Java que é executado pela JVM então quando a gente quadrar Java, management é a nossa aplicação a gente participa em java agent e aí eu vou trojar que esse outro Java vai ter a possibilidade de se plugar de se conectar em algumas partes da JVM e falar eu estou interessado em eventos do tipo TAL estou interessado em classes do tipo TAL sendo carregadas ou estou interessado em métodos da classe TAL sendo executados e aí nesses eventos nesses lugares então são injetadas as bibliotecas de instrumentação então por isso que eu disse aqui uma nós temos a instrumentação manual com base de tudo de instrumentação em cima da instrumentação manual e nós temos a instrumentação automática fazendo em tempo de execução a instrumentação utilizando as bibliotecas de instrumentação então são esses os três tipos de instrumentação nós temos em quase todos os projetos dentro do telemetro nós temos instrumentação manual e bibliotecas de instrumentação para praticamente todas, então Java, Python, Goal Node, Ruby Dotnet e Previne e a instrumentação automática para as linguagens que oferecem suportes então Node.js, Ruby, Java acham que Dotnet também não tem certeza mas não por exemplo para Goal nenhum não possivelita do jeito que a linguagem funciona ela não possivelita instrumentação automática então isso, eu acho que eu falei bastante de instrumentação Java vamos dar uma olhada na demonstração eu preparei aqui uma aplicação Java, perdoei por focar tanto assim no Java é uma aplicação que foi construída utilizando esse framework chamado Quarkus é um framework Java para desenvolvimento de aplicações nativas para nuvem Cloud Native ou seja, para se rodar as linguagens cobertas então a ideia é que essas são as aplicações que iniciam muito rápido, conseguem fazer esclodamento rápido ou são bem elásticos, ou seja, eles escalam de uma forma muito rápida e Quarkus então é um framework que foi concebido justamente para o cenário de Cloud Native e tudo o que se passa é sobre Quarkus não ganhamos de Quarkus, a ideia não é essa é não ganhamos de fazer um tab com essa palavra, mas enfim a ideia é que nós eu construí uma aplicação eu vim aqui nesse code.quarkus.io eu coloquei aqui os grupos o nome do grupo, portfato, artefato e qual ferramenta que eu quero utilizar para construir a aplicação e aqui então de Open Telemetry e selecionei a primeira biblioteca, então essa biblioteca vai fazer a instrumentação da minha aplicação Quarkus ela entende de Quarkus e ela entende de Open Telemetry e sabe o que fazer e quais partes do Quarkus para que minha aplicação seja instrumentada vamos à parte geral da aplicação, ou seja, a parte HTTP que chega, a parte de cliente HTTP, ou seja, HTTP que sai a parte de dados, a parte enfim por exemplo e eu coloquei também deixa eu clicar aqui, eu coloquei aqui que é o de OTP ou seja todos os dados de telemetry que são gerados por essa integração pela integração de OTP elas são enviadas por um sistema externo, por um processo externo utilizando o protocolo OTP e aí então eu gerei a minha aplicação já no arquivo ZIP aí eu descontrui o arquivo ZIP então está aqui a aplicação a única coisa que eu alterei é que no meu application.properties eu alterei algumas coisas, com o nome da minha aplicação eu habilitei a extensão e eu especificei para onde os dados são enviados e no meu caso é um destino OTP em localhost na minha máquina na porta 4317 e nessa localização eu tenho um open telemetry com trip, então com trip aquele que contém algumas outras algumas outras surpresas a gente vai ver mais sobre o colector daqui a pouquinho e ele passa então essa configuração a configuração é local.yager.yaml e a ideia é que esse colector ele receba OTP seguindo o padrão GRPC então ele abre uma porta GRPC que aceita o protocolo OTP e então ele aceita esses dados e envia através de GRPC também para o Yager que está rodando no meu localhost na porta 14250 e aí eu configura a minha pipeline eu configura aqui o meu conduit é um conduit de rastros de traces em que eu tenho um receptador, OTP nenhum processador e um exportador para Yager então deixa eu iniciar aqui o Yager não tem nada a rodar eu estou rodando aqui pelo código forte obviamente que você não precisa fazer isso você pode baixar o binário você pode usar como o console container utilizando potman ou docker é a mesma coisa para o open telemetry colector contrip aparentemente eu não estava no menu aqui vamos lá eu acho que atualizei no menu então eu vou baixar a nossa dependência baixar as dependências go mas foi bem rápido então eu já conectou com o Yager eu tenho o meu processo de open telemetry colector rodando na porta 4317 e meu colector está conectado com o Yager na porta 14250 então deixa eu iniciar aqui a minha aplicação é o maven wrapper clean e equipus dev assim que a minha aplicação iniciar aparentemente já iniciou eu vou então rodar um comando crawl no slash no barra hello e ele deve me retornar hello road então é esse comando aqui então crawl no localhost 880 barra hello e eu tenho aqui hello road só para ver se a gente está realmente no lugar certo hello isso vamos ver se funciona beleza funciona e aí então a gente pode abrir o Yager e aqui nós temos já em todo serviço KCD Brasil 222 que foi gerado alguns segundos atrás então esse é um rastro que contém apenas um trecho três que contém apenas um spam e nós temos aqui várias informações e tudo isso aqui foi gerado automaticamente pelo Quarkus por aquela biblioteca que nós carregamos ao gerar a nossa aplicação então aqui nós temos praticamente todas as informações possíveis sobre esse requerimento da TV então se eu precisar demorar essa aplicação por algum motivo se eu precisar depurar essa aplicação por algum motivo eu tenho aqui bastante que eu posso começar por aqui o pessoal está pedindo para dar um zoom aí na tela obrigado o código também bota lá no código deixa eu dar uma olhadinha um pouquinho, se dá um pouquinho acho que dá pra... qualquer coisa eu dá um bicho beleza então nós temos ali os dados sobre esse nosso requerimento da TV aparentemente eu já tinha um resquício aqui de um teste e eu rodei obviamente essa demonstração aqui de um teste hoje mas esse inject tracer não é necessário pra que aquele rastro seja criado esse inject tracer aqui é necessário pra segunda parte da demonstração que é a que eu vou começar agora que é eu posso também criar trechos de negócio trechos que acrescentam esse meu rastro ou seja, spams que adicionam ao meu trace pra adicionar informações relevantes de negócio então por exemplo eu posso vir aqui e colocar um novo span então span o nosso trecho tracer span builder plano e aqui eu posso colocar minha operação minha operação e iniciar span eu posso então colocar um novo atributo então vamos dizer que eu sei que esse requerimento aqui é do meu cliente a DC123 então eu posso criar um trecho falando que essa transação esse rastro pertence ao cliente a DC123 aqui eu posso fazer uma operação de negócio então aqui talvez demora um pouco demora um pouco e eu quero então entender depois de um tempo eu quero entender no futuro como é que esse esse algoritmo é executado em produção, então quanto tempo ele leva se ele bloqueia por muito tempo ou se ele está transando enfim eu posso então criar um um trecho aqui pra entender um comportamento desse locódio e então depois que eu fiz tudo isso eu posso simplesmente finalizar um trecho e aí eu retorno para o meu cliente e então eu vou reiniciar a minha aplicação de uma forma geral não é necessário reiniciar a aplicações quárculos ela pega a alteração de uma forma dinâmica mas com relação ao open transit tem um bug ali que seja necessário que seja reiniciado uma da nova o ozinho está diluído quer dizer pelo novo código e a gente volta aqui então para o Yega procurar os rástrores aqui nós temos um novo rástro alguns segundos atrás e agora nós temos dois trechos um com o hello, esse é o que foi criado pelo quárculos pra gente e esse segundo aqui é a minha operação isso é o que a gente criou manualmente com o nosso cliente porque eu colocaria o ID do meu cliente no trecho desses a resposta talvez seja óbvia pra alguns mas a ideia é que eu posso então se esse cliente me liga, se esse cliente manda um e-mail reclamando que aconteça alguma coisa eu posso vir aqui e falar então me retorna todos os rástros relacionados ao cliente ABC123 ele fala que então são dois os rástros né são esses dois que a gente tem aqui e então é isso então de novo nós temos aqui um novo entrando de collector conectado com o Yega e o ponto desse collector aqui é de servir como tradução entre o otel IP nós temos o cliente o formato Yega que o Yega ainda não recebe o otel IP naturalmente então nós temos um collector pra fazer a tradução dessa informação vai receber o otel IP e vai enviar o Yega Então isso é isso que eu tinha aqui para essa demonstração, espero que tenha sido útil e a gente vai então para a parte final dessa apresentação que é sobre o collector. Eu acho que a gente tem aqui cinco minutos para vim, para passar por essa parte, então eu vou ter uma pressupressão bem rápida sobre o collector. O collector é um menor que serve de conduite para da raça de telemetria. Então nesse esquema que nós temos aqui, o collector é esse processo, está no meio da tela, de um lado da tela nós temos o Workload, nós temos nossas aplicações, nós temos uma aplicação que está instrumentada com uma biblioteca Prometheus, então ela expõe uma barra metrics em alguma porta específica e aí o processo geralmente Prometheus vai nessa porta e faz a raspagem, faz o Scrapping dessa informação e amazenem em algum storage, amazenem em alguma ferramenta de amazenamento, possivelmente do próprio Prometheus, possivelmente o Tans, possivelmente o Cortex, possivelmente até um proveidor de serviços. Então no nosso caso aqui nós temos um open-traps collector no meio deles, nós temos de novo o de um lado a nossa aplicação de negócios, do outro o storage, o destino final desses informações, um collector no meio, então o collector é que vai ser o responsável fazer essa raspagem de dados da nossa barra metrics, vai passar por todos os processadores que nós temos como parte desse conduite, como parte dessa pipeline e vai fazer a exportação desses dados para sistemas diferentes, então nesse exemplo aqui nós estamos exportando os mesmos dados para dois sistemas diferentes, primeiro por um Prometheus e segundo por um sistema que aceite o Telepake, possivelmente até um outro collector em um outro nível, em outro cluster, para fazer talvez a aplicação, para fazer talvez o descarte da informação se ela não for interessante, então a ideia interessante aqui é nós temos uma fontilidade e nós temos dois destinos, nós temos aqui também, de novo na nossa esquerda, nós temos dois sistemas destinos, um instrumentado com uma biblioteca Eager que gera dados de todo o formato próprio do Eager e envia esses dados por um servidor que se passa a passar nesse caso no nosso do Eager é um receptador do OpenTrack de collector que entende o formato Eager, a segunda aplicação que nós temos é uma aplicação instrumentada com alguma coisa que gera o Telepake, possivelmente uma biblioteca OpenTrack com OpenTrack SDK, então ele gera dados do Telepake e envia para o cliente não sabe quem tem o formato, sabe somente que é no padrão o Telepake, como nossa demonstração anterior, então o nosso OpenTrack de collector ele tem um receptador para o Telepake e independente do que foi recebido, de onde foi recebido, foi recebido na porta Eager, foi recebido na porta o Telepake, independente a passar pelos mesmos processadores a visão dos dados é a mesma e então no final dos processadores a mesma informação enviada para três destinos, um possivelmente um outro collector e um outro nível de clusters, então se eu tenho um cluster de uma região talvez agora eu esteja enviando todos os meus dados para um cluster dedicado a telemetria em outra região principalmente, ou então estou enviando esses dados para um grafão na tempo ou então estou enviando esses dados para um Eager nesse caso aqui para todos os três ao mesmo tempo OpenTrack de collector é um é é uma é um é muito versátil, existem muitas formas de se utilizar OpenTrack de collector, existe uma palestra inteira dedicada ao OpenTrack de collector a formas de deployment dele que foi feita na Cubicon america do ano 2021, tem um link os esses slides eu já coloquei no twitter um pouco tempo atrás, você pode baixar, clicar em se vem que aqui você vai direto para a palestra sobre OpenTrack de collector collector de novo é muito versátil, esses são os componentes que nós tínhamos há uns dois meses atrás, essa vista já está defasada, não é para se ler, não é para se entender esse slide, a ideia é só mostrar quantos componentes nós temos aqui, é isso então um notinho para a gente falar sobre o futuro do projeto, até agora o foco foi quase exclusivamente para rastros, patroces e a parte está bem estável, você já pode utilizar hoje tanto a parte da especificação, como a inscrição semântica, as APIs, SDKs, o collector é tudo bem bem bem estável já, métricas está sendo estabilizada nesse momento, então nós temos API e as especificações estão estabilizadas as APIs e SDKs para algumas linguagens também já são tidas como estáveis para algumas outras não e na parte do collector ainda não está estável, a parte de protocol no collector está estável mas a pipeline não está, então o foco agora e daqui para os próximos meses é focar em métricas, então deixar todas as partes de métricas bem estável, e feito isso a gente a focar em logs, então logs agora está começando a conversa sobre estabilizar a especificação e aí o próximo passo são as APIs, SDKs e depois a gente vai para a parte de collector também, e aí para o futuro, um futuro mais distante, talvez aí um ano e meio, para frente talvez um pouco mais, quem sabe um quarto sinal, quem sabe um sinal do tipo perfilamento talvez, um profiling que vem ganhando muita atenção nos últimos meses, talvez um ano e meio, especialmente na forma de IPPF, então mas isso bem lá por frente é muito interessante, eu adoro seguir esse tópico, mas é uma coisa que eu não espero ver amanhã, logo no Projeto Quantitative. Então é isso, muito obrigado pela sua atenção, eu gostaria de finalizar aqui, convidando todos vocês para participar, se você se interessa por observabilidade, acho que não consigo falar hoje, eu convido a todos vocês a se juntar a esse canal, observabilidade no select da CNCF, e aqui estão os meus dados de contato, você pode me encontrar no Twitter, no GitHub, quando o J.P. Collin ou no Slack, quando o J.P. Kroll, ele é como o pessoal escreve na Alemanha, e a última coisa que gostaria de mencionar aqui, a Grafana está contratando, se você tem interesse em entrar nessa área, se você tem vontade de trabalhar com projetos open source, me dá um toque e vamos conversar, é isso, muito obrigado de novo, agora eu estou aberto, essas perguntas se tiveram tempo. Em seguida é intervalo, então acho que dá mais uns 5, 10 minutinhos aí de pergunta também. Vamos lá, eu falo para as perguntas antiguas aqui, mas se você quiser começar a ver, ele tem aqui, a primeira é do Gaspar, existe diferença na performance da aplicação a utilizar a instrumentação automática? A resposta geral para a pergunta sobre performance é sim, tem penalidade performance, você não ganha, você não consegue atingir as coisas sem pagar por alguma coisa, então sempre que você vai fazer instrumentação da sua aplicação, você vai pagar por isso de alguma forma. Dito isso, foram feitos alguns estudos, foram feitos alguns estágios, por parte do projeto Authority, alguns anos atrás, e que vimos que chegamos à conclusão de que o custo de instrumentação é baixíssimo se você for com o custo que a sua aplicação tem para rodar. Então quando a gente está falando de um requerimento da HTTB, por exemplo, então nós temos todo o custo de rede, chegando na sua aplicação e voltando para o cliente de forma que a parte de instrumentação é realmente mínima. Então não deixe de instrumentar por problemas de pensar em performance. É claro que não abuse da instrumentação, talvez até por outro motivo, se você tiver muitos dados, você está coletando muita informação, é difícil você entender onde está o problema, você acaba tendo um palheiro se você achar aquela magulha ali. Então começa instrumentando os corpos e vá ampliando conforme necessidade e aí você não vai ter nenhum problema de ter muitos dados e nem ter... Não é uma promessa, mas aí você não teria também um problema de performance da sua... por excesso de instrumentação. É como eu digo, ninguém não quer. Se você quer instrumentação, se você quer saber alguma coisa, você tem que pagar alguma coisa. Eu vou pegar umas aleatórias aqui, até para ser junto aqui. Então jura-se, o grafana tempo, tem compatibilidade para ser utilizado como exporter do Open Telemetry? Desculpa, qual é a início da pergunta? O grafana tempo, tem compatibilidade para ser usado como exporter do hotel? O grafana tempo é um storage que pode ser usado como Open Telemetry collector. Acho que talvez seja esse o contexto da pergunta. Então o grafana tempo, ele aceita o TLP, ele aceita o padrão TLP nativamente. Então você pode colocar a sua aplicação, exportando dados do TLP direto para o tempo ou se quiser, você pode colocar o collector do TLP para fazer talvez um TLP sampling. Enfim, eu vou ficar devendo essa, mas você consegue ter o collector para fazer outras atividades, para ter outras features que não existem, outras funcionalidades que não existam no grafana tempo. Mas o grafana tempo, ele aceita, ele aceita dados em hotel e TLP nativamente. Eu vou fazer uma última aqui e aí, depois a gente copia e cola lá no chat. O que você recomendaria nos cenários em que as miliotecas de alimentação do Open Telemetry ainda não estão em versões estáveis, o menor de 1.00. Faz sentido assumir o risco de colocá-las em produção? Depende do propósito que você quer. Se você está falando de rastros, se você está falando de traces, então sim, já pode utilizar, não tem problema nenhum. Nós já estamos utilizando em alguns projetos, nós já estamos recomendando para os clientes. Então eu já utilizaria as miliotecas de instrumentação, ou enfim, tanto miliotecas de instrumentação quanto as APIs de instrumentação, eu já recomendaria para a parte de traces. Para parte de metrics, métricas é um pouco mais complicado. Então nem no próprio collector nós estamos utilizando a milioteca de métricas agora do Open Telemetry, porque falta funcionalidades, as coisas ainda podem mudar de uma forma ou de outra. Então para rastros, para traces, sim, manda bala para qualquer outra coisa, espera um pouco. Se você tem uma necessidade ou se você não vai entrar em produção, amanhã use e mande o seu feedback, projeto, todo vai adorar receber seu feedback, mas você vai entrar em produção, aplicação crítica, então aí eu recomendo um pouco mais. Eu vou fazer só mais um então, também, tem pergunta para caramba aqui. Depois vai ser civil aí, Jura, eu vou colar tudo. Em um ambiente produtivo usando Kubernetes, o que é mais recomendado? Subir o agente do Open Telemetry Collector como um sidecar, como um novo deployment ou uma terceira sugestão? Assista a essa palestra que eu comentei agora pouco na KubeCon, no norte, eu falo sobre isso lá também. Existem, dependendo das respostas, como tudo é, depende. Então se você tem centenas de pequenas aplicações, centenas de microserviços por negue spaces, então talvez faça sentido você usar um demo set, talvez faça sentido você ter uma instância de Open Telemetry Collector como agente para cada node. Se você tem um material em que você tenha múltiplos inquilinos, na sua aplicação, ou seja, se cada name space, pertenção de apartamentos, cada name space, pertenção cliente e por aí vai, então não tem no outro jeito, ou enfim, existem poucas soluções no seu sidecar. Então use sidecar. Eu pessoalmente, eu geralmente recomendo o sidecar, eu acho que é uma forma que você escala de uma forma melhor, tanto na parte do cliente quanto na parte do servidor, tanto quanto mais clientes você tem pela natureza do GRPC, mais conexões você tem do servidor, melhor o balanceamento da carga. Então eu recomendo os sidecars, ao menos que você acabe tendo milhares de sidecars, que aí o seu overhead vai acabar fazendo diferença no seu bolso, e aí para esse de costuração, então realmente pense em como você pode adotar um demo set. Mas se você pode, comece com o sidecar, a minha recomendação. Beleza. Obrigado, a gente tem mais um monte aqui, mas aí eu vou deixar então para depois você conseguir dar uma olhadinha e responder. Acho que o que é ficar aberto se você não consegue responder. Brigadão sensacional. Pessoal, a gente vai fazer um intervalo aí até 4 e 20. Então 4 e 20 a gente volta, voltem aí na pilha aí, na pegada. E aí a gente vai falar com a palestra do William e do Pedro sobre o Thanos. Então 4 e 20 tamo de volta aí pessoal. Jura-se e brigadão, vou deixar aqui por enquanto pausado aí por 10 minutinhos. Eu agradeço, muito obrigado. Se puderem, pergunte em mim no Twitter. Até lá. Até, valeu.