Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

3.8. Configuration du stockage d’écriture à distance

Il est possible de configurer le stockage d’écriture à distance pour permettre à Prometheus d’envoyer des métriques ingérées à des systèmes distants pour un stockage à long terme. Cela n’a aucun impact sur la façon dont ou pendant combien de temps Prometheus stocke les métriques.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle d’administrateur dédié.
  • L’objet ConfigMap existe. Cet objet est créé par défaut lorsque le cluster est créé.
  • L’OpenShift CLI (oc) a été installé.

  • Il y a un point de terminaison compatible avec l’écriture à distance (tel que Thanos) et vous connaissez l’URL du point de terminaison. Consultez les points de terminaison distants Prometheus et la documentation de stockage pour obtenir des informations sur les points de terminaison compatibles avec la fonction d’écriture à distance.

    Important

    Le Red Hat fournit uniquement des informations pour la configuration des expéditeurs d’écriture à distance et n’offre pas de conseils sur la configuration des points de terminaison du récepteur. Les clients sont responsables de la mise en place de leurs propres points de terminaison compatibles avec l’écriture à distance. Les problèmes avec les configurations des récepteurs de point de terminaison ne sont pas inclus dans le support de production de Red Hat.

  • Dans un objet Secret, vous avez configuré des identifiants d’authentification pour le point de terminaison de l’écriture à distance. Il faut créer le secret dans l’espace de noms openshift-user-workload-monitoring.

    Avertissement

    Afin de réduire les risques de sécurité, utilisez HTTPS et l’authentification pour envoyer des métriques à un point de terminaison.

Procédure

  1. Éditez la carte de configuration de la configuration de l’utilisateur-workload-monitoring dans le projet openshift-user-workload-monitoring: 

    $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
    Copy to Clipboard Toggle word wrap

  2. Ajouter une section RemoteWrite: sous data/config.yaml/prometheus, comme indiqué dans l’exemple suivant: 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    prometheus:
      remoteWrite:
      - url: "https://remote-write-endpoint.example.com"
    1 
    
        <endpoint_authentication_credentials>
    2
    Copy to Clipboard Toggle word wrap
    1
    L’URL du point de terminaison de l’écriture distante.
    2
    La méthode d’authentification et les informations d’identification pour le point de terminaison. Les méthodes d’authentification actuellement prises en charge sont AWS Signature Version 4, l’authentification à l’aide de HTTP dans un en-tête de demande d’autorisation, l’authentification de base, OAuth 2.0 et le client TLS. Consultez les paramètres d’authentification d’écriture à distance pris en charge pour les configurations d’échantillons de méthodes d’authentification prises en charge.

  3. Ajouter des valeurs de configuration de relabel d’écriture après les identifiants d’authentification: 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    prometheus:
      remoteWrite:
      - url: "https://remote-write-endpoint.example.com"
        <endpoint_authentication_credentials>
        writeRelabelConfigs:
        - <your_write_relabel_configs>
    1
    Copy to Clipboard Toggle word wrap
    1
    Ajoutez une configuration pour les métriques que vous souhaitez envoyer au point de terminaison distant.

    Exemple de transfert d’une seule métrique appelée my_metric

    apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    prometheus:
      remoteWrite:
      - url: "https://remote-write-endpoint.example.com"
        writeRelabelConfigs:
        - sourceLabels: [__name__]
          regex: 'my_metric'
          action: keep
    Copy to Clipboard Toggle word wrap

    Exemple de mesures de transmission appelées my_metric_1 et my_metric_2 dans my_namespace namespace

    apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    prometheus:
      remoteWrite:
      - url: "https://remote-write-endpoint.example.com"
        writeRelabelConfigs:
        - sourceLabels: [__name__,namespace]
          regex: '(my_metric_1|my_metric_2);my_namespace'
          action: keep
    Copy to Clipboard Toggle word wrap

  4. Enregistrez le fichier pour appliquer les modifications. La nouvelle configuration est appliquée automatiquement.

Il est possible d’utiliser différentes méthodes pour s’authentifier avec un point de terminaison d’écriture à distance. Les méthodes d’authentification actuellement prises en charge sont AWS Signature Version 4, l’authentification de base, l’autorisation, OAuth 2.0 et le client TLS. Le tableau suivant fournit des détails sur les méthodes d’authentification prises en charge pour une utilisation avec l’écriture à distance.

Expand
La méthode d’authentificationConfigurer le champ mapDescription

AWS Signature Version 4

à propos de Sigv4

Cette méthode utilise l’authentification AWS Signature Version 4 pour signer des requêtes. Cette méthode ne peut pas être utilisée simultanément avec l’autorisation, l’authentification OAuth 2.0 ou l’authentification Basic.

Authentification de base

Basicauth

L’authentification de base définit l’en-tête d’autorisation sur chaque demande d’écriture à distance avec le nom d’utilisateur et le mot de passe configurés.

autorisation

autorisation

L’autorisation définit l’en-tête d’autorisation sur chaque demande d’écriture à distance à l’aide du jeton configuré.

À propos de OAuth 2.0

à proximité de Oauth2

La configuration OAuth 2.0 utilise le type de subvention d’identification client. Le Prometheus obtient un jeton d’accès à partir de tokenUrl avec l’ID client spécifié et le secret client pour accéder au point de terminaison d’écriture distante. Cette méthode ne peut pas être utilisée simultanément avec l’autorisation, l’authentification AWS Signature 4 ou l’authentification Basic.

Client TLS

à propos de TlsConfig

La configuration du client TLS spécifie le certificat CA, le certificat client et les informations de fichier clé du client utilisées pour authentifier avec le serveur de point de terminaison d’écriture à distance à l’aide de TLS. La configuration de l’échantillon suppose que vous avez déjà créé un fichier de certificat CA, un fichier de certificat client et un fichier clé client.

Les échantillons suivants montrent différents paramètres d’authentification que vous pouvez utiliser pour vous connecter à un point de terminaison d’écriture à distance. Chaque échantillon montre également comment configurer un objet secret correspondant qui contient des informations d’authentification et d’autres paramètres pertinents. Chaque échantillon configure l’authentification pour une utilisation avec la surveillance des projets définis par l’utilisateur dans l’espace de noms openshift-user-workload-monitoring.

Ce qui suit montre les paramètres d’un secret sigv4 nommé sigv4-credentials dans l’espace de noms openshift-user-workload-monitoring. 

apiVersion: v1
kind: Secret
metadata:
  name: sigv4-credentials
  namespace: openshift-user-workload-monitoring
stringData:
  accessKey: <AWS_access_key>
1 

  secretKey: <AWS_secret_key>
2 

type: Opaque
Copy to Clipboard Toggle word wrap
1
La clé d’accès AWS API.
2
La clé secrète AWS API.

Ce qui suit montre les paramètres d’authentification d’écriture à distance AWS Signature Version 4 qui utilisent un objet secret nommé sigv4-credentials dans l’espace de noms openshift-user-workload-monitoring: 

apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    prometheus:
      remoteWrite:
      - url: "https://authorization.example.com/api/write"
        sigv4:
          region: <AWS_region>
1 

          accessKey:
            name: sigv4-credentials
2 

            key: accessKey
3 

          secretKey:
            name: sigv4-credentials
4 

            key: secretKey
5 

          profile: <AWS_profile_name>
6 

          roleArn: <AWS_role_arn>
7
Copy to Clipboard Toggle word wrap
1
La région AWS.
2 4
Le nom de l’objet Secret contenant les identifiants d’accès AWS API.
3
La clé qui contient la clé d’accès AWS API dans l’objet Secret spécifié.
5
La clé qui contient la clé secrète AWS API dans l’objet secret spécifié.
6
Le nom du profil AWS qui est utilisé pour authentifier.
7
L’identifiant unique pour le nom de ressource Amazon (ARN) attribué à votre rôle.

3.8.2.2. Échantillon YAML pour l’authentification de base
Copier lien

Ce qui suit montre des paramètres d’authentification de base pour un objet secret nommé rw-basic-auth dans l’espace de noms openshift-user-workload-monitoring: 

apiVersion: v1
kind: Secret
metadata:
  name: rw-basic-auth
  namespace: openshift-user-workload-monitoring
stringData:
  user: <basic_username>
1 

  password: <basic_password>
2 

type: Opaque
Copy to Clipboard Toggle word wrap
1
Le nom d’utilisateur.
2
Le mot de passe.

L’échantillon suivant montre une configuration d’écriture à distance de baseAuth qui utilise un objet secret nommé rw-basic-auth dans l’espace de noms openshift-user-workload-monitoring. Il suppose que vous avez déjà configuré des informations d’authentification pour le point de terminaison. 

apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    prometheus:
      remoteWrite:
      - url: "https://basicauth.example.com/api/write"
        basicAuth:
          username:
            name: rw-basic-auth
1 

            key: user
2 

          password:
            name: rw-basic-auth
3 

            key: password
4
Copy to Clipboard Toggle word wrap
1 3
Le nom de l’objet Secret qui contient les identifiants d’authentification.
2
La clé qui contient le nom d’utilisateur dans l’objet secret spécifié.
4
La clé qui contient le mot de passe dans l’objet secret spécifié.

Ce qui suit montre les paramètres de jeton porteur pour un objet secret nommé rw-porter-auth dans l’espace de noms openshift-user-workload-monitoring: 

apiVersion: v1
kind: Secret
metadata:
  name: rw-bearer-auth
  namespace: openshift-user-workload-monitoring
stringData:
  token: <authentication_token>
1 

type: Opaque
Copy to Clipboard Toggle word wrap
1
Le jeton d’authentification.

Ce qui suit montre les paramètres de configuration de jeton de porteur d’échantillons qui utilisent un objet secret nommé rw-bearer-auth dans l’espace de noms openshift-user-workload-monitoring: 

apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    enableUserWorkload: true
    prometheus:
      remoteWrite:
      - url: "https://authorization.example.com/api/write"
        authorization:
          type: Bearer
1 

          credentials:
            name: rw-bearer-auth
2 

            key: token
3
Copy to Clipboard Toggle word wrap
1
Le type d’authentification de la demande. La valeur par défaut est Bearer.
2
Le nom de l’objet Secret qui contient les identifiants d’authentification.
3
La clé qui contient le jeton d’authentification dans l’objet secret spécifié.

3.8.2.4. Échantillon YAML pour l’authentification OAuth 2.0
Copier lien

Ce qui suit montre les paramètres OAuth 2.0 pour un objet secret nommé oauth2-credentials dans l’espace de noms openshift-user-workload-monitoring: 

apiVersion: v1
kind: Secret
metadata:
  name: oauth2-credentials
  namespace: openshift-user-workload-monitoring
stringData:
  id: <oauth2_id>
1 

  secret: <oauth2_secret>
2 

type: Opaque
Copy to Clipboard Toggle word wrap
1
L’identifiant Oauth 2.0.
2
Le secret OAuth 2.0.

Ce qui suit montre une configuration d’échantillon d’authentification d’écriture à distance oauth2 qui utilise un objet secret nommé oauth2-credentials dans l’espace de noms openshift-user-workload-monitoring: 

apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    prometheus:
      remoteWrite:
      - url: "https://test.example.com/api/write"
        oauth2:
          clientId:
            secret:
              name: oauth2-credentials
1 

              key: id
2 

          clientSecret:
            name: oauth2-credentials
3 

            key: secret
4 

          tokenUrl: https://example.com/oauth2/token
5 

          scopes:
6 

          - <scope_1>
          - <scope_2>
          endpointParams:
7 

            param1: <parameter_1>
            param2: <parameter_2>
Copy to Clipboard Toggle word wrap
1 3
Le nom de l’objet secret correspondant. A noter que ClientId peut se référer alternativement à un objet ConfigMap, bien que clientSecret doive se référer à un objet secret.
2 4
La clé qui contient les informations d’identification OAuth 2.0 dans l’objet secret spécifié.
5
L’URL utilisée pour récupérer un jeton avec le clientId et clientSecret spécifiés.
6
La portée OAuth 2.0 de la demande d’autorisation. Ces portées limitent les données auxquelles les jetons peuvent accéder.
7
Les paramètres de demande d’autorisation OAuth 2.0 requis pour le serveur d’autorisation.

Ce qui suit montre les paramètres du client TLS pour un objet secret nommé mtls-grouple dans l’espace de noms openshift-user-workload-monitoring. 

apiVersion: v1
kind: Secret
metadata:
  name: mtls-bundle
  namespace: openshift-user-workload-monitoring
data:
  ca.crt: <ca_cert>
1 

  client.crt: <client_cert>
2 

  client.key: <client_key>
3 

type: tls
Copy to Clipboard Toggle word wrap
1
Le certificat CA dans le conteneur Prometheus avec lequel valider le certificat serveur.
2
Le certificat client pour l’authentification avec le serveur.
3
La clé cliente.

L’échantillon suivant montre une configuration d’authentification d’écriture à distance tlsConfig qui utilise un objet TLS Secret nommé mtls-bundle. 

apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    prometheus:
      remoteWrite:
      - url: "https://remote-write-endpoint.example.com"
        tlsConfig:
          ca:
            secret:
              name: mtls-bundle
1 

              key: ca.crt
2 

          cert:
            secret:
              name: mtls-bundle
3 

              key: client.crt
4 

          keySecret:
            name: mtls-bundle
5 

            key: client.key
6
Copy to Clipboard Toggle word wrap
1 3 5
Le nom de l’objet Secret correspondant qui contient les identifiants d’authentification TLS. A noter que ca et cert peuvent faire référence alternativement à un objet ConfigMap, bien que keySecret doive se référer à un objet secret.
2
La clé dans l’objet secret spécifié qui contient le certificat CA pour le point de terminaison.
4
La clé de l’objet Secret spécifié qui contient le certificat client pour le point de terminaison.
6
La clé dans l’objet secret spécifié qui contient le secret de clé client.

Il est possible d’utiliser l’objet queueConfig pour l’écriture à distance afin d’ajuster les paramètres de file d’écriture à distance. L’exemple suivant montre les paramètres de file d’attente avec leurs valeurs par défaut pour la surveillance des projets définis par l’utilisateur dans l’espace de noms openshift-user-workload-monitoring.

Exemple de configuration des paramètres d’écriture à distance avec des valeurs par défaut

apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    prometheus:
      remoteWrite:
      - url: "https://remote-write-endpoint.example.com"
        <endpoint_authentication_credentials>
        queueConfig:
          capacity: 10000
1 

          minShards: 1
2 

          maxShards: 50
3 

          maxSamplesPerSend: 2000
4 

          batchSendDeadline: 5s
5 

          minBackoff: 30ms
6 

          maxBackoff: 5s
7 

          retryOnRateLimit: false
8 

          sampleAgeLimit: 0s
9
Copy to Clipboard Toggle word wrap

1
Le nombre d’échantillons à tampon par fragment avant qu’ils ne soient supprimés de la file d’attente.
2
Le nombre minimum de fragments.
3
Le nombre maximum de fragments.
4
Le nombre maximal d’échantillons par envoi.
5
Le temps maximum pour un échantillon d’attendre en tampon.
6
L’heure initiale d’attendre avant de réessayer une demande échouée. Le temps est doublé pour chaque réessayer jusqu’au temps maxbackoff.
7
Le temps maximum d’attendre avant de réessayer une demande échouée.
8
Définissez ce paramètre sur true pour réessayer une requête après avoir reçu un code d’état 429 à partir du stockage d’écriture à distance.
9
Les échantillons qui sont plus anciens que la limite de l’échantillonAgeLimit sont supprimés de la file d’attente. Lorsque la valeur n’est pas définie ou définie sur 0s, le paramètre est ignoré.
Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat