Lors de PromCon Online 2020, j'ai donné une conférence intitulée "L'avenir de Prométhée et de son écosystème". Et je veux partager avec vous ses points clés.
Résumé
Depuis la dernière conférence PromCon - 2019, il y a eu de nombreux changements dans Prometheus.
2.14
La version 2.14 introduit une nouvelle interface dans React. Bien qu'en termes de fonctionnalités, il soit toujours en retard sur l'ancien, nous y travaillons et continuons à l'améliorer.
2,15
La version 2.15 est tombée sous la bannière de l'API de métadonnées. Le format d'exposition Prometheus a longtemps pris en charge les expressions spéciales
HELP, TYPEetc., cependant Prometheus lui-même avait l'habitude de simplement supprimer ces données. Maintenant qu'ils restent, vous pouvez leur ouvrir un accès externe via l'API. Par exemple, Grafana profite déjà de cette opportunité et fournit aux utilisateurs des informations supplémentaires sur les séries chronologiques avec lesquelles ils travaillent:
2,16
La version 2.16 s'est concentrée sur diverses améliorations et stabilité. Par exemple, depuis 2016, les utilisateurs se posent des questions sur la possibilité de sélectionner l'heure locale dans l'interface utilisateur, ainsi que sur la mise en œuvre du journal des requêtes - c'était bien de fermer ces problèmes.
2,17
En parlant de demandes de fonctionnalités persistantes, la version 2.17 a finalement apporté le "I" tant attendu dans ACID pour la base de données : isolation .
2,18
Dans la version 2.18 , le traçage et la prise en charge des instances de format d'exposition ont été améliorés. Les instances sont le premier impact perceptible par l'utilisateur de la mise en œuvre d' OpenMetrics dans Prometheus. En les combinant avec Grafana, vous pouvez obtenir une granularité pratique, vous permettant de passer de:
... à:
2.19
En 2.19, nous avons réduit la consommation de mémoire jusqu'à 50%! Même si Prometheus est déjà assez efficace, il existe un potentiel d'optimisation important à la fois excitant et intimidant.
Ce graphique en est une excellente illustration:
2,20
La version 2.20 possède le plus long journal des modifications depuis la v2.6 (!). Le principal est probablement la prise en charge native de la découverte de services pour Docker Swarm et DigitalOcean.
Mais il y a un changement plus important qui va au-delà de la mise en œuvre de deux mécanismes indépendants de découverte de services: nous séparons Prometheus et jetons un regard neuf sur de nombreuses solutions anciennes et approches établies. Le monde a changé (peut-être avons-nous également joué un rôle dans ce domaine) - cela doit être pris en compte à la fois dans le projet lui-même et dans les autres.
node_exporter
Pour résumer, j'aimerais souligner que node_exporter a atteint la version 1.0 et inclut désormais le support EXPERIMENTAL TLS. La Cloud Native Computing Foundation a parrainé l'audit de node_exporter par Cure53 (il a couvert à la fois l'exportateur en général et notre implémentation TLS en particulier). Et cela valait doublement la peine: nous avons non seulement vérifié TLS avant de le copier vers d'autres exportateurs, mais nous avons également utilisé node_exporter comme cobaye à partir duquel d'autres modèles sont copiés.
Futur
Parfois, j'ai le sentiment que nous, en tant que projet, nous nous reposons sur nos lauriers. Il y a quelque temps, j'ai organisé une session de brainstorming à l'intérieur de Grafana sous la devise «Prometheus manque de fonctionnalités» et j'ai encouragé Red Hat à faire de même. En cours de route, nous avons créé un document sur TOUT disponible à toute l'équipe Prometheus. Il sert de cadre pour aborder des sujets spécifiques, décomposés en points de discussion lors des dev-summits (dès que ces points sont prêts).
Sommets des développeurs
L'année dernière, nous avons eu deux sommets de développement: l'un après la KubeCon EU, le second après la PromCon. Il était prévu de faire de même en 2020, mais COVID l'a empêché. Il n'y a pas eu de sommets cette année, mais je pense que nous avons trouvé une issue: des réunions plus courtes, plus fréquentes et virtuelles. Nous passons des blocs de 4 heures au lieu de collecter pendant 1 à 2 jours à la fois. Le premier sommet de ce type a eu lieu le 10 juillet et le prochain aura probablement lieu le 7 août. Nous continuerons à les conduire jusqu'à ce que nous ayons traité toutes les questions accumulées (bien que leur nombre augmente constamment à mesure que de plus en plus d'éléments du document ci-dessus sont ajoutés).
En ce moment, je veux faire deux choses:
- , . , , . , . — , , .
- , , . , , .
Les métadonnées commencent à apporter une valeur réelle à Prometheus (voir 2.15 ci-dessus). Nous devons implémenter plus d'options pour travailler avec les métadonnées (par exemple, les distribuer via lecture / écriture à distance). Le consensus ci-dessous ne couvre pas des questions intéressantes telles que "Et si les métadonnées changeaient / disparaissaient?" ou "Et s'ils deviennent un vecteur d'attaque?"
CONSENSUS: Nous voulons mieux conserver les métadonnées. Le travail sera réalisé dans un document spécial .
CONSENSUS: PR 6815 sera une solution de contournement EXPÉRIMENTALE. Très probablement, ce sera différent dans les versions 3.x.
Modifications du flux de travail et s / master / main /
Le thème du nettoyage des ordures accumulées dans les processus de travail ne nécessite pas d'explication particulière, mais il faut dire quelques mots sur l'élimination du verbiage (unité de terminologie). Nous voulons vraiment nettoyer la terminologie: ce n'est pas la chose la plus importante, mais quelque chose que nous pouvons faire maintenant. En attendant la boîte à outils correspondante de GitHub. Dès qu'il apparaîtra, nous tenterons d'attirer un stagiaire rémunéré à ce travail via le Community Bridge.
Je suis en pourparlers avec la Linux Foundation et la CNCF pour potentiellement implémenter cela dans tous les projets. Une belle opportunité pour toute personne intéressée par ce sujet: l'opportunité d'explorer de nombreux projets, de travailler avec divers outils, de rencontrer de nombreuses personnes. Contactez-moi sur Twitter ( @TwitchiH ) ou par mail ( richih sur grafana.com) si vous êtes intéressé.
CONSENSUS: Définissez «Exiger des vérifications de statut avant la fusion» dans tous les prometheus / référentiels ... Ne pas autoriser les poussées directes dans la branche principale? Ne pas permettre les poussées de force dans la branche principale?
CONSENSUS: Désactivez la poussée forcée vers toutes les branches principales.
CONSENSUS: Le comportement par défaut permet de pousser dans la branche principale, mais il devrait être désactivé pour certains dépôts "importants", par exemple, prometheus / prometheus (à la discrétion du responsable).
Remplissage de données (remblayage)
C'est l'une des demandes de fonctionnalités les plus anciennes et un bon exemple de la façon d'aborder le consensus. Il y a de nombreuses opinions différentes qui circulent dans l'équipe de Prometheus sur cette question, et il est difficile d'arriver à un dénominateur commun. Par conséquent, j'ai rédigé une proposition de consensus limitée et très spécifique avec trois critères: "Nous voulons soutenir le remblayage sur le réseau au moins dans les blocs qui ne chevauchent pas le bloc principal ."
Après de longues discussions et des tentatives pour parvenir à un consensus, il est devenu clair que ce ne serait pas facile à faire. Par conséquent, j'ai reformulé la proposition comme suit: «Nous voulons soutenir le remblayage sur le réseau au moins par des cours d' eau qui ne croisent pas le bloc principal".
Ce n'est qu'en forçant chacun à exprimer sa propre opinion à ce sujet, que nous avons pu arriver à la version finale: "Nous aimerions soutenir le remblayage sur le réseau dans des blocs qui ne se croisent pas avec le bloc principal, à condition qu'il soit correctement implémenté ." Chaque mot ici a été choisi pour refléter l'étendue exacte et les limites du consensus.
: Prometheus OpenMetrics, CSV- .
: backfilling , .
: backfilling , .
: backfilling , .
Une autre des tâches associées à la mise en ordre. Ici, je veux critiquer Go: il a été développé dans un monde où le mono mono est la norme. Google stocke la totalité (ou la plupart) de son code commun dans un seul référentiel. Cette approche présente de nombreux avantages, mais ne se traduit pas bien dans les conditions du monde réel. Go s'éloigne lentement mais sûrement de cet héritage.
Fait amusant: j'ai rédigé la proposition de consensus presque au tout début de la discussion. Il était clair que nous allions au moins essayer. Il était clair que Ben Kochie se porterait volontaire pour le faire. Et il était clair que node_exporter deviendrait la "victime". En règle générale, nous nous efforçons d'améliorer le flux de travail, et Ben est toujours bénévole, et node_exporter est le banc de test à partir duquel nous copions ensuite les résultats vers d'autres exportateurs. Et oui, il était important que la discussion se poursuive pendant un certain temps et que les gens y parviennent seuls, au lieu de les confronter à un fait.
CONSENSUS: Supprimez-le dans node_exporter et voyez si nous sommes satisfaits du résultat.
Listes de diffusion et IRC
Google est bloqué en Chine, mais nos listes de diffusion fonctionnent dessus. Nous avons décidé d'essayer de rendre possible la souscription par email. J'ai vérifié: prometheus-users+subscribe@googlegroups.com fonctionne. Vous pouvez également consulter les archives ( https://www.mail-archive.com/prometheus-users@googlegroups.com/maillist.html ) si vous le souhaitez.
De plus, nous nous sommes assurés que tout le monde puisse utiliser IRC via Matrix, car pour certains xkcd 1782 est très pertinent.
:
, Google ; - .
docs/community , Google.
IRC, Matrix; , .
Permettez-moi de répéter ce que j'ai dit lors du sommet: «La toute première chose que je n'aimais pas chez Prometheus en 2015 était la documentation; en 2020, je la déteste juste. Il est difficile à utiliser et presque inutile, ne convient qu'à ceux qui savent déjà ce qu'ils font, ou du moins ont une bonne idée des concepts. " Bref, nous travaillerons dans ce sens:
:
:
* (user manual) .
* (reference) , PromQL /.
* (guides), .
Diana Payton , .. .
.
Si vous êtes intéressé, nous recherchons actuellement un rédacteur technique sur Grafana Cloud pour travailler sur la documentation officielle en amont de Prometheus. À la fin de la journée, nous prenons notre engagement envers la communauté au sérieux.
Comme d'habitude, les notes du dev-Summit seront publiées. Vous pouvez également lire les résultats du sommet 2020-1 et des sommets des dernières années .
PS du traducteur
Lisez aussi sur notre blog:
- " Monitoring et Kubernetes " (revue et reportage vidéo);
- " Le dispositif et le mécanisme de l'opérateur Prometheus dans Kubernetes ";
- « Présentation de k8s-image-availability-exporter pour détecter les images manquantes dans Kubernetes ».