10.3. 配置 LokiStack 日志存储

在日志记录文档中,LokiStack 指的是 Loki 和 Web 代理与 OpenShift Container Platform 身份验证集成的日志记录组合。LokiStack 的代理使用 OpenShift Container Platform 身份验证来强制实施多租户。Loki 将日志存储指代为单个组件或外部存储。

10.3.1. 为 cluster-admin 用户角色创建新组

重要

cluster-admin 用户身份查询多个命名空间的应用程序日志,其中集群中所有命名空间的字符总和大于 5120,会导致错误 Parse error: input size too long (XXXX > 5120)。为了更好地控制 LokiStack 中日志的访问,请使 cluster-admin 用户成为 cluster-admin 组的成员。如果 cluster-admin 组不存在,请创建它并将所需的用户添加到其中。

使用以下步骤为具有 cluster-admin 权限的用户创建新组。

流程

  1. 输入以下命令创建新组:

    $ oc adm groups new cluster-admin
  2. 输入以下命令将所需的用户添加到 cluster-admin 组中:

    $ oc adm groups add-users cluster-admin <username>
  3. 输入以下命令在组中添加 cluster-admin 用户角色:

    $ oc adm policy add-cluster-role-to-group cluster-admin cluster-admin

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

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

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

在日志记录 5.8 及更新的版本中,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
必须匹配键-值对(标签)才能应用该规则。

10.3.4. 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。

在上例配置中,所有 Loki pod 都移到包含 node-role.kubernetes.io/infra: "" 标签的节点。

带有节点选择器和容限的 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.
...

10.3.5. 支持区域的数据复制

在日志记录 5.8 及更新的版本中,Loki Operator 通过 pod 拓扑分布限制支持区感知数据复制。启用这个功能可提高可靠性,并防止出现单一区域故障的日志丢失。在将部署大小配置为 1x.extra.small1x.small1x.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
以与节点标签对应的拓扑键的形式定义区域。

10.3.5.1. 从失败的区恢复 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 复制。

先决条件

  • 日志记录版本 5.8 或更高版本。
  • 验证 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

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

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

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

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

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

10.3.6. 对 Loki 日志的精细访问

在日志记录 5.8 及更高版本中,Red Hat OpenShift Logging Operator 默认不授予所有用户对日志的访问权限。作为管理员,您需要配置用户访问权限,除非 Operator 已升级并且以前的配置已就位。根据您的配置和需要,您可以使用以下内容配置对日志的精细访问:

  • 集群范围内的策略
  • 命名空间范围策略
  • 创建自定义 admin 组

作为管理员,您需要创建适合部署的角色绑定和集群角色绑定。Red Hat OpenShift Logging Operator 提供以下集群角色:

  • cluster-logging-application-view 授予读取应用程序日志的权限。
  • cluster-logging-infrastructure-view 授予读取基础架构日志的权限。
  • cluster-logging-audit-view 授予读取审计日志的权限。

如果您从以前的版本升级,则额外的集群角色 logging-application-logs-reader 和关联的集群角色绑定 logging-all-authenticated-application-logs-reader 提供向后兼容性,允许任何经过身份验证的用户在命名空间中读取访问权限。

注意

在查询应用程序日志时,具有命名空间权限的用户必须提供命名空间。

10.3.6.1. 集群范围内的访问

集群角色绑定资源引用集群角色,以及设置集群范围的权限。

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

1
额外的 ClusterRolecluster-logging-infrastructure-viewcluster-logging-audit-view
2
指定此对象应用到的用户或组。

10.3.6.2. 命名空间访问

RoleBinding 资源可用于 ClusterRole 对象来定义用户或组可以访问日志的命名空间。

RoleBinding 示例

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

1
指定此 RoleBinding 应用到的命名空间。

10.3.6.3. 自定义 admin 组访问

如果您的部署有很多需要更广泛的用户,您可以使用 adminGroup 字段创建自定义组。属于 LokiStack CR 的 adminGroups 字段中指定的任何组的成员的用户被视为 admin。如果还被分配了 cluster-logging-application-view 角色,则管理员用户有权访问所有命名空间中的所有应用程序日志。

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

1
自定义管理组仅在此模式中可用。
2
为此字段输入空 list [] 值会禁用 admin 组。
3
覆盖默认组(system:cluster-admins,cluster-admin,dedicated-admin)

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

使用日志记录版本 5.6 及更高版本,您可以根据日志流配置保留策略。这些规则可全局设置,每个租户或两个都设置。如果同时配置这两个,则租户规则会在全局规则之前应用。

  1. 要启用基于流的保留,请创建一个 LokiStack 自定义资源(CR):

    全局的基于流的保留示例

    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: v11
        secret:
          name: logging-loki-s3
          type: aws
      storageClassName: standard
      tenants:
        mode: openshift-logging

    1
    为所有日志流设置保留策略。注: 此字段不会影响存储在对象存储中的保留周期。
    2
    当此块被添加到 CR 时,集群中会启用保留。
    3
    包含用于定义日志流的 LogQL 查询

    针对一个租户的基于流的保留示例

    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: v11
        secret:
          name: logging-loki-s3
          type: aws
      storageClassName: standard
      tenants:
        mode: openshift-logging

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

    $ oc apply -f <filename>.yaml
注意

这不适用于为存储的日志管理保留。使用对象存储配置存储在支持的最大 30 天的全局保留周期。

10.3.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 为单位)。如果日志速率超过限制,则会出现速率限制错误,但收集器会重试发送日志。只要总平均值低于限制,系统就会在没有用户干预的情况下解决错误。

10.3.9. 其它资源