6.3. Configuration de l'entrepôt de données

1. Créez ou modifiez un fichier YAML qui définit l'objet ClusterLogForwarder CR :

   • Créez un CR pour envoyer tous les types de journaux à l'instance Elasticsearch interne. Vous pouvez utiliser l'exemple suivant sans y 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

     1

     Un pipeline définit le type de journaux à transmettre à l'aide de la sortie spécifiée. La sortie par défaut transmet les journaux à l'instance Elasticsearch interne.

     Note

     Vous devez spécifier les trois types de journaux dans le pipeline : application, infrastructure et audit. Si vous ne spécifiez pas un type de journal, ces journaux ne sont pas stockés et seront perdus.

   • Si vous disposez d'un CR ClusterLogForwarder existant, ajoutez un pipeline à la sortie par défaut des journaux d'audit. Il n'est pas nécessaire de définir la sortie par défaut. Par exemple, il n'est pas nécessaire de définir la sortie par défaut :

     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

     1

     Ce pipeline envoie les journaux d'audit à l'instance Elasticsearch interne en plus d'une instance externe.

1. Editer le CR ClusterLogging pour ajouter ou modifier le paramètre retentionPolicy:

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

   1

   Spécifiez la durée pendant laquelle Elasticsearch doit conserver chaque source de journal. Saisissez un nombre entier et une désignation de temps : semaines(w), heures(h/H), minutes(m) et secondes(s). Par exemple, 1d pour un jour. Les journaux antérieurs à maxAge sont supprimés. Par défaut, les journaux sont conservés pendant sept jours.

2. Vous pouvez vérifier les paramètres dans la ressource personnalisée (CR) Elasticsearch.

   Par exemple, l'opérateur de journalisation Red Hat OpenShift a mis à jour le document suivant Elasticsearch CR pour configurer une politique de rétention qui inclut des paramètres permettant de renouveler les index actifs pour les journaux d'infrastructure toutes les huit heures et les index renouvelés sont supprimés sept jours après le renouvellement. OpenShift Container Platform vérifie toutes les 15 minutes si les index doivent être reconduits.

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

   1

   Pour chaque source de logs, la politique de conservation indique quand supprimer et reconduire les logs de cette source.

   2

   Lorsque OpenShift Container Platform supprime les index reportés. Ce paramètre est le maxAge que vous avez défini dans le CR ClusterLogging.

   3

   L'âge de l'index pour OpenShift Container Platform à prendre en compte lors de la reconduction des index. Cette valeur est déterminée par la valeur maxAge que vous avez définie dans le CR ClusterLogging.

   4

   Quand OpenShift Container Platform vérifie si les indices doivent être reconduits. Ce paramètre est par défaut et ne peut pas être modifié.

   Note

   La modification de la CR Elasticsearch n'est pas prise en charge. Toutes les modifications apportées aux politiques de conservation doivent être effectuées dans le CR ClusterLogging.

   L'OpenShift Elasticsearch Operator déploie un job cron pour rouler les index pour chaque mapping en utilisant la politique définie, planifiée en utilisant le pollInterval.

   $ oc get cronjob

   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

Procédure

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

   $ oc edit ClusterLogging instance

   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

   1

   Spécifiez les demandes de CPU et de mémoire pour Elasticsearch si nécessaire. Si vous laissez ces valeurs vides, OpenShift Elasticsearch Operator 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 demande de mémoire et 1 pour la demande de CPU.

   2

   Quantité maximale de ressources qu'un module peut utiliser.

   3

   Les ressources minimales requises pour planifier un pod.

   4

   Spécifiez les demandes de CPU et de mémoire pour le proxy Elasticsearch si nécessaire. Si vous laissez ces valeurs vides, OpenShift Elasticsearch Operator définit des valeurs par défaut qui sont suffisantes pour la plupart des déploiements. Les valeurs par défaut sont 256Mi pour la demande de mémoire et 100m pour la demande de CPU.

Procédure

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

   $ oc edit clusterlogging instance

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
   
   ....
   
   spec:
     logStore:
       type: "elasticsearch"
       elasticsearch:
         redundancyPolicy: "SingleRedundancy" 1

   1

   Spécifiez une politique de redondance pour les shards. La modification est appliquée lors de l'enregistrement des changements.

   • FullRedundancy. Elasticsearch réplique entièrement les shards primaires de chaque index sur chaque nœud de données. Cette méthode offre la plus grande sécurité, mais au prix de la plus grande quantité de disque nécessaire et de la plus faible performance.
   • MultipleRedundancy. Elasticsearch réplique entièrement les shards primaires de chaque index sur la moitié des nœuds de données. Cela permet d'obtenir un bon compromis entre sécurité et performance.
   • SingleRedundancy. Elasticsearch fait une copie des shards primaires pour chaque index. Les logs sont toujours disponibles et récupérables tant qu'il existe au moins deux nœuds de données. Meilleure performance que MultipleRedundancy, lors de l'utilisation de 5 nœuds ou plus. Vous ne pouvez pas appliquer cette politique aux déploiements d'un seul nœud Elasticsearch.
   • ZeroRedundancy. Elasticsearch n'effectue pas de copies des shards primaires. Les journaux peuvent être indisponibles ou perdus en cas d'arrêt ou de défaillance d'un nœud. Utilisez ce mode si vous êtes plus préoccupé par les performances que par la sécurité, ou si vous avez mis en œuvre votre propre stratégie de sauvegarde/restauration sur disque/PVC.

Procédure

1. Modifiez la CR ClusterLogging 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"

Procédure

1. Modifiez le CR ClusterLogging pour spécifier emptyDir :

    spec:
       logStore:
         type: "elasticsearch"
         elasticsearch:
           nodeCount: 3
           storage: {}

1. Modification du projet openshift-logging:

   $ oc project openshift-logging

2. Obtenir les noms des pods Elasticsearch :

   $ oc get pods -l component=elasticsearch-

3. Réduire les pods collecteurs afin qu'ils cessent d'envoyer de nouveaux journaux à Elasticsearch :

   $ oc -n openshift-logging patch daemonset/collector -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-collector": "false"}}}}}'

4. Effectuer un shard synced flush à l'aide de l'outil OpenShift Container Platform es_util pour s'assurer qu'il n'y a pas d'opérations en attente d'écriture sur le disque avant l'arrêt :

   $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_flush/synced" -XPOST

   Par exemple :

   $ oc exec -c elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6  -c elasticsearch -- es_util --query="_flush/synced" -XPOST

   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}}

5. Empêcher l'équilibrage des shards lors de l'arrêt volontaire des nœuds à l'aide de l'outil es_util d'OpenShift Container Platform :

   $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent" : { "cluster.routing.allocation.enable" : \N- "primaries\N" } }'

   Par exemple :

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

   Exemple de sortie

   {"acknowledged":true,"persistent":{"cluster":{"routing":{"allocation":{"enable":"primaries"}}}},"transient":

6. Une fois la commande terminée, pour chaque déploiement que vous avez pour un cluster ES :

   1. Par défaut, le cluster Elasticsearch d'OpenShift Container Platform bloque les déploiements sur ses nœuds. Utilisez la commande suivante pour autoriser les déploiements et permettre au pod de récupérer les modifications :

      oc rollout resume deployment/<deployment-name> $ oc rollout resume deployment/<deployment-name>

      Par exemple :

      $ oc rollout resume deployment/elasticsearch-cdm-0-1

      Exemple de sortie

      deployment.extensions/elasticsearch-cdm-0-1 resumed

      Un nouveau pod est déployé. Une fois que le pod a un conteneur prêt, vous pouvez passer au déploiement suivant.

      $ oc get pods -l component=elasticsearch-

      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

   2. Une fois les déploiements terminés, réinitialisez le pod pour interdire les déploiements :

      oc rollout pause deployment/<deployment-name>

      Par exemple :

      $ oc rollout pause deployment/elasticsearch-cdm-0-1

      Exemple de sortie

      deployment.extensions/elasticsearch-cdm-0-1 paused

   3. Vérifiez que le cluster Elasticsearch est dans un état green ou yellow:

      $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query=_cluster/health?pretty=true

      Note

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

      Par exemple :

      $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query=_cluster/health?pretty=true

      {
        "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
      }

      1

      Assurez-vous que la valeur de ce paramètre est green ou yellow avant de poursuivre.

7. Si vous avez modifié la carte de configuration d'Elasticsearch, répétez ces étapes pour chaque module d'Elasticsearch.

8. Une fois que tous les déploiements de la grappe ont été effectués, réactivez l'équilibrage de la grappe :

   $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent" : { "cluster.routing.allocation.enable" : "tous" } }'

   Par exemple :

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

   Exemple de sortie

   {
     "acknowledged" : true,
     "persistent" : { },
     "transient" : {
       "cluster" : {
         "routing" : {
           "allocation" : {
             "enable" : "all"
           }
         }
       }
     }
   }

9. Augmenter les pods collecteurs pour qu'ils envoient de nouveaux journaux à Elasticsearch.

   $ oc -n openshift-logging patch daemonset/collector -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-collector": "true"}}}}}'

1. Modification du projet openshift-logging:

   $ oc project openshift-logging

2. Extraire le certificat de l'autorité de certification de la base de données et l'écrire dans le fichier admin-ca dans le fichier

   $ oc extract secret/elasticsearch --to=. --keys=admin-ca

   Exemple de sortie

   admin-ca

3. Créez la route pour le service de stockage de journaux sous la forme d'un 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

      1

      Ajoutez le certificat de l'autorité de certification du magasin de journaux ou utilisez la commande de 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 reencrypt.

   2. Exécutez la commande suivante pour ajouter le certificat de l'autorité de certification du magasin de journaux à l'itinéraire YAML créé à l'étape précédente :

      $ cat ./admin-ca | sed -e "s/^/      /" >> <file-name>.yaml

   3. Créer l'itinéraire :

      oc create -f <nom-de-fichier>.yaml

      Exemple de sortie

      route.route.openshift.io/elasticsearch created

4. Vérifier que le service Elasticsearch est exposé :

   1. Obtenir le jeton de ce compte de service à utiliser dans la demande :

      $ token=$(oc whoami -t)

   2. Définissez la route elasticsearch que vous avez créée comme variable d'environnement.

      $ routeES=`oc get route elasticsearch -o jsonpath={.spec.host}`

   3. Pour vérifier que la route a été créée avec succès, exécutez la commande suivante qui accède à Elasticsearch via la route exposée :

      curl -tlsv1.2 --insecure -H "Authorization: Bearer ${token}" "https://${routeES}"

      La réponse ressemble à 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>"
      }