Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

2.9. Configuration du stockage persistant

L'exécution de la surveillance des clusters avec un stockage persistant signifie que vos mesures sont stockées dans un volume persistant (PV) et peuvent survivre au redémarrage ou à la recréation d'un pod. Cette solution est idéale si vous souhaitez que vos données de mesure ou d'alerte soient protégées contre la perte de données. Pour les environnements de production, il est fortement recommandé de configurer le stockage persistant. En raison des exigences élevées en matière d'entrées-sorties, il est préférable d'utiliser le stockage local.

2.9.1. Conditions préalables au stockage permanent

  • Consacrez suffisamment d'espace de stockage persistant local pour éviter que le disque ne soit saturé. La quantité de stockage nécessaire dépend du nombre de modules.
  • Vérifiez que vous disposez d'un volume persistant (PV) prêt à être réclamé par la réclamation de volume persistant (PVC), un PV pour chaque réplique. Prometheus et Alertmanager ayant tous deux deux répliques, vous avez besoin de quatre PV pour prendre en charge l'ensemble de la pile de surveillance. Les PV sont disponibles auprès de l'opérateur de stockage local, mais pas si vous avez activé le stockage à provisionnement dynamique.

  • Utilisez Filesystem comme valeur de type de stockage pour le paramètre volumeMode lorsque vous configurez le volume persistant.

    Note

    Si vous utilisez un volume local pour le stockage persistant, n'utilisez pas de volume de bloc brut, qui est décrit avec volumeMode: Block dans l'objet LocalVolume. Prometheus ne peut pas utiliser de volumes de blocs bruts.

2.9.2. Configuration d'une revendication de volume persistant local

Pour que les composants de surveillance utilisent un volume persistant (PV), vous devez configurer une réclamation de volume persistant (PVC).

Conditions préalables

  • If you are configuring core OpenShift Container Platform monitoring components:

    • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
    • Vous avez créé l'objet cluster-monitoring-config ConfigMap .

  • If you are configuring components that monitor user-defined projects:

    • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin, ou en tant qu'utilisateur ayant le rôle user-workload-monitoring-config-edit dans le projet openshift-user-workload-monitoring.
    • Vous avez créé l'objet user-workload-monitoring-config ConfigMap .
  • Vous avez installé l'OpenShift CLI (oc).

Procédure

  1. Modifiez l'objet ConfigMap:

    • To configure a PVC for a component that monitors core OpenShift Container Platform projects:

      1. Modifiez l'objet cluster-monitoring-config ConfigMap dans le projet openshift-monitoring: 

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
        Copy to Clipboard

      2. Ajoutez votre configuration PVC pour le composant sous data/config.yaml: 

        apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    <component>:
      volumeClaimTemplate:
        spec:
          storageClassName: <storage_class>
          resources:
            requests:
              storage: <amount_of_storage>
        Copy to Clipboard

        Voir la documentation Kubernetes sur PersistentVolumeClaims pour plus d'informations sur la façon de spécifier volumeClaimTemplate.

        L'exemple suivant configure un PVC qui réclame un stockage persistant local pour l'instance Prometheus qui surveille les composants principaux d'OpenShift Container Platform : 

        apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    prometheusK8s:
      volumeClaimTemplate:
        spec:
          storageClassName: local-storage
          resources:
            requests:
              storage: 40Gi
        Copy to Clipboard

        Dans l'exemple ci-dessus, la classe de stockage créée par l'Opérateur de stockage local s'appelle local-storage.

        L'exemple suivant configure un PVC qui demande un stockage persistant local pour Alertmanager : 

        apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    alertmanagerMain:
      volumeClaimTemplate:
        spec:
          storageClassName: local-storage
          resources:
            requests:
              storage: 10Gi
        Copy to Clipboard

    • To configure a PVC for a component that monitors user-defined projects:

      1. Modifiez l'objet user-workload-monitoring-config ConfigMap dans le projet openshift-user-workload-monitoring: 

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

      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>:
      volumeClaimTemplate:
        spec:
          storageClassName: <storage_class>
          resources:
            requests:
              storage: <amount_of_storage>
        Copy to Clipboard

        Voir la documentation Kubernetes sur PersistentVolumeClaims pour plus d'informations sur la façon de spécifier volumeClaimTemplate.

        L'exemple suivant configure un PVC qui réclame un stockage persistant local pour l'instance Prometheus qui surveille les projets définis par l'utilisateur : 

        apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    prometheus:
      volumeClaimTemplate:
        spec:
          storageClassName: local-storage
          resources:
            requests:
              storage: 40Gi
        Copy to Clipboard

        Dans l'exemple ci-dessus, la classe de stockage créée par l'Opérateur de stockage local s'appelle local-storage.

        L'exemple suivant configure un PVC qui réclame un stockage persistant local pour Thanos Ruler : 

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

        Les besoins en stockage du composant thanosRuler dépendent du nombre de règles évaluées et du nombre d'échantillons générés par chaque règle.

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

    Note

    Les configurations appliquées à l'objet user-workload-monitoring-config ConfigMap ne sont pas activées à moins qu'un administrateur de cluster n'ait activé la surveillance pour les projets définis par l'utilisateur.

    Avertissement

    Lorsque des modifications sont enregistrées dans une carte de configuration de surveillance, les pods et autres ressources du projet concerné peuvent être redéployés. Les processus de surveillance en cours dans ce projet peuvent également être redémarrés.

2.9.3. Redimensionnement d'un volume de stockage persistant

OpenShift Container Platform ne prend pas en charge le redimensionnement d'un volume de stockage persistant existant utilisé par des ressources StatefulSet, même si la ressource sous-jacente StorageClass utilisée prend en charge le dimensionnement du volume persistant. Par conséquent, même si vous mettez à jour le champ storage pour une réclamation de volume persistant (PVC) existante avec une taille plus grande, ce paramètre ne sera pas propagé au volume persistant (PV) associé.

Cependant, le redimensionnement d'un PV est toujours possible en utilisant un processus manuel. Si vous souhaitez redimensionner un PV pour un composant de surveillance tel que Prometheus, Thanos Ruler ou Alertmanager, vous pouvez mettre à jour la carte de configuration appropriée dans laquelle le composant est configuré. Ensuite, corrigez le PVC, puis supprimez et rendez les pods orphelins. Le fait de rendre les pods orphelins recrée immédiatement la ressource StatefulSet et met automatiquement à jour la taille des volumes montés dans les pods avec les nouveaux paramètres du PVC. Aucune interruption de service ne se produit au cours de ce processus.

Conditions préalables

  • Vous avez installé l'OpenShift CLI (oc).

  • If you are configuring core OpenShift Container Platform monitoring components:

    • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
    • Vous avez créé l'objet cluster-monitoring-config ConfigMap .
    • Vous avez configuré au moins un PVC pour les composants de surveillance de base d'OpenShift Container Platform.

  • If you are configuring components that monitor user-defined projects:

    • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin, ou en tant qu'utilisateur ayant le rôle user-workload-monitoring-config-edit dans le projet openshift-user-workload-monitoring.
    • Vous avez créé l'objet user-workload-monitoring-config ConfigMap .
    • Vous avez configuré au moins un PVC pour les composants qui surveillent les projets définis par l'utilisateur.

Procédure

  1. Modifiez l'objet ConfigMap:

    • To resize a PVC for a component that monitors core OpenShift Container Platform projects:

      1. Modifiez l'objet cluster-monitoring-config ConfigMap dans le projet openshift-monitoring: 

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
        Copy to Clipboard

      2. Ajouter une nouvelle taille de stockage pour la configuration PVC du composant sous data/config.yaml: 

        apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    <component>:
        1 
        
      volumeClaimTemplate:
        spec:
          storageClassName: <storage_class>
        2 
        
          resources:
            requests:
              storage: <amount_of_storage>
        3
        Copy to Clipboard
        1
        Spécifier la composante de base de la surveillance.
        2
        Spécifiez la classe de stockage.
        3
        Indiquez la nouvelle taille du volume de stockage.

        L'exemple suivant configure un PVC qui définit le stockage persistant local à 100 gigaoctets pour l'instance Prometheus qui surveille les composants principaux d'OpenShift Container Platform : 

        apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    prometheusK8s:
      volumeClaimTemplate:
        spec:
          storageClassName: local-storage
          resources:
            requests:
              storage: 100Gi
        Copy to Clipboard

        L'exemple suivant configure un PVC qui définit le stockage persistant local pour Alertmanager à 40 gigaoctets : 

        apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    alertmanagerMain:
      volumeClaimTemplate:
        spec:
          storageClassName: local-storage
          resources:
            requests:
              storage: 40Gi
        Copy to Clipboard

    • To resize a PVC for a component that monitors user-defined projects:

      Note

      Vous pouvez redimensionner les volumes des instances Thanos Ruler et Prometheus qui surveillent les projets définis par l'utilisateur.

      1. Modifiez l'objet user-workload-monitoring-config ConfigMap dans le projet openshift-user-workload-monitoring: 

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

      2. Mettre à jour la configuration du PVC pour le composant de surveillance 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
        1
        Spécifier la composante de base de la surveillance.
        2
        Spécifiez la classe de stockage.
        3
        Indiquez la nouvelle taille du volume de stockage.

        L'exemple suivant configure la taille du PVC à 100 gigaoctets pour l'instance Prometheus qui surveille les projets définis par l'utilisateur : 

        apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    prometheus:
      volumeClaimTemplate:
        spec:
          storageClassName: local-storage
          resources:
            requests:
              storage: 100Gi
        Copy to Clipboard

        L'exemple suivant définit la taille du PVC à 20 gigaoctets pour Thanos Ruler : 

        apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    thanosRuler:
      volumeClaimTemplate:
        spec:
          storageClassName: local-storage
          resources:
            requests:
              storage: 20Gi
        Copy to Clipboard
        Note

        Les besoins en stockage du composant thanosRuler dépendent du nombre de règles évaluées et du nombre d'échantillons générés par chaque règle.

  2. Enregistrez le fichier pour appliquer les modifications. Les pods concernés par la nouvelle configuration redémarrent automatiquement.

    Avertissement

    Lorsque vous enregistrez les modifications apportées à une carte de configuration de surveillance, les pods et autres ressources du projet concerné peuvent être redéployés. Les processus de surveillance en cours d'exécution dans ce projet peuvent également être redémarrés.

  3. Patch manuel de chaque PVC avec la demande de stockage mise à jour. L'exemple suivant redéfinit la taille du stockage pour le composant Prometheus dans l'espace de noms openshift-monitoring à 100Gi : 

    $ for p in $(oc -n openshift-monitoring get pvc -l app.kubernetes.io/name=prometheus -o jsonpath='{range .items[*]}{.metadata.name} {end}'); do \
  oc -n openshift-monitoring patch pvc/${p} --patch '{"spec": {"resources": {"requests": {"storage":"100Gi"}}}}'; \
  done
    Copy to Clipboard

  4. Supprime le StatefulSet sous-jacent avec le paramètre --cascade=orphan: 

    $ oc delete statefulset -l app.kubernetes.io/name=prometheus --cascade=orphan
    Copy to Clipboard

2.9.4. Modification de la durée et de la taille de rétention des données de métrologie Prometheus

Par défaut, Prometheus conserve automatiquement les données de mesure pendant 15 jours. Vous pouvez modifier la durée de conservation pour changer le délai de suppression des données en spécifiant une valeur de temps dans le champ retention. Vous pouvez également configurer la quantité maximale d'espace disque utilisée par les données de mesure conservées en spécifiant une valeur de taille dans le champ retentionSize. Si 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 à nouveau inférieur à la limite.

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

  • La politique de conservation 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 WAL (write-ahead log) et les blocs m-mappés.
  • Les données des répertoires /wal et /head_chunks sont prises en compte dans la limite de taille de rétention, mais Prometheus ne purge jamais les données de ces répertoires sur la base de politiques de rétention 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 qu'il ne conserve aucun bloc 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, ce qui se produit toutes les deux heures lorsque le WAL contient au moins trois heures de données.
  • Si vous ne définissez pas explicitement de valeurs pour retention ou retentionSize, la durée de conservation est fixée par défaut à 15 jours et la taille de la conservation n'est pas définie.
  • Si vous définissez des valeurs pour retention et retentionSize, les deux valeurs s'appliquent. Si des blocs de données dépassent la durée de conservation définie ou la limite de taille définie, Prometheus purge ces blocs de données.
  • Si vous définissez une valeur pour retentionSize et que vous ne définissez pas retention, seule la valeur retentionSize s'applique.
  • Si vous ne définissez pas de valeur pour retentionSize et que vous ne définissez qu'une valeur pour retention, seule la valeur retention s'applique.

Conditions préalables

  • If you are configuring core OpenShift Container Platform monitoring components:

    • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
    • Vous avez créé l'objet cluster-monitoring-config ConfigMap .

  • If you are configuring components that monitor user-defined projects:

    • Un administrateur de cluster a activé la surveillance des projets définis par l'utilisateur.
    • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin, ou en tant qu'utilisateur ayant le rôle user-workload-monitoring-config-edit dans le projet openshift-user-workload-monitoring.
    • Vous avez créé l'objet user-workload-monitoring-config ConfigMap .
  • Vous avez installé l'OpenShift CLI (oc).
Avertissement

L'enregistrement des modifications apportées à une carte de configuration de surveillance peut redémarrer les processus de surveillance et redéployer les pods et autres ressources dans le projet concerné. Les processus de surveillance en cours dans ce projet peuvent également redémarrer.

Procédure

  1. Modifiez l'objet ConfigMap:

    • To modify the retention time and size for the Prometheus instance that monitors core OpenShift Container Platform projects:

      1. Modifiez l'objet cluster-monitoring-config ConfigMap dans le projet openshift-monitoring: 

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
        Copy to Clipboard

      2. Ajoutez la configuration du temps de rétention et de la taille sous data/config.yaml: 

        apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    prometheusK8s:
      retention: <time_specification>
        1 
        
      retentionSize: <size_specification>
        2
        Copy to Clipboard
        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). Vous pouvez également combiner des valeurs temporelles pour des périodes spécifiques, comme 1h30m15s.
        2
        La taille de rétention : un nombre directement suivi de B (octets), KB (kilo-octets), MB (méga-octets), GB (giga-octets), TB (téra-octets), PB (péta-octets) et EB (exa-octets).

        L'exemple suivant définit la durée de rétention à 24 heures et la taille de rétention à 10 gigaoctets pour l'instance Prometheus qui surveille les composants principaux d'OpenShift Container Platform : 

        apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    prometheusK8s:
      retention: 24h
      retentionSize: 10GB
        Copy to Clipboard

    • To modify the retention time and size for the Prometheus instance that monitors user-defined projects:

      1. Modifiez l'objet user-workload-monitoring-config ConfigMap dans le projet openshift-user-workload-monitoring: 

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

      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
        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). Vous pouvez également combiner des valeurs temporelles pour des périodes spécifiques, comme 1h30m15s.
        2
        La taille de rétention : un nombre directement suivi de B (octets), KB (kilo-octets), MB (méga-octets), GB (giga-octets), TB (téra-octets), PB (péta-octets) ou EB (exa-octets).

        L'exemple suivant définit la durée de conservation à 24 heures et la taille de conservation à 10 gigaoctets pour l'instance Prometheus qui surveille les projets définis par l'utilisateur : 

        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
  2. Enregistrez le fichier pour appliquer les modifications. Les pods concernés par la nouvelle configuration redémarrent automatiquement.

2.9.5. Modifier le temps de rétention des données de métriques de la règle de Thanos

Par défaut, pour les projets définis par l'utilisateur, Thanos Ruler conserve automatiquement les données de mesure pendant 24 heures. Vous pouvez modifier la durée de conservation des données en spécifiant une valeur de temps dans la carte de configuration user-workload-monitoring-config, dans l'espace de noms openshift-user-workload-monitoring.

Conditions préalables

  • Vous avez installé l'OpenShift CLI (oc).
  • Un administrateur de cluster a activé la surveillance des projets définis par l'utilisateur.
  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin ou en tant qu'utilisateur ayant le rôle user-workload-monitoring-config-edit dans le projet openshift-user-workload-monitoring.
  • Vous avez créé l'objet user-workload-monitoring-config ConfigMap .
Avertissement

L'enregistrement des modifications apportées à une carte de configuration de surveillance peut redémarrer les processus de surveillance et redéployer les pods et autres ressources dans le projet concerné. Les processus de surveillance en cours dans ce projet peuvent également redémarrer.

Procédure

  1. Modifiez l'objet user-workload-monitoring-config ConfigMap dans le projet openshift-user-workload-monitoring: 

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

  2. Ajoutez 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
    1
    Spécifiez la durée de rétention au format suivant : un nombre directement suivi de ms (millisecondes), s (secondes), m (minutes), h (heures), d (jours), w (semaines) ou y (années). Vous pouvez également combiner des valeurs temporelles pour des heures spécifiques, comme 1h30m15s. La valeur par défaut est 24h.

    L'exemple suivant fixe la durée de conservation à 10 jours pour les données de 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
  3. Enregistrez le fichier pour appliquer les modifications. Les pods concernés par la nouvelle configuration redémarrent automatiquement.
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