Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

10.4. Configuration du log store Elasticsearch

Elasticsearch 6 vous permet de stocker et d’organiser les données de log.

Il est possible d’apporter des modifications à votre log store, y compris:

  • Entreposage pour votre cluster Elasticsearch
  • La réplication partagée entre les nœuds de données dans le cluster, de la réplication complète à l’absence de réplication
  • Accès externe aux données Elasticsearch

10.4.1. Configuration du stockage des journaux
Copier lien

Il est possible de configurer le type de stockage de journal utilisé par votre journal en modifiant la ressource personnalisée ClusterLogging (CR).

Conditions préalables

  • Il y a des autorisations d’administrateur.
  • L’OpenShift CLI (oc) a été installé.
  • L’opérateur de journalisation Red Hat OpenShift et un log store interne sont soit le LokiStack, soit Elasticsearch.
  • C’est vous qui avez créé un ClusterLogging CR.
Note

La version Logging 5.9 ne contient pas une version mise à jour de l’opérateur OpenShift Elasticsearch. Actuellement, si vous utilisez l’opérateur OpenShift Elasticsearch publié avec Logging 5.8, il continuera à fonctionner avec Logging jusqu’à ce que l’EOL de Logging 5.8. Comme alternative à l’utilisation de l’opérateur OpenShift Elasticsearch pour gérer le stockage de journaux par défaut, vous pouvez utiliser l’opérateur Loki. Consultez Platform Agnostic Operators pour plus d’informations sur les dates du cycle de vie de l’enregistrement.

Procédure

  1. ClusterLogging CR logStore Spécification:

    Exemple de ClusterLogging CR

    apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
# ...
spec:
# ...
  logStore:
    type: <log_store_type>
    1 
    
    elasticsearch:
    2 
    
      nodeCount: <integer>
      resources: {}
      storage: {}
      redundancyPolicy: <redundancy_type>
    3 
    
    lokistack:
    4 
    
      name: {}
# ...
    Copy to Clipboard Toggle word wrap

    1
    Indiquez le type de log store. Cela peut être soit le lokistack ou la recherche élastique.
    2
    Des options de configuration optionnelles pour la boutique de journal Elasticsearch.
    3
    Indiquez le type de redondance. Cette valeur peut être ZeroRedundancy, SingleRedundancy, MultipleRedundancy ou FullRedundancy.
    4
    Configuration optionnelle pour LokiStack.

    Exemple ClusterLogging CR pour spécifier LokiStack comme log store

    apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  managementState: Managed
  logStore:
    type: lokistack
    lokistack:
      name: logging-loki
# ...
    Copy to Clipboard Toggle word wrap

  2. Appliquez le ClusterLogging CR en exécutant la commande suivante: 

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

10.4.2. Envoi des journaux d’audit au log store
Copier lien

Dans un déploiement de journalisation, les journaux de conteneurs et d’infrastructures sont transférés au log store interne défini dans la ressource personnalisée ClusterLogging (CR) par défaut.

Les journaux d’audit ne sont pas transmis au log store interne par défaut, car cela ne fournit pas de stockage sécurisé. Il vous incombe de vous assurer que le système vers lequel vous transmettez les journaux d’audit est conforme à vos réglementations organisationnelles et gouvernementales et qu’il est correctement sécurisé.

Lorsque cette configuration par défaut répond à vos besoins, vous n’avez pas besoin de configurer un ClusterLogForwarder CR. En cas d’existence d’un ClusterLogForwarder CR, les journaux ne sont pas transmis au log store interne à moins qu’un pipeline ne soit défini qui contient la sortie par défaut.

Procédure

D’utiliser l’API Log Forward pour transmettre les journaux d’audit à l’instance interne Elasticsearch:

  1. Créer ou modifier un fichier YAML qui définit l’objet ClusterLogForwarder CR:

    • Créez un CR pour envoyer tous les types de journaux à l’instance interne Elasticsearch. Il est possible d’utiliser l’exemple suivant sans apporter de modifications: 

      apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  pipelines:
      1 
      
  - name: all-to-default
    inputRefs:
    - infrastructure
    - application
    - audit
    outputRefs:
    - default
      Copy to Clipboard Toggle word wrap
      1
      Le pipeline définit le type de logs à transmettre à l’aide de la sortie spécifiée. La sortie par défaut transmet les journaux à l’instance interne Elasticsearch.
      Note

      Dans le pipeline, vous devez spécifier les trois types de logs : application, infrastructure et audit. Dans le cas où vous ne spécifiez pas un type de journal, ces journaux ne sont pas stockés et seront perdus.

    • Lorsque vous avez un ClusterLogForwarder CR existant, ajoutez un pipeline à la sortie par défaut pour les journaux d’audit. Il n’est pas nécessaire de définir la sortie par défaut. À titre d’exemple: 

      apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
   - name: elasticsearch-insecure
     type: "elasticsearch"
     url: http://elasticsearch-insecure.messaging.svc.cluster.local
     insecure: true
   - name: elasticsearch-secure
     type: "elasticsearch"
     url: https://elasticsearch-secure.messaging.svc.cluster.local
     secret:
       name: es-audit
   - name: secureforward-offcluster
     type: "fluentdForward"
     url: https://secureforward.offcluster.com:24224
     secret:
       name: secureforward
  pipelines:
   - name: container-logs
     inputRefs:
     - application
     outputRefs:
     - secureforward-offcluster
   - name: infra-logs
     inputRefs:
     - infrastructure
     outputRefs:
     - elasticsearch-insecure
   - name: audit-logs
     inputRefs:
     - audit
     outputRefs:
     - elasticsearch-secure
     - default
      1
      Copy to Clipboard Toggle word wrap
      1
      Ce pipeline envoie les journaux d’audit à l’instance interne Elasticsearch en plus d’une instance externe.

10.4.3. Configuration du temps de rétention du journal
Copier lien

Il est possible de configurer une stratégie de rétention qui spécifie combien de temps le magasin de journal Elasticsearch par défaut conserve des indices pour chacune des trois sources de journaux : journaux d’infrastructures, journaux d’applications et journaux d’audit.

Afin de configurer la stratégie de rétention, vous définissez un paramètre maxAge pour chaque source de journal de la ressource personnalisée ClusterLogging (CR). Le CR applique ces valeurs au calendrier de roulement Elasticsearch, qui détermine quand Elasticsearch supprime les indices reportés.

Elasticsearch roule sur un index, en déplaçant l’index actuel et en créant un nouvel index, lorsqu’un index correspond à l’une des conditions suivantes:

  • L’indice est plus ancien que la valeur rollover.maxAge dans le CR Elasticsearch.
  • La taille de l’indice est supérieure à 40 Go × le nombre de fragments primaires.
  • Le nombre de doc index est supérieur à 40960 KB × le nombre de fragments primaires.

Elasticsearch supprime les indices en fonction de la stratégie de rétention que vous configurez. Lorsque vous ne créez pas de stratégie de rétention pour les sources de journaux, les journaux sont supprimés après sept jours par défaut.

Conditions préalables

  • L’opérateur de journalisation Red Hat OpenShift et l’opérateur OpenShift Elasticsearch doivent être installés.

Procédure

Configurer le temps de rétention du journal:

  1. Modifiez le ClusterLogging CR pour ajouter ou modifier le paramètre de rétentionPolicy: 

    apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
...
spec:
  managementState: "Managed"
  logStore:
    type: "elasticsearch"
    retentionPolicy:
    1 
    
      application:
        maxAge: 1d
      infra:
        maxAge: 7d
      audit:
        maxAge: 7d
    elasticsearch:
      nodeCount: 3
...
    Copy to Clipboard Toggle word wrap
    1
    Indiquez l’heure à laquelle Elasticsearch doit conserver chaque source de journal. Entrez un entier et une désignation de temps: semaines (w), heures (h/H), minutes(m) et secondes(s). A titre d’exemple, 1d pour une journée. Les journaux plus anciens que le maxAge sont supprimés. Les journaux sont conservés par défaut pendant sept jours.

  2. Il est possible de vérifier les paramètres de la ressource personnalisée Elasticsearch (CR).

    À titre d’exemple, le Red Hat OpenShift Logging Operator a mis à jour la version suivante d’Elasticsearch CR pour configurer une politique de rétention qui inclut des paramètres permettant de renverser les indices actifs pour les journaux d’infrastructure toutes les huit heures et les indices enroulés sont supprimés sept jours après le roulement. Le service OpenShift Red Hat sur AWS vérifie toutes les 15 minutes pour déterminer si les indices doivent être reportés. 

    apiVersion: "logging.openshift.io/v1"
kind: "Elasticsearch"
metadata:
  name: "elasticsearch"
spec:
...
  indexManagement:
    policies:
    1 
    
      - name: infra-policy
        phases:
          delete:
            minAge: 7d
    2 
    
          hot:
            actions:
              rollover:
                maxAge: 8h
    3 
    
        pollInterval: 15m
    4 
    
...
    Copy to Clipboard Toggle word wrap
    1
    Dans chaque source de journal, la stratégie de rétention indique quand supprimer et retourner les journaux pour cette source.
    2
    Lorsque Red Hat OpenShift Service sur AWS supprime les indices laminés. Ce paramètre est le maxAge que vous définissez dans le ClusterLogging CR.
    3
    L’âge de l’index pour Red Hat OpenShift Service sur AWS à prendre en compte lors du roulement sur les indices. Cette valeur est déterminée à partir du maxAge que vous définissez dans le ClusterLogging CR.
    4
    Lorsque Red Hat OpenShift Service sur AWS vérifie si les indices doivent être reportés. Ce paramètre est le paramètre par défaut et ne peut pas être modifié.
    Note

    La modification du CR Elasticsearch n’est pas prise en charge. Les modifications apportées aux politiques de conservation doivent être apportées dans le ClusterLogging CR.

    L’opérateur OpenShift Elasticsearch déploie une tâche cron pour déplacer les indices de chaque mappage à l’aide de la stratégie définie, programmée à l’aide du pollInterval. 

    $ oc get cronjob
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME                     SCHEDULE       SUSPEND   ACTIVE   LAST SCHEDULE   AGE
elasticsearch-im-app     */15 * * * *   False     0        <none>          4s
elasticsearch-im-audit   */15 * * * *   False     0        <none>          4s
elasticsearch-im-infra   */15 * * * *   False     0        <none>          4s
    Copy to Clipboard Toggle word wrap

Chaque spécification de composant permet d’ajuster à la fois le CPU et les demandes de mémoire. Il ne faut pas avoir à ajuster manuellement ces valeurs car l’opérateur OpenShift Elasticsearch définit des valeurs suffisantes pour votre environnement.

Note

Dans les clusters à grande échelle, la limite de mémoire par défaut pour le conteneur proxy Elasticsearch pourrait ne pas être suffisante, ce qui rend le conteneur proxy OOMKilled. Lorsque vous rencontrez ce problème, augmentez les demandes de mémoire et les limites pour le proxy Elasticsearch.

Chaque nœud Elasticsearch peut fonctionner avec un réglage de mémoire inférieur, mais cela n’est pas recommandé pour les déploiements de production. En production, vous ne devriez pas avoir moins que le 16Gi par défaut alloué à chaque pod. De préférence, vous devriez allouer autant que possible, jusqu’à 64Gi par dose.

Conditions préalables

  • Les opérateurs Red Hat OpenShift Logging et Elasticsearch doivent être installés.

Procédure

  1. Éditer la ressource personnalisée ClusterLogging (CR) dans le projet openshift-logging: 

    $ oc edit ClusterLogging instance
    Copy to Clipboard Toggle word wrap 
    apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
....
spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
    1 
    
        resources:
          limits:
    2 
    
            memory: "32Gi"
          requests:
    3 
    
            cpu: "1"
            memory: "16Gi"
        proxy:
    4 
    
          resources:
            limits:
              memory: 100Mi
            requests:
              memory: 100Mi
    Copy to Clipboard Toggle word wrap
    1
    Indiquez les requêtes CPU et mémoire pour Elasticsearch au besoin. Lorsque vous laissez ces valeurs vides, l’opérateur OpenShift Elasticsearch définit des valeurs par défaut qui devraient être suffisantes pour la plupart des déploiements. Les valeurs par défaut sont 16Gi pour la requête mémoire et 1 pour la requête CPU.
    2
    La quantité maximale de ressources qu’un pod peut utiliser.
    3
    Les ressources minimales requises pour planifier un pod.
    4
    Indiquez les requêtes CPU et mémoire pour le proxy Elasticsearch au besoin. Lorsque vous laissez ces valeurs vides, l’opérateur OpenShift Elasticsearch définit des valeurs par défaut suffisantes pour la plupart des déploiements. Les valeurs par défaut sont 256Mi pour la requête mémoire et 100m pour la requête CPU.

Lors de l’ajustement de la quantité de mémoire Elasticsearch, la même valeur doit être utilisée pour les requêtes et les limites.

À titre d’exemple: 

      resources:
        limits:
1 

          memory: "32Gi"
        requests:
2 

          cpu: "8"
          memory: "32Gi"
Copy to Clipboard Toggle word wrap
1
Le montant maximal de la ressource.
2
Le montant minimum requis.

Kubernetes adhère généralement à la configuration du nœud et ne permet pas à Elasticsearch d’utiliser les limites spécifiées. La définition de la même valeur pour les requêtes et les limites garantit qu’Elasticsearch peut utiliser la mémoire que vous voulez, en supposant que le nœud dispose de la mémoire disponible.

Il est possible de définir comment les fragments Elasticsearch sont reproduits sur les nœuds de données du cluster.

Conditions préalables

  • Les opérateurs Red Hat OpenShift Logging et Elasticsearch doivent être installés.

Procédure

  1. Éditer la ressource personnalisée ClusterLogging (CR) dans le projet openshift-logging: 

    $ oc -n openshift-logging edit ClusterLogging instance
    Copy to Clipboard Toggle word wrap 
    apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"

....

spec:
  logStore:
    type: "elasticsearch"
    elasticsearch:
      redundancyPolicy: "SingleRedundancy"
    1
    Copy to Clipboard Toggle word wrap
    1
    Indiquez une politique de redondance pour les fragments. Le changement est appliqué lors de la sauvegarde des changements.
    • FullRedundancy. Elasticsearch réplique complètement les fragments primaires de chaque index à chaque nœud de données. Cela offre la sécurité la plus élevée, mais au coût de la plus grande quantité de disque requise et des performances les plus pauvres.
    • De multiplesRedundancy. Elasticsearch reproduit complètement les fragments primaires de chaque index à la moitié des nœuds de données. Cela offre un bon compromis entre la sécurité et la performance.
    • Le singleRedundancy. Elasticsearch fait une copie des fragments primaires pour chaque index. Les journaux sont toujours disponibles et récupérables tant qu’il existe au moins deux nœuds de données. De meilleures performances que MultipleRedundancy, lorsque vous utilisez 5 nœuds ou plus. Il est impossible d’appliquer cette politique sur les déploiements d’un nœud Elasticsearch unique.
    • Le ZeroRedundancy. Elasticsearch ne fait pas de copies des fragments primaires. Les journaux peuvent être indisponibles ou perdus en cas de panne ou d’échec d’un nœud. Lorsque vous êtes plus préoccupé par les performances que par la sécurité, utilisez ce mode ou avez mis en œuvre votre propre stratégie de sauvegarde/restauration de disque/PVC.
Note

Le nombre de fragments primaires pour les modèles d’index est égal au nombre de nœuds de données Elasticsearch.

10.4.6. Évoluant vers le bas des pods Elasticsearch
Copier lien

La réduction du nombre de pods Elasticsearch dans votre cluster peut entraîner une perte de données ou une dégradation des performances d’Elasticsearch.

Lorsque vous baissez, vous devriez réduire d’une dose à la fois et permettre au cluster de rééquilibrer les éclats et les répliques. Après le retour de l’état de santé Elasticsearch au vert, vous pouvez réduire par une autre dose.

Note

Lorsque votre cluster Elasticsearch est défini sur ZeroRedundancy, vous ne devriez pas réduire vos pods Elasticsearch.

10.4.7. Configuration du stockage persistant pour le log store
Copier lien

Elasticsearch nécessite un stockage persistant. Le stockage est rapide, plus la performance Elasticsearch est rapide.

Avertissement

L’utilisation du stockage NFS comme volume ou volume persistant (ou via un NAS tel que Gluster) n’est pas prise en charge pour le stockage Elasticsearch, car Lucene s’appuie sur le comportement du système de fichiers que NFS ne fournit pas. La corruption des données et d’autres problèmes peuvent survenir.

Conditions préalables

  • Les opérateurs Red Hat OpenShift Logging et Elasticsearch doivent être installés.

Procédure

  1. Éditez le ClusterLogging CR pour spécifier que chaque nœud de données dans le cluster est lié à une revendication de volume persistant. 

    apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
# ...
spec:
  logStore:
    type: "elasticsearch"
    elasticsearch:
      nodeCount: 3
      storage:
        storageClassName: "gp2"
        size: "200G"
    Copy to Clipboard Toggle word wrap

Cet exemple spécifie chaque nœud de données dans le cluster est lié à une revendication de volume persistant qui demande le stockage "200G" d’AWS General Purpose SSD (gp2).

Note

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

10.4.8. Configuration du log store pour le stockage emptyDir
Copier lien

Il est possible d’utiliser emptyDir avec votre log store, ce qui crée un déploiement éphémère dans lequel toutes les données d’un pod sont perdues lors du redémarrage.

Note

Lorsque vous utilisez emptyDir, si le stockage du journal est redémarré ou redéployé, vous perdrez des données.

Conditions préalables

  • Les opérateurs Red Hat OpenShift Logging et Elasticsearch doivent être installés.

Procédure

  1. Éditez le ClusterLogging CR pour spécifier emptyDir: 

     spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage: {}
    Copy to Clipboard Toggle word wrap

Effectuez un redémarrage roulant lorsque vous modifiez la carte de configuration de la recherche élastique ou l’une des configurations de déploiement élastiquesearch-*.

En outre, un redémarrage roulant est recommandé si les nœuds sur lesquels fonctionne un pod Elasticsearch nécessitent un redémarrage.

Conditions préalables

  • Les opérateurs Red Hat OpenShift Logging et Elasticsearch doivent être installés.

Procédure

Effectuer un redémarrage du cluster roulant:

  1. Changement au projet openshift-logging: 

    $ oc project openshift-logging
    Copy to Clipboard Toggle word wrap

  2. Les noms des pods Elasticsearch: 

    $ oc get pods -l component=elasticsearch
    Copy to Clipboard Toggle word wrap

  3. Faites baisser les pods de collecteurs afin qu’ils arrêtent d’envoyer de nouveaux journaux à Elasticsearch: 

    $ oc -n openshift-logging patch daemonset/collector -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-collector": "false"}}}}}'
    Copy to Clipboard Toggle word wrap

  4. Effectuez une flush synchronisée en utilisant le service OpenShift Red Hat sur AWS es_util pour s’assurer qu’il n’y a pas d’opérations en attente d’être écrites sur le disque avant d’arrêter: 

    $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_flush/synced" -XPOST
    Copy to Clipboard Toggle word wrap

    À titre d’exemple: 

    $ oc exec -c elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6  -c elasticsearch -- es_util --query="_flush/synced" -XPOST
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    {"_shards":{"total":4,"successful":4,"failed":0},".security":{"total":2,"successful":2,"failed":0},".kibana_1":{"total":2,"successful":2,"failed":0}}
    Copy to Clipboard Toggle word wrap

  5. Évitez l’équilibrage shard lorsque vous faites tomber délibérément les nœuds à l’aide du service OpenShift Red Hat sur AWS es_util: 

    $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "primaries" } }'
    Copy to Clipboard Toggle word wrap

    À titre d’exemple: 

    $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "primaries" } }'
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    {"acknowledged":true,"persistent":{"cluster":{"routing":{"allocation":{"enable":"primaries"}}}},"transient":
    Copy to Clipboard Toggle word wrap

  6. Après la commande est terminée, pour chaque déploiement que vous avez pour un cluster ES:

    1. Le service OpenShift de Red Hat sur AWS Elasticsearch bloque les déploiements sur leurs nœuds. À l’aide de la commande suivante pour autoriser les déploiements et permettre au pod de récupérer les modifications: 

      $ oc rollout resume deployment/<deployment-name>
      Copy to Clipboard Toggle word wrap

      À titre d’exemple: 

      $ oc rollout resume deployment/elasticsearch-cdm-0-1
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      deployment.extensions/elasticsearch-cdm-0-1 resumed
      Copy to Clipboard Toggle word wrap

      Il y a un nouveau pod. Après que la gousse a un conteneur prêt, vous pouvez passer au prochain déploiement. 

      $ oc get pods -l component=elasticsearch-
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      NAME                                            READY   STATUS    RESTARTS   AGE
elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6k    2/2     Running   0          22h
elasticsearch-cdm-5ceex6ts-2-f799564cb-l9mj7    2/2     Running   0          22h
elasticsearch-cdm-5ceex6ts-3-585968dc68-k7kjr   2/2     Running   0          22h
      Copy to Clipboard Toggle word wrap

    2. Après que les déploiements soient terminés, réinitialisez le pod pour refuser les déploiements: 

      $ oc rollout pause deployment/<deployment-name>
      Copy to Clipboard Toggle word wrap

      À titre d’exemple: 

      $ oc rollout pause deployment/elasticsearch-cdm-0-1
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      deployment.extensions/elasticsearch-cdm-0-1 paused
      Copy to Clipboard Toggle word wrap

    3. Assurez-vous que le cluster Elasticsearch est dans un état vert ou jaune: 

      $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query=_cluster/health?pretty=true
      Copy to Clipboard Toggle word wrap
      Note

      Lorsque vous avez effectué un déploiement sur le pod Elasticsearch que vous avez utilisé dans les commandes précédentes, le pod n’existe plus et vous avez besoin d’un nouveau nom de pod ici.

      À titre d’exemple: 

      $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query=_cluster/health?pretty=true
      Copy to Clipboard Toggle word wrap 
      {
  "cluster_name" : "elasticsearch",
  "status" : "yellow",
      1 
      
  "timed_out" : false,
  "number_of_nodes" : 3,
  "number_of_data_nodes" : 3,
  "active_primary_shards" : 8,
  "active_shards" : 16,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 1,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 100.0
}
      Copy to Clipboard Toggle word wrap
      1
      Assurez-vous que cette valeur de paramètre est verte ou jaune avant de procéder.
  7. Lorsque vous avez modifié la carte de configuration Elasticsearch, répétez ces étapes pour chaque pod Elasticsearch.

  8. Après que tous les déploiements pour le cluster aient été déployés, réactivez l’équilibrage en dur: 

    $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "all" } }'
    Copy to Clipboard Toggle word wrap

    À titre d’exemple: 

    $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "all" } }'
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    {
  "acknowledged" : true,
  "persistent" : { },
  "transient" : {
    "cluster" : {
      "routing" : {
        "allocation" : {
          "enable" : "all"
        }
      }
    }
  }
}
    Copy to Clipboard Toggle word wrap

  9. Augmentez les pods de collecteurs afin qu’ils envoient de nouveaux journaux à Elasticsearch. 

    $ oc -n openshift-logging patch daemonset/collector -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-collector": "true"}}}}}'
    Copy to Clipboard Toggle word wrap

10.4.10. Exposer le service de log store comme itinéraire
Copier lien

Le log store déployé avec l’enregistrement n’est pas accessible depuis l’extérieur du cluster de journalisation. Il est possible d’activer un itinéraire avec terminaison de recryptage pour un accès externe au service log store pour les outils qui accèdent à ses données.

En externe, vous pouvez accéder au log store en créant un itinéraire recrypté, votre Red Hat OpenShift Service sur le jeton AWS et le certificat CA installé. Ensuite, accédez à un nœud qui héberge le service log store avec une requête cURL qui contient:

  • L’autorisation: Porteur ${token}
  • La route Elasticsearch recrypte et une demande d’API Elasticsearch.

En interne, vous pouvez accéder au service de log store à l’aide du cluster de log store IP, que vous pouvez obtenir en utilisant l’une des commandes suivantes: 

$ oc get service elasticsearch -o jsonpath={.spec.clusterIP} -n openshift-logging
Copy to Clipboard Toggle word wrap

Exemple de sortie

172.30.183.229
Copy to Clipboard Toggle word wrap 

$ oc get service elasticsearch -n openshift-logging
Copy to Clipboard Toggle word wrap

Exemple de sortie

NAME            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
elasticsearch   ClusterIP   172.30.183.229   <none>        9200/TCP   22h
Copy to Clipboard Toggle word wrap

Il est possible de vérifier l’adresse IP du cluster avec une commande similaire à ce qui suit: 

$ oc exec elasticsearch-cdm-oplnhinv-1-5746475887-fj2f8 -n openshift-logging -- curl -tlsv1.2 --insecure -H "Authorization: Bearer ${token}" "https://172.30.183.229:9200/_cat/health"
Copy to Clipboard Toggle word wrap

Exemple de sortie

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    29  100    29    0     0    108      0 --:--:-- --:--:-- --:--:--   108
Copy to Clipboard Toggle word wrap

Conditions préalables

  • Les opérateurs Red Hat OpenShift Logging et Elasticsearch doivent être installés.
  • Il faut avoir accès au projet pour pouvoir accéder aux journaux.

Procédure

Exposer le log store à l’extérieur:

  1. Changement au projet openshift-logging: 

    $ oc project openshift-logging
    Copy to Clipboard Toggle word wrap

  2. Extrayez le certificat CA du log store et écrivez dans le fichier admin-ca: 

    $ oc extract secret/elasticsearch --to=. --keys=admin-ca
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    admin-ca
    Copy to Clipboard Toggle word wrap

  3. Créez l’itinéraire pour le service log store en tant que fichier YAML:

    1. Créez un fichier YAML avec ce qui suit: 

      apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: elasticsearch
  namespace: openshift-logging
spec:
  host:
  to:
    kind: Service
    name: elasticsearch
  tls:
    termination: reencrypt
    destinationCACertificate: |
      1
      Copy to Clipboard Toggle word wrap
      1
      Ajoutez le log store CA certifcate ou utilisez la commande dans l’étape suivante. Il n’est pas nécessaire de définir les paramètres spec.tls.key, spec.tls.certificate et spec.tls.caCertificate requis par certains itinéraires recryptés.

    2. Exécutez la commande suivante pour ajouter le certificat CA log store à l’itinéraire YAML que vous avez créé à l’étape précédente: 

      $ cat ./admin-ca | sed -e "s/^/      /" >> <file-name>.yaml
      Copy to Clipboard Toggle word wrap

    3. Créer l’itinéraire: 

      $ oc create -f <file-name>.yaml
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      route.route.openshift.io/elasticsearch created
      Copy to Clipboard Toggle word wrap

  4. Assurez-vous que le service Elasticsearch est exposé:

    1. Bénéficiez du jeton de ce compte de service pour être utilisé dans la demande: 

      $ token=$(oc whoami -t)
      Copy to Clipboard Toggle word wrap

    2. Définissez l’itinéraire de recherche élastique que vous avez créé en tant que variable d’environnement. 

      $ routeES=`oc get route elasticsearch -o jsonpath={.spec.host}`
      Copy to Clipboard Toggle word wrap

    3. Afin de vérifier que l’itinéraire a été créé avec succès, exécutez la commande suivante qui accède à Elasticsearch à travers la route exposée: 

      curl -tlsv1.2 --insecure -H "Authorization: Bearer ${token}" "https://${routeES}"
      Copy to Clipboard Toggle word wrap

      La réponse semble similaire à ce qui suit:

      Exemple de sortie

      {
  "name" : "elasticsearch-cdm-i40ktba0-1",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "0eY-tJzcR3KOdpgeMJo-MQ",
  "version" : {
  "number" : "6.8.1",
  "build_flavor" : "oss",
  "build_type" : "zip",
  "build_hash" : "Unknown",
  "build_date" : "Unknown",
  "build_snapshot" : true,
  "lucene_version" : "7.7.0",
  "minimum_wire_compatibility_version" : "5.6.0",
  "minimum_index_compatibility_version" : "5.0.0"
},
  "<tagline>" : "<for search>"
}
      Copy to Clipboard Toggle word wrap

En tant qu’administrateur, dans le cas rare que vous transmettiez des journaux vers un magasin de journal tiers et que vous n’utilisiez pas le log store Elasticsearch par défaut, vous pouvez supprimer plusieurs composants inutilisés de votre cluster de journalisation.

En d’autres termes, si vous n’utilisez pas le log store Elasticsearch par défaut, vous pouvez supprimer les composants de visualisation internes Elasticsearch logStore et Kibana de la ressource personnalisée ClusterLogging (CR). La suppression de ces composants est facultative, mais permet d’économiser des ressources.

Conditions préalables

  • Assurez-vous que votre transmetteur de journaux n’envoie pas de données de journal au cluster interne Elasticsearch par défaut. Inspectez le fichier ClusterLogForwarder CR YAML que vous avez utilisé pour configurer le transfert de journaux. Assurez-vous qu’il n’a pas d’élément outputRefs qui spécifie par défaut. À titre d’exemple: 

    outputRefs:
- default
    Copy to Clipboard Toggle word wrap
Avertissement

Imaginez que le ClusterLogForwarder CR transmet les données de log vers le cluster Elasticsearch interne, et vous supprimez le composant logStore du ClusterLogging CR. Dans ce cas, le cluster Elasticsearch interne ne sera pas présent pour stocker les données du journal. Cette absence peut entraîner une perte de données.

Procédure

  1. Éditer la ressource personnalisée ClusterLogging (CR) dans le projet openshift-logging: 

    $ oc edit ClusterLogging instance
    Copy to Clipboard Toggle word wrap
  2. En cas de présence, retirez les strophes logStore et visualisation du ClusterLogging CR.

  3. Conserver la strophe de collection du ClusterLogging CR. Le résultat devrait ressembler à l’exemple suivant: 

    apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
  namespace: "openshift-logging"
spec:
  managementState: "Managed"
  collection:
    type: "fluentd"
    fluentd: {}
    Copy to Clipboard Toggle word wrap

  4. Assurez-vous que les pods de collecteur sont redéployés: 

    $ oc get pods -l component=collector -n openshift-logging
    Copy to Clipboard Toggle word wrap
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