• /
  • EnglishEspañolFrançais日本語한국어Português
  • Se connecterDémarrer

Cette traduction automatique est fournie pour votre commodité.

En cas d'incohérence entre la version anglaise et la version traduite, la version anglaise prévaudra. Veuillez visiter cette page pour plus d'informations.

Créer un problème

Fonctionnalités PromQL prises en charge

New Relic prend en charge les requêtes de style PromQL, et notre générateur de requêtes propose un mode de requête de style PromQL qui traduit les requêtes de syntaxe PromQL en l'approximation NRQL la plus proche. Bien que la méthode d'approximation implique qu'une poignée de cas limites ne soient pas entièrement pris en charge, elle couvre une écrasante majorité de requêtes, prenant en charge plus de 99,5 % des requêtes sur les 7,8 millions de téléchargements des principaux dashboards Grafana.

Découvrez comment nous travaillons avec les requêtes PromQL, ainsi que les différences entre le PromQL standard et notre langage de requête de type PromQL.

Fonctionnalités prises en charge

Nous prenons en charge les fonctions d'agrégation, d'arithmétique, de mathématique et de taux suivantes. À mesure que nous continuons à étendre le support pour Prometheus et PromQL, cette liste sera mise à jour.

Dépannage PromQL

Cette section décrit les différences de comportement entre PromQL et notre comportement de requête de style PromQL et comment travailler avec et contourner ces différences. Ceci est particulièrement pertinent si vous souhaitez utiliser des requêtes avancées et notre mode de style PromQL dans le générateur de requêtes.

types métriques

Les recommandations Prometheus indiquent que vous ne devez utiliser que certaines fonctions, comme delta(), sur les jauges, et n'en utiliser d'autres comme rate() et increase() sur les compteurs, mais les requêtes dans Prometheus fonctionnent toujours la plupart du temps même si elles ne suivent pas ces instructions.

Cependant, parce que NRDB convertit les compteurs cumulatifs de style PromQL en compteurs delta, notre implémentation ne gère pas ces fonctions sur le mauvais type de données et produira des réponses différentes ou incorrectes.

Pour cette raison, il est préférable de suivre toutes les recommandations Prometheus lorsque vous travaillez avec notre requête de style PromQL, même si vous ne suivez pas ces recommandations dans Prometheus.

Limites

  • Pour garantir la stabilité et la performance de notre système pour tous les utilisateurs, nous imposons certaines limites aux requêtes qui peuvent être exécutées. Dans tous les cas, nous imposons une limite de 366 étapes dans les requêtes de plage. Nous renvoyons également uniquement 100 séries temporelles à partir des requêtes par défaut.
  • Si vous souhaitez en voir plus (ou moins), vous devez ajouter explicitement un topk() à votre requête. (Notez que l'implémentation topk() dans notre requête de style PromQL est différente de celle de Prometheus.)
  • Nous limitons la mémoire totale qu'une requête peut utiliser. Cela signifie que requests portant sur un grand nombre d'étapes temporelles ou de séries temporelles peuvent être rejetées, en particulier si elles sont combinées avec une agrégation telle que count ou quantile unique, qui nécessite beaucoup plus de mémoire pour être calculée que de simples agrégations arithmétiques.

Sélecteurs de vecteurs de plage (fenêtres coulissantes et comportement de lissage)

Nous fournissons un support pour les agrégations de séries chronologiques à fenêtre glissante. Pour plus d'informations, consultez notre référence NRQL et notre analyse approfondie des fenêtres coulissantes.

Pour plus d'informations sur la traduction entre NRQL et notre langage de style PromQL, voir Traduire la requête PromQL en NRQL.

Plage de requêtes et intervalles de récupération des données

  • La plage de votre requête dans PromQL doit être supérieure à la durée de l'étape de la requête pour éviter l'erreur « La taille du bucket TIMESERIES est supérieure à la fenêtre temporelle actuelle ».
  • Nous inspectons les données datant d'une minute maximum lors de l'exécution d'une requête instantanée. Si votre intervalle de scraping est supérieur à 1 minute, certaines requêtes peuvent aboutir à No data found. Évitez cela en envoyant des données au moins une fois par minute.
  • Si l'unité de série chronologique de votre requête NRQL est inférieure à l'intervalle de récupération de votre application, certaines périodes manqueront de données et le graphique résultant peut être irrégulier ou contenir des pics et des vallées. En général, définissez la taille du pas sur votre intervalle de grattage, ou plus.
Droits d'auteur © 2026 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.