Chapitre 9. Collecte et transfert de journaux
9.1. À propos de la collecte et du transfert de journaux
Le Red Hat OpenShift Logging Operator déploie un collecteur basé sur la spécification de ressources ClusterLogForwarder. Il existe deux options de collecteur prises en charge par cet opérateur : l’ancien collectionneur Fluentd et le collecteur Vecteur.
Fluentd est déprécié et devrait être retiré dans une version ultérieure. Le Red Hat fournit des corrections de bogues et une prise en charge de cette fonctionnalité pendant le cycle de vie de la version actuelle, mais cette fonctionnalité ne reçoit plus d’améliorations. Comme alternative à Fluentd, vous pouvez utiliser Vector à la place.
9.1.1. Collection de journaux
Le collecteur de journaux est un jeu de démons qui déploie des pods sur chaque nœud dédié OpenShift pour collecter les logs des conteneurs et des nœuds.
Le collecteur de journaux utilise par défaut les sources suivantes:
- Journaux système et infrastructure générés par les messages journalisés du système d’exploitation, du temps d’exécution du conteneur et d’OpenShift Dedicated.
- /Var/log/containers/*.log pour tous les journaux de conteneurs.
Lorsque vous configurez le collecteur de journaux pour collecter les journaux d’audit, il les recueille à partir de /var/log/audit/audit.log.
Le collecteur de journaux recueille les journaux à partir de ces sources et les transmet en interne ou en externe en fonction de votre configuration de journalisation.
9.1.1.1. Les types de collecteurs de journaux
Le vecteur est un collecteur de journaux offert comme alternative à Fluentd pour l’enregistrement.
Configurez le type de collecteur de journalisation utilisé par votre cluster en modifiant la spécification de collecte de ressources personnalisées ClusterLogging (CR):
Exemple ClusterLogging CR qui configure Vector en tant que collecteur
apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: name: instance namespace: openshift-logging spec: collection: logs: type: vector vector: {} # ...
apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
name: instance
namespace: openshift-logging
spec:
collection:
logs:
type: vector
vector: {}
# ...
9.1.1.2. Limites de collecte des journaux
Les temps d’exécution du conteneur fournissent des informations minimales pour identifier la source des messages journaux : projet, nom de pod et ID du conteneur. Cette information ne suffit pas à identifier de manière unique la source des journaux. Lorsqu’une pod avec un nom et un projet est supprimée avant que le collecteur de journaux ne commence à traiter ses journaux, les informations provenant du serveur API, telles que les étiquettes et les annotations, pourraient ne pas être disponibles. Il n’y a peut-être pas de moyen de distinguer les messages de log d’un pod et de projeter ou de tracer les journaux jusqu’à leur source. Cette limitation signifie que la collecte et la normalisation des logs sont considérées comme les meilleurs efforts.
Les temps d’exécution des conteneurs disponibles fournissent des informations minimales pour identifier la source des messages journaux et ne garantissent pas que les messages de journal individuels uniques ou que ces messages puissent être tracés à leur source.
9.1.1.3. Caractéristiques du collecteur de journaux par type
Caractéristique | Fluentd | Le vecteur |
---|---|---|
Journaux de conteneurs d’applications | ✓ | ✓ |
Routage spécifique à l’application | ✓ | ✓ |
Routage spécifique à l’application par namespace | ✓ | ✓ |
Journaux de conteneurs infra | ✓ | ✓ |
Journaux de journaux infra | ✓ | ✓ |
Journaux d’audit d’API Kube | ✓ | ✓ |
Journaux d’audit d’API OpenShift | ✓ | ✓ |
Journaux d’audit Open Virtual Network (OVN) | ✓ | ✓ |
Caractéristique | Fluentd | Le vecteur |
---|---|---|
Certificats Elasticsearch | ✓ | ✓ |
Elasticsearch nom d’utilisateur / mot de passe | ✓ | ✓ |
Clés Amazon Cloudwatch | ✓ | ✓ |
Amazon Cloudwatch STS | ✓ | ✓ |
Certificats Kafka | ✓ | ✓ |
Kafka Nom d’utilisateur / mot de passe | ✓ | ✓ |
Kafka SASL | ✓ | ✓ |
Jeton au porteur Loki | ✓ | ✓ |
Caractéristique | Fluentd | Le vecteur |
---|---|---|
Le modèle de données VIAQ - app | ✓ | ✓ |
Le modèle de données VIAQ - infra | ✓ | ✓ |
Le modèle de données VIAQ - infra(journal) | ✓ | ✓ |
Le modèle de données VIAQ - Audit Linux | ✓ | ✓ |
Le modèle de données VIAQ - audit kube-apiserver | ✓ | ✓ |
Le modèle de données VIAQ - Audit d’API OpenShift | ✓ | ✓ |
Données VIAQ - OVN | ✓ | ✓ |
LogLevel Normalisation | ✓ | ✓ |
JSON parsing | ✓ | ✓ |
Indice structuré | ✓ | ✓ |
Détection d’erreurs multilignes | ✓ | ✓ |
Indices multiconteneurs / fractionnés | ✓ | ✓ |
Étiquettes aplaties | ✓ | ✓ |
Étiquettes statiques CLF | ✓ | ✓ |
Caractéristique | Fluentd | Le vecteur |
---|---|---|
Fluentd readlinelimit | ✓ | |
Le tampon Fluentd | ✓ | |
- chunklimitsize | ✓ | |
- totallimitsize | ✓ | |
- débordement | ✓ | |
- flushthreadcount | ✓ | |
- FlushMode | ✓ | |
- flushinterval | ✓ | |
- réessayer d’attendre | ✓ | |
- retrytype | ✓ | |
- retrymaxinterval | ✓ | |
- RetryTimeout | ✓ |
Caractéristique | Fluentd | Le vecteur |
---|---|---|
Les métriques | ✓ | ✓ |
Tableau de bord | ✓ | ✓ |
Alertes | ✓ | ✓ |
Caractéristique | Fluentd | Le vecteur |
---|---|---|
La prise en charge globale des proxys | ✓ | ✓ |
assistance x86 | ✓ | ✓ |
Le soutien d’ARM | ✓ | ✓ |
Le support IBM Power® | ✓ | ✓ |
Le support IBM Z® | ✓ | ✓ |
Assistance IPv6 | ✓ | ✓ |
Enregistrement de l’événement tampon | ✓ | |
Cluster déconnecté | ✓ | ✓ |
9.1.1.4. Les sorties du collecteur
Les extrants suivants sont pris en charge:
Caractéristique | Fluentd | Le vecteur |
---|---|---|
Elasticsearch v6-v8 | ✓ | ✓ |
Fluent vers l’avant | ✓ | |
À propos de Syslog RFC3164 | ✓ | ✓ (Enregistrement 5.7+) |
À propos de Syslog RFC5424 | ✓ | ✓ (Enregistrement 5.7+) |
Kafka | ✓ | ✓ |
Amazon Cloudwatch | ✓ | ✓ |
Amazon Cloudwatch STS | ✓ | ✓ |
Loki | ✓ | ✓ |
HTTP | ✓ | ✓ (Enregistrement 5.7+) |
Google Cloud Logging | ✓ | ✓ |
À propos de Splunk | ✓ (Enregistrement 5.6+) |
9.1.2. Envoi de journaux
Les administrateurs peuvent créer des ressources ClusterLogForwarder qui spécifient quels journaux sont recueillis, comment ils sont transformés et où ils sont transférés.
Les ressources ClusterLogForwarder peuvent être utilisées pour transférer des journaux de conteneurs, d’infrastructures et d’audits vers des points de terminaison spécifiques à l’intérieur ou à l’extérieur d’un cluster. La sécurité de la couche de transport (TLS) est prise en charge afin que les transmetteurs de journaux puissent être configurés pour envoyer des journaux en toute sécurité.
Les administrateurs peuvent également autoriser les autorisations RBAC qui définissent les comptes de service et les utilisateurs qui peuvent accéder et transmettre les types de journaux.
9.1.2.1. Implémentations de transfert journalier
Il existe deux implémentations de transfert de journaux disponibles: l’implémentation héritée et la fonction d’expéditeur multi log.
Le collecteur Vecteur seul est pris en charge pour une utilisation avec la fonction d’expéditeur multi log. Le collecteur Fluentd ne peut être utilisé qu’avec des implémentations héritées.
9.1.2.1.1. La mise en œuvre de l’héritage
Dans les implémentations héritées, vous ne pouvez utiliser qu’un seul transmetteur de journaux dans votre cluster. La ressource ClusterLogForwarder dans ce mode doit être nommée instance, et doit être créée dans l’espace de noms openshift-logging. La ressource ClusterLogForwarder nécessite également une ressource ClusterLogging correspondante nommée instance dans l’espace de noms openshift-logging.
9.1.2.1.2. Fonction d’expéditeur multi log
La fonction d’expéditeur multi log est disponible dans la journalisation 5.8 et ultérieure, et fournit les fonctionnalités suivantes:
- Les administrateurs peuvent contrôler quels utilisateurs sont autorisés à définir la collection de journaux et quels journaux ils sont autorisés à collecter.
- Les utilisateurs qui ont les autorisations requises sont en mesure de spécifier des configurations supplémentaires de collecte de journaux.
- Les administrateurs qui migrent du collecteur Fluentd déprécié vers le collecteur Vector peuvent déployer un nouveau transmetteur de journaux séparément de leur déploiement existant. Les transmetteurs de journaux existants et nouveaux peuvent fonctionner simultanément pendant la migration des charges de travail.
Dans les implémentations de transfert de journaux multiples, vous n’êtes pas tenu de créer une ressource ClusterLogging correspondante pour votre ressource ClusterLogForwarder. Il est possible de créer plusieurs ressources ClusterLogForwarder en utilisant n’importe quel nom, dans n’importe quel espace de noms, avec les exceptions suivantes:
- Il est impossible de créer une instance de ressource ClusterLogForwarder nommée instance dans l’espace de noms openshift-logging, car elle est réservée à un transmetteur de journaux qui prend en charge le flux de travail existant à l’aide du collecteur Fluentd.
- Il est impossible de créer une ressource ClusterLogForwarder nommée collector dans l’espace de noms openshift-logging, car cela est réservé au collectionneur.
9.1.2.2. Activer la fonction d’expéditeur multi log pour un cluster
Afin d’utiliser la fonction d’expéditeur multi log, vous devez créer un compte de service et des liaisons de rôle de cluster pour ce compte de service. Ensuite, vous pouvez consulter le compte de service dans la ressource ClusterLogForwarder pour contrôler les autorisations d’accès.
Afin de prendre en charge le transfert de journaux multiples dans des espaces de noms supplémentaires autres que l’espace de noms openshift, vous devez mettre à jour l’opérateur de journalisation Red Hat OpenShift pour regarder tous les espaces de noms. Cette fonctionnalité est prise en charge par défaut dans les nouvelles installations Red Hat OpenShift Logging Operator version 5.8.
9.1.2.2.1. Autoriser la collecte de journaux d’autorisations RBAC
Dans l’enregistrement 5.8 et plus tard, le Red Hat OpenShift Logging Operator fournit des rôles de cluster collect-audit-logs, collect-application-logs et collect-infrastructure-logs, qui permettent au collecteur de collecter des journaux d’audit, des journaux d’applications et des journaux d’infrastructure respectivement.
Les autorisations RBAC pour la collecte de journaux peuvent être autorisées en liant les rôles de cluster requis à un compte de service.
Conditions préalables
- Le Red Hat OpenShift Logging Operator est installé dans l’espace de noms openshift-logging.
- Il y a des autorisations d’administrateur.
Procédure
- Créez un compte de service pour le collecteur. Lorsque vous souhaitez écrire des journaux au stockage qui nécessite un jeton pour l’authentification, vous devez inclure un jeton dans le compte de service.
Lier les rôles de cluster appropriés au compte de service:
Exemple de commande de liaison
oc adm policy add-cluster-role-to-user <cluster_role_name> system:serviceaccount:<namespace_name>:<service_account_name>
$ oc adm policy add-cluster-role-to-user <cluster_role_name> system:serviceaccount:<namespace_name>:<service_account_name>
Copy to Clipboard Copied!