3.4. 使用 LokiStack 存储日志
您可以配置 LokiStack
CR 来存储应用程序、审计和基础架构相关的日志。
Loki 是一个可横向扩展的、高度可用、多租户日志聚合系统,作为 Red Hat OpenShift 的日志记录的 GA 日志存储,可以使用 OpenShift Observability UI 视觉化。OpenShift Logging 提供的 Loki 配置是一个短期日志存储,旨在让用户使用收集的日志执行快速故障排除。为此,Loki 的 Red Hat OpenShift 配置的日志记录具有短期存储,并针对非常最新的查询进行了优化。
对于长期存储或长时间查询,用户应查找其集群外部的日志存储。Loki 大小只针对短期存储(最多 30 天)进行了测试并被支持。
3.4.1. Loki 部署大小
Loki 的大小使用 1x.<size>
格式,其中值 1x
是实例数量,<size>
指定性能功能。
1x.pico
配置定义了具有最少资源和限制要求的单个 Loki 部署,为所有 Loki 组件提供高可用性(HA)支持。此配置适用于不需要单个复制因子或自动编译的部署。
磁盘请求在大小配置之间相似,允许客户测试不同的大小,以确定其部署需求的最佳选择。
对于部署大小,无法更改 1x
值。
1x.demo | 1x.pico [6.1+ only] | 1x.extra-small | 1x.small | 1x.medium | |
---|---|---|---|---|---|
数据传输 | 仅用于演示 | 50GB/day | 100GB/day | 500GB/day | 2TB/day |
每秒查询数 (QPS) | 仅用于演示 | 1-25 QPS at 200ms | 1-25 QPS at 200ms | 25-50 QPS at 200ms | 25-75 QPS at 200ms |
复制因子 | 无 | 2 | 2 | 2 | 2 |
总 CPU 请求 | 无 | 7 个 vCPU | 14 个 vCPU | 34 个 vCPU | 54 个 vCPU |
使用标尺的 CPU 请求总数 | 无 | 8 个 vCPU | 16 个 vCPU | 42 个 vCPU | 70 个 vCPU |
内存请求总数 | 无 | 17Gi | 31Gi | 67Gi | 139Gi |
使用规则器的内存请求总数 | 无 | 18Gi | 35Gi | 83Gi | 171Gi |
磁盘请求总数 | 40Gi | 590Gi | 430Gi | 430Gi | 590Gi |
使用标尺的磁盘请求总数 | 80Gi | 910Gi | 750Gi | 750Gi | 910Gi |
3.4.2. 先决条件
- 已使用 CLI 或 Web 控制台安装 Loki Operator。
-
在同一命名空间中有一个
serviceAccount
,您可以在其中创建ClusterLogForwarder
。 -
serviceAccount
被分配了collect-audit-logs
、collect-application-logs
和collect-infrastructure-logs
集群角色。
3.4.3. 核心设置和配置
基于角色的访问控制、基本监控和 pod 放置来部署 Loki。
3.4.4. 授权 LokiStack 规则 RBAC 权限
管理员可以允许用户通过将集群角色绑定到 username 来创建和管理自己的警报和记录规则。集群角色定义为 ClusterRole
对象,其中包含用户所需的基于角色的访问控制(RBAC)权限。
LokiStack 有以下用于警报和记录规则的集群角色:
运行名称 | 描述 |
---|---|
|
具有此角色的用户具有管理级别访问权限来管理警报规则。此集群角色授予在 |
|
具有此角色的用户可以查看与 |
|
具有此角色的用户有权创建、更新和删除 |
|
具有此角色的用户可以读取 |
|
具有此角色的用户具有管理记录规则的管理级别访问权限。此集群角色授予在 |
|
具有此角色的用户可以查看与 |
|
具有此角色的用户有权创建、更新和删除 |
|
具有此角色的用户可以读取 |
3.4.4.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>
3.4.5. 使用 Loki 创建基于日志的警报规则
AlertingRule
CR 包含一组规格和 webhook 验证定义,用于声明单个 LokiStack
实例的警报规则组。另外,webhook 验证定义支持规则验证条件:
-
如果
AlertingRule
CR 包含无效的interval
周期,则它是一个无效的警报规则 -
如果
AlertingRule
CR 包含无效的for
周期,则它是一个无效的警报规则 -
如果
AlertingRule
CR 包含无效的 LogQLexpr
,则它是一个无效的警报规则。 -
如果
AlertingRule
CR 包含两个同名的组,则它是一个无效的警报规则。 - 如果以上都不适用,则警报规则被视为有效。
租户类型 | AlertingRule CR 的有效命名空间 |
---|---|
application |
|
audit |
|
infrastructure |
|
流程
创建
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 的命名空间必须具有与 LokiStackspec.rules.namespaceSelector
定义匹配的标签。 - 2
labels
块必须与 LokiStackspec.rules.selector
定义匹配。- 3
infrastructure
租户的AlertingRule
CR 只在openshift-*
,kube-\*
, 或default
命名空间中被支持。- 4
kubernetes_namespace_name:
的值必须与metadata.namespace
的值匹配。- 5
- 此必需字段的值必须是
critical
、warning
或info
。 - 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
应用
AlertingRule
CR:$ oc apply -f <filename>.yaml
3.4.6. 配置 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 # ...
3.4.7. 使用 Loki 启用基于流的保留
您可以根据日志流配置保留策略。这些规则可全局设置,可以是每个租户,或两者。如果同时配置这两个,则租户规则会在全局规则之前应用。
如果没有在 s3 存储桶或 LokiStack 自定义资源 (CR) 中定义保留周期,则不会修剪日志,它们会永久保留在 s3 存储桶中,这可能会填满 s3 存储。
建议采用 schema v13。
流程
创建
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
根据租户启用基于流的保留,如下例所示:
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
应用
LokiStack
CR:$ oc apply -f <filename>.yaml
3.4.8. 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: "" # ...
带有节点选择器和容限的 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) 的 nodeSelector
和 tolerations
字段,您可以使用 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. ...
3.4.8.1. 增强的可靠性和性能
配置以确保 Loki 在生产环境中的可靠性和效率。
3.4.8.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>
-
如果使用 OpenShift Container Platform Web 控制台安装 Loki Operator,则会自动检测到使用简短令牌的集群。系统将提示您创建角色,并提供 Loki Operator 所需的数据,以创建
3.4.8.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 # ...
3.4.8.4. 集群重启过程中的 LokiStack 行为
当 OpenShift Container Platform 集群重启时,LokiStack ingestion 和查询路径将继续在可用于节点的可用 CPU 和内存资源中运行。这意味着 OpenShift Container Platform 集群更新过程中,LokiStack 没有停机。此行为通过使用 PodDisruptionBudget
资源来实现。Loki Operator 为 Loki 置备 PodDisruptionBudget
资源,它决定了每个组件必须可用的最少 pod 数量,以确保特定条件下正常操作。
3.4.8.5. 高级部署和可扩展性
用于高可用性、可扩展性和错误处理的专用配置。
3.4.8.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
3.4.8.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。
流程
运行以下命令,列出处于
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 位于失败的区中。
运行以下命令,列出处于
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
运行以下命令,删除 pod 的 PVC:
$ oc delete pvc <pvc_name> -n openshift-logging
运行以下命令来删除 pod:
$ oc delete pod <pod_name> -n openshift-logging
成功删除这些对象后,应在可用区域中自动重新调度它们。
3.4.8.7.1. 对处于终止状态的 PVC 进行故障排除
如果 PVC 元数据终结器被设置为 kubernetes.io/pv-protection
,PVC 可能会处于 terminating 状态。删除终结器应该允许 PVC 成功删除。
运行以下命令删除每个 PVC 的终结器,然后重试删除。
$ oc patch pvc <pvc_name> -p '{"metadata":{"finalizers":null}}' -n openshift-logging
3.4.8.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 中的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 # ...