• /
  • 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

Mise à l'échelle de l'instance de l'agent Prometheus

À mesure que la taille du cluster augmente, davantage de données sont collectées par Prometheus et, à un moment donné, les limites de la quantité de données que l'agent Prometheus peut traiter sont atteintes. Le mode de défaillance le plus courant est le manque de mémoire en raison de la cardinalité accrue de la série temporelle. Lorsque cela se produit, votre instance Prometheus commence à mourir car elle a besoin de plus de mémoire, ce qui signifie que vous devez commencer à évoluer.

Pour analyser la solution en détail, nous fournissons un dashboard avec différents graphiques qui nous aident à savoir quand nous devons faire évoluer notre solution Prometheus .

Il existe deux approches de mise à l'échelle différentes pour l'agent Prometheus de New Relic : verticale ou horizontale.

Mise à l'échelle verticale

Ce type de mise à l’échelle ne présente aucune complexité. C'est aussi simple que de mettre à jour la mémoire ou le processeur de la machine correspondante sur laquelle se trouve le nœud du cluster.

Cependant, cette approche peut ne pas être évolutive pour un grand cluster, ou nous ne voulons tout simplement pas avoir un seul pod qui consomme autant de Go de mémoire dans notre nœud. Si tel est le cas, vous devrez peut-être utiliser une mise à l’échelle horizontale.

Mise à l'échelle horizontale

La mise à l'échelle horizontale, également connue sous le nom de sharding, est prise en charge par la configuration d'un paramètre configuration qui permet d'exécuter plusieurs serveurs Prometheus en mode agent pour collecter vos données.

Si vous définissez la valeur sharding.total_shards_count , l'exécution StatefulSet inclura autant de répliques que vous définissez. Lorsque vous l'utilisez, le composant configurateur inclut automatiquement des règles de réétiquetage supplémentaires, de sorte que chaque cible n'est récupérée que par un seul serveur Prometheus. Ces règles s'appuient sur l'adresse de la cible hacher-mod.

Pour définir les règles de réétiquetage pour chaque cible, l'agent calcule un hacher pour la cible donnée __address__ puis il applique le modulus au hacher, le module étant le nombre total de fragments. Ensuite, il connaît le fragment dans lequel la cible récupérée doit être incluse.

Par exemple, si vous incluez les éléments suivants dans le fichier custom-values.yaml :

# (...)
sharding:
total_shards_count: 2
# (...)

Et ensuite, vous mettez à niveau la sortie en exécutant :

bash
$
helm upgrade my-prometheus-release newrelic-prometheus-configurator/newrelic-prometheus-agent -f custom-values.yaml

Ensuite, deux serveurs Prometheus seront exécutés et chaque cible ne sera scrapée que par l'un d'entre eux.

Un exemple de diagramme serait le suivant :

Prometheus sharding

Identification du grattoir cible

L'identification du fragment (nom du StatefulSet Pod) est ajoutée en tant qu'étiquette prometheus_server à toutes les métriques et vous pouvez l'utiliser pour comprendre quelle instance Prometheus récupère chaque cible.

Pour identifier de manière unique une instance de serveur Prometheus au sein d'un compte, vous devez utiliser une combinaison des étiquettes cluster_name et prometheus_server .

Auto-métriques

Les auto-métriques du serveur Prometheus doivent être collectées à partir de tous les serveurs Prometheus, donc les règles supplémentaires lors de la configuration sharding ne s'appliquent pas au travail de collecte des auto-métriques Prometheus. Cela est possible car l'agent accepte l'indicateur skip_sharding dans les tâches static_target . Ce paramètre est déjà défini dans la tâche d'auto-métriques par défaut.

Limites

Si vous incluez des tâches de scraping supplémentaires dans la configuration en tant extra_scrape_configs que, étant donné que ce champ contient la définition brute des tâches Prometheus, l'agent n'inclura pas les règles correspondant à sharding configuration et, par conséquent, la cible correspondante sera supprimée par tous les serveurs Prometheus.

Actuellement, la mise à l'échelle automatique n'est pas prise en charge. Pour augmenter ou diminuer le nombre de fragments, vous devez mettre à jour les paramètres du graphique, ce qui redémarre le pod Prometheus.

Droits d'auteur © 2025 New Relic Inc.

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