9.4. Configuration du transfert de journaux

Procédure

1. Créez un secret à l’aide de votre jeton Splunk HEC codé Base64.

   $ oc -n openshift-logging create secret generic vector-splunk-secret --from-literal hecToken=<HEC_Token>

   Copy to Clipboard Toggle word wrap

2. Créez ou modifiez la ressource personnalisée ClusterLogForwarder (CR) en utilisant le modèle ci-dessous:

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: <log_forwarder_name> 

   1

   
     namespace: <log_forwarder_namespace> 

   2

   
   spec:
     serviceAccountName: <service_account_name> 

   3

   
     outputs:
       - name: splunk-receiver 

   4

   
         secret:
           name: vector-splunk-secret 

   5

   
         type: splunk 

   6

   
         url: <http://your.splunk.hec.url:8088> 

   7

   
     pipelines: 

   8

   
       - inputRefs:
           - application
           - infrastructure
         name: 

   9

   
         outputRefs:
           - splunk-receiver 

   10

   Copy to Clipboard Toggle word wrap

   1

   Dans les implémentations antérieures, le nom CR doit être instance. Dans les implémentations de transbordeur de journaux multiples, vous pouvez utiliser n’importe quel nom.

   2

   Dans les implémentations héritées, l’espace de noms CR doit être ouvert-logging. Dans les implémentations de transfert de journaux multiples, vous pouvez utiliser n’importe quel espace de noms.

   3

   Le nom de votre compte de service. Le compte de service n’est requis que dans les implémentations de transbordeur de journaux multiples si l’expéditeur de journaux n’est pas déployé dans l’espace de noms openshift-logging.

   4

   Indiquez un nom pour la sortie.

   5

   Indiquez le nom du secret qui contient votre jeton HEC.

   6

   Indiquez le type de sortie comme splunk.

   7

   Indiquez l’URL (y compris le port) de votre Splunk HEC.

   8

   Indiquez les types de journaux à transmettre en utilisant le pipeline : application, infrastructure ou vérification.

   9

   Facultatif : Spécifiez un nom pour le pipeline.

   10

   Indiquez le nom de la sortie à utiliser lors de la transmission des journaux avec ce pipeline.

Procédure

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

   Exemple ClusterLogForwarder CR

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: instance 

   1

   
     namespace: openshift-logging 

   2

   
   spec:
     outputs:
      - name: fluentd-server-secure 

   3

   
        type: fluentdForward 

   4

   
        url: 'tls://fluentdserver.security.example.com:24224' 

   5

   
        secret: 

   6

   
           name: fluentd-secret
      - name: fluentd-server-insecure
        type: fluentdForward
        url: 'tcp://fluentdserver.home.example.com:24224'
     inputs: 

   7

   
      - name: my-app-logs
        application:
           namespaces:
           - my-project 

   8

   
     pipelines:
      - name: forward-to-fluentd-insecure 

   9

   
        inputRefs: 

   10

   
        - my-app-logs
        outputRefs: 

   11

   
        - fluentd-server-insecure
        labels:
          project: "my-project" 

   12

   
      - name: forward-to-fluentd-secure 

   13

   
        inputRefs:
        - application 

   14

   
        - audit
        - infrastructure
        outputRefs:
        - fluentd-server-secure
        - default
        labels:
          clusterId: "C1234"

   Copy to Clipboard Toggle word wrap

   1

   Le nom du ClusterLogForwarder CR doit être instance.

   2

   L’espace de noms du ClusterLogForwarder CR doit être ouvert-logging.

   3

   Le nom de la sortie.

   4

   Le type de sortie: recherche élastique, fluentdForward, syslog, ou kafka.

   5

   L’URL et le port de l’agrégateur de journal externe en tant qu’URL absolue valide. Lorsque le proxy à l’échelle du cluster utilisant l’annotation CIDR est activé, la sortie doit être un nom de serveur ou un FQDN, et non une adresse IP.

   6

   En utilisant un préfixe tls, vous devez spécifier le nom du secret requis par le point de terminaison pour la communication TLS. Le secret doit exister dans le projet openshift-logging et avoir des touches tls.crt, tls.key et ca-bundle.crt qui pointent vers les certificats qu’ils représentent.

   7

   La configuration d’une entrée pour filtrer les journaux des applications à partir des projets spécifiés.

   8

   En l’absence d’espace de noms, les journaux sont recueillis dans tous les espaces de noms.

   9

   La configuration du pipeline dirige les journaux d’une entrée nommée vers une sortie nommée. Dans cet exemple, un pipeline nommé forward-to-fluentd-insécurité enregistre des logs d’une entrée nommée my-app-logs à un produit nommé couramment serveur non sécurisé.

   10

   Liste des entrées.

   11

   Le nom de la sortie à utiliser.

   12

   Facultatif: String. Il y a une ou plusieurs étiquettes à ajouter aux journaux.

   13

   Configuration pour qu’un pipeline envoie des journaux à d’autres agrégateurs de journaux.

   • Facultatif : Spécifiez un nom pour le pipeline.
   • Indiquez les types de journaux à transmettre en utilisant le pipeline : application, infrastructure ou vérification.
   • Indiquez le nom de la sortie à utiliser lors de la transmission des journaux avec ce pipeline.
   • Facultatif : Spécifiez la sortie par défaut pour transférer les journaux vers le log store par défaut.
   • Facultatif: String. Il y a une ou plusieurs étiquettes à ajouter aux journaux.

   14

   Les journaux d’applications de tous les espaces de noms sont recueillis lors de l’utilisation de cette configuration.

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

   $ oc apply -f <filename>.yaml

   Copy to Clipboard Toggle word wrap

Procédure

1. Créez ou modifiez un fichier YAML qui définit l’objet ClusterLogForwarder CR. Dans le fichier, spécifiez les étiquettes de pod en utilisant des sélecteurs simples basés sur l’égalité sous input[].name.application.selector.matchLabels, comme indiqué dans l’exemple suivant.

   Exemple de fichier ClusterLogForwarder CR YAML

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: <log_forwarder_name> 

   1

   
     namespace: <log_forwarder_namespace> 

   2

   
   spec:
     pipelines:
       - inputRefs: [ myAppLogData ] 

   3

   
         outputRefs: [ default ] 

   4

   
     inputs: 

   5

   
       - name: myAppLogData
         application:
           selector:
             matchLabels: 

   6

   
               environment: production
               app: nginx
           namespaces: 

   7

   
           - app1
           - app2
     outputs: 

   8

   
       - <output_name>
       ...

   Copy to Clipboard Toggle word wrap

   1

   Dans les implémentations antérieures, le nom CR doit être instance. Dans les implémentations de transbordeur de journaux multiples, vous pouvez utiliser n’importe quel nom.

   2

   Dans les implémentations héritées, l’espace de noms CR doit être ouvert-logging. Dans les implémentations de transfert de journaux multiples, vous pouvez utiliser n’importe quel espace de noms.

   3

   Indiquez une ou plusieurs valeurs séparées par des virgules à partir des entrées[].name.

   4

   Indiquez une ou plusieurs valeurs séparées par les virgules des sorties[].

   5

   Définissez une entrée unique[].nom pour chaque application qui a un ensemble unique d’étiquettes de pod.

   6

   Indiquez les paires clés-valeur d’étiquettes de pod dont vous souhaitez recueillir les données de journal. Il faut spécifier à la fois une clé et une valeur, pas seulement une clé. Afin d’être sélectionnés, les gousses doivent correspondre à toutes les paires clé-valeur.

   7

   Facultatif : Spécifiez un ou plusieurs espaces de noms.

   8

   Indiquez une ou plusieurs sorties pour transmettre vos données de journal.

2. Facultatif: Pour limiter la collecte de données de journal à des espaces de noms spécifiques, utilisez les entrées[].name.application.namespaces, comme indiqué dans l’exemple précédent.

3. Facultatif: Vous pouvez envoyer des données de log à partir d’applications supplémentaires qui ont des étiquettes de pod différentes vers le même pipeline.

   1. Dans chaque combinaison unique d’étiquettes de pod, créez une section d’entrées supplémentaires similaire à celle affichée.
   2. Actualisez les sélecteurs pour correspondre aux étiquettes de pod de cette application.

   3. Ajoutez la nouvelle valeur d’entrée[].name à inputRefs. À titre d’exemple:

      - inputRefs: [ myAppLogData, myOtherAppLogData ]

      Copy to Clipboard Toggle word wrap

4. Créer l’objet CR:

   $ oc create -f <file-name>.yaml

   Copy to Clipboard Toggle word wrap

Procédure

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

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: <log_forwarder_name> 

   1

   
     namespace: <log_forwarder_namespace> 

   2

   
   spec:
     serviceAccountName: <service_account_name> 

   3

   
     outputs:
     - name: loki-insecure 

   4

   
       type: "loki" 

   5

   
       url: http://loki.insecure.com:3100 

   6

   
       loki:
         tenantKey: kubernetes.namespace_name
         labelKeys:
         - kubernetes.labels.foo
     - name: loki-secure 

   7

   
       type: "loki"
       url: https://loki.secure.com:3100
       secret:
         name: loki-secret 

   8

   
       loki:
         tenantKey: kubernetes.namespace_name 

   9

   
         labelKeys:
         - kubernetes.labels.foo 

   10

   
     pipelines:
     - name: application-logs 

   11

   
       inputRefs:  

   12

   
       - application
       - audit
       outputRefs: 

   13

   
       - loki-secure

   Copy to Clipboard Toggle word wrap

   1

   Dans les implémentations antérieures, le nom CR doit être instance. Dans les implémentations de transbordeur de journaux multiples, vous pouvez utiliser n’importe quel nom.

   2

   Dans les implémentations héritées, l’espace de noms CR doit être ouvert-logging. Dans les implémentations de transfert de journaux multiples, vous pouvez utiliser n’importe quel espace de noms.

   3

   Le nom de votre compte de service. Le compte de service n’est requis que dans les implémentations de transbordeur de journaux multiples si l’expéditeur de journaux n’est pas déployé dans l’espace de noms openshift-logging.

   4

   Indiquez un nom pour la sortie.

   5

   Indiquez le type comme "loki".

   6

   Indiquez l’URL et le port du système Loki en tant qu’URL absolue valide. Il est possible d’utiliser le protocole http (non sécurisé) ou https (sécurisé HTTP). Lorsque le proxy à l’échelle du cluster utilisant l’annotation CIDR est activé, la sortie doit être un nom de serveur ou un FQDN, et non une adresse IP. Le port par défaut de Loki pour la communication HTTP(S) est 3100.

   7

   Dans le cas d’une connexion sécurisée, vous pouvez spécifier une URL https ou http que vous authentifiez en spécifiant un secret.

   8

   Dans le cas d’un préfixe https, spécifiez le nom du secret requis par le point de terminaison pour la communication TLS. Le secret doit contenir une clé ca-bundle.crt qui pointe vers les certificats qu’il représente. Autrement, pour les préfixes http et https, vous pouvez spécifier un secret qui contient un nom d’utilisateur et un mot de passe. Dans les implémentations héritées, le secret doit exister dans le projet d’exploitation en openshift. En savoir plus, voir « Exemple : Configurer un secret qui contient un nom d’utilisateur et un mot de passe ».

   9

   Facultatif : Spécifiez un champ clé de métadonnées pour générer des valeurs pour le champ TenantID dans Loki. À titre d’exemple, le paramètre tenantKey: kubernetes.namespace_name utilise les noms des espaces de noms Kubernetes comme valeurs pour les identifiants de locataire dans Loki. Afin de voir les autres champs d’enregistrement de journaux que vous pouvez spécifier, consultez le lien « Champs d’enregistrement de registre » dans la section suivante « Ressources supplémentaires ».

   10

   Facultatif: Spécifiez une liste de touches de champ de métadonnées pour remplacer les étiquettes Loki par défaut. Les noms d’étiquettes Loki doivent correspondre à l’expression régulière [a-zA-Z_:][a-zA-Z0-9_:]*. Les caractères illégaux dans les clés de métadonnées sont remplacés par _ pour former le nom de l’étiquette. Ainsi, la clé de métadonnées kubernetes.labels.foo devient le label Loki kubernetes_labels_foo. Dans le cas où vous ne définissez pas de baliseKeys, la valeur par défaut est : [log_type, kubernetes.namespace_name, kubernetes.pod_name, kubernetes_host]. Gardez l’ensemble d’étiquettes petit car Loki limite la taille et le nombre d’étiquettes autorisées. Consultez Configuring Loki, limit_config. Cependant, vous pouvez toujours interroger en fonction de n’importe quel champ d’enregistrement de journal à l’aide de filtres de requête.

   11

   Facultatif : Spécifiez un nom pour le pipeline.

   12

   Indiquez les types de journaux à transmettre en utilisant le pipeline : application, infrastructure ou vérification.

   13

   Indiquez le nom de la sortie à utiliser lors de la transmission des journaux avec ce pipeline.

   Note

   Étant donné que Loki exige que les flux de journaux soient correctement commandés par horodatage, labelKeys inclut toujours l’ensemble d’étiquettes kubernetes_host, même si vous ne le spécifiez pas. Cette inclusion garantit que chaque flux provient d’un seul hôte, ce qui empêche les horodatages de devenir désordonnés en raison des différences d’horloge sur différents hôtes.

2. Appliquez l’objet ClusterLogForwarder CR en exécutant la commande suivante:

   $ oc apply -f <filename>.yaml

   Copy to Clipboard Toggle word wrap

Procédure

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

   Exemple ClusterLogForwarder CR

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: <log_forwarder_name> 

   1

   
     namespace: <log_forwarder_namespace> 

   2

   
   spec:
     serviceAccountName: <service_account_name> 

   3

   
     outputs:
      - name: elasticsearch-example 

   4

   
        type: elasticsearch 

   5

   
        elasticsearch:
          version: 8 

   6

   
        url: http://elasticsearch.example.com:9200 

   7

   
        secret:
          name: es-secret 

   8

   
     pipelines:
      - name: application-logs 

   9

   
        inputRefs: 

   10

   
        - application
        - audit
        outputRefs:
        - elasticsearch-example 

   11

   
        - default 

   12

   
        labels:
          myLabel: "myValue" 

   13

   
   # ...

   Copy to Clipboard Toggle word wrap

   1

   Dans les implémentations antérieures, le nom CR doit être instance. Dans les implémentations de transbordeur de journaux multiples, vous pouvez utiliser n’importe quel nom.

   2

   Dans les implémentations héritées, l’espace de noms CR doit être ouvert-logging. Dans les implémentations de transfert de journaux multiples, vous pouvez utiliser n’importe quel espace de noms.

   3

   Le nom de votre compte de service. Le compte de service n’est requis que dans les implémentations de transbordeur de journaux multiples si l’expéditeur de journaux n’est pas déployé dans l’espace de noms openshift-logging.

   4

   Indiquez un nom pour la sortie.

   5

   Indiquez le type de recherche élastique.

   6

   Indiquez la version Elasticsearch. Cela peut être 6, 7 ou 8.

   7

   Indiquez l’URL et le port de l’instance externe Elasticsearch comme URL absolue valide. Il est possible d’utiliser le protocole http (non sécurisé) ou https (sécurisé HTTP). Lorsque le proxy à l’échelle du cluster utilisant l’annotation CIDR est activé, la sortie doit être un nom de serveur ou un FQDN, et non une adresse IP.

   8

   Dans le cas d’un préfixe https, spécifiez le nom du secret requis par le point de terminaison pour la communication TLS. Le secret doit contenir une clé ca-bundle.crt qui pointe vers le certificat qu’il représente. Autrement, pour les préfixes http et https, vous pouvez spécifier un secret qui contient un nom d’utilisateur et un mot de passe. Dans les implémentations héritées, le secret doit exister dans le projet d’exploitation en openshift. En savoir plus, voir « Exemple : Configurer un secret qui contient un nom d’utilisateur et un mot de passe ».

   9

   Facultatif : Spécifiez un nom pour le pipeline.

   10

   Indiquez les types de journaux à transmettre en utilisant le pipeline : application, infrastructure ou vérification.

   11

   Indiquez le nom de la sortie à utiliser lors de la transmission des journaux avec ce pipeline.

   12

   Facultatif : Spécifiez la sortie par défaut pour envoyer les journaux à l’instance interne Elasticsearch.

   13

   Facultatif: String. Il y a une ou plusieurs étiquettes à ajouter aux journaux.

2. Appliquer le ClusterLogForwarder CR:

   $ oc apply -f <filename>.yaml

   Copy to Clipboard Toggle word wrap

1. Créez un fichier Secret YAML similaire à l’exemple suivant. Les valeurs encodées base64 sont utilisées pour les champs nom d’utilisateur et mot de passe. Le type secret est opaque par défaut.

   apiVersion: v1
   kind: Secret
   metadata:
     name: openshift-test-secret
   data:
     username: <username>
     password: <password>
   # ...

   Copy to Clipboard Toggle word wrap

2. Créer le secret:

   $ oc create secret -n openshift-logging openshift-test-secret.yaml

   Copy to Clipboard Toggle word wrap

3. Indiquez le nom du secret dans le ClusterLogForwarder CR:

   kind: ClusterLogForwarder
   metadata:
     name: instance
     namespace: openshift-logging
   spec:
     outputs:
      - name: elasticsearch
        type: "elasticsearch"
        url: https://elasticsearch.secure.com:9200
        secret:
           name: openshift-test-secret
   # ...

   Copy to Clipboard Toggle word wrap
   Note

   Dans la valeur du champ url, le préfixe peut être http ou https.

4. Appliquer l’objet CR:

   $ oc apply -f <filename>.yaml

   Copy to Clipboard Toggle word wrap

Procédure

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

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: instance 

   1

   
     namespace: openshift-logging 

   2

   
   spec:
     outputs:
      - name: fluentd-server-secure 

   3

   
        type: fluentdForward 

   4

   
        url: 'tls://fluentdserver.security.example.com:24224' 

   5

   
        secret: 

   6

   
           name: fluentd-secret
      - name: fluentd-server-insecure
        type: fluentdForward
        url: 'tcp://fluentdserver.home.example.com:24224'
     pipelines:
      - name: forward-to-fluentd-secure 

   7

   
        inputRefs:  

   8

   
        - application
        - audit
        outputRefs:
        - fluentd-server-secure 

   9

   
        - default 

   10

   
        labels:
          clusterId: "C1234" 

   11

   
      - name: forward-to-fluentd-insecure 

   12

   
        inputRefs:
        - infrastructure
        outputRefs:
        - fluentd-server-insecure
        labels:
          clusterId: "C1234"

   Copy to Clipboard Toggle word wrap

   1

   Le nom du ClusterLogForwarder CR doit être instance.

   2

   L’espace de noms du ClusterLogForwarder CR doit être ouvert-logging.

   3

   Indiquez un nom pour la sortie.

   4

   Indiquez le type fluentdForward.

   5

   Indiquez l’URL et le port de l’instance Fluentd externe comme URL absolue valide. Il est possible d’utiliser le protocole tcp (non sécurisé) ou tls (TCP sécurisé). Lorsque le proxy à l’échelle du cluster utilisant l’annotation CIDR est activé, la sortie doit être un nom de serveur ou un FQDN, et non une adresse IP.

   6

   Lorsque vous utilisez un préfixe tls, vous devez spécifier le nom du secret requis par le point de terminaison pour la communication TLS. Le secret doit exister dans le projet openshift-logging et doit contenir une clé ca-bundle.crt qui pointe vers le certificat qu’il représente.

   7

   Facultatif : Spécifiez un nom pour le pipeline.

   8

   Indiquez les types de journaux à transmettre en utilisant le pipeline : application, infrastructure ou vérification.

   9

   Indiquez le nom de la sortie à utiliser lors de la transmission des journaux avec ce pipeline.

   10

   Facultatif : Spécifiez la sortie par défaut pour transmettre les journaux à l’instance interne Elasticsearch.

   11

   Facultatif: String. Il y a une ou plusieurs étiquettes à ajouter aux journaux.

   12

   Facultatif: Configurez plusieurs sorties pour transmettre les journaux à d’autres agrégateurs de journaux externes de tout type pris en charge:

   • C’est un nom pour décrire le pipeline.
   • L’entréeRefs est le type de journal à transmettre en utilisant le pipeline : application, infrastructure ou vérification.
   • La sortieRefs est le nom de la sortie à utiliser.
   • Facultatif: String. Il y a une ou plusieurs étiquettes à ajouter aux journaux.

2. Créer l’objet CR:

   $ oc create -f <file-name>.yaml

   Copy to Clipboard Toggle word wrap

Procédure

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

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: <log_forwarder_name> 

   1

   
     namespace: <log_forwarder_namespace> 

   2

   
   spec:
     serviceAccountName: <service_account_name> 

   3

   
     outputs:
      - name: rsyslog-east 

   4

   
        type: syslog 

   5

   
        syslog: 

   6

   
          facility: local0
          rfc: RFC3164
          payloadKey: message
          severity: informational
        url: 'tls://rsyslogserver.east.example.com:514' 

   7

   
        secret: 

   8

   
           name: syslog-secret
      - name: rsyslog-west
        type: syslog
        syslog:
         appName: myapp
         facility: user
         msgID: mymsg
         procID: myproc
         rfc: RFC5424
         severity: debug
        url: 'tcp://rsyslogserver.west.example.com:514'
     pipelines:
      - name: syslog-east 

   9

   
        inputRefs: 

   10

   
        - audit
        - application
        outputRefs: 

   11

   
        - rsyslog-east
        - default 

   12

   
        labels:
          secure: "true" 

   13

   
          syslog: "east"
      - name: syslog-west 

   14

   
        inputRefs:
        - infrastructure
        outputRefs:
        - rsyslog-west
        - default
        labels:
          syslog: "west"

   Copy to Clipboard Toggle word wrap

   1

   Dans les implémentations antérieures, le nom CR doit être instance. Dans les implémentations de transbordeur de journaux multiples, vous pouvez utiliser n’importe quel nom.

   2

   Dans les implémentations héritées, l’espace de noms CR doit être ouvert-logging. Dans les implémentations de transfert de journaux multiples, vous pouvez utiliser n’importe quel espace de noms.

   3

   Le nom de votre compte de service. Le compte de service n’est requis que dans les implémentations de transbordeur de journaux multiples si l’expéditeur de journaux n’est pas déployé dans l’espace de noms openshift-logging.

   4

   Indiquez un nom pour la sortie.

   5

   Indiquez le type de syslog.

   6

   Facultatif: Spécifiez les paramètres de syslog, énumérés ci-dessous.

   7

   Indiquez l’URL et le port de l’instance syslog externe. Il est possible d’utiliser le protocole udp (non sécurisé), tcp (non sécurisé) ou tls (TCP sécurisé). Lorsque le proxy à l’échelle du cluster utilisant l’annotation CIDR est activé, la sortie doit être un nom de serveur ou un FQDN, et non une adresse IP.

   8

   En utilisant un préfixe tls, vous devez spécifier le nom du secret requis par le point de terminaison pour la communication TLS. Le secret doit contenir une clé ca-bundle.crt qui pointe vers le certificat qu’il représente. Dans les implémentations héritées, le secret doit exister dans le projet d’exploitation en openshift.

   9

   Facultatif : Spécifiez un nom pour le pipeline.

   10

   Indiquez les types de journaux à transmettre en utilisant le pipeline : application, infrastructure ou vérification.

   11

   Indiquez le nom de la sortie à utiliser lors de la transmission des journaux avec ce pipeline.

   12

   Facultatif : Spécifiez la sortie par défaut pour transmettre les journaux à l’instance interne Elasticsearch.

   13

   Facultatif: String. Il y a une ou plusieurs étiquettes à ajouter aux journaux. Citez des valeurs comme "vrai" afin qu’elles soient reconnues comme des valeurs de chaîne, et non comme un booléen.

   14

   Facultatif: Configurez plusieurs sorties pour transmettre les journaux à d’autres agrégateurs de journaux externes de tout type pris en charge:

   • C’est un nom pour décrire le pipeline.
   • L’entréeRefs est le type de journal à transmettre en utilisant le pipeline : application, infrastructure ou vérification.
   • La sortieRefs est le nom de la sortie à utiliser.
   • Facultatif: String. Il y a une ou plusieurs étiquettes à ajouter aux journaux.

2. Créer l’objet CR:

   $ oc create -f <filename>.yaml

   Copy to Clipboard Toggle word wrap

Procédure

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

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: <log_forwarder_name> 

   1

   
     namespace: <log_forwarder_namespace> 

   2

   
   spec:
     serviceAccountName: <service_account_name> 

   3

   
     outputs:
      - name: app-logs 

   4

   
        type: kafka 

   5

   
        url: tls://kafka.example.devlab.com:9093/app-topic 

   6

   
        secret:
          name: kafka-secret 

   7

   
      - name: infra-logs
        type: kafka
        url: tcp://kafka.devlab2.example.com:9093/infra-topic 

   8

   
      - name: audit-logs
        type: kafka
        url: tls://kafka.qelab.example.com:9093/audit-topic
        secret:
           name: kafka-secret-qe
     pipelines:
      - name: app-topic 

   9

   
        inputRefs: 

   10

   
        - application
        outputRefs: 

   11

   
        - app-logs
        labels:
          logType: "application" 

   12

   
      - name: infra-topic 

   13

   
        inputRefs:
        - infrastructure
        outputRefs:
        - infra-logs
        labels:
          logType: "infra"
      - name: audit-topic
        inputRefs:
        - audit
        outputRefs:
        - audit-logs
        labels:
          logType: "audit"

   Copy to Clipboard Toggle word wrap

   1

   Dans les implémentations antérieures, le nom CR doit être instance. Dans les implémentations de transbordeur de journaux multiples, vous pouvez utiliser n’importe quel nom.

   2

   Dans les implémentations héritées, l’espace de noms CR doit être ouvert-logging. Dans les implémentations de transfert de journaux multiples, vous pouvez utiliser n’importe quel espace de noms.

   3

   Le nom de votre compte de service. Le compte de service n’est requis que dans les implémentations de transbordeur de journaux multiples si l’expéditeur de journaux n’est pas déployé dans l’espace de noms openshift-logging.

   4

   Indiquez un nom pour la sortie.

   5

   Indiquez le type kafka.

   6

   Indiquez l’URL et le port du courtier Kafka en tant qu’URL absolue valide, éventuellement avec un sujet spécifique. Il est possible d’utiliser le protocole tcp (non sécurisé) ou tls (TCP sécurisé). Lorsque le proxy à l’échelle du cluster utilisant l’annotation CIDR est activé, la sortie doit être un nom de serveur ou un FQDN, et non une adresse IP.

   7

   Lorsque vous utilisez un préfixe tls, vous devez spécifier le nom du secret requis par le point de terminaison pour la communication TLS. Le secret doit contenir une clé ca-bundle.crt qui pointe vers le certificat qu’il représente. Dans les implémentations héritées, le secret doit exister dans le projet d’exploitation en openshift.

   8

   Facultatif: Pour envoyer une sortie non sécurisée, utilisez un préfixe tcp devant l’URL. Également omettre la clé secrète et son nom de cette sortie.

   9

   Facultatif : Spécifiez un nom pour le pipeline.

   10

   Indiquez les types de journaux à transmettre en utilisant le pipeline : application, infrastructure ou vérification.

   11

   Indiquez le nom de la sortie à utiliser lors de la transmission des journaux avec ce pipeline.

   12

   Facultatif: String. Il y a une ou plusieurs étiquettes à ajouter aux journaux.

   13

   Facultatif: Configurez plusieurs sorties pour transmettre les journaux à d’autres agrégateurs de journaux externes de tout type pris en charge:

   • C’est un nom pour décrire le pipeline.
   • L’entréeRefs est le type de journal à transmettre en utilisant le pipeline : application, infrastructure ou vérification.
   • La sortieRefs est le nom de la sortie à utiliser.
   • Facultatif: String. Il y a une ou plusieurs étiquettes à ajouter aux journaux.

2. Facultatif: Pour transférer une seule sortie à plusieurs courtiers Kafka, spécifiez un éventail de courtiers Kafka comme indiqué dans l’exemple suivant:

   # ...
   spec:
     outputs:
     - name: app-logs
       type: kafka
       secret:
         name: kafka-secret-dev
       kafka:  

   1

   
         brokers: 

   2

   
           - tls://kafka-broker1.example.com:9093/
           - tls://kafka-broker2.example.com:9093/
         topic: app-topic 

   3

   
   # ...

   Copy to Clipboard Toggle word wrap

   1

   Indiquez une clé kafka qui a une clé de courtier et de sujet.

   2

   Faites appel à la clé des courtiers pour spécifier un éventail d’un ou plusieurs courtiers.

   3

   La clé de sujet permet de spécifier le sujet cible qui reçoit les journaux.

3. Appliquez le ClusterLogForwarder CR en exécutant la commande suivante:

   $ oc apply -f <filename>.yaml

   Copy to Clipboard Toggle word wrap

Procédure

1. Créez un fichier Secret YAML qui utilise les champs aws_access_key_id et aws_secret_access_key pour spécifier vos identifiants AWS codés base64. À titre d’exemple:

   apiVersion: v1
   kind: Secret
   metadata:
     name: cw-secret
     namespace: openshift-logging
   data:
     aws_access_key_id: QUtJQUlPU0ZPRE5ON0VYQU1QTEUK
     aws_secret_access_key: d0phbHJYVXRuRkVNSS9LN01ERU5HL2JQeFJmaUNZRVhBTVBMRUtFWQo=

   Copy to Clipboard Toggle word wrap

2. Créez le secret. À titre d’exemple:

   $ oc apply -f cw-secret.yaml

   Copy to Clipboard Toggle word wrap

3. Créez ou modifiez un fichier YAML qui définit l’objet ClusterLogForwarder CR. Dans le fichier, spécifiez le nom du secret. À titre d’exemple:

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: <log_forwarder_name> 

   1

   
     namespace: <log_forwarder_namespace> 

   2

   
   spec:
     serviceAccountName: <service_account_name> 

   3

   
     outputs:
      - name: cw 

   4

   
        type: cloudwatch 

   5

   
        cloudwatch:
          groupBy: logType 

   6

   
          groupPrefix: <group prefix> 

   7

   
          region: us-east-2 

   8

   
        secret:
           name: cw-secret 

   9

   
     pipelines:
       - name: infra-logs 

   10

   
         inputRefs: 

   11

   
           - infrastructure
           - audit
           - application
         outputRefs:
           - cw 

   12

   Copy to Clipboard Toggle word wrap

   1

   Dans les implémentations antérieures, le nom CR doit être instance. Dans les implémentations de transbordeur de journaux multiples, vous pouvez utiliser n’importe quel nom.

   2

   Dans les implémentations héritées, l’espace de noms CR doit être ouvert-logging. Dans les implémentations de transfert de journaux multiples, vous pouvez utiliser n’importe quel espace de noms.

   3

   Le nom de votre compte de service. Le compte de service n’est requis que dans les implémentations de transbordeur de journaux multiples si l’expéditeur de journaux n’est pas déployé dans l’espace de noms openshift-logging.

   4

   Indiquez un nom pour la sortie.

   5

   Indiquez le type de cloudwatch.

   6

   Facultatif: Spécifiez comment regrouper les journaux:

   • logType crée des groupes de journaux pour chaque type de journal.
   • namespaceName crée un groupe de journal pour chaque espace de noms d’application. Il crée également des groupes de journaux distincts pour l’infrastructure et les journaux d’audit.
   • namespaceUUID crée un nouveau groupe de journaux pour chaque espace de noms d’application UUID. Il crée également des groupes de journaux distincts pour l’infrastructure et les journaux d’audit.

   7

   Facultatif : Spécifiez une chaîne de caractères pour remplacer le préfixe par défaut d’infrastructureName dans les noms des groupes de journaux.

   8

   Indiquez la région AWS.

   9

   Indiquez le nom du secret qui contient vos identifiants AWS.

   10

   Facultatif : Spécifiez un nom pour le pipeline.

   11

   Indiquez les types de journaux à transmettre en utilisant le pipeline : application, infrastructure ou vérification.

   12

   Indiquez le nom de la sortie à utiliser lors de la transmission des journaux avec ce pipeline.

4. Créer l’objet CR:

   $ oc create -f <file-name>.yaml

   Copy to Clipboard Toggle word wrap

Procédure

1. Créer le compte AWS:

   1. Créez un fichier JSON de stratégie IAM avec le contenu suivant:

      {
      "Version": "2012-10-17",
      "Statement": [
          {
          "Effect": "Allow",
          "Action": [
            "logs:CreateLogGroup",
            "logs:CreateLogStream",
            "logs:DescribeLogGroups",
            "logs:DescribeLogStreams",
            "logs:PutLogEvents",
            "logs:PutRetentionPolicy"
          ],
          "Resource": "arn:aws:logs:*:*:*"
          }
        ]
      }

      Copy to Clipboard Toggle word wrap

   2. Créez un fichier JSON de confiance IAM avec le contenu suivant:

      {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Effect": "Allow",
            "Principal": {
              "Federated": "arn:aws:iam::<your_aws_account_id>:oidc-provider/<openshift_oidc_provider>" 

      1

      
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
              "StringEquals": {
                "<openshift_oidc_provider>:sub": "system:serviceaccount:openshift-logging:logcollector" 

      2

      
              }
            }
          }
        ]
      }

      Copy to Clipboard Toggle word wrap

      1

      Indiquez votre identifiant de compte AWS et le point de terminaison du fournisseur OpenShift OIDC. Obtenez le point de terminaison en exécutant la commande suivante:

      $ rosa describe cluster \
        -c $(oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{"\n"}') \
        -o yaml | awk '/oidc_endpoint_url/ {print $2}' | cut -d '/' -f 3,4

      Copy to Clipboard Toggle word wrap

      2

      Indiquez à nouveau le point de terminaison OpenShift OIDC.

   3. Créer le rôle de l’IAM:

      $ aws iam create-role
        --role-name “<your_rosa_cluster_name>-RosaCloudWatch” \
        --assume-role-policy-document file://<your_trust_file_name>.json \
        --query Role.Arn \
        --output text

      Copy to Clipboard Toggle word wrap

      Enregistrez la sortie. Dans les prochaines étapes, vous l’utiliserez.

   4. Créer la politique IAM:

      $ aws iam create-policy \
      --policy-name "RosaCloudWatch" \
      --policy-document file:///<your_policy_file_name>.json \
      --query Policy.Arn \
      --output text

      Copy to Clipboard Toggle word wrap

      Enregistrez la sortie. Dans les prochaines étapes, vous l’utiliserez.

   5. Attacher la politique de l’IAM au rôle de l’IAM:

      $ aws iam attach-role-policy \
       --role-name “<your_rosa_cluster_name>-RosaCloudWatch” \
       --policy-arn <policy_ARN> 

      1

      Copy to Clipboard Toggle word wrap

      1

      Remplace policy_ARN par la sortie que vous avez enregistrée lors de la création de la stratégie.

2. Créer un fichier Secret YAML pour le Red Hat OpenShift Logging Operator:

   apiVersion: v1
   kind: Secret
   metadata:
     name: cloudwatch-credentials
     namespace: openshift-logging
   stringData:
     credentials: |-
       [default]
       sts_regional_endpoints = regional
       role_arn: <role_ARN>  

   1

   
       web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token

   Copy to Clipboard Toggle word wrap

   1

   Il suffit de remplacer role_ARN par la sortie que vous avez enregistrée lors de la création du rôle.

3. Créer le secret:

   $ oc apply -f cloudwatch-credentials.yaml

   Copy to Clipboard Toggle word wrap

4. Créer ou modifier une ressource personnalisée ClusterLogForwarder:

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: <log_forwarder_name> 

   1

   
     namespace: <log_forwarder_namespace> 

   2

   
   spec:
     serviceAccountName: <service_account_name> 

   3

   
     outputs:
      - name: cw 

   4

   
        type: cloudwatch 

   5

   
        cloudwatch:
          groupBy: logType 

   6

   
          groupPrefix: <group prefix> 

   7

   
          region: us-east-2 

   8

   
        secret:
           name: <your_secret_name> 

   9

   
     pipelines:
       - name: to-cloudwatch 

   10

   
         inputRefs: 

   11

   
           - infrastructure
           - audit
           - application
         outputRefs:
           - cw 

   12

   Copy to Clipboard Toggle word wrap

   1

   Dans les implémentations antérieures, le nom CR doit être instance. Dans les implémentations de transbordeur de journaux multiples, vous pouvez utiliser n’importe quel nom.

   2

   Dans les implémentations héritées, l’espace de noms CR doit être ouvert-logging. Dans les implémentations de transfert de journaux multiples, vous pouvez utiliser n’importe quel espace de noms.

   3

   Le nom de votre compte de service. Le compte de service n’est requis que dans les implémentations de transbordeur de journaux multiples si l’expéditeur de journaux n’est pas déployé dans l’espace de noms openshift-logging.

   4

   Indiquez un nom pour la sortie.

   5

   Indiquez le type de cloudwatch.

   6

   Facultatif: Spécifiez comment regrouper les journaux:

   • logType crée des groupes de journaux pour chaque type de journal
   • namespaceName crée un groupe de journal pour chaque espace de noms d’application. Les journaux d’infrastructure et d’audit ne sont pas affectés, restant regroupés par logType.
   • namespaceUUID crée un nouveau groupe de journaux pour chaque espace de noms d’application UUID. Il crée également des groupes de journaux distincts pour l’infrastructure et les journaux d’audit.

   7

   Facultatif : Spécifiez une chaîne de caractères pour remplacer le préfixe par défaut d’infrastructureName dans les noms des groupes de journaux.

   8

   Indiquez la région AWS.

   9

   Indiquez le nom du secret que vous avez créé précédemment.

   10

   Facultatif : Spécifiez un nom pour le pipeline.

   11

   Indiquez les types de journaux à transmettre en utilisant le pipeline : application, infrastructure ou vérification.

   12

   Indiquez le nom de la sortie à utiliser lors de la transmission des journaux avec ce pipeline.