Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

3.7. Configuration du stockage persistant

Exécutez la surveillance des clusters avec un stockage persistant pour obtenir les avantages suivants:

  • De protéger vos métriques et d’alerter les données contre la perte de données en les stockant dans un volume persistant (PV). En conséquence, ils peuvent survivre aux gousses redémarrées ou recréées.
  • Évitez d’obtenir des notifications en double et de perdre des silences pour les alertes lorsque les pods Alertmanager sont redémarrés.

Dans les environnements de production, il est fortement recommandé de configurer le stockage persistant.

Important

Dans les clusters multi-nœuds, vous devez configurer le stockage persistant pour Prometheus, Alertmanager et Thanos Ruler pour assurer une disponibilité élevée.

3.7.1. Conditions de stockage persistantes
Copier lien

  • Employez le type de stockage de bloc.

Afin d’utiliser un volume persistant (PV) pour la surveillance des composants, vous devez configurer une revendication de volume persistant (PVC).

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é.

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. Ajoutez votre configuration PVC pour le composant sous data/config.yaml: 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    <component>:
    1 
    
      volumeClaimTemplate:
        spec:
          storageClassName: <storage_class>
    2 
    
          resources:
            requests:
              storage: <amount_of_storage>
    3
    Copy to Clipboard Toggle word wrap
    1
    Indiquez le composant de surveillance pour lequel vous souhaitez configurer le PVC.
    2
    Indiquez une classe de stockage existante. Lorsqu’une classe de stockage n’est pas spécifiée, la classe de stockage par défaut est utilisée.
    3
    Indiquez la quantité de stockage requise.

    L’exemple suivant configure un PVC qui revendique un stockage persistant pour Thanos Ruler:

    Exemple de configuration PVC

    apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    thanosRuler:
      volumeClaimTemplate:
        spec:
          storageClassName: my-storage-class
          resources:
            requests:
              storage: 10Gi
    Copy to Clipboard Toggle word wrap

    Note

    Les exigences de stockage pour le composant thanosRuler dépendent du nombre de règles évaluées et du nombre d’échantillons générés par chaque règle.

  3. Enregistrez le fichier pour appliquer les modifications. Les pods affectés par la nouvelle configuration sont automatiquement redéployés et la nouvelle configuration de stockage est appliquée.

    Avertissement

    Lorsque vous mettez à jour la carte de configuration avec une configuration PVC, l’objet StatefulSet affecté est recréé, ce qui entraîne une panne de service temporaire.

Par défaut, Prometheus conserve les données métriques pour les durées suivantes:

  • Base de surveillance de la plate-forme: 15 jours
  • Contrôle des projets définis par l’utilisateur: 24 heures

Il est possible de modifier le délai de conservation de l’instance Prometheus afin de modifier la rapidité avec laquelle les données sont supprimées. De plus, vous pouvez définir la quantité maximale d’espace disque utilisée par les données métriques conservées. Lorsque les données atteignent cette limite de taille, Prometheus supprime d’abord les données les plus anciennes jusqu’à ce que l’espace disque utilisé soit de nouveau inférieur à la limite.

À noter les comportements suivants de ces paramètres de conservation des données:

  • La stratégie de rétention basée sur la taille s’applique à tous les répertoires de blocs de données du répertoire /prometheus, y compris les blocs persistants, les données du journal d’écriture-ahead (WAL) et les morceaux m-mapped.
  • Les données dans les répertoires /wal et /head_chunks comptent vers la limite de taille de rétention, mais Prometheus ne purge jamais les données de ces répertoires en fonction des politiques de conservation basées sur la taille ou le temps. Ainsi, si vous définissez une limite de taille de rétention inférieure à la taille maximale définie pour les répertoires /wal et /head_chunks, vous avez configuré le système pour ne pas conserver de blocs de données dans les répertoires de données /prometheus.
  • La politique de conservation basée sur la taille n’est appliquée que lorsque Prometheus coupe un nouveau bloc de données, qui se produit toutes les deux heures après que le WAL contient au moins trois heures de données.
  • Lorsque vous ne définissez pas explicitement des valeurs de rétention ou de rétention, le temps de rétention par défaut est de 15 jours pour la surveillance de la plate-forme de base et de 24 heures pour la surveillance de projet définie par l’utilisateur. La taille de rétention n’est pas définie.
  • Lorsque vous définissez des valeurs pour la rétention et la taille de rétention, les deux valeurs s’appliquent. Lorsque des blocs de données dépassent le temps de conservation défini ou la limite de taille définie, Prometheus purge ces blocs de données.
  • Lorsque vous définissez une valeur pour la taille de rétention et que vous ne définissez pas la rétention, seule la valeur de la taille de rétention s’applique.
  • Dans le cas où vous ne définissez pas une valeur pour la taille de la rétention et que vous ne définissez qu’une valeur de rétention, seule la valeur de rétention s’applique.
  • Lorsque vous définissez la valeur de rétention ou de rétention sur 0, les paramètres par défaut s’appliquent. Les paramètres par défaut fixent le temps de rétention à 15 jours pour la surveillance de la plate-forme de base et 24 heures pour la surveillance de projet définie par l’utilisateur. La taille de la rétention n’est pas définie par défaut.
Note

Le compactage des données se produit toutes les deux heures. Ainsi, un volume persistant (PV) pourrait se remplir avant le compactage, dépassant potentiellement la limite de taille de rétention. Dans de tels cas, l’alerte KubePersistentVolumeFillingUp s’allume jusqu’à ce que l’espace sur un PV soit inférieur à la limite de taille de rétention.

Par défaut, Prometheus conserve les données métriques pendant 24 heures pour la surveillance des projets définis par l’utilisateur. Lorsque les données sont supprimées, vous pouvez modifier le temps de conservation de l’instance Prometheus. De plus, vous pouvez définir la quantité maximale d’espace disque utilisée par les données métriques conservées.

Note

Le compactage des données se produit toutes les deux heures. Ainsi, un volume persistant (PV) pourrait se remplir avant le compactage, dépassant potentiellement la limite de taille de rétention. Dans de tels cas, l’alerte KubePersistentVolumeFillingUp s’allume jusqu’à ce que l’espace sur un PV soit inférieur à la limite de taille de rétention.

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é.

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. Ajoutez la configuration du temps de rétention et de la taille sous data/config.yaml: 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    prometheus:
      retention: <time_specification>
    1 
    
      retentionSize: <size_specification>
    2
    Copy to Clipboard Toggle word wrap
    1
    Le temps de rétention: un nombre directement suivi de ms (millisecondes), s (secondes), m (minutes), h (heures), d (jours), w (semaines) ou y (années). Il est également possible de combiner des valeurs de temps pour des temps spécifiques, tels que 1h30m15s.
    2
    La taille de rétention: un nombre directement suivi de B (octets), KB (kilooctets), MB (mégaoctets), GB (gigaoctets), TB (teraoctets), PB (pétaoctets) et EB (exabytes).

    L’exemple suivant définit le temps de rétention à 24 heures et la taille de rétention à 10 gigaoctets pour l’instance Prometheus:

    Exemple de réglage du temps de rétention pour Prometheus

    apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    prometheus:
      retention: 24h
      retentionSize: 10GB
    Copy to Clipboard Toggle word wrap

  3. Enregistrez le fichier pour appliquer les modifications. Les pods affectés par la nouvelle configuration sont automatiquement redéployés.

Dans le cas des projets définis par l’utilisateur, Thanos Ruler conserve automatiquement les données métriques pendant 24 heures. Il est possible de modifier le temps de conservation pour modifier la durée de conservation de ces données en spécifiant une valeur de temps dans la carte de configuration de configuration de la charge de travail de l’utilisateur dans l’espace de noms openshift-user-workload-monitoring.

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é.

Procédure

  1. Éditer l’objet ConfigMap de l’utilisateur-workload-monitoring-config 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 la configuration du temps de rétention sous data/config.yaml: 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    thanosRuler:
      retention: <time_specification>
    1
    Copy to Clipboard Toggle word wrap
    1
    Indiquez le temps de rétention dans le format suivant: un nombre directement suivi de ms (millisecondes), s (secondes), m (minutes), h (heures), d (jours), w (semaines) ou y (années). Il est également possible de combiner des valeurs de temps pour des temps spécifiques, tels que 1h30m15s. La valeur par défaut est 24h.

    L’exemple suivant définit le temps de conservation à 10 jours pour les données Thanos Ruler: 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    thanosRuler:
      retention: 10d
    Copy to Clipboard Toggle word wrap
  3. Enregistrez le fichier pour appliquer les modifications. Les pods affectés par la nouvelle configuration sont automatiquement redéployés.
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