Je vous suggère de lire la transcription du rapport de Roman Khavronenko « ExtendedPromQL »
En bref sur moi. Je m'appelle Romain. Je travaille chez CloudFlare et vis à Londres. Mais je suis également responsable de VictoriaMetrics.
Et je suis l'auteur pour Grafana et est un petit proxy pour ClickHouse.
Nous commencerons par la première partie, intitulée « Difficultés de traduction » et j'y parlerai du fait que toute langue, ou même simplement une langue de communication, est très importante. Parce que c'est ainsi que vous transmettez vos pensées à une autre personne ou à un autre système, ainsi que vous formulez une demande. Les internautes se disputent pour savoir quelle langue est la meilleure : Java ou une autre. Pour ma part, j'ai décidé qu'il fallait choisir en fonction de la tâche, car tout cela est spécifique.
Commençons par le tout début. Qu’est-ce que PromQL ? PromQL est le langage de requête Prometheus. C'est ainsi que nous formons des requêtes dans Prometheus pour obtenir des données de séries chronologiques.
Que sont les données de séries chronologiques ? Littéralement, ce sont trois paramètres.
Ce sont:
- Que regardons-nous ?
- Quand on le regarde.
- Et quelle valeur cela montre-t-il ?
Si vous regardez ce graphique (ce graphique provient de mon téléphone et montre mes statistiques de pas), il peut répondre rapidement à ces questions.
Nous regardons les étapes. Nous voyons le sens et nous voyons le moment où nous le regardons. Autrement dit, en regardant ce diagramme, vous pouvez facilement dire que dimanche j'ai fait environ 15 000 pas. Il s’agit de données de séries chronologiques.
Maintenant, « divisons-les » (convertissons) en un autre modèle de données sous la forme d'un tableau. Ici, nous avons également ce que nous regardons. Ici, j'ai ajouté quelques données supplémentaires, que nous appellerons métadonnées, c'est-à-dire que ce n'est pas moi qui ai vécu cela, mais deux personnes, par exemple Jay et Silent Bob. C'est ce que nous regardons ; qu'est-ce que cela montre et quand montre-t-il cette valeur.
Essayons maintenant de stocker toutes ces données dans une base de données. Par exemple, j'ai pris la syntaxe ClickHouse. Et ici, nous créons un tableau appelé « Étapes », c'est-à-dire ce que nous regardons. Il y a un moment où nous y regardons ; ce qu'il montre et quelques métadonnées où nous stockerons de qui il s'agit : Jay et Silent Bob.
Et pour essayer de visualiser tout cela, nous utiliserons Grafana parce que, d'abord, c'est beau.
Nous utiliserons également ce plugin. Il y a deux raisons à cela. La première est parce que je l’ai écrit. Et je sais exactement à quel point il est difficile d'extraire des données de séries chronologiques de ClickHouse pour les afficher dans Grafana.
Nous l'afficherons dans le panneau graphique. Il s’agit du panneau le plus populaire de Grafana, qui montre la dépendance d’une valeur au temps, nous n’avons donc besoin que de deux paramètres.
Écrivons la requête la plus simple : comment afficher les statistiques des étapes dans Grafana, en stockant ces données dans ClickHouse, dans le tableau que nous avons créé. Et nous écrivons cette simple demande. Nous choisissons parmi les étapes. Nous sélectionnons une valeur et sélectionnons l'heure de ces valeurs, c'est-à-dire les trois mêmes paramètres dont nous avons parlé.
Et en conséquence, nous obtiendrons un graphique comme celui-ci. Qui sait pourquoi il est si étrange ?
C'est vrai, nous devons trier par temps.
Et à la fin, nous obtiendrons un calendrier meilleur, mais toujours étrange. Qui sait pourquoi ? C'est vrai, il y a deux participants, et chez Grafana, nous offrons deux séries chronologiques, car si vous regardez à nouveau le modèle de données, chaque série chronologique est une combinaison unique de nom et de toutes les étiquettes clé-valeur.
Nous devons donc choisir une personne spécifique. Nous choisissons Jay.
Et dessinons à nouveau. Le graphique ressemble désormais à la vérité. Maintenant, c'est un programme normal et tout fonctionne bien.
Et vous savez probablement comment faire à peu près la même chose, mais dans Prometheus via PromQL. Quelque chose comme ça. Un peu plus simple. Et décomposons tout cela. Nous avons fait des pas. Et filtrez par Jay. Nous ne précisons pas ici que nous devons obtenir une valeur et nous ne choisissons pas de moment.
Essayons maintenant de calculer la vitesse de déplacement de Jay ou Silent Bob. Dans ClickHouse, nous devrons faire runningDifference, c'est-à-dire calculer la différence entre des paires de points et les diviser par le temps pour obtenir la vitesse exacte. La demande ressemblera à ceci.
Et il affichera approximativement ces valeurs, c'est-à-dire que Silent Bob ou Jay fait environ 1,8 pas par seconde.
Et dans Prometheus, vous savez aussi comment faire. Beaucoup plus facile qu’avant.
Et pour que cela soit également facile à faire dans Grafana, j'ai ajouté ce wrapper, qui ressemble beaucoup à PromQL. Cela s'appelle Rate Macros ou peu importe comment vous voulez l'appeler. Dans Grafana, vous écrivez simplement « taux », mais quelque part au fond, cela se transforme en cette grande demande. Et vous n'avez même pas besoin de le regarder, il est là quelque part, mais vous gagnez beaucoup de temps, car écrire des requêtes SQL aussi volumineuses coûte toujours cher. Vous pouvez facilement faire une erreur et ne pas comprendre ce qui se passe pendant longtemps.
Et c'est une demande qui ne rentrait même pas dans une seule diapositive et j'ai même dû la diviser en deux colonnes. C'est aussi une requête dans ClickHouse, qui fait le même tarif, mais pour les deux séries temporelles : Silent Bob et Jay, ce qui fait que nous avons deux séries temporelles sur le panel. Et c'est déjà très difficile, à mon avis.
Et selon Prométhée, ce sera somme (taux). Pour ClickHouse, j'ai créé une macro distincte appelée RateColumns, qui ressemble à une requête dans Prometheus.
Nous l'avons examiné et il semble que PromQL soit vraiment cool, mais il a bien sûr des limites.
Ce sont:
- SÉLECTION limitée.
- JOIN limites.
- Pas de support.
Et si vous travaillez avec depuis longtemps, alors vous savez que parfois il est très difficile de faire quelque chose dans PromQL, mais en SQL, vous pouvez presque tout faire, car toutes ces options dont nous venons de parler pourraient être réalisées en SQL. . Mais serait-il pratique de l'utiliser ? Et cela me fait penser que le langage le plus puissant n’est pas toujours le plus pratique.
Par conséquent, vous devez parfois choisir une langue pour la tâche. C'est comme si Batman combattait Superman. Il est clair que Superman est plus fort, mais Batman a pu le vaincre parce qu'il est plus pratique et savait exactement ce qu'il faisait.
Et la partie suivante est l'extension de PromQL.
Encore une fois à propos de VictoriaMetrics. Qu’est-ce que VictoriaMetrics ? Il s'agit d'une base de données de séries chronologiques, elle est en OpenSource, nous distribuons ses versions simples et cluster. Selon nos benchmarks, il est plus rapide que tout ce qui existe actuellement sur le marché et la compression est similaire, c'est-à-dire que de vraies personnes signalent une compression d'environ 0,4 octet par point, tandis que celle de Prometheus est de 1,2 à 1,4.
Nous soutenons bien plus que Prometheus. Nous prenons en charge InfluxDB, Graphite, OpenTSDB.
Vous pouvez nous « écrire », c’est-à-dire que vous pouvez transférer d’anciennes données.
Et nous travaillons également parfaitement avec Prometheus et Grafana, c'est-à-dire que nous prenons en charge le moteur PromQL. Et dans Grafana, vous pouvez simplement remplacer le point de terminaison Prometheus par VictoriaMetrics et tous vos tableaux de bord fonctionneront comme avant.
Mais vous pouvez également utiliser les fonctionnalités supplémentaires fournies par VictoriaMetrics.
Nous passerons rapidement en revue les fonctionnalités que nous avons ajoutées.
Omettre le paramètre d'intervalle – vous pouvez omettre les paramètres d'intervalle dans Grafana. Lorsque vous ne souhaitez pas obtenir des graphiques étranges lors d'un zoom avant/arrière dans le panneau, il est recommandé d'utiliser la variable $__interval. Il s'agit d'un changement interne à Grafana et il sélectionne lui-même la plage de données. Et VictoriaMetrics elle-même peut comprendre quelle devrait être cette plage. Et vous n'avez pas besoin de mettre à jour toutes vos demandes. Ce sera beaucoup plus facile.
La deuxième fonction est le référencement d’intervalle. Vous pouvez utiliser cet intervalle dans vos expressions. Vous pouvez multiplier, diviser, transférer, vous y référer.
Vient ensuite la famille de fonctions de cumul. La fonction Rollup transforme n'importe laquelle de vos séries chronologiques en trois séries chronologiques distinctes. Ce sont le minimum, le maximum et la moyenne. Je trouve cela très pratique car cela peut parfois révéler des valeurs aberrantes et des inexactitudes.
Et si vous êtes simplement en colère ou en colère, vous manquerez probablement certains cas où la série chronologique ne se comporte pas comme prévu. Avec cette fonction, c'est beaucoup plus facile à voir, disons que max est très éloigné de avg.
Vient ensuite la variable par défaut. Par défaut - cela signifie quelle valeur nous devons dessiner dans Grafana si nous n'avons pas de série chronologique pour le moment. Quand est-ce que cela arrive ? Supposons que vous exportiez des mesures d'erreur. Et vous avez une application tellement cool que lorsque vous démarrez, vous n'avez aucune erreur et même aucune erreur pendant les trois heures ou même la journée suivantes. Et vous disposez de tableaux de bord qui montrent la relation entre le succès et l’erreur. Et ils ne vous montreront rien car vous n’avez pas de métrique d’erreur. Et par défaut, vous pouvez spécifier n'importe quoi.
Keep_last_Value – enregistre la dernière valeur de la métrique si elle est manquante. Si Prometheus ne le trouve pas dans les 5 minutes suivant le prochain grattage, nous nous souviendrons ici de sa dernière valeur et vos graphiques ne se briseront plus.
Scrape_interval – indique à quelle fréquence Prometheus collecte des données sur votre métrique et à quelle fréquence. Ici, vous pouvez voir un laissez-passer, par exemple.
Le remplacement d'étiquette est une fonctionnalité populaire. Mais nous pensons que c'est un peu compliqué car cela nécessite des arguments entiers. Et vous devez non seulement vous souvenir de 5 arguments, mais également vous souvenir de leur séquence.
Alors pourquoi ne pas les rendre plus simples ? Autrement dit, divisez-le en petites fonctions avec une syntaxe compréhensible.
Et maintenant la partie amusante. Pourquoi pensons-nous qu'il s'agit d'un PromQL étendu ? Parce que nous prenons en charge les expressions de table communes. Vous pouvez suivre le code QR (), voir les liens avec des exemples, du terrain de jeu, où vous pouvez exécuter des requêtes directement dans VictoriaMetrics sans l'installer simplement dans le navigateur.
Et qu'est ce que c'est? Cette demande ci-dessus est une demande assez populaire. Je pense que dans n'importe quel tableau de bord de nombreuses entreprises, vous utilisez le même filtre pour tout. Habituellement, c'est le cas. Mais lorsque vous devez ajouter un nouveau filtre, vous devez mettre à jour chaque panneau, ou télécharger le tableau de bord, l'ouvrir en JSON, rechercher un remplacement, ce qui prend également du temps. Pourquoi ne pas stocker cette valeur dans une variable et la réutiliser ? Cela semble, à mon avis, beaucoup plus simple et clair.
Par exemple, lorsque j'ai besoin de mettre à jour les filtres dans Grafana dans toutes les requêtes, le tableau de bord peut être énorme ou il peut même y en avoir plusieurs. Et comment aimerais-je résoudre ce problème dans Grafana ?
Je résous ce problème de cette façon : je crée un commonFilter et j'y définis ce filtre, puis je le réutilise dans les requêtes. Mais si vous faites la même chose maintenant, cela ne fonctionnera pas car Grafana ne vous permet pas d'utiliser des variables dans les variables de requête. Et c'est un peu étrange.
Et j’ai donc créé une option qui vous permet de faire cela. Et si vous êtes intéressé ou souhaitez une telle fonctionnalité, soutenez-la ou n’aimez pas si vous n’aimez pas cette idée.
En savoir plus sur PromQL étendu. Ici, nous définissons non seulement une variable, mais une fonction entière. Et nous l’appelons ru (utilisation des ressources). Et cette fonction accepte les ressources gratuites, la limitation des ressources et le filtrage. La syntaxe semble simple. Et il est très simple d’utiliser cette fonction et de calculer le pourcentage de mémoire libre dont nous disposons. Autrement dit, quelle est la quantité de mémoire dont nous disposons, quelle est la limitation et comment filtrer. Cela semble beaucoup plus pratique si vous écrivez tout cela, en réutilisant les mêmes filtres, car cela se transformerait en une très grosse requête.
Et voici un exemple d’une si grande demande. Il provient du tableau de bord officiel NodeExporter pour Grafana. Mais je comprends à peine ce qui se passe ici. Bien sûr, je comprends si vous regardez attentivement, mais le nombre de parenthèses peut immédiatement réduire la motivation à comprendre ce qui se passe ici. Et pourquoi ne pas le rendre plus simple et plus clair ?
Par exemple, comme ceci, séparer les choses ou parties significatives en variables. Et puis faites vos calculs de base. Cela ressemble déjà plus à de la programmation, c'est ce que j'aimerais voir à l'avenir dans Grafana.
Voici un deuxième exemple de la façon dont nous pourrions rendre cela encore plus facile si nous avions déjà cette fonction ru, et qu'elle existe déjà directement dans VictoriaMetrics. Et vous transmettez ensuite simplement la valeur mise en cache que vous avez déclarée dans le CTE.
J'ai déjà parlé de l'importance d'utiliser le bon langage de programmation. Et, probablement, chaque entreprise de Grafana a quelque chose de différent à faire. Et vous donnez probablement également accès à Grafana à vos développeurs, et les développeurs font ce qu'ils veulent. Et ils le font tous différemment. Mais je voulais que ce soit en quelque sorte le même, c'est-à-dire qu'il soit réduit à une norme commune.
Disons que vous n'avez même pas que des ingénieurs système, peut-être même que vous avez des experts, des développeurs ou des SRE. Peut-être avez-vous des experts qui savent ce qu'est la surveillance, qui savent ce qu'est Grafana, c'est-à-dire qu'ils travaillent avec lui depuis des années et qu'ils savent exactement comment le faire correctement. Et ils l'ont déjà écrit 100 fois et l'ont expliqué à tout le monde, mais pour une raison quelconque, personne n'écoute.
Et s’ils pouvaient mettre ces connaissances directement dans Grafana afin que d’autres utilisateurs puissent réutiliser les fonctionnalités ? Et s’ils avaient besoin de calculer le pourcentage de mémoire libre, ils appliqueraient simplement la fonction. Et si les créateurs d'exportateurs, en plus de leur produit, fournissaient également un ensemble de fonctions sur la façon de travailler avec leurs métriques, car ils savent exactement ce que sont ces métriques et comment les calculer correctement ?
Cela n'existe pas vraiment. C'est ce que j'ai fait moi-même. Il s'agit du support de la bibliothèque dans Grafana. Disons que les gars qui ont créé NodeExporter ont fait ce dont j'ai parlé. Et ils fournissaient également un ensemble de fonctions.
Autrement dit, cela ressemble à ceci. Vous connectez cette bibliothèque à Grafana, vous passez à l'édition et c'est écrit très simplement en JSON comment travailler avec cette métrique. C'est-à-dire un ensemble de fonctions, leur description et ce qu'elles deviennent.
Je pense que cela pourrait être utile, car dans Grafana, vous écririez exactement comme ça. Et Grafana vous "dit" qu'il existe telle ou telle fonction de telle ou telle bibliothèque - utilisons-la. Je pense que ce serait très cool.
Un peu sur VictoriaMetrics. Nous faisons beaucoup de choses intéressantes. Lisez nos articles sur la compression, sur nos compétitions avec d'autres applications de données de séries chronologiques, notre explication sur la façon de travailler avec PromQL, car il y a encore beaucoup de débutants dans ce domaine, ainsi que sur l'évolutivité verticale et sur la confrontation avec Thanos.
Questions:
Je vais commencer ma question par une histoire de vie simple. Lorsque j’ai commencé à utiliser Grafana, j’ai écrit une requête très convaincante de 5 lignes. Le résultat final est un graphique très convaincant. Ce programme est presque entré en production. Mais en y regardant de plus près, il s’est avéré que ce graphique montre une absurdité absolue qui n’a rien à voir avec la réalité, même si les chiffres se situent dans la fourchette à laquelle nous nous attendions. Et ma question. Nous avons des bibliothèques, nous avons des fonctions, mais comment écrire des tests pour Grafana ? Vous avez rédigé une demande complexe dont dépend une décision commerciale : commander ou ne pas commander un véritable conteneur de serveurs. Et comme nous le savons, cette fonction qui dessine le graphique est similaire à la vérité. Merci.
Merci pour la question. Il y a deux parties. Premièrement, j'ai l'impression, d'après mon expérience, que la plupart des utilisateurs, lorsqu'ils regardent leurs graphiques, ne comprennent pas ce qu'ils leur montrent. Pour une raison quelconque, les gens sont très doués pour trouver une excuse pour toute anomalie qui se produit dans les graphiques, même s'il s'agit d'une erreur dans une fonction. Et la deuxième partie - il me semble que l'utilisation de telles fonctions serait une bien meilleure approche pour résoudre votre problème, au lieu que chacun de vos développeurs fasse sa propre planification de capacité et commette des erreurs avec une certaine probabilité.
Comment vérifier?
Comment vérifier? Probablement pas.
Comme test à Grafana.
Qu’est-ce que Grafana a à voir là-dedans ? Grafana traduit cette requête directement vers le DataSource.
Ajout d'un petit peu aux paramètres.
Non, rien n'est ajouté à Grafana. Il peut y avoir des paramètres GET, comme, par exemple, step. Il n'est pas explicitement spécifié, mais vous pouvez le remplacer, ou vous ne pouvez pas le remplacer, mais il est ajouté automatiquement. Vous n'écrirez pas de tests ici. Je ne pense pas que nous devrions compter sur Grafana comme source de vérité ici.
Merci pour le rapport! Merci pour la compression ! Vous avez mentionné le mappage d'une variable dans un graphique, que dans Grafana vous ne pouvez pas utiliser une variable dans une variable. Tu vois ce que je veux dire?
Oui.
C'était au départ un casse-tête lorsque j'ai voulu créer une alerte dans Grafana. Et là, vous devez créer une alerte pour chaque hôte séparément. Ce truc que vous avez fait, est-ce que ça marche pour les alertes dans Grafana ?
Si Grafana n'accède pas aux variables différemment, alors oui, cela fonctionnera. Mais mon conseil est de ne pas utiliser du tout les alertes dans Grafana, il vaut mieux utiliser alertmanager.
Oui, je l'utilise, mais il me semblait juste plus simple à mettre en place dans Grafana, mais merci pour le conseil !
Source: habr.com