Chapitre 10. Transférer les journaux vers des systèmes de journalisation tiers externes

Pour envoyer des journaux à des points d'extrémité spécifiques à l'intérieur et à l'extérieur de votre cluster OpenShift Container Platform, vous spécifiez une combinaison de outputs et pipelines dans une ressource personnalisée (CR) ClusterLogForwarder. Vous pouvez également utiliser inputs pour transmettre les journaux d'application associés à un projet spécifique à un point de terminaison. L'authentification est fournie par un objet Kubernetes Secret.

Il convient de noter ce qui suit :

L'exemple suivant transfère les journaux d'audit vers une instance Elasticsearch externe sécurisée, les journaux d'infrastructure vers une instance Elasticsearch externe non sécurisée, les journaux d'application vers un courtier Kafka et les journaux d'application du projet my-apps-logs vers l'instance Elasticsearch interne.

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: instance 1
  namespace: openshift-logging 2
spec:
  outputs:
   - name: elasticsearch-secure 3
     type: "elasticsearch"
     url: https://elasticsearch.secure.com:9200
     secret:
        name: elasticsearch
   - name: elasticsearch-insecure 4
     type: "elasticsearch"
     url: http://elasticsearch.insecure.com:9200
   - name: kafka-app 5
     type: "kafka"
     url: tls://kafka.secure.com:9093/app-topic
  inputs: 6
   - name: my-app-logs
     application:
        namespaces:
        - my-project
  pipelines:
   - name: audit-logs 7
     inputRefs:
      - audit
     outputRefs:
      - elasticsearch-secure
      - default
     parse: json 8
     labels:
       secure: "true" 9
       datacenter: "east"
   - name: infrastructure-logs 10
     inputRefs:
      - infrastructure
     outputRefs:
      - elasticsearch-insecure
     labels:
       datacenter: "west"
   - name: my-app 11
     inputRefs:
      - my-app-logs
     outputRefs:
      - default
   - inputRefs: 12
      - application
     outputRefs:
      - kafka-app
     labels:
       datacenter: "south"

Gestion des journaux Fluentd lorsque l'agrégateur de journaux externe n'est pas disponible

Si votre agrégateur de logs externe devient indisponible et ne peut pas recevoir les logs, Fluentd continue à collecter les logs et les stocke dans un tampon. Lorsque l'agrégateur de logs devient disponible, la transmission des logs reprend, y compris les logs mis en mémoire tampon. Si le tampon se remplit complètement, Fluentd arrête de collecter les logs. OpenShift Container Platform fait tourner les logs et les supprime. Vous ne pouvez pas ajuster la taille du tampon ou ajouter une revendication de volume persistant (PVC) à l'ensemble de démon Fluentd ou aux pods.

Clés d'autorisation prises en charge

Les types de clés les plus courants sont fournis ici. Certains types de sortie prennent en charge des clés spécialisées supplémentaires, documentées par le champ de configuration spécifique à la sortie. Toutes les clés secrètes sont facultatives. Activez les fonctions de sécurité que vous souhaitez en définissant les clés correspondantes. Vous êtes responsable de la création et de la maintenance de toutes les configurations supplémentaires que les destinations externes pourraient exiger, telles que les clés et les secrets, les comptes de service, les ouvertures de port ou la configuration globale du proxy. Open Shift Logging n'essaiera pas de vérifier une incompatibilité entre les combinaisons d'autorisation.

$ oc create secret generic -n openshift-logging <my-secret> \
 --from-file=tls.key=<your_key_file>
 --from-file=tls.crt=<your_crt_file>
 --from-file=ca-bundle.crt=<your_bundle_file>
 --from-literal=username=<your_username>
 --from-literal=password=<your_password>