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.

Important

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

  1. Entrez la commande suivante pour créer un nouveau groupe:

    $ oc adm groups new cluster-admin
    Copy to Clipboard Toggle word wrap
  2. Entrez la commande suivante pour ajouter l’utilisateur souhaité au groupe cluster-admin:

    $ oc adm groups add-users cluster-admin <username>
    Copy to Clipboard Toggle word wrap
  3. 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
    Copy to Clipboard Toggle word wrap

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

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

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    ingester:
      podAntiAffinity:
      # ...
        requiredDuringSchedulingIgnoredDuringExecution: 
1

        - labelSelector:
            matchLabels: 
2

              app.kubernetes.io/component: ingester
          topologyKey: kubernetes.io/hostname
# ...
Copy to Clipboard Toggle word wrap

1
La strophe pour définir une règle requise.
2
La paire clé-valeur (étiquette) qui doit être assortie pour appliquer la règle.

10.3.4. La réplication de données conscientes de zone

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

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
 name: logging-loki
 namespace: openshift-logging
spec:
 replicationFactor: 2 
1

 replication:
   factor: 2 
2

   zones:
   -  maxSkew: 1 
3

      topologyKey: topology.kubernetes.io/zone 
4
Copy to Clipboard Toggle word wrap

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.

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.

Avertissement

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

  1. É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
    Copy to Clipboard Toggle word wrap

    Exemple oc get pods sortie

    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 Toggle word wrap

    1
    Ces gousses sont en attente parce que leurs PVC correspondants sont dans la zone défaillante.
  2. É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
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

  3. Effacer le(s) PVC(s) pour un pod en exécutant la commande suivante:

    oc delete pvc __<pvc_name>__  -n openshift-logging
    Copy to Clipboard Toggle word wrap
  4. Ensuite, supprimez le(s) pod(s) en exécutant la commande suivante:

    oc delete pod __<pod_name>__  -n openshift-logging
    Copy to Clipboard Toggle word wrap

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

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.

  1. 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
    Copy to Clipboard Toggle word wrap

10.3.5. Accès grainé fin pour les bûches Loki

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.

Note

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

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

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: logging-all-application-logs-reader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-logging-application-view 
1

subjects: 
2

- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io
Copy to Clipboard Toggle word wrap

1
D’autres ClusterRoles sont cluster-logging-infrastructure-view, et cluster-logging-audit-view.
2
Indique les utilisateurs ou les groupes auxquels s’applique cet objet.

10.3.5.2. Accès espacement de nom

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

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: allow-read-logs
  namespace: log-test-0 
1

roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-logging-application-view
subjects:
- kind: User
  apiGroup: rbac.authorization.k8s.io
  name: testuser-0
Copy to Clipboard Toggle word wrap

1
Indique l’espace de noms auquel s’applique le RoleBinding.

10.3.5.3. Accès au groupe administrateur personnalisé

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

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  tenants:
    mode: openshift-logging 
1

    openshift:
      adminGroups: 
2

      - cluster-admin
      - custom-admin-group 
3
Copy to Clipboard Toggle word wrap

1
Les groupes d’administrateurs personnalisés ne sont disponibles que dans ce mode.
2
Entrer une valeur de liste vide [] pour ce champ désactive les groupes d’administrateurs.
3
Remplace les groupes par défaut (système:cluster-admins, cluster-admin, dédié-admin)

10.3.7. Dépannage des erreurs de limite de taux Loki

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

Important

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:

    "values":[["1630410392689800468","{\"kind\":\"Event\",\"apiVersion\":\
    .......
    ......
    ......
    ......
    \"received_at\":\"2021-08-31T11:46:32.800278+00:00\",\"version\":\"1.7.4 1.6.0\"}},\"@timestamp\":\"2021-08-31T11:46:32.799692+00:00\",\"viaq_index_name\":\"audit-write\",\"viaq_msg_id\":\"MzFjYjJkZjItNjY0MC00YWU4LWIwMTEtNGNmM2E5ZmViMGU4\",\"log_type\":\"audit\"}"]]}]}
    Copy to Clipboard Toggle word wrap
  • 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
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

    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"
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

Procédure

  • Actualisez les champs ingestionBurstSize et ingestionRate dans le LokiStack CR:

    apiVersion: loki.grafana.com/v1
    kind: LokiStack
    metadata:
      name: logging-loki
      namespace: openshift-logging
    spec:
      limits:
        global:
          ingestion:
            ingestionBurstSize: 16 
    1
    
            ingestionRate: 8 
    2
    
    # ...
    Copy to Clipboard Toggle word wrap
    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.

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"}}}}'
Copy to Clipboard Toggle word wrap

Exemple LokiStack pour inclure podIP

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  hashRing:
    type: memberlist
    memberlist:
      instanceAddrType: podIP
# ...
Copy to Clipboard Toggle word wrap

Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat