10.3. Configuration du log store LokiStack
Dans la documentation de journalisation, LokiStack fait référence à la combinaison prise en charge de la journalisation de Loki et de proxy Web avec Red Hat OpenShift Service sur l’intégration d’authentification AWS. Le proxy de LokiStack utilise Red Hat OpenShift Service sur l’authentification AWS pour appliquer la multi-tenance. Loki se réfère au log store comme étant soit le composant individuel, soit un magasin externe.
10.3.1. Créer un nouveau groupe pour le rôle d’utilisateur cluster-admin Copier lienLien copié sur presse-papiers!
La requête de journaux d’applications pour plusieurs espaces de noms en tant qu’utilisateur cluster-admin, où la somme totale des caractères de tous les espaces de noms dans le cluster est supérieure à 5120, entraîne l’erreur Parse erreur: taille d’entrée trop longue (XXXX > 5120). Afin de mieux contrôler l’accès aux connexions dans LokiStack, faites de l’utilisateur cluster-admin un membre du groupe cluster-admin. Lorsque le groupe cluster-admin n’existe pas, créez-le et ajoutez-y les utilisateurs souhaités.
La procédure suivante permet de créer un nouveau groupe pour les utilisateurs disposant d’autorisations cluster-admin.
Procédure
Entrez la commande suivante pour créer un nouveau groupe:
oc adm groups new cluster-admin
$ oc adm groups new cluster-admin
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Entrez la commande suivante pour ajouter l’utilisateur souhaité au groupe cluster-admin:
oc adm groups add-users cluster-admin <username>
$ oc adm groups add-users cluster-admin <username>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Entrez la commande suivante pour ajouter le rôle utilisateur cluster-admin au groupe:
oc adm policy add-cluster-role-to-group cluster-admin cluster-admin
$ oc adm policy add-cluster-role-to-group cluster-admin cluster-admin
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.3.2. Comportement LokiStack pendant le redémarrage des clusters Copier lienLien copié sur presse-papiers!
Dans la version de journalisation 5.8 et les versions plus récentes, lorsqu’un Red Hat OpenShift Service sur AWS cluster est redémarré, l’ingestion LokiStack et le chemin de requête continuent à fonctionner dans les ressources CPU et mémoire disponibles pour le nœud. Cela signifie qu’il n’y a pas de temps d’arrêt pour le LokiStack pendant Red Hat OpenShift Service sur les mises à jour du cluster AWS. Ce comportement est atteint en utilisant les ressources PodDisruptionBudget. L’opérateur Loki fournit les ressources de PodDisruptionBudget pour Loki, qui déterminent le nombre minimum de gousses qui doivent être disponibles par composant pour assurer des opérations normales dans certaines conditions.
10.3.3. Configurer Loki pour tolérer l’échec du nœud Copier lienLien copié sur presse-papiers!
Dans la journalisation 5.8 et les versions ultérieures, l’opérateur Loki prend en charge le réglage des règles anti-affinité de pod pour demander que les pods du même composant soient programmés sur différents nœuds disponibles dans le cluster.
Affinité est une propriété de pods qui contrôle les nœuds sur lesquels ils préfèrent être programmés. L’anti-affinité est une propriété de gousses qui empêche une gousse d’être programmée sur un nœud.
Dans Red Hat OpenShift Service sur AWS, l’affinité de pod et la pod anti-affinité vous permettent de limiter les nœuds que votre pod est éligible pour être programmé sur la base des étiquettes de valeur clé sur d’autres gousses.
L’opérateur définit les règles par défaut, podAntiAffinity préférées pour tous les composants Loki, qui comprend le compacteur, le distributeur, la passerelle, indexGateway, ingester, querier, queryFrontend et les composants de règle.
Il est possible de remplacer les paramètres podAntiAffinity préférés pour les composants Loki en configurant les paramètres requis dans le champ requisDuringSchedulingIgnoredDuringExecution:
Exemple de paramètres utilisateur pour le composant ingester
10.3.4. La réplication de données conscientes de zone Copier lienLien copié sur presse-papiers!
Dans l’enregistrement 5.8 et les versions ultérieures, l’opérateur Loki offre une prise en charge de la réplication des données conscientes de la zone grâce à des contraintes de propagation de la topologie des pod. L’activation de cette fonctionnalité améliore la fiabilité et les protections contre la perte de log en cas de défaillance d’une seule zone. Lors de la configuration de la taille de déploiement comme 1x.extra.petit, 1x.petit, ou 1x.medium, le champ réplication.factor est automatiquement réglé sur 2.
Afin d’assurer une réplication appropriée, vous devez avoir au moins autant de zones de disponibilité que le facteur de réplication le spécifie. Bien qu’il soit possible d’avoir plus de zones de disponibilité que le facteur de réplication, avoir moins de zones peut conduire à des échecs d’écriture. Chaque zone doit accueillir un nombre égal d’instances pour un fonctionnement optimal.
Exemple LokiStack CR avec réplication de zone activée
- 1
- Champ déprécié, les valeurs saisies sont écrasées par réplication.factor.
- 2
- Cette valeur est automatiquement définie lorsque la taille du déploiement est sélectionnée lors de la configuration.
- 3
- La différence maximale de nombre de pods entre deux domaines de topologie. La valeur par défaut est 1, et vous ne pouvez pas spécifier une valeur de 0.
- 4
- Définit des zones sous la forme d’une clé de topologie qui correspond à une étiquette de nœud.
10.3.4.1. La récupération des gousses Loki à partir de zones défaillantes Copier lienLien copié sur presse-papiers!
Dans Red Hat OpenShift Service sur AWS, une défaillance de zone se produit lorsque des ressources de zone de disponibilité spécifiques deviennent inaccessibles. Les zones de disponibilité sont des zones isolées du centre de données d’un fournisseur de cloud, visant à améliorer la redondance et la tolérance aux pannes. Lorsque votre Red Hat OpenShift Service sur AWS cluster n’est pas configuré pour gérer cela, une défaillance de zone peut entraîner une perte de service ou de données.
Les pods Loki font partie d’un StatefulSet, et ils sont livrés avec des revendications de volume persistants (PVC) fournies par un objet StorageClass. Chaque gousse Loki et ses PVC résident dans la même zone. Lorsqu’une défaillance de zone se produit dans un cluster, le contrôleur StatefulSet tente automatiquement de récupérer les pods affectés dans la zone défaillante.
La procédure suivante supprimera les PVC dans la zone défaillante et toutes les données qui y sont contenues. Afin d’éviter toute perte de données, le champ de facteur de réplication du LokiStack CR doit toujours être réglé à une valeur supérieure à 1 pour s’assurer que Loki réplique.
Conditions préalables
- Journalisation de la version 5.8 ou ultérieure.
- Assurez-vous que votre LokiStack CR a un facteur de réplication supérieur à 1.
- La défaillance de la zone détectée par le plan de contrôle, et les nœuds dans la zone défaillante sont marqués par l’intégration du fournisseur de cloud.
Le contrôleur StatefulSet tente automatiquement de rééchelonner les pods dans une zone défaillante. Étant donné que les PVC associés sont également dans la zone défaillante, le rééchelonnement automatique vers une zone différente ne fonctionne pas. Il faut supprimer manuellement les PVC dans la zone défaillante pour permettre une recréation réussie de l’étatique Loki Pod et de son PVC approvisionné dans la nouvelle zone.
Procédure
Énumérez les pods dans l’état en attente en exécutant la commande suivante:
oc get pods --field-selector status.phase==Pending -n openshift-logging
oc get pods --field-selector status.phase==Pending -n openshift-logging
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple oc get pods sortie
NAME READY STATUS RESTARTS AGE logging-loki-index-gateway-1 0/1 Pending 0 17m logging-loki-ingester-1 0/1 Pending 0 16m logging-loki-ruler-1 0/1 Pending 0 16m
NAME READY STATUS RESTARTS AGE
1 logging-loki-index-gateway-1 0/1 Pending 0 17m logging-loki-ingester-1 0/1 Pending 0 16m logging-loki-ruler-1 0/1 Pending 0 16m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Ces gousses sont en attente parce que leurs PVC correspondants sont dans la zone défaillante.
Énumérez les PVC en attente d’état en exécutant la commande suivante:
oc get pvc -o=json -n openshift-logging | jq '.items[] | select(.status.phase == "Pending") | .metadata.name' -r
oc get pvc -o=json -n openshift-logging | jq '.items[] | select(.status.phase == "Pending") | .metadata.name' -r
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple oc obtenir la sortie pvc
storage-logging-loki-index-gateway-1 storage-logging-loki-ingester-1 wal-logging-loki-ingester-1 storage-logging-loki-ruler-1 wal-logging-loki-ruler-1
storage-logging-loki-index-gateway-1 storage-logging-loki-ingester-1 wal-logging-loki-ingester-1 storage-logging-loki-ruler-1 wal-logging-loki-ruler-1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Effacer le(s) PVC(s) pour un pod en exécutant la commande suivante:
oc delete pvc __<pvc_name>__ -n openshift-logging
oc delete pvc __<pvc_name>__ -n openshift-logging
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ensuite, supprimez le(s) pod(s) en exécutant la commande suivante:
oc delete pod __<pod_name>__ -n openshift-logging
oc delete pod __<pod_name>__ -n openshift-logging
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Lorsque ces objets ont été supprimés avec succès, ils doivent être automatiquement reprogrammés dans une zone disponible.
10.3.4.1.1. Dépannage PVC dans un état de terminaison Copier lienLien copié sur presse-papiers!
Les PVC peuvent être suspendus à l’état de terminaison sans être supprimés, si les finalisateurs de métadonnées PVC sont réglés sur kubernetes.io/pv-protection. Le retrait des finalisateurs devrait permettre aux PVC de supprimer avec succès.
Enlevez le finalisateur pour chaque PVC en exécutant la commande ci-dessous, puis réessayez la suppression.
oc patch pvc __<pvc_name>__ -p '{"metadata":{"finalizers":null}}' -n openshift-logging
oc patch pvc __<pvc_name>__ -p '{"metadata":{"finalizers":null}}' -n openshift-logging
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.3.5. Accès grainé fin pour les bûches Loki Copier lienLien copié sur presse-papiers!
Dans l’enregistrement 5.8 et plus tard, l’opérateur de journalisation Red Hat OpenShift n’accorde pas à tous les utilisateurs l’accès aux journaux par défaut. En tant qu’administrateur, vous devez configurer l’accès de vos utilisateurs à moins que l’opérateur n’ait été mis à niveau et que des configurations antérieures ne soient en place. En fonction de votre configuration et de votre besoin, vous pouvez configurer l’accès au grain fin aux logs en utilisant les éléments suivants:
- Groupe de politiques à grande échelle
- Domaines d’application de l’espace de noms
- Création de groupes d’administrateurs personnalisés
En tant qu’administrateur, vous devez créer les liaisons de rôle et les liaisons de rôle de cluster appropriées à votre déploiement. Le Red Hat OpenShift Logging Operator fournit les rôles de cluster suivants:
- cluster-logging-application-view autorise la lecture des journaux des applications.
- cluster-logging-infrastructure-view donne l’autorisation de lire les journaux d’infrastructure.
- cluster-logging-audit-view donne l’autorisation de lire les journaux d’audit.
Lorsque vous avez mis à niveau à partir d’une version précédente, un cluster supplémentaire logging-application-logs-lecteur de rôle et la liaison de rôle de cluster associé logging-all-authenticated-application-logs-lecteur fournit une rétrocompatibilité, permettant à tout utilisateur authentifié d’accéder à la lecture dans leurs espaces de noms.
Les utilisateurs ayant accès par namespace doivent fournir un espace de noms lors de l’interrogation des journaux des applications.
10.3.5.1. Accès large en cluster Copier lienLien copié sur presse-papiers!
Les ressources de liaison des rôles de cluster référencent les rôles de cluster, et définissent les autorisations de cluster large.
Exemple ClusterRoleBinding
10.3.5.2. Accès espacement de nom Copier lienLien copié sur presse-papiers!
Les ressources RoleBinding peuvent être utilisées avec les objets ClusterRole pour définir l’espace de noms pour lequel un utilisateur ou un groupe a accès aux journaux.
Exemple de rôleBinding
- 1
- Indique l’espace de noms auquel s’applique le RoleBinding.
10.3.5.3. Accès au groupe administrateur personnalisé Copier lienLien copié sur presse-papiers!
Lorsque vous avez un déploiement important avec plusieurs utilisateurs qui nécessitent des autorisations plus larges, vous pouvez créer un groupe personnalisé à l’aide du champ adminGroup. Les utilisateurs qui sont membres de tout groupe spécifié dans le champ adminGroups du LokiStack CR sont considérés comme des administrateurs.
Les utilisateurs administrateurs ont accès à tous les journaux d’applications dans tous les espaces de noms, s’ils reçoivent également le rôle cluster-logging-application-view.
Exemple LokiStack CR
10.3.7. Dépannage des erreurs de limite de taux Loki Copier lienLien copié sur presse-papiers!
Lorsque l’API Log Forwarder transmet un grand bloc de messages qui dépasse la limite de taux à Loki, Loki génère des erreurs de limite de débit (429).
Ces erreurs peuvent se produire pendant le fonctionnement normal. À titre d’exemple, lors de l’ajout de la journalisation à un cluster qui possède déjà certains journaux, des erreurs de limite de taux peuvent se produire pendant que la journalisation tente d’ingérer toutes les entrées de journal existantes. Dans ce cas, si le taux d’ajout de nouveaux journaux est inférieur à la limite de taux totale, les données historiques sont finalement ingérées, et les erreurs de limite de taux sont résolues sans nécessiter l’intervention de l’utilisateur.
Dans les cas où les erreurs de limite de taux continuent de se produire, vous pouvez résoudre le problème en modifiant la ressource personnalisée LokiStack (CR).
Le LokiStack CR n’est pas disponible sur Grafana-hosted Loki. Cette rubrique ne s’applique pas aux serveurs Loki hébergés par Grafana.
Les conditions
- L’API Log Forwarder est configurée pour transférer les journaux vers Loki.
Le système envoie un bloc de messages de plus de 2 Mo à Loki. À titre d’exemple:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Après avoir entré les journaux oc -n openshift-logging -l component=collector, les journaux collecteurs de votre cluster affichent une ligne contenant l’un des messages d’erreur suivants:
429 Too Many Requests Ingestion rate limit exceeded
429 Too Many Requests Ingestion rate limit exceeded
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de message d’erreur vectoriel
2023-08-25T16:08:49.301780Z WARN sink{component_kind="sink" component_id=default_loki_infra component_type=loki component_name=default_loki_infra}: vector::sinks::util::retries: Retrying after error. error=Server responded with an error: 429 Too Many Requests internal_log_rate_limit=true
2023-08-25T16:08:49.301780Z WARN sink{component_kind="sink" component_id=default_loki_infra component_type=loki component_name=default_loki_infra}: vector::sinks::util::retries: Retrying after error. error=Server responded with an error: 429 Too Many Requests internal_log_rate_limit=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de message d’erreur Fluentd
2023-08-30 14:52:15 +0000 [warn]: [default_loki_infra] failed to flush the buffer. retry_times=2 next_retry_time=2023-08-30 14:52:19 +0000 chunk="604251225bf5378ed1567231a1c03b8b" error_class=Fluent::Plugin::LokiOutput::LogPostError error="429 Too Many Requests Ingestion rate limit exceeded for user infrastructure (limit: 4194304 bytes/sec) while attempting to ingest '4082' lines totaling '7820025' bytes, reduce log volume or contact your Loki administrator to see if the limit can be increased\n"
2023-08-30 14:52:15 +0000 [warn]: [default_loki_infra] failed to flush the buffer. retry_times=2 next_retry_time=2023-08-30 14:52:19 +0000 chunk="604251225bf5378ed1567231a1c03b8b" error_class=Fluent::Plugin::LokiOutput::LogPostError error="429 Too Many Requests Ingestion rate limit exceeded for user infrastructure (limit: 4194304 bytes/sec) while attempting to ingest '4082' lines totaling '7820025' bytes, reduce log volume or contact your Loki administrator to see if the limit can be increased\n"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow L’erreur est également visible à l’extrémité de réception. À titre d’exemple, dans la pod LokiStack ingester:
Exemple de message d’erreur Loki ingester
level=warn ts=2023-08-30T14:57:34.155592243Z caller=grpc_logging.go:43 duration=1.434942ms method=/logproto.Pusher/Push err="rpc error: code = Code(429) desc = entry with timestamp 2023-08-30 14:57:32.012778399 +0000 UTC ignored, reason: 'Per stream rate limit exceeded (limit: 3MB/sec) while attempting to ingest for stream
level=warn ts=2023-08-30T14:57:34.155592243Z caller=grpc_logging.go:43 duration=1.434942ms method=/logproto.Pusher/Push err="rpc error: code = Code(429) desc = entry with timestamp 2023-08-30 14:57:32.012778399 +0000 UTC ignored, reason: 'Per stream rate limit exceeded (limit: 3MB/sec) while attempting to ingest for stream
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Procédure
Actualisez les champs ingestionBurstSize et ingestionRate dans le LokiStack CR:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Le champ ingestionBurstSize définit la taille maximale de l’échantillon par distributeur en MB. Cette valeur est une limite dure. Définissez cette valeur sur au moins la taille maximale des logs attendue dans une seule requête push. Les demandes uniques qui sont plus grandes que la valeur d’ingestionBurstSize ne sont pas autorisées.
- 2
- Le champ ingestionRate est une limite molle sur la quantité maximale d’échantillons ingérés par seconde en MB. Les erreurs de limite de taux se produisent si le taux de logs dépasse la limite, mais le collecteur retries en envoyant les journaux. Aussi longtemps que la moyenne totale est inférieure à la limite, le système récupère et les erreurs sont résolues sans intervention de l’utilisateur.
10.3.8. Configurer Loki pour tolérer l’échec de la création de la liste de membres Copier lienLien copié sur presse-papiers!
Dans un cluster OpenShift, les administrateurs utilisent généralement une plage de réseau IP non privée. En conséquence, la configuration de la liste de membres LokiStack échoue parce que, par défaut, elle utilise uniquement des réseaux IP privés.
En tant qu’administrateur, vous pouvez sélectionner le réseau pod pour la configuration de la liste de membres. Il est possible de modifier le LokiStack CR pour utiliser le podIP dans la spécification hashRing. Afin de configurer le LokiStack CR, utilisez la commande suivante:
oc patch LokiStack logging-loki -n openshift-logging --type=merge -p '{"spec": {"hashRing":{"memberlist":{"instanceAddrType":"podIP","type": "memberlist"}}}}'
$ oc patch LokiStack logging-loki -n openshift-logging --type=merge -p '{"spec": {"hashRing":{"memberlist":{"instanceAddrType":"podIP","type": "memberlist"}}}}'
Exemple LokiStack pour inclure podIP