Migrer depuis l'intégration Prometheus OpenMetrics

Si vous utilisez notre intégrationPrometheus OpenMetrics, nri-prometheus dans Kubernetes, vous devez migrer vers l'agent Prometheus de New Relic, newrelic-prometheus-agent, pour obtenir la même expérience monitoring . Découvrez comment configurer l'agent Prometheus de New Relic.

Étant donné que newrelic-prometheus-agent exécute en réalité Prometheus server en mode agent, la structure du fichier configuration a changé pour offrir plus de flexibilité et la possibilité d'utiliser n'importe quelle fonctionnalité liée au scraping du serveur Prometheus , comme la prise en charge de nombreuses méthodes d'autorisation, les configuration de réétiquetage ou la mise à l'échelle de l'instance Prometheus .

Nous traduisons notre fichier de configuration simplifié en un fichier de configuration de serveur Prometheus, pour vous offrir une expérience de configuration plus simple. Nous vous suggérons de lire la documentation pour pouvoir mieux suivre ce guide de migration.

Pour effectuer la migration, ajustez la section de configuration dans votre fichier values.yml avec les valeurs de ce document.

Dashboards et alertes

Les métriques sont envoyées de la même manière qu’elles ont été envoyées à l’aide de l’intégration Prometheus OpenMetrics, nri-prometheus. Dans certains cas, vous devrez peut-être modifier certaines métadonnées qui ont changé entre l'intégration Prometheus OpenMetrics, nri-prometheus, et l'agent Prometheus, newrelic-prometheus-agent.

Conseil

Lisez la liste complète des étiquettes ajoutées par l'agent Prometheus.

Métadonnées renommées

Le tableau suivant met en évidence les métadonnées renommées entre l'intégration Prometheus OpenMetrics, nri-prometheus et l'agent Prometheus, newrelic-prometheus-agent:

`nri-prometheus`	`newrelic-prometheus-agent`
`namespaceName`	`namespace`
`nodeName`	`node`
`podName`	`pod`
`serviceName`	`service`
`deploymentName`	N/A
`clusterName`	`cluster_name`
`scrapedTargetKind`	`job`. Vous pouvez également l'utiliser pour identifier le type de grattage.
`scrapedTargetName`	`instance`. Il contient également le `host:port` pour la cible.

Si vous souhaitez que les noms d'attributs nri-prometheus métadonnées précédents persistent après la migration, vous pouvez activer la configuration de réétiquetage d'écriture à distance suivante dans le fichier newrelic-prometheus-agent values.yaml . Cela garantira que le dashboard et les alertes ciblant ces attributs continueront de fonctionner normalement.

newrelic_remote_write:
  extra_write_relabel_configs:
    # Enable the extra_write_relabel_configs below for backwards compatibility with legacy POMI labels.
    # This helpful when migrating from POMI to ensure that Prometheus metrics will contain both labels (e.g. cluster_name and clusterName).
    - source_labels: [namespace]
      action: replace
      target_label: namespaceName
    - source_labels: [node]
      action: replace
      target_label: nodeName
    - source_labels: [pod]
      action: replace
      target_label: podName
    - source_labels: [service]
      action: replace
      target_label: serviceName
    - source_labels: [cluster_name]
      action: replace
      target_label: clusterName
    - source_labels: [job]
      action: replace
      target_label: scrapedTargetKind
    - source_labels: [instance]
      action: replace
      target_label: scrapedTargetInstance

Important

Pour se conformer au modèle de données Prometheus, les noms d'étiquettes Kubernetes (label.kubernetesLabel) sont nettoyés après avoir été récupérés pour remplacer tout caractère non pris en charge par _. Par exemple, l’étiquette Kubernetes k8s.io/app est ajoutée en tant que k8s_io_app. Le préfixe label. a été supprimé. La valeur de l’étiquette reste inchangée.

Méta supprimé

Les métadonnées suivantes ne sont pas disponibles avec l'agent Prometheus, newrelic-prometheus-agent:

deploymentName
integrationName
integrationVersion
nrMetricType
promMetricType
targetName
scrapedTargetName

Découverte de cibles Kubernetes

Nous avons amélioré la configuration de la découverte de cible en ajoutant Jobs. Découvrez comment configurer la découverte de cibles Kubernetes .

Les comportements par défaut ont changé entre Prometheus OpenMetrics et l'agent Prometheus. Alors que, par défaut, Prometheus OpenMetrics récupère les pods et les services contenant prometheus.io/scrape=true comme étiquette ou annotation, l'agent Prometheus récupère toutes les cibles annotated avec newrelic.io/scrape: "true", le pod et les services annotés avec prometheus.io/scrape=true ne seront récupérés par défaut que s'ils correspondent à l'une des intégrations Prometheus de New Relic prises en charge, consultez la documentation de configuration de scrape pour plus de détails.

Les métriques des nœuds ne sont plus récupérées par défaut dans l'agent Prometheus , car cela peut entraîner une duplication des métriques puisqu'elles sont normalement utilisées par l'intégration Kubernetes de New Relic.

types métriques

Prometheus OpenMetrics, nri-prometheus, en tant que solution personnalisée, convertit les métriques Prometheus en métriques New Relic avant de les envoyer, en appliquant une modélisation selon la lecture de type métrique métadonnées à partir des données récupérées : # TYPE <metric_type>.

Sur l'agent Prometheus , newrelic-prometheus-agent, qui exploite un serveur Prometheus standard, les métriques sont envoyées directement au point de terminaison d'écriture distant de New Relic, qui gère cette conversion en fonction des noms de métriques. Certaines métriques peuvent ne pas être correctement converties par le point de terminaison d'écriture distant :

Les métriques du compteur Prometheus sans le suffixe de nom total, count, sum ou bucket seront converties en Gauge.
Les métriques Prometheus Gauge avec le suffixe de nom total, count, sum ou bucket seront converties en Counter.

Pour résoudre ce problème, vous pouvez configurer des options de réétiquetage de modélisation de type métrique, vérifier les transformations métriques et d'étiquettes pour plus de détails.

Transformations

Les transformations Prometheus OpenMetrics, nri-prometheus, sont désormais remplacées par la configuration de réétiquetage Prometheus . Voir une liste d' exemples de configuration de réétiquetage.

Auto-instrumentation

Similaire à Prometheus OpenMetrics (nri-prometheus), l'agent Prometheus (newrelic-prometheus-agent) auto-scrape les métriques internes. Ces métriques ont le préfixe prometheus_ et vous pouvez les utiliser pour observer l'état de l'instance Prometheus. Par défaut, seul un ensemble réduit de ces métriques est envoyé. Vous pouvez trouver la liste des métriques sur le fichier default values.yaml du graphique, en recherchant job_name: self-metrics.

Nous vous proposons également un dashboard organisé pour les auto-métriques avec des informations sur les performances et la santé, ainsi que sur le volume de métriques envoyées. Installez le quickstart contenant le dashboard de l'agent Prometheus dans votre compte New Relic.

Conserver l'intégration de Prometheus OpenMetrics pendant la migration

New Relic souhaite garantir à ses clients une migration fluide et transparente. Vous pouvez conserver soit l'intégration Prometheus OpenMetrics, nri-prometheus, l'agent Prometheus, newrelic-prometheus-agent, ou les deux.

Pour préserver nri-prometheus et ne pas utiliser l'agent Prometheus pour le moment, définissez votre fichier values.yaml comme suit :

nri-metadata-injection:
  enabled: true

nri-prometheus:
  enabled: true

newrelic-prometheus-agent:
  enabled: false

Suivez les étapes expliquées dans ce document pour mettre à niveau le cluster Kubernetes à l'aide de Helm.

Cette traduction automatique est fournie pour votre commodité.