Oferta de tempo limitado! Estou pronto para minha próxima aventura como advogado de devrel/evangelista técnico/TI talespinner. Se isso soa como algo que você precisa, deixe -me uma linha por e -mail ou em LinkedIn.
Meu blog sobre preços do outro dia chamou a atenção do pessoal no MetricFire, e iniciamos uma conversa sobre algumas das idéias, ideais e desafios que giram em torno do monitoramento, observabilidade e seu lugar na paisagem mais ampla de TI.
A certa altura, JJ, o engenheiro principal, perguntou: “Você blogou sobre se preparar para obter uma certificação em telemetria aberta. O que há sobre Otel que você está tão empolgado? ”
Eu dei uma resposta rápida, mas a pergunta de JJ me fez pensar e eu queria colocar algumas dessas idéias aqui.
Otel é a melhor coisa desde …
Deixe-me começar respondendo diretamente à pergunta de JJ: acho a telemetria aberta emocionante, porque é a maior mudança na maneira como o monitoramento e a observabilidade são feitos desde que os traços (que foram lançados por volta de 2000, mas não foram amplamente utilizados até 2010-ish).
E traços foram a maior mudança desde … de sempre. Deixe -me explicar.
Veja esta foto? Era assim que era usar o monitoramento para entender seu ambiente quando comecei há quase 30 anos. O que queríamos era saber o que estava acontecendo naquele barco. Mas isso nunca foi uma opção.
Poderíamos raspar métricas juntas dos comandos de rede e SO e poderíamos criar alguns scripts e consultas de banco de dados que me deram um pouco mais de insight. Poderíamos coletar e (com muito trabalho) agregar mensagens de log juntos para identificar tendências em vários sistemas. Tudo isso nos daria uma idéia de como a infraestrutura estava funcionando e inferir as coisas que podem estar acontecendo no topo. Mas nunca sabíamos.
O rastreamento mudou tudo isso. De repente, poderíamos obter dados difíceis (e obtê-los em tempo real) sobre o que os usuários estavam fazendo e o que estava acontecendo no aplicativo quando o fizeram.
Foi uma mudança completa do mar (trocadilho) de como trabalhamos e o que monitoramos. Mesmo assim, o rastreamento não removeu a necessidade de métricas e logs. E famoso (ou infame) “três pilares” de observabilidade.
Recentemente, comecei a trabalhar no livro “Learning Opentelemetry” e um dos comentários que me impressionaram foi que esses não são “três pilares” no sentido de que eles não se combinam para sustentar um todo unificado. Os autores Ted Young e Austin Parker re-moldaram a combinação de métricas, toras e traços como “as três guias do navegador da observabilidade” porque muitas ferramentas colocam o esforço de volta ao usuário para virar entre as telas e montar tudo junto à vista.
Por outro lado, as saídas do OTEL podem apresentar todos os três fluxos de dados como uma única “trança”.
A partir da aprendizagem Opentelemetria, de Ted Young e Austin Parker, Copyright © 2024. Publicado pela O’Reilly Media, Inc. Usado com permissão.
Deve -se notar que, apesar da capacidade da Otel de combinar e correlacionar essas informações, os autores do livro apontam mais tarde que muitas ferramentas ainda não têm a capacidade de apresentá -las dessa maneira.
Apesar de ser um trabalho em andamento (mas o que, no mundo, não é?), Ainda sinto que a Otel já provou seu potencial para mudar a face do monitoramento e da observabilidade.
Otel é o esperanto de monitoramento
Quase todo fornecedor aproveitará a chance de fazer com que você envie todos os seus dados para eles. Eles insistem que o deles é a única ferramenta de observabilidade.
De fato, vamos divulgar isso em aberto: simplesmente não há uma “melhor” ferramenta de monitoramento singular por aí mais do que uma “melhor” linguagem de programação, modelo de carro ou estilo de pizza.* Não há uma única ferramenta que abranja 100% de suas necessidades em todos os casos de uso.
E para as ferramentas maiores, mesmo os casos de uso que não fazem parte de seu ponto ideal absoluto custarão (em termos de horas ou dólares) para acertar.
Então, você terá várias ferramentas. Escusado será dizer (ou pelo menos deveria) que você não enviará uma cópia completa de todos os seus dados para vários fornecedores. Portanto, grande parte do seu trabalho como engenheiro de monitoramento (ou equipe de engenheiros) é mapear sua telemetria para os casos de uso que eles suportam e, portanto, para as ferramentas que você precisa empregar nesses casos de uso.
Isso não é realmente um problema difícil. Claro, é complexo, mas depois que você tem o mapeamento, fazer isso acontecer é relativamente fácil. Mas, como eu gosto de dizer, não é o custo comprar o filhote que é o problema, é o custo continuar alimentando -o.
Porque as ferramentas que você tem hoje vão mudar no futuro. É quando as coisas ficam loucas. Você deve esperar que as coisas estejam documentadas o suficiente para entender todos esses mapeamentos de telemetria para uso.
(Narrador: eles não o farão documentar bem o suficiente)
Então você também deve esperar que sua instrumentação seja documentada e compreendida o suficiente para saber como desbaste a ferramenta X e a ferramenta de instrumentos Y, de modo que você mantenha os mesmos recursos.
(Narrador: não é assim que vai cair.)
Mas Otel resolve o problema “Comprar o filhote” e o problema “alimentar o filhote”. Meu amigo Matt MacDonald-Wallace (Solutions Architect em Grafana) Coloque assim:
Otel resolve muitos dos problemas em torno de ‘oh, ótimo! Agora estamos presos com o fornecedor X e vai nos custar milhões para refatorar todo esse código ‘, em oposição a’ Oh, estamos trocando de fornecedores? Legal, deixe -me apenas atualizar meu ponto final … ‘
Não apenas isso, mas a capacidade da OTELS de criar pipelines (para aqueles que não estão atualizados nesse conceito, é a capacidade de identificar, filtrar, amostrar e transformar um fluxo de dados antes de enviá -los para um destino específico) significa que você pode enviar o mesmo fluxo de dados para vários locais seletivamente. Significando que sua equipe de segurança pode obter seu syslog sem filtro bruto enquanto ainda está no local. Alguns dos dados – traços, logs e/ou métricas – podem ir a um ou mais fornecedores.
É por isso que digo: Otel é o Esperonto da observabilidade.
O molho secreto de Otel não é OTLP
… É padronização.
Antes de explicar por que o verdadeiro benefício para o OTEL não é OTLP, devo levar um segundo para explicar o que é o OTLP:
Se você procurar “o que é protocolo de linha de telemetria aberta?” você provavelmente encontrará alguma variação de “… um conjunto de padrões, regras e/ou convenções que especificam como os elementos OTEL enviam dados da coisa que os criou para um destino”. Isso é tecnicamente verdadeiro, mas também não é muito útil.
Funcionalmente, o OTLP é a caixa mágica que leva métricas, toras ou traços e os envia para onde eles precisam ir. Não é tão baixo quanto, digamos, TCP, mas em termos de como muda o dia do engenheiro de monitoramento, também pode ser. Nós não usar OTLP tanto quanto nós indicar deve ser usado.
Só para ficar claro, o OTLP é incrivelmente legal e importante. Simplesmente não é (na minha opinião) tão importante quanto alguns outros aspectos.
Não, existem (pelo menos) duas coisas que, na minha opinião, fazem de Otel uma mudança tão evolutiva no monitoramento:
Colecionadores
Primeiro, padroniza o modelo de ter um colecionador de três camadas (não agente) no meio, arquitetura. Para nós, veteranos no espaço de monitoramento, a idéia de um colecionador não é novidade. Na época passada de tudo sobre o local, você não conseguiu se safar de mil (ou mesmo cem) agentes conversando com algum destino remoto. A mudança para a arquitetura em nuvem mudou tudo isso, mas ainda não é a melhor ideia.
Ter um único (ou pequeno número) de sistemas balanceados de carga que retiram todos os dados de vários alvos-com o benefício adicional de poder processar esses dados, filtragem, amostragem, combinação etc.-antes de enviá-lo para a frente, não é apenas uma boa idéia ™, ele pode ter um impacto direto no seu resultado que você deseja que você não seja um grande momento.
Semântica
Olha, serei o primeiro a lhe dizer que não sou o melhor desenvolvedor do mundo. Portanto, a questão da terminologia semântica geralmente não me mantém acordada à noite. O que FAZ Mantenha -me acordado é a incapacidade de obter uma peça de dados que eu sei que deveria estar lá, mas não é.
O que quero dizer é que é bastante comum que o mesmo ponto de dados – digamos, a largura de banda – seja referida por um nome e localização completamente diferentes em dispositivos de dois fornecedores diferentes. E talvez isso não pareça tão estranho.
Mas e quanto ao mesmo ponto de dados ser diferente em dois tipos diferentes de dispositivos do mesmo fornecedor? Ainda não é estranho?
Vamos falar sobre o mesmo ponto de dados ser diferente no mesmo tipo de dispositivo do mesmo fornecedor, mas dois modelos diferentes? Ficando estranho, certo (para não mencionar irritante).
Mas o verdadeiro kicker é quando o mesmo ponto de dados é diferente em duas partes diferentes do mesmo dispositivo.
Depois de atingir todo esse coelho em particular, você tem uma apreciação totalmente diferente pela nomeação semântica. Se estiver procurando por CPU ou largura de banda ou latência ou o que for, eu realmente gostaria que ela fosse chamada de mesma coisa e seja encontrada no local semanticamente.
Otel faz isso e faz isso como um aspecto central da plataforma. Não sou o único a ter notado isso também.
Vários anos atrás, durante uma reunião entre os mantenedores de Prometheus e Opentelemetria, um mantenedor de Prometheus sem nome brincou: “Sabe, não tenho certeza sobre o resto disso, mas essas convenções semânticas são a coisa mais valiosa que eu já vi há algum tempo”. Pode parecer um pouco bobo, mas também é verdade.
A partir da aprendizagem Opentelemetria, de Ted Young e Austin Parker, Copyright © 2024. Publicado pela O’Reilly Media, Inc. Usado com permissão.
Resumindo os dados
Admito que o Opentelemetria ainda é muito (muito) brilhante para mim.
Mas também admito que quanto mais eu cavo, mais eu acho gostar. Felizmente, este blog lhe deu alguns motivos para conferir o OTEL também.
* Ok, eu menti. 1) Perl 2) O Ford Mustang 390 gt/a e 3) de 1967 PLARO DE Tel Aviv Kosher Pizza em Chicago
