Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

2.4. 高级部署和可扩展性

要配置高可用性、可扩展性和错误处理，请使用以下信息：

2.4.1. 支持区域的数据复制
复制链接

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

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

2.4.2. 从失败的区恢复 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
    Copy to Clipboard Toggle word wrap

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

    1
    这些 pod 处于 Pending 状态，因为它们对应的 PVC 位于失败的区中。

  2. 运行以下命令，列出处于 Pending 状态的 PVC： 

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

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

  3. 运行以下命令，删除 pod 的 PVC： 

    $ oc delete pvc <pvc_name> -n openshift-logging
    Copy to Clipboard Toggle word wrap

  4. 运行以下命令来删除 pod： 

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

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

2.4.2.1. 对处于终止状态的 PVC 进行故障排除
复制链接

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

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

    $ oc patch pvc <pvc_name> -p '{"metadata":{"finalizers":null}}' -n openshift-logging
    Copy to Clipboard Toggle word wrap

2.4.3. 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\"}"]]}]}
    Copy to Clipboard Toggle word wrap

  • 输入 oc logs -n openshift-logging -l component=collector 后，集群中的收集器日志会显示包含以下错误消息之一的行： 

    429 Too Many Requests Ingestion rate limit exceeded
    Copy to Clipboard Toggle word wrap

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

    在接收结束时也会看到这个错误。例如，在 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
    Copy to Clipboard Toggle word wrap

流程

  • 更新 LokiStack CR 中的 ingestionBurstSize 和 ingestionRate 字段： 

    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
    ingestionBurstSize 字段定义每个经销商副本的最大本地速率限制示例大小（以 MB 为单位）。这个值是一个硬限制。将此值设置为至少在单个推送请求中预期的最大日志大小。不允许大于 ingestionBurstSize 值的单个请求。
    2
    ingestionRate 字段是每秒最大最大样本量的软限制（以 MB 为单位）。如果日志速率超过限制，则会出现速率限制错误，但收集器会重试发送日志。只要总平均值低于限制，系统就会在没有用户干预的情况下解决错误。
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat