1.5. 使用 LokiStack 存储日志


您可以配置 LokiStack CR 来存储应用程序、审计和基础架构相关的日志。

Loki 是一个可横向扩展的、高度可用、多租户日志聚合系统,作为 Red Hat OpenShift 的日志记录的 GA 日志存储,可以使用 OpenShift Observability UI 视觉化。OpenShift Logging 提供的 Loki 配置是一个短期日志存储,旨在让用户使用收集的日志执行快速故障排除。为此,Loki 的 Red Hat OpenShift 配置的日志记录具有短期存储,并针对非常最新的查询进行了优化。

重要

对于长期存储或长时间查询,用户应查找其集群外部的日志存储。Loki 大小只针对短期存储(最多 30 天)进行了测试并被支持。

1.5.1. 先决条件

  • 已使用 CLI 或 Web 控制台安装 Loki Operator。
  • 在同一命名空间中有一个 serviceAccount,您可以在其中创建 ClusterLogForwarder
  • serviceAccount 被分配了 collect-audit-logscollect-application-logscollect-infrastructure-logs 集群角色。

1.5.2. 核心设置和配置

基于角色的访问控制、基本监控和 pod 放置来部署 Loki。

1.5.3. 授权 LokiStack 规则 RBAC 权限

管理员可以允许用户通过将集群角色绑定到 username 来创建和管理自己的警报和记录规则。集群角色定义为 ClusterRole 对象,其中包含用户所需的基于角色的访问控制(RBAC)权限。

LokiStack 有以下用于警报和记录规则的集群角色:

运行名称描述

alertingrules.loki.grafana.com-v1-admin

具有此角色的用户具有管理级别访问权限来管理警报规则。此集群角色授予在 loki.grafana.com/v1 API 组中创建、读取、更新、删除、列出和监视 AlertingRule 资源的权限。

alertingrules.loki.grafana.com-v1-crdview

具有此角色的用户可以查看与 loki.grafana.com/v1 API 组中的 AlertingRule 资源相关的自定义资源定义(CRD)的定义,但没有修改或管理这些资源的权限。

alertingrules.loki.grafana.com-v1-edit

具有此角色的用户有权创建、更新和删除 AlertingRule 资源。

alertingrules.loki.grafana.com-v1-view

具有此角色的用户可以读取 loki.grafana.com/v1 API 组中的 AlertingRule 资源。它们可以检查现有警报规则的配置、标签和注解,但不能对它们进行任何修改。

recordingrules.loki.grafana.com-v1-admin

具有此角色的用户具有管理记录规则的管理级别访问权限。此集群角色授予在 loki.grafana.com/v1 API 组中创建、读取、更新、删除、列出和监视 RecordingRule 资源的权限。

recordingrules.loki.grafana.com-v1-crdview

具有此角色的用户可以查看与 loki.grafana.com/v1 API 组中的 RecordingRule 资源相关的自定义资源定义(CRD)的定义,但没有修改或管理这些资源的权限。

recordingrules.loki.grafana.com-v1-edit

具有此角色的用户有权创建、更新和删除 RecordingRule 资源。

recordingrules.loki.grafana.com-v1-view

具有此角色的用户可以读取 loki.grafana.com/v1 API 组中的 RecordingRule 资源。它们可以检查现有警报规则的配置、标签和注解,但不能对它们进行任何修改。

1.5.3.1. 例子

要为用户应用集群角色,您必须将现有集群角色绑定到特定用户名。

集群角色可以是集群或命名空间范围,具体取决于您使用的角色绑定。使用 RoleBinding 对象时,如使用 oc adm policy add-role-to-user 命令时,集群角色仅适用于指定的命名空间。当使用 ClusterRoleBinding 对象时,如使用 oc adm policy add-cluster-role-to-user 命令时,集群角色会应用到集群中的所有命名空间。

以下示例命令为指定用户在集群中的特定命名空间中创建、读取、更新和删除(CRUD)权限:

特定命名空间中警报规则 CRUD 权限的集群角色绑定命令示例

$ oc adm policy add-role-to-user alertingrules.loki.grafana.com-v1-admin -n <namespace> <username>

以下命令为所有命名空间中的警报规则授予指定用户管理员权限:

管理员权限的集群角色绑定命令示例

$ oc adm policy add-cluster-role-to-user alertingrules.loki.grafana.com-v1-admin <username>

1.5.4. 使用 Loki 创建基于日志的警报规则

AlertingRule CR 包含一组规格和 webhook 验证定义,用于声明单个 LokiStack 实例的警报规则组。另外,webhook 验证定义支持规则验证条件:

  • 如果 AlertingRule CR 包含无效的 interval 周期,则它是一个无效的警报规则
  • 如果 AlertingRule CR 包含无效的 for 周期,则它是一个无效的警报规则
  • 如果 AlertingRule CR 包含无效的 LogQL expr,则它是一个无效的警报规则。
  • 如果 AlertingRule CR 包含两个同名的组,则它是一个无效的警报规则。
  • 如果以上都不适用,则警报规则被视为有效。
表 1.2. AlertingRule 定义
租户类型AlertingRule CR 的有效命名空间

application

<your_application_namespace>

audit

openshift-logging

infrastructure

openshift-/*, kube-/\*, default

流程

  1. 创建 AlertingRule 自定义资源 (CR):

    基础架构 AlertingRule CR 示例

      apiVersion: loki.grafana.com/v1
      kind: AlertingRule
      metadata:
        name: loki-operator-alerts
        namespace: openshift-operators-redhat 1
        labels: 2
          openshift.io/<label_name>: "true"
      spec:
        tenantID: "infrastructure" 3
        groups:
          - name: LokiOperatorHighReconciliationError
            rules:
              - alert: HighPercentageError
                expr: | 4
                  sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"} |= "error" [1m])) by (job)
                    /
                  sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"}[1m])) by (job)
                    > 0.01
                for: 10s
                labels:
                  severity: critical 5
                annotations:
                  summary: High Loki Operator Reconciliation Errors 6
                  description: High Loki Operator Reconciliation Errors 7

    1
    创建此 AlertingRule CR 的命名空间必须具有与 LokiStack spec.rules.namespaceSelector 定义匹配的标签。
    2
    labels 块必须与 LokiStack spec.rules.selector 定义匹配。
    3
    infrastructure 租户的 AlertingRule CR 只在 openshift-*, kube-\*, 或 default 命名空间中被支持。
    4
    kubernetes_namespace_name: 的值必须与 metadata.namespace 的值匹配。
    5
    此必需字段的值必须是 criticalwarninginfo
    6
    这个字段是必须的。
    7
    这个字段是必须的。

    应用程序 AlertingRule CR 示例

      apiVersion: loki.grafana.com/v1
      kind: AlertingRule
      metadata:
        name: app-user-workload
        namespace: app-ns 1
        labels: 2
          openshift.io/<label_name>: "true"
      spec:
        tenantID: "application"
        groups:
          - name: AppUserWorkloadHighError
            rules:
              - alert:
                expr: | 3
                  sum(rate({kubernetes_namespace_name="app-ns", kubernetes_pod_name=~"podName.*"} |= "error" [1m])) by (job)
                for: 10s
                labels:
                  severity: critical 4
                annotations:
                  summary:  5
                  description:  6

    1
    创建此 AlertingRule CR 的命名空间必须具有与 LokiStack spec.rules.namespaceSelector 定义匹配的标签。
    2
    labels 块必须与 LokiStack spec.rules.selector 定义匹配。
    3
    kubernetes_namespace_name: 的值必须与 metadata.namespace 的值匹配。
    4
    此必需字段的值必须是 criticalwarninginfo
    5
    此必需字段的值是规则的摘要。
    6
    此必填字段的值是规则的详细描述。
  2. 应用 AlertingRule CR:

    $ oc apply -f <filename>.yaml

1.5.5. 配置 Loki 以容许 memberlist 创建失败

在 OpenShift Container Platform 集群中,管理员通常使用非专用 IP 网络范围。因此,Loki memberlist 配置会失败,因为默认情况下,它只使用私有 IP 网络。

作为管理员,您可以为 memberlist 配置选择 pod 网络。您可以修改 LokiStack 自定义资源(CR)以使用 hashRing spec 中的 podIP 地址。要配置 LokiStack CR,请使用以下命令:

$ oc patch LokiStack logging-loki -n openshift-logging  --type=merge -p '{"spec": {"hashRing":{"memberlist":{"instanceAddrType":"podIP"},"type":"memberlist"}}}'

LokiStack 示例,使其包含 podIP

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  hashRing:
    type: memberlist
    memberlist:
      instanceAddrType: podIP
# ...

1.5.6. 使用 Loki 启用基于流的保留

您可以根据日志流配置保留策略。这些规则可全局设置,可以是每个租户,或两者。如果同时配置这两个,则租户规则会在全局规则之前应用。

重要

如果没有在 s3 存储桶或 LokiStack 自定义资源 (CR) 中定义保留周期,则不会修剪日志,它们会永久保留在 s3 存储桶中,这可能会填满 s3 存储。

注意

建议采用 schema v13。

流程

  1. 创建 LokiStack CR:

    • 全局启用基于流的保留,如下例所示:

      AWS 的基于流的全局保留示例

      apiVersion: loki.grafana.com/v1
      kind: LokiStack
      metadata:
        name: logging-loki
        namespace: openshift-logging
      spec:
        limits:
         global: 1
            retention: 2
              days: 20
              streams:
              - days: 4
                priority: 1
                selector: '{kubernetes_namespace_name=~"test.+"}' 3
              - days: 1
                priority: 1
                selector: '{log_type="infrastructure"}'
        managementState: Managed
        replicationFactor: 1
        size: 1x.small
        storage:
          schemas:
          - effectiveDate: "2020-10-11"
            version: v13
          secret:
            name: logging-loki-s3
            type: aws
        storageClassName: gp3-csi
        tenants:
          mode: openshift-logging

      1
      为所有日志流设置保留策略。注: 此字段不会影响存储在对象存储中的保留周期。
      2
      当此块被添加到 CR 时,集群中会启用保留。
      3
      包含用于定义日志 stream.spec: limits 的 LogQL 查询
    • 根据租户启用基于流的保留,如下例所示:

      AWS 的基于流的基于流的保留示例

      apiVersion: loki.grafana.com/v1
      kind: LokiStack
      metadata:
        name: logging-loki
        namespace: openshift-logging
      spec:
        limits:
          global:
            retention:
              days: 20
          tenants: 1
            application:
              retention:
                days: 1
                streams:
                  - days: 4
                    selector: '{kubernetes_namespace_name=~"test.+"}' 2
            infrastructure:
              retention:
                days: 5
                streams:
                  - days: 1
                    selector: '{kubernetes_namespace_name=~"openshift-cluster.+"}'
        managementState: Managed
        replicationFactor: 1
        size: 1x.small
        storage:
          schemas:
          - effectiveDate: "2020-10-11"
            version: v13
          secret:
            name: logging-loki-s3
            type: aws
        storageClassName: gp3-csi
        tenants:
          mode: openshift-logging

      1
      根据租户设置保留策略。有效的租户类型是 applicationauditinfrastructure
      2
      包含用于定义日志流的 LogQL 查询
  2. 应用 LokiStack CR:

    $ oc apply -f <filename>.yaml

1.5.7. Loki pod 放置

您可以通过在 pod 上使用容忍度或节点选择器来控制 Loki pod 在哪些节点上运行,并防止其他工作负载使用这些节点。

您可以使用 LokiStack 自定义资源 (CR) 将容限应用到日志存储 pod,并将污点应用到具有节点规格的节点。节点上的污点是一个 key:value 对,它指示节点排斥所有不允许污点的 pod。通过使用不在其他 pod 上的特定 key:value 对,可确保只有日志存储 pod 能够在该节点上运行。

带有节点选择器的 LokiStack 示例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor: 1
      nodeSelector:
        node-role.kubernetes.io/infra: "" 2
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
# ...

1
指定应用到节点选择器的组件 pod 类型。
2
指定移到包含定义标签的节点的 pod。

带有节点选择器和容限的 LokiStack CR 示例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
# ...

要配置 LokiStack (CR) 的 nodeSelectortolerations 字段,您可以使用 oc explain 命令查看特定资源的描述和字段:

$ oc explain lokistack.spec.template

输出示例

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: template <Object>

DESCRIPTION:
     Template defines the resource/limits/tolerations/nodeselectors per
     component

FIELDS:
   compactor	<Object>
     Compactor defines the compaction component spec.

   distributor	<Object>
     Distributor defines the distributor component spec.
...

如需更多信息,您可以添加一个特定字段:

$ oc explain lokistack.spec.template.compactor

输出示例

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: compactor <Object>

DESCRIPTION:
     Compactor defines the compaction component spec.

FIELDS:
   nodeSelector	<map[string]string>
     NodeSelector defines the labels required by a node to schedule the
     component onto it.
...

1.5.7.1. 增强的可靠性和性能

配置以确保 Loki 在生产环境中的可靠性和效率。

1.5.7.2. 使用简短的令牌启用对基于云的日志存储的身份验证

工作负载身份联邦允许使用简短的令牌对基于云的日志存储进行身份验证。

流程

  • 使用以下选项之一启用身份验证:

    • 如果使用 OpenShift Container Platform Web 控制台安装 Loki Operator,则会自动检测到使用简短令牌的集群。系统将提示您创建角色,并提供 Loki Operator 所需的数据,以创建 CredentialsRequest 对象,该对象填充 secret。
    • 如果使用 OpenShift CLI (oc) 安装 Loki Operator,则必须使用正确的模板为存储供应商手动创建 Subscription 对象,如下例所示。此身份验证策略只支持所示的存储供应商。

      Azure 示例订阅

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: loki-operator
        namespace: openshift-operators-redhat
      spec:
        channel: "stable-6.0"
        installPlanApproval: Manual
        name: loki-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
        config:
          env:
            - name: CLIENTID
              value: <your_client_id>
            - name: TENANTID
              value: <your_tenant_id>
            - name: SUBSCRIPTIONID
              value: <your_subscription_id>
            - name: REGION
              value: <your_region>

      AWS 示例订阅示例

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: loki-operator
        namespace: openshift-operators-redhat
      spec:
        channel: "stable-6.0"
        installPlanApproval: Manual
        name: loki-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
        config:
          env:
          - name: ROLEARN
            value: <role_ARN>

1.5.7.3. 配置 Loki 以容忍节点故障

Loki Operator 支持设置 pod 反关联性规则,以请求同一组件的 pod 调度到集群中的不同可用节点上。

关联性是 pod 的一个属性,用于控制它们希望调度到的节点。反关联性是 pod 的一个属性,用于阻止 pod 调度到某个节点上。

在 OpenShift Container Platform 中,可以借助 pod 关联性pod 反关联性来根据其他 pod 上的键/值标签限制 pod 有资格调度到哪些节点。

Operator 会为所有 Loki 组件设置默认、首选的 podAntiAffinity 规则,其中包括 compactor, distributor, gateway, indexGateway, ingester, querier, queryFrontend, 和 ruler 组件。

您可以通过在 requiredDuringSchedulingIgnoredDuringExecution 字段中配置所需的设置来覆盖 Loki 组件的首选 podAntiAffinity 设置:

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

1
定义必要规则的小节。
2
必须匹配键-值对(标签)才能应用该规则。

1.5.7.4. 集群重启过程中的 LokiStack 行为

当 OpenShift Container Platform 集群重启时,LokiStack ingestion 和查询路径将继续在可用于节点的可用 CPU 和内存资源中运行。这意味着 OpenShift Container Platform 集群更新过程中,LokiStack 没有停机。此行为通过使用 PodDisruptionBudget 资源来实现。Loki Operator 为 Loki 置备 PodDisruptionBudget 资源,它决定了每个组件必须可用的最少 pod 数量,以确保特定条件下正常操作。

1.5.7.5. 高级部署和可扩展性

用于高可用性、可扩展性和错误处理的专用配置。

1.5.7.6. 支持区域的数据复制

Loki Operator 通过 pod 拓扑分布限制支持区感知数据复制。启用这个功能可提高可靠性,并防止出现单一区域故障的日志丢失。在将部署大小配置为 1x.extra-small, 1x.small, 或 1x.medium 时,replication.factor 字段会自动设置为 2。

为确保正确复制,您需要至少具有与复制因子指定的可用区数量。虽然可用区可能会比复制因素更多,但区域数量较少可能会导致写入失败。每个区域应托管相等的实例数量,以实现最佳操作。

启用区复制的 LokiStack CR 示例

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

1
弃用的字段,输入的值会被 replication.factor 覆盖。
2
当在设置时选择部署大小时,会自动设置这个值。
3
两个拓扑域间的 pod 数量的最大差别。默认值为 1,您无法指定 0。
4
以与节点标签对应的拓扑键的形式定义区域。

1.5.7.7. 从失败的区恢复 Loki pod

在 OpenShift Container Platform 中,当特定可用区资源无法访问时,会发生区失败。可用性区域是云提供商数据中心内的隔离区域,旨在增强冗余和容错能力。如果您的 OpenShift Container Platform 集群没有配置为处理此操作,则区失败可能会导致服务或数据丢失。

Loki pod 是 StatefulSet 的一部分,它们附带 StorageClass 对象置备的 PVC。每个 Loki pod 及其 PVC 驻留在同一区域中。当在集群中发生区故障时,StatefulSet 控制器会自动尝试恢复失败的区中受影响的 pod。

警告

以下流程将删除失败的区中的 PVC,以及其中包含的所有数据。为了避免完成数据丢失的 LokiStack CR 的 replication factor 字段,应该始终设置为大于 1 的值,以确保 Loki 复制。

先决条件

  • 验证 LokiStack CR 是否具有大于 1 的复制因素。
  • control plane 检测到区失败,故障区中的节点由云供应商集成标记。

StatefulSet 控制器会自动尝试重新调度失败的区中的 pod。因为关联的 PVC 也位于失败的区中,所以自动重新调度到不同的区无法正常工作。您必须手动删除失败的区中 PVC,以便在新区中成功重新创建有状态 Loki Pod 及其置备的 PVC。

流程

  1. 运行以下命令,列出处于 Pending 状态的 pod:

    $ oc get pods --field-selector status.phase==Pending -n openshift-logging

    oc get pods 输出示例

    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

    1
    这些 pod 处于 Pending 状态,因为它们对应的 PVC 位于失败的区中。
  2. 运行以下命令,列出处于 Pending 状态的 PVC:

    $ oc get pvc -o=json -n openshift-logging | jq '.items[] | select(.status.phase == "Pending") | .metadata.name' -r

    oc get 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

  3. 运行以下命令,删除 pod 的 PVC:

    $ oc delete pvc <pvc_name>  -n openshift-logging
  4. 运行以下命令来删除 pod:

    $ oc delete pod <pod_name>  -n openshift-logging

    成功删除这些对象后,应在可用区域中自动重新调度它们。

1.5.7.7.1. 对处于终止状态的 PVC 进行故障排除

如果 PVC 元数据终结器被设置为 kubernetes.io/pv-protection,PVC 可能会处于 terminating 状态。删除终结器应该允许 PVC 成功删除。

  • 运行以下命令删除每个 PVC 的终结器,然后重试删除。

    $ oc patch pvc <pvc_name> -p '{"metadata":{"finalizers":null}}' -n openshift-logging

1.5.7.8. Loki 速率限制错误故障排除

如果 Log Forwarder API 将超过速率限制的大量信息转发到 Loki,Loki 会生成速率限制(429)错误。

这些错误可能会在正常操作过程中发生。例如,当将 logging 添加到已具有某些日志的集群中时,logging 会尝试充分利用现有日志条目时可能会出现速率限制错误。在这种情况下,如果添加新日志的速度小于总速率限值,历史数据最终会被处理,并且不要求用户干预即可解决速率限制错误。

如果速率限制错误持续发生,您可以通过修改 LokiStack 自定义资源(CR)来解决此问题。

重要

LokiStack CR 在 Grafana 托管的 Loki 上不可用。本主题不适用于 Grafana 托管的 Loki 服务器。

Conditions

  • Log Forwarder API 配置为将日志转发到 Loki。
  • 您的系统向 Loki 发送大于 2 MB 的消息块。例如:

    "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\"}"]]}]}
  • 输入 oc logs -n openshift-logging -l component=collector 后,集群中的收集器日志会显示包含以下错误消息之一的行:

    429 Too Many Requests Ingestion rate limit exceeded

    Vector 错误消息示例

    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

    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"

    在接收结束时也会看到这个错误。例如,在 LokiStack ingester pod 中:

    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

流程

  • 更新 LokiStack CR 中的 ingestionBurstSizeingestionRate 字段:

    apiVersion: loki.grafana.com/v1
    kind: LokiStack
    metadata:
      name: logging-loki
      namespace: openshift-logging
    spec:
      limits:
        global:
          ingestion:
            ingestionBurstSize: 16 1
            ingestionRate: 8 2
    # ...
    1
    ingestionBurstSize 字段定义每个经销商副本的最大本地速率限制示例大小(以 MB 为单位)。这个值是一个硬限制。将此值设置为至少在单个推送请求中预期的最大日志大小。不允许大于 ingestionBurstSize 值的单个请求。
    2
    ingestionRate 字段是每秒最大最大样本量的软限制(以 MB 为单位)。如果日志速率超过限制,则会出现速率限制错误,但收集器会重试发送日志。只要总平均值低于限制,系统就会在没有用户干预的情况下解决错误。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.