Configurer l'agent Prometheus

Configurer l'agent Prometheus

Vous devez placer les exemples ci-dessous dans la section config de l'agent. Reportez-vous à la méthode d'installation que vous avez utilisée pour savoir laquelle est dans votre cas.

Pour configurer l'agent à l'aide de Helm, vous devez configurer votre values.yaml de l'une de ces deux manières :

global:
  licenseKey: YOUR_NEW_RELIC_LICENSE_KEY
  cluster: K8S_CLUSTER_NAME

newrelic-prometheus-agent:
  enabled: true
  config:
    # YOUR CONFIGURATION GOES HERE

licenseKey: YOUR_NEW_RELIC_LICENSE_KEY
cluster: K8S_CLUSTER_NAME

config:
  # YOUR CONFIGURATION GOES HERE. An example:

Définir quel point de terminaison gratter

Par défaut, l'agent New Relic Prometheus utilise deux annotations pour découvrir la cible : newrelic.io/scrape: "true" et prometheus.io/scrape: "true".

Toutes les cibles du cluster annotées avec newrelic.io/scrape: "true" sont découvertes et récupérées par défaut. La cible annotée avec prometheus.io/scrape: "true" sera scrapée ou non en fonction de la configuration.

Scrape métriques uniquement à partir de l'intégration Prometheus

L'agent Prometheus peut être configuré pour extraire les métriques de l'intégration la plus populaire de Kubernetes. Jetez un œil à la liste des intégrations contenant un ensemble de dashboards et alertespour commencer monitoring dès le départ.

Cette liste est définie dans le fichier values.yaml du graphique de gestion de l'agent Prometheus de New Relic. Vous pouvez modifier cette liste, mais certains dashboardspeuvent ne pas fonctionner immédiatement avec des étiquettes ou des valeurs personnalisées.

Lors de la mise à niveau, de nouveaux filtres d'intégration peuvent être disponibles. Par conséquent, la quantité de données récupérées pourrait augmenter, en fonction des services de votre cluster, après une mise à niveau impliquant des filtres d'intégration. Vous pouvez éviter cela en enregistrant une liste fixe de app_values dans votre fichier values.yaml . Par exemple:

app_values: ["redis", "traefik", "calico", "nginx", "coredns", "kube-dns", "etcd", "cockroachdb"]

De plus, il peut arriver qu'une nouvelle version des filtres d'intégration provoque le scraping d'une cible qui a déjà été scrapée par un travail une deuxième fois. Afin de recevoir une notification en cas de données dupliquées (et d'éviter complètement le scraping de données dupliquées), vous pouvez créer une alerte basée sur la requête suivante :

FROM Metric SELECT uniqueCount(job) FACET instance, cluster_name LIMIT 10 SINCE 2 minutes ago

Si une valeur est différente de 1, cela signifie que vous avez deux tâches ou plus qui récupèrent la même instance dans le même cluster.

Grattez les métriques de toutes les cibles

Si vous devez extraire toutes les cibles annotées avec prometheus.io/scrape: "true", vous devez effectuer l'une des actions suivantes, selon la méthode d'installation choisie :

• Si vous avez utilisé l’installation guidée, sélectionnez l’option Scrape all Prometheus endpoints .

  

• Si vous avez utilisé Helm, ajoutez les valeurs suivantes dans votre configuration Prometheus-agent :

  kubernetes:
    integrations_filter:
      enabled: false

  Copier

Découverte de cibles Kubernetes

Les tâches Kubernetes découvrent la cible et la récupèrent selon la configuration target_discovery. Si dans la configuration target_discovery , vous définissez les commutateurs pod et endpoints sur true, Prometheus créera des règles pour découvrir tout pod ou point de terminaison dans le cluster ayant un port exposé.

Utilisez le paramètre configuration target_discovery.filter pour filtrer la cible que Prometheus récupère. Utilisez les étiquettes label et annotations pour filtrer par conditions actuelles et l'opérateur AND pour toutes les conditions.

L'exemple suivant récupère uniquement Pods et Endpoints avec l'annotation newrelic.io/scrape: "true" et l'étiquette k8s.io/app avec postgres ou mysql comme valeurs. Pour le point de terminaison, l'annotation doit être présente dans le service qui lui est lié. Les expressions régulières sont ancrées, c'est-à-dire que si vous configurez scrape: 'true', Prometheus évalue true comme ^true$. Pour éviter cela, utilisez .*true.* pour qu'il corresponde également a-true-example.

kubernetes:
  jobs:
    - job_name_prefix: example
      integrations_filter:
        enabled: false
      target_discovery:
        pod: true
        endpoints: true
        filter:
          annotations:
            # <string>: <regex>
            newrelic.io/scrape: "true"
          label:
            # <string>: <regex>
            k8s.io/app: "(postgres|mysql)"

Configurer une cible statique

L'agent Prometheus définit une tâche cible statique pour extraire les auto-métriques par défaut, mais vous pouvez configurer une cible statique supplémentaire en incluant des tâches supplémentaires.

L'exemple suivant inclut une tâche supplémentaire pour récupérer un serveur géré séparément et la tâche d'auto-métriques pour continuer à signaler les métriques de l'agent Prometheus, telles que définies par défaut.

static_targets:
  jobs:
    - job_name: managed-exporter
      targets:
        - "managed_exporter.your-company.tld:5432"
    - job_name: self-metrics
      skip_sharding: true  # sharding is skipped to obtain self-metrics from all Prometheus servers.
      targets:
        - "localhost:9090"
      extra_metric_relabel_config:
        - source_labels: [__name__]
          action: keep
          regex: "\
            prometheus_agent_active_series|\
            prometheus_target_interval_length_seconds|\
            prometheus_target_scrape_pool_targets|\
            prometheus_remote_storage_samples_pending|\
            prometheus_remote_storage_samples_in_total|\
            prometheus_remote_storage_samples_retried_total|\
            prometheus_agent_corruptions_total|\
            prometheus_remote_storage_shards|\
            prometheus_sd_kubernetes_events_total|\
            prometheus_agent_checkpoint_creations_failed_total|\
            prometheus_agent_checkpoint_deletions_failed_total|\
            prometheus_remote_storage_samples_dropped_total|\
            prometheus_remote_storage_samples_failed_total|\
            prometheus_sd_kubernetes_http_request_total|\
            prometheus_agent_truncate_duration_seconds_sum|\
            prometheus_build_info|\
            process_resident_memory_bytes|\
            process_virtual_memory_bytes|\
            process_cpu_seconds_total"

Intervalle de grattage cible

Par défaut, l'agent Prometheus récupère toutes les cibles pour les métriques toutes les 30 secondes comme défini dans common.scrape_interval pour toutes les tâches de scraping dans la configuration. Vous pouvez modifier cela en utilisant la touche scrape_interval dans cette section.

Cet exemple montre deux tâches Kubernetes avec des intervalles de scraping différents :

common:
  scrape_interval: 30s
kubernetes:
  jobs:
    # this job will use the default scrape_interval defined in common.
    - job_name_prefix: default-targets-with-30s-interval
      target_discovery:
        pod: true
        filter:
          annotations:
            newrelic.io/scrape: "true"

    - job_name_prefix: slow-targets-with-60s-interval
      scrape_interval: 60s
      target_discovery:
        pod: true
        filter:
          annotations:
            newrelic.io/scrape_slow: "true"

transformations métriques et d'étiquettes

Vous pouvez appliquer des transformations métriques et d'étiquettes à n'importe quelle section configuration , mais le fait de les définir au niveau de l'écriture à distance élargit le filtrage ou les transformations.

Si vous les définissez au niveau newrelic_remote_write , les filtres s'appliquent à toutes les métriques envoyées à New Relic. Si vous les définissez dans une autre section, ils s'appliquent aux métriques récupérées par cette section. Le processus de filtrage métrique se produit après que les métriques ont été extraites de la cible.

Vous pouvez utiliser le paramètre extra_metric_relabel_config pour appliquer les filtres, ce qui ajoute des entrées du paramètre métrique . Ce paramètre est présent dans static_targets.jobs, kubernetes.jobs et le paramètre extra_write_relabel_configs pour newrelic_remote_write.

Voici un exemple de la façon de l’utiliser dans différentes parties du fichier de configuration YAML :

static_targets:
  - name: self-metrics
    urls:
      - "http://static-service:8181"
    extra_metric_relabel_config:
      # Drop metrics with prefix 'go_' for this target.
      - source_labels: [__name__]
        regex: "go_.+"
        action: drop

newrelic_remote_write:
  extra_write_relabel_configs:
    # Drop all metrics with the specified name before sent to New Relic.
    - source_labels: [__name__]
      regex: "metric_name"
      action: drop

Exemples d' snippet de fichiers YAML

Ajoutez l’un de ces exemples dans le fichier configuration YAML à partir de la section des transformations métriques et d’étiquettes .

Pour filtrer les métriques

- source_labels: [__name__]
  regex: 'prefix_.+'
  action: drop

- source_labels: [k8s_io_app]
  regex: 'appLabelValue'
  action: drop

- source_labels: [__name__,k8s_io_app]
  regex: 'prefix_.+;appLabelValue'
  action: drop

- source_labels: [__name__]
  regex: 'prefix_.+'
  action: keep

Pour ajouter ou supprimer des étiquettes métriques

- source_labels: [__name__]
  regex: 'prefix_.+'
  target_label: new_label
  action: replace
  replacement: newLabelValue

- regex: 'label_name'
  action: labeldrop

Configuration de l'autorisation cible

Certaines cibles ont besoin d'une autorisation d'accès pour être scrapées, comme la base de données No-SQL pour récupérer les données auxquelles l'utilisateur se connectant a accès, ou les exportateurs qui exposent des données sensibles dans leurs métriques point de terminaison. Toutes les méthodes d'autorisation prises en charge par Prometheus peuvent être configurées dans les sections static_targets et kubernetes .

Comme expliqué dans le guide d'installation, nous créons une configuration pour Prometheus basée sur notre YAML. Cette partie de la configuration a été transmise à Prometheus telle quelle à partir de notre YAML, vous devez donc vous référer à la documentation de Prometheus :

• TLS
• OAuth2
• En-tête d'autorisation
• Authentification de base

Voici quelques exemples de gestion de cibles nécessitant une autorisation d'accès :

kubernetes:
  jobs:
    - job_name_prefix: skip-verify-on-https-targets
      target_discovery:
        pod: true
        filter:
          annotations:
            newrelic.io/scrape: "true"
    - job_name_prefix: bearer-token
      target_discovery:
        pod: true
        filter:
          label:
            k8s.io/app: my-app-with-token
      authorization:
        type: Bearer
        credentials_file: "/etc/my-app/token"

static_targets:
  jobs:
    - job_name: mtls-target
      scheme: https
      targets:
        - "my-mtls-target:8181"
      tls_config:
        ca_file: "/etc/my-app/client-ca.crt"
        cert_file: "/etc/my-app/client.crt"
        key_file: "/etc/my-app/client.key"

    - job_name: basic-auth-target
      targets:
        - "my-basic-auth-static:8181"
      basic_auth:
        password_file: "/etc/my-app/pass.htpasswd"