Em 2014, quando a onda de contêineres, Kubernetes e computação distribuída estava invadindo a indústria de tecnologia, Torkel Ödegaard trabalhava como engenheiro de plataforma no eBay Suécia. Como outros pioneiros do Devops, Ödegaard estava lutando com o novo formato de microsserviços e contêineres e lutando para escalar a íngreme curva de aprendizado de operações e solução de problemas do Kubernetes.
Como engenheiro que se esforça para tornar a entrega contínua segura e fácil para os desenvolvedores, Ödegaard precisava de uma maneira de visualizar o estado de produção do sistema Kubernetes e o comportamento dos usuários. Infelizmente, não havia um manual específico sobre como extrair, agregar e visualizar os dados de telemetria desses sistemas. A pesquisa de Ödegaard eventualmente o levou a uma ferramenta de monitoramento nascente chamada Graphite e a outra ferramenta chamada Kibana que simplificou a experiência de criação de visualizações.
“Com o Graphite, você poderia, com muito pouco esforço, enviar métricas de seu aplicativo detalhando seus comportamentos internos e, para mim, isso foi muito capacitador, como desenvolvedor, para realmente ver insights em tempo real sobre o que os aplicativos e serviços estavam fazendo e se comportando, e o que o impacto de uma mudança de código ou nova implantação foi”, disse Ödegaard ao InfoWorld. “Isso foi visualmente emocionante e gratificante e nos fez sentir muito mais confiantes sobre como as coisas estavam se comportando.”
O que levou Ödegaard a iniciar o seu próprio projeto paralelo foi que, apesar do poder do Grafite, era muito difícil de usar. Foi necessário aprender uma linguagem de consulta complicada e processos desajeitados para construir estruturas. Mas Ödegaard percebeu que, se você pudesse combinar o poder de monitoramento do Graphite com a facilidade do Kibana, poderia tornar as visualizações para sistemas distribuídos muito mais acessíveis e úteis para os desenvolvedores.
E foi assim que nasceu a visão do Grafana. Hoje, o Grafana e outras ferramentas de observabilidade não preenchem um nicho no cenário de monitoramento, mas um abismo que as ferramentas tradicionais de monitoramento de redes e sistemas nunca previram.
Um sistema operacional em nuvem
Nas últimas décadas assistimos a dois grandes saltos na evolução da infra-estrutura. Primeiro, passamos de servidores robustos de “expansão vertical” para frotas de “expansão horizontal” de servidores Linux comuns em execução em data centers. Depois demos outro salto para níveis ainda mais elevados de abstração, abordando nossa infraestrutura como uma agregação de recursos de nuvem que são acessados por meio de APIs.
Ao longo desta evolução dos sistemas distribuídos impulsionada por agregações, abstrações e automação, a analogia do “sistema operacional” tem sido repetidamente invocada. A Sun Microsystems tinha o slogan: “A rede é o computador”. Matei Zaharia, da UC Berkeley AMPLab, criador do Apache Spark, cocriador do Apache Mesos e agora CTO e cofundador da Databricks, disse que “o data center precisa de um sistema operacional”. E hoje, o Kubernetes é cada vez mais conhecido como um “sistema operacional em nuvem”.
Chamar o Kubernetes de sistema operacional gera críticas de alguns, que são rápidos em apontar as diferenças entre o Kubernetes e o Kubernetes. real sistemas operacionais.
Mas a analogia é razoável. Você não precisa informar ao seu laptop qual núcleo iniciar ao iniciar um aplicativo. Você não precisa informar ao servidor quais recursos usar sempre que uma solicitação de API for feita. Esses processos são automatizados por meio de primitivos do sistema operacional. Da mesma forma, o Kubernetes (e o ecossistema de software de infraestrutura nativo da nuvem em sua órbita) fornece abstrações semelhantes às do sistema operacional que tornam possíveis sistemas distribuídos, mascarando operações de baixo nível do usuário.
O outro lado de toda essa maravilhosa abstração e automação é que entendimento o que está acontecendo nos bastidores do Kubernetes e dos sistemas distribuídos requer muita coordenação que recai sobre o usuário. O Kubernetes nunca foi fornecido com uma GUI bonita que acumula automaticamente as métricas de desempenho do sistema, e as ferramentas de monitoramento tradicionais nunca foram projetadas para agregar todos os dados de telemetria emitidos por esses sistemas extremamente complicados.
De zero a 20 milhões de usuários em 10 anos
A criação e visualização de painéis são associações comuns que os desenvolvedores fazem quando pensam no Grafana. Seu poder como ferramenta de visualização e sua capacidade de trabalhar com praticamente qualquer tipo de dados tornaram-no um projeto de código aberto extremamente popular, muito além da computação distribuída e dos casos de uso nativos da nuvem.
Os amadores usam a visualização Grafana para tudo, desde visualizar as atividades das colônias de abelhas dentro da colméia até rastrear pegadas de carbono em pesquisas científicas. Grafana foi usado no centro de controle da SpaceX para o lançamento do Falcon 9 em 2015, e novamente pela Agência de Exploração Aeroespacial do Japão em seu próprio pouso lunar. Esta é uma tecnologia que está literalmente em todos os lugares onde você encontra casos de uso de visualização.
Mas a verdadeira história é o impacto do Grafana em um domínio de observabilidade que antes de sua chegada era definido por bancos de dados back-end proprietários e linguagens de consulta que prendiam os usuários a ofertas de fornecedores específicos, grandes custos de mudança para os fornecedores migrarem para outros usuários e jardins murados de fontes de dados suportadas.
Ödegaard atribui muito do sucesso inicial do Grafana ao sistema de plugins que ele criou em seus primeiros dias. Depois que ele escreveu pessoalmente as fontes de dados InfluxDB e Elasticsearch para Grafana, os membros da comunidade contribuíram com integrações com Prometheus e OpenTSDB, desencadeando uma onda de plug-ins comunitários para Grafana. Hoje, o projeto suporta mais de 160 fontes de dados externas – o que chama de abordagem de “grande tenda” para a observabilidade.
O projeto Grafana continua a trabalhar com outros projetos de código aberto como o OpenTelemetry para fornecer modelos semânticos padrão simples para todos os tipos de dados de telemetria e para unificar os “pilares” dos dados de telemetria de observabilidade (logs, métricas, rastreamentos, perfis). A comunidade Grafana está conectada por uma filosofia de “possuir seus próprios dados” que continua atraindo conectores e integrações com todos os tipos de dados de telemetria e bancos de dados possíveis.
Futuros do Grafana: novas visualizações e fontes de telemetria
Ödegaard diz que as capacidades de visualização do Grafana têm sido um grande foco pessoal para a evolução do projeto. “Houve uma longa jornada para criar uma nova arquitetura de aplicativos React, onde desenvolvedores terceirizados possam construir aplicativos semelhantes a painéis no Grafana”, disse Ödegaard.
Mas, além de enriquecer as maneiras pelas quais terceiros podem criar visualizações com base nessa arquitetura de aplicativos, os próprios painéis estão recebendo um grande impulso em termos de inteligência.
“Uma grande tendência é aquele painel criação deverá eventualmente tornar-se obsoleto”, disse Ödegaard. “Os desenvolvedores não deveriam ter que construí-los manualmente, eles deveriam ser inteligentes o suficiente para gerar automaticamente com base em tipos de dados, relacionamentos de equipe e outros critérios. Conhecendo a linguagem de consulta, as bibliotecas detectadas, as linguagens de programação com as quais você está escrevendo e muito mais. Estamos trabalhando para tornar a experiência muito mais dinâmica, reutilizável e combinável.”
Ödegaard também vê os recursos de visualização do Grafana evoluindo em direção a novos métodos de desagregação – sendo capaz de retroceder dos gráficos até a forma como os gráficos são compostos e dividir os dados em dimensões de componentes e causas raiz.
A jornada de observabilidade da infraestrutura em nuvem continuará a ver novas camadas de abstração e dados de telemetria. Abstração em nível de kernel O eBPF está reescrevendo as regras de como as primitivas do kernel se tornam programáveis para engenheiros de plataforma. Cilium, um projeto que recentemente se formou na incubação da Cloud Native Computing Foundation, criou uma camada de abstração de rede que permite ainda mais agregações e abstrações em ambientes multinuvem.
Este é apenas o começo. A inteligência artificial está introduzindo novas considerações todos os dias para a interseção de linguagens de programação primitivas, hardware especializado e a necessidade dos humanos entenderem o que está acontecendo dentro das cargas de trabalho de IA altamente dinâmicas que são computacionalmente caras para serem executadas.
Você escreve, você monitora
À medida que o Kubernetes e os projetos relacionados continuam a estabilizar o modelo operacional da nuvem, Ödegaard acredita que as considerações de monitorização da saúde e observabilidade continuarão a recair sobre a instrumentação dos operadores humanos, e que a observabilidade será um dos superpoderes que distinguem os talentos mais procurados.
“Se você escreve, você executa e você deve esteja disponível para o software que você escreve – essa é uma filosofia muito importante”, disse Ödegaard. “E nesse sentido, quando você escreve software, você deve pensar em como monitorá-lo, como medir seu comportamento, não apenas de uma perspectiva de desempenho e estabilidade, mas de uma perspectiva de impacto nos negócios.”
Para um sistema operacional em nuvem que está evoluindo a uma velocidade vertiginosa, quem melhor do que Ödegaard para defender a necessidade dos humanos de raciocinar com os sistemas subjacentes? Além de adorar programar, ele é apaixonado por história natural e evolução e lê todos os livros que encontra sobre história natural e psicologia evolutiva.
“Se você não acha que a evolução é incrível, algo está errado com você. É assim que a natureza programas. Quão mais incrível pode ser?”
