
Durante o PromCon Online 2020, dei uma palestra intitulada "O Futuro de Prometheus e seu Ecossistema". E quero compartilhar com vocês seus pontos-chave.
Resumo
Desde a última conferência do PromCon - 2019, muitas mudanças ocorreram no Prometheus.
2,14
A versão 2.14 possui uma nova interface React. Embora ainda esteja atrás do antigo em termos de funcionalidade, estamos trabalhando nisso e continuamos a aprimorá-lo.
2,15
A versão 2.15 veio sob a bandeira da API de metadados. O formato de exposição do Prometheus há muito suporta expressões especiais
HELP
, TYPE
etc., no entanto, o próprio Prometheus costumava simplesmente descartar esses dados. Agora que eles permanecem, você pode abrir o acesso externo a eles por meio da API. Por exemplo, o Grafana já aproveita essa oportunidade e fornece aos usuários informações adicionais sobre as séries temporais com as quais trabalham:

2,16
A versão 2.16 se concentra em várias melhorias e estabilidade. Por exemplo, desde 2016, os usuários têm perguntado sobre a capacidade de selecionar a hora local na IU, bem como a implementação do log de consulta - foi bom fechar esses problemas.
2,17
Por falar em solicitações de recursos persistentes, a versão 2.17 finalmente trouxe o tão esperado "I" no ACID para o banco de dados : isolamento .
2,18
No 2.18 , o rastreamento e o suporte para instâncias de formato de exposição foram aprimorados. As instâncias são o primeiro impacto perceptível pelo usuário da implementação do OpenMetrics no Prometheus. Ao combiná-los com o Grafana, você pode obter uma granularidade conveniente, permitindo ir de:

... para:

2,19
No 2.19, reduzimos o consumo de memória em até 50%! Embora o Prometheus já seja bastante eficaz, há um potencial significativo para otimização - é emocionante e assustador.
Este gráfico é uma ótima ilustração disso:

2,20
A versão 2.20 possui o changelog mais longo desde a v2.6 (!). O principal é provavelmente o suporte de descoberta de serviço nativo para Docker Swarm e DigitalOcean.
Mas há uma mudança mais importante que vai além da implementação de dois mecanismos independentes de descoberta de serviço: separamos o Prometheus e examinamos de novo muitas das soluções antigas e abordagens estabelecidas. O mundo mudou (talvez nós também tenhamos ajudado nisso) - isso deve ser levado em consideração tanto no projeto em si quanto em outros.
node_exporter
Para resumir, gostaria de salientar que node_exporter alcançou a versão 1.0 e agora inclui suporte EXPERIMENTAL TLS. A Cloud Native Computing Foundation patrocinou a auditoria de node_exporter por Cure53 (cobriu o exportador em geral e nossa implementação de TLS em particular). E valeu a pena: não apenas verificamos o TLS antes de copiá-lo para outros exportadores, mas também usamos o node_exporter como uma cobaia da qual outros padrões são copiados.
Futuro
Às vezes tenho a sensação de que nós, como projeto, estamos descansando sobre os louros. Há algum tempo, fiz uma sessão de brainstorming dentro do Grafana sob o lema "O Prometheus está sem recursos" e incentivei a Red Hat a fazer o mesmo. Ao longo do caminho, criamos um documento sobre TUDO disponível para toda a equipe da Prometheus. Ele serve como uma estrutura para abordar tópicos específicos, divididos em pontos para discussão durante os dev-summits (assim que esses pontos estiverem prontos).
Developer Summits
No ano passado, tivemos duas cúpulas de desenvolvimento: uma após a KubeCon EU, a segunda após a PromCon. Foi planejado fazer o mesmo em 2020, mas a COVID evitou. Este ano não houve cúpulas, mas acredito que encontramos uma saída: reuniões mais curtas, mais frequentes e virtuais. Gastamos blocos de 4 horas em vez de coletar por 1-2 dias de uma vez. A primeira cúpula de desenvolvimento ocorreu em 10 de julho, e a próxima provavelmente ocorrerá em 7 de agosto. Continuaremos a conduzi-los até que tenhamos tratado de todas as questões acumuladas (embora seu número esteja crescendo constantemente à medida que mais e mais itens do documento acima são adicionados).
No momento, quero fazer duas coisas:
- , . , , . , . — , , .
- , , . , , .
Os metadados estão começando a agregar valor real ao Prometheus (ver 2.15 acima). Precisamos implementar mais opções para trabalhar com metadados (por exemplo, distribuí-los por meio de leitura / gravação remota). O consenso abaixo não cobre questões interessantes como "E se os metadados mudassem / desaparecessem?" ou "E se eles se tornarem um vetor de ataque?"
CONSENSO: Queremos manter melhor os metadados. O trabalho será realizado em documento especial .
CONSENSO: PR 6815 funcionará como uma solução alternativa EXPERIMENTAL. Provavelmente, será diferente nas versões 3.x.
Mudanças de fluxo de trabalho e s / master / main /
O tópico de varrer o lixo acumulado nos processos de trabalho não requer explicação especial, mas algumas palavras devem ser ditas sobre a eliminação da verborragia (unidade de terminologia). Levamos a sério a limpeza da terminologia: isso não é o mais importante, mas algo que podemos fazer agora. Enquanto esperamos pelo kit de ferramentas correspondente do GitHub. Assim que aparecer, tentaremos atrair um estagiário remunerado para este trabalho através da Community Bridge.
Estou em conversações com a Linux Foundation e CNCF para potencialmente implementar isso em todos os projetos. Uma grande oportunidade para qualquer pessoa interessada neste tema: a oportunidade de explorar muitos projetos, trabalhar com várias ferramentas, conhecer muitas pessoas. Contate-me no Twitter ( @TwitchiH ) ou por e-mail ( richih em grafana.com) se estiver interessado.
CONSENSO: Defina "Exigir verificações de status antes da fusão" em todos os prometheus / repositórios ... Não permitir push diretos no branch principal? Não permite empurrões de força no ramal principal?
CONSENSO: Desative o empurrão de força para todos os ramos principais.
CONSENSO: O comportamento padrão permite o push no branch principal, entretanto, deve ser desabilitado para alguns repositórios "importantes", por exemplo, prometheus / prometheus (a critério do mantenedor).
Preenchendo com dados (preenchimento)
Esta é uma das solicitações de recursos mais antigas e um bom exemplo de como abordar o consenso. Há muitas opiniões diferentes circulando na equipe da Prometheus sobre esse assunto, e é difícil chegar a um denominador comum. Portanto, escrevi uma proposta de consenso limitada e muito específica com três critérios: "Queremos oferecer suporte ao preenchimento da rede pelo menos em blocos que não se cruzem com o bloco principal ."
Após longas discussões e tentativas de chegar a um consenso, ficou claro que isso não seria fácil de fazer. Portanto, reformulei a proposta da seguinte maneira: “Queremos apoiar o preenchimento da rede pelo menos por fluxos que não se cruzem com o bloco principal"
Somente forçando todos a expressarem suas próprias opiniões sobre o assunto, conseguimos chegar à versão final: "Gostaríamos de suportar o preenchimento da rede em blocos que não se cruzem com o bloco principal, desde que devidamente implementado ." Cada palavra aqui foi escolhida para refletir a extensão exata e os limites do consenso.
: Prometheus OpenMetrics, CSV- .
: backfilling , .
: backfilling , .
: backfilling , .
Outra das tarefas associadas a colocar as coisas em ordem. Aqui, quero criticar o Go: ele foi desenvolvido em um mundo onde mono único é a norma. O Google armazena todo (ou a maioria) de seu código comum em um único repositório. Essa abordagem tem muitas vantagens, mas não se traduz bem nas condições do mundo real. Go está lenta mas seguramente se afastando desse legado.
Curiosidade: escrevi a proposta de consenso quase no início da discussão. Ficou claro que pelo menos tentaríamos. Estava claro que Ben Kochie se ofereceria para fazer isso. E estava claro que node_exporter seria a "vítima". Como regra, nós nos esforçamos para melhorar o fluxo de trabalho, e Ben é sempre um voluntário e node_exporter é a bancada de teste da qual copiamos os resultados para outros exportadores. E sim, era importante que a discussão continuasse por um tempo e que as pessoas chegassem a isso por conta própria, em vez de confrontá-las com um fato.
CONSENSO: Exclua em node_exporter e veja se estamos felizes com o resultado.
Listas de mala direta e IRC
O Google está bloqueado na China, mas nossas listas de e-mail funcionam nisso. Decidimos tentar tornar possível a inscrição por e-mail. Eu verifiquei: prometheus-users+subscribe@googlegroups.com funciona. Você também pode ler os arquivos ( https://www.mail-archive.com/prometheus-users@googlegroups.com/maillist.html ) se desejar.
Além disso, garantimos que todos possam usar o IRC através do Matrix, já que para alguns xkcd 1782 é muito relevante.
:
, Google ; - .
docs/community , Google.
IRC, Matrix; , .
Deixe-me repetir o que disse na cimeira: “A primeira coisa que não gostei no Prometheus em 2015 foi a documentação; em 2020, eu simplesmente a odeio. É difícil de usar e quase inútil, adequado apenas para quem já sabe o que está a fazer, ou pelo menos tem uma boa ideia dos conceitos. ” Resumindo, trabalharemos nesta direção:
:
:
* (user manual) .
* (reference) , PromQL /.
* (guides), .
Diana Payton , .. .
.
Se você estiver interessado, estamos procurando um redator técnico sobre Grafana Cloud que trabalhará na documentação oficial do upstream do Prometheus. No final do dia, levamos nosso compromisso com a comunidade a sério.
Como de costume, as notas do dev-summit serão publicadas. Você também pode ler os resultados da cúpula 2020-1 e das cúpulas dos anos anteriores .
PS do tradutor
Leia também em nosso blog:
- “ Monitoramento e Kubernetes ” (revisão e vídeo-relatório);
- " O dispositivo e mecanismo do Operador Prometheus no Kubernetes ";
- " Apresentando k8s-image-availability-exporter para detectar imagens ausentes no Kubernetes ».