Loki Operator 指南绕过 Gateway 将日志直推 Distributor 多租户写入Fluentd / Vector【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki本文以 Loki Operator 官方用户指南为基础介绍在 OpenShift 场景下如何让 Fluentd 或 Vector 作为日志收集器绕过 LokiStack Gateway 的认证网关直接通过distributor-http服务把 application、infrastructure、audit 三类日志以不同租户身份推送到 Loki Distributor。读完本文你将掌握整个部署链路LokiStack → OpenShift Logging → CA 证书 Secret → ClusterLogForwarder并理解tenantKey: log_type的多租户路由原理、TLS 服务证书校验方法以及429背压问题的排查思路。适用与免责说明本文操作仅适用于 OpenShift 部署。绕过认证网关并非 OpenShift 部署的常规配置仅当无法经由 GatewayForwarding Logs to LokiStack时才建议用于测试环境。一、背景Gateway 与 Distributor 直连两条路径的取舍由 Loki Operator 部署的 LokiStack 默认会包含一个lokistack-gateway组件它通过 OAuth/OIDC 端点对请求主体做认证与授权为写入distributor和查询query-frontend提供安全入口。正因如此默认情况下 LokiStack 内所有组件都启用了 TLS服务证书由集群内部 CA 签发。本文要走的“无 Gateway”路径与其形成对照对比项走 Gateway绕开 Gateway本文入口地址https://stack-gateway-http.ns.svc:8080/api/logs/v1/tenanthttps://stack-distributor-http.ns.svc:3100认证方式OAuth/OIDC bearer token无依赖 Service Network / mTLS 环境信任租户识别URL 路径段/api/logs/v1/application等日志字段log_type→X-Scope-OrgID适用场景生产环境常规配置测试 / 无法使用 Gateway 的场景从源码看distributor 的 HTTP 服务端口固定为 3100例如在 gateway_test.go 中Gateway 写入端点为https://abcd-distributor-http.efgh.svc.cluster.local:3100而服务命名规则fmt.Sprintf(%s-distributor-http, stackName)定义在 certrotation/var.go对应certrotation内部目录。这解释了文中 URLhttps://lokistack-dev-distributor-http.openshift-logging.svc:3100的构成LokiStack 名称-distributor-http 命名空间 端口 3100。二、前置条件与部署顺序动手之前先按 hacking guide 完成环境准备整体顺序如下部署 Loki Operator 与 LokiStack 实例按 OpenShift 上的操作指南 完成。注意无 Gateway 路径下创建的 LokiStack 应只包含 distributor、compactor、ingester、querier、query-frontend 五个组件不包含lokistack-gateway。在 OLM 部署场景中可通过移除loki-operator-controller-managerdeployment 的--with-lokistack-gateway参数来跳过 Gateway 组件kubectl -n openshift-operators-redhat edit deployment/loki-operator-controller-manager删除args中的--with-lokistack-gateway后保存再创建 LokiStack 实例。相应地stack名称为lokistack-dev时distributor 服务名为lokistack-dev-distributor-http。部署 OpenShift Logging Operator从 Operator Hub 安装或在本地用以下命令部署make deploy-image deploy-catalog install创建只含collection的 ClusterLogging 实例位于openshift-logging命名空间让集群具备日志收集能力见下一节。关于租户模式的一个补充虽然本文绕开了 Gateway但了解 tenancy-modes.md 中列出的五种模式static、dynamic、passthrough、openshift-logging、openshift-network有助于理解openshift-logging模式预置了application、infrastructure、audit三个租户本文直推 Distributor 时正是通过log_type字段把这三种日志路由到同名租户实现与 Gateway 路径等价的多租户隔离存储。三、创建 ClusterLogging 实例Fluentd / Vector 二选一在openshift-logging命名空间创建 ClusterLogging CR只需定义collection不配置存储与可视化让日志先被收集、随后由 ClusterLogForwarder 转发Fluentd 版本apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: name: instance namespace: openshift-logging spec: collection: logs: type: fluentd fluentd: {}Vector 版本apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: name: instance namespace: openshift-logging spec: collection: logs: type: vector fluentd: {}注意Vector 示例中的fluentd: {}为原文档原文保留两个 CR 除collection.logs.type外结构一致后续步骤对 fluentd 与 vector 完全相同。四、TLS 信任把 CA 证书 ConfigMap 转成 Secret4.1 为什么需要这一步默认情况下Loki Operator 部署的所有组件都启用了 TLS服务证书由集群内部 CA 签发。收集器在访问https://lokistack-dev-distributor-http...时必须校验 distributor 返回的证书因此需要把 CA 证书提供给收集器。CA 证书存放在 loki-operator 随 LokiStack 创建的 ConfigMap 中该 ConfigMap 无法被收集器直接使用必须先转换为收集器可读的 Secret。ConfigMap 与 Secret 的命名关系可在 gateway_test.go 中看到同一 stack 会同时生成abcd-ca-bundle与abcd-gateway-ca-bundle两个 ConfigMap其中 Gateway CA ConfigMap 由 openshift/service_ca.go 的BuildGatewayCAConfigMap构建其注释明确指出该 ConfigMap 用于“配置 gateway 与各组件以校验 TLS 证书”。4.2 获取ca-bundle.crtSecret 必须存在于openshift-logging命名空间且必须包含键ca-bundle.crt。先从 ConfigMap 中把 CA 取出来以lokistack-dev-gateway-ca-bundle为例kubectl -n openshift-logging get cm lokistack-dev-gateway-ca-bundle -o jsonpath{.data.service-ca\.crt} FILE_NAME其中FILE_NAME可取ca_bundle.crt并直接用于下一步创建 Secret。若你的 LokiStack 名称为stackConfigMap 名称相应为stack-gateway-ca-bundle。4.3 创建 Secretkubectl -n openshift-logging create secret generic loki-distributor-ca \ --from-fileca-bundle.crtPATH/TO/CA_BUNDLE.CRT其中PATH/TO/CA_BUNDLE.CRT为上一步ca_bundle.crt保存到的文件路径。创建后 Secret 名为loki-distributor-ca供后续 ClusterLogForwarder 引用。五、创建 ClusterLogForwarder把三类日志推送到 Distributor这是整条链路的最后一步。创建以下 CR将 application、audit、infrastructure 日志转发到 distributor 端点apiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance namespace: openshift-logging spec: outputs: - name: loki-operator type: loki url: https://lokistack-dev-distributor-http.openshift-logging.svc:3100 secret: name: loki-distributor-ca loki: tenantKey: log_type pipelines: - name: send-logs inputRefs: - application - audit - infrastructure outputRefs: - loki-operator关键点说明url直接指向 distributor 的 HTTP 服务https://lokistack-dev-distributor-http.openshift-logging.svc:3100端口 3100 是 Loki 各组件的标准 HTTP 端口可对照 gateway_test.go 中--logs.write.endpointhttps://abcd-distributor-http.efgh.svc.cluster.local:3100。secret.name引用第四节创建的loki-distributor-ca用于 TLS 校验。tenantKey: log_typefluentd 与 vector 会根据所收集日志的类型把log_type解析为application、audit或infrastructure随后作为不同租户 ID 写入 Loki实现与 Gateway 路径等价的多租户隔离。inputRefs同时引用application、audit、infrastructure即可用单个 output 单个 pipeline 完成三类日志的租户化写入若只想转发部分日志可像 Forwarding Logs to LokiStack 中说明的那样自行增删 pipeline。六、Troubleshooting日志条目乱序与 429 背压现象如果 forwarder 在短时间内发送过多数据Loki 会对 forwarder 施加背压并对 POST 请求返回429错误导致日志条目出现乱序。处理方式这与 Forwarding Logs to LokiStack 中描述的429问题是同一机制。缓解手段包括提升 LokiStack 规格t-shirt size更大规格带来更多资源与更高摄取速率。kubectl -n openshift-logging edit lokistacksize: 1x.medium手动调整摄取速率限制全局或按租户kubectl -n openshift-logging edit lokistacklimits: tenants: TENANT_NAME: IngestionLimits: IngestionRate: 15其中TENANT_NAME可为application、audit或infrastructure。七、回顾与验证建议完整部署顺序可归纳为部署 Loki Operator不带 Gateway→ 部署 OpenShift Logging Operator → 创建只含collection的 ClusterLogging → 从stack-gateway-ca-bundleConfigMap 提取service-ca.crt并创建含ca-bundle.crt键的 Secret → 创建引用该 Secret 且带tenantKey: log_type的 ClusterLogForwarder。验证建议用kubectl -n openshift-logging get pods确认collectorPodfluentd 或 vector处于 Running在 Grafana 或通过查询前端分别以application、audit、infrastructure租户查询日志确认三类日志已按租户正确落库若流量较大持续观察 distributor 是否返回429据此调整size或租户级IngestionLimits。相关文档Forwarding Logs to LokiStack经 Gateway 的标准转发方式OAuth/OIDC bearer tokenTenancy Modes五种租户模式总览Gateway Configuration外部访问与 Ingress 设置Hacking on OpenShiftLoki Operator 在 OpenShift 上的部署与调试【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Loki Operator 指南：绕过 Gateway 将日志直推 Distributor 多租户写入（Fluentd / Vector）
Loki Operator 指南绕过 Gateway 将日志直推 Distributor 多租户写入Fluentd / Vector【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki本文以 Loki Operator 官方用户指南为基础介绍在 OpenShift 场景下如何让 Fluentd 或 Vector 作为日志收集器绕过 LokiStack Gateway 的认证网关直接通过distributor-http服务把 application、infrastructure、audit 三类日志以不同租户身份推送到 Loki Distributor。读完本文你将掌握整个部署链路LokiStack → OpenShift Logging → CA 证书 Secret → ClusterLogForwarder并理解tenantKey: log_type的多租户路由原理、TLS 服务证书校验方法以及429背压问题的排查思路。适用与免责说明本文操作仅适用于 OpenShift 部署。绕过认证网关并非 OpenShift 部署的常规配置仅当无法经由 GatewayForwarding Logs to LokiStack时才建议用于测试环境。一、背景Gateway 与 Distributor 直连两条路径的取舍由 Loki Operator 部署的 LokiStack 默认会包含一个lokistack-gateway组件它通过 OAuth/OIDC 端点对请求主体做认证与授权为写入distributor和查询query-frontend提供安全入口。正因如此默认情况下 LokiStack 内所有组件都启用了 TLS服务证书由集群内部 CA 签发。本文要走的“无 Gateway”路径与其形成对照对比项走 Gateway绕开 Gateway本文入口地址https://stack-gateway-http.ns.svc:8080/api/logs/v1/tenanthttps://stack-distributor-http.ns.svc:3100认证方式OAuth/OIDC bearer token无依赖 Service Network / mTLS 环境信任租户识别URL 路径段/api/logs/v1/application等日志字段log_type→X-Scope-OrgID适用场景生产环境常规配置测试 / 无法使用 Gateway 的场景从源码看distributor 的 HTTP 服务端口固定为 3100例如在 gateway_test.go 中Gateway 写入端点为https://abcd-distributor-http.efgh.svc.cluster.local:3100而服务命名规则fmt.Sprintf(%s-distributor-http, stackName)定义在 certrotation/var.go对应certrotation内部目录。这解释了文中 URLhttps://lokistack-dev-distributor-http.openshift-logging.svc:3100的构成LokiStack 名称-distributor-http 命名空间 端口 3100。二、前置条件与部署顺序动手之前先按 hacking guide 完成环境准备整体顺序如下部署 Loki Operator 与 LokiStack 实例按 OpenShift 上的操作指南 完成。注意无 Gateway 路径下创建的 LokiStack 应只包含 distributor、compactor、ingester、querier、query-frontend 五个组件不包含lokistack-gateway。在 OLM 部署场景中可通过移除loki-operator-controller-managerdeployment 的--with-lokistack-gateway参数来跳过 Gateway 组件kubectl -n openshift-operators-redhat edit deployment/loki-operator-controller-manager删除args中的--with-lokistack-gateway后保存再创建 LokiStack 实例。相应地stack名称为lokistack-dev时distributor 服务名为lokistack-dev-distributor-http。部署 OpenShift Logging Operator从 Operator Hub 安装或在本地用以下命令部署make deploy-image deploy-catalog install创建只含collection的 ClusterLogging 实例位于openshift-logging命名空间让集群具备日志收集能力见下一节。关于租户模式的一个补充虽然本文绕开了 Gateway但了解 tenancy-modes.md 中列出的五种模式static、dynamic、passthrough、openshift-logging、openshift-network有助于理解openshift-logging模式预置了application、infrastructure、audit三个租户本文直推 Distributor 时正是通过log_type字段把这三种日志路由到同名租户实现与 Gateway 路径等价的多租户隔离存储。三、创建 ClusterLogging 实例Fluentd / Vector 二选一在openshift-logging命名空间创建 ClusterLogging CR只需定义collection不配置存储与可视化让日志先被收集、随后由 ClusterLogForwarder 转发Fluentd 版本apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: name: instance namespace: openshift-logging spec: collection: logs: type: fluentd fluentd: {}Vector 版本apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: name: instance namespace: openshift-logging spec: collection: logs: type: vector fluentd: {}注意Vector 示例中的fluentd: {}为原文档原文保留两个 CR 除collection.logs.type外结构一致后续步骤对 fluentd 与 vector 完全相同。四、TLS 信任把 CA 证书 ConfigMap 转成 Secret4.1 为什么需要这一步默认情况下Loki Operator 部署的所有组件都启用了 TLS服务证书由集群内部 CA 签发。收集器在访问https://lokistack-dev-distributor-http...时必须校验 distributor 返回的证书因此需要把 CA 证书提供给收集器。CA 证书存放在 loki-operator 随 LokiStack 创建的 ConfigMap 中该 ConfigMap 无法被收集器直接使用必须先转换为收集器可读的 Secret。ConfigMap 与 Secret 的命名关系可在 gateway_test.go 中看到同一 stack 会同时生成abcd-ca-bundle与abcd-gateway-ca-bundle两个 ConfigMap其中 Gateway CA ConfigMap 由 openshift/service_ca.go 的BuildGatewayCAConfigMap构建其注释明确指出该 ConfigMap 用于“配置 gateway 与各组件以校验 TLS 证书”。4.2 获取ca-bundle.crtSecret 必须存在于openshift-logging命名空间且必须包含键ca-bundle.crt。先从 ConfigMap 中把 CA 取出来以lokistack-dev-gateway-ca-bundle为例kubectl -n openshift-logging get cm lokistack-dev-gateway-ca-bundle -o jsonpath{.data.service-ca\.crt} FILE_NAME其中FILE_NAME可取ca_bundle.crt并直接用于下一步创建 Secret。若你的 LokiStack 名称为stackConfigMap 名称相应为stack-gateway-ca-bundle。4.3 创建 Secretkubectl -n openshift-logging create secret generic loki-distributor-ca \ --from-fileca-bundle.crtPATH/TO/CA_BUNDLE.CRT其中PATH/TO/CA_BUNDLE.CRT为上一步ca_bundle.crt保存到的文件路径。创建后 Secret 名为loki-distributor-ca供后续 ClusterLogForwarder 引用。五、创建 ClusterLogForwarder把三类日志推送到 Distributor这是整条链路的最后一步。创建以下 CR将 application、audit、infrastructure 日志转发到 distributor 端点apiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance namespace: openshift-logging spec: outputs: - name: loki-operator type: loki url: https://lokistack-dev-distributor-http.openshift-logging.svc:3100 secret: name: loki-distributor-ca loki: tenantKey: log_type pipelines: - name: send-logs inputRefs: - application - audit - infrastructure outputRefs: - loki-operator关键点说明url直接指向 distributor 的 HTTP 服务https://lokistack-dev-distributor-http.openshift-logging.svc:3100端口 3100 是 Loki 各组件的标准 HTTP 端口可对照 gateway_test.go 中--logs.write.endpointhttps://abcd-distributor-http.efgh.svc.cluster.local:3100。secret.name引用第四节创建的loki-distributor-ca用于 TLS 校验。tenantKey: log_typefluentd 与 vector 会根据所收集日志的类型把log_type解析为application、audit或infrastructure随后作为不同租户 ID 写入 Loki实现与 Gateway 路径等价的多租户隔离。inputRefs同时引用application、audit、infrastructure即可用单个 output 单个 pipeline 完成三类日志的租户化写入若只想转发部分日志可像 Forwarding Logs to LokiStack 中说明的那样自行增删 pipeline。六、Troubleshooting日志条目乱序与 429 背压现象如果 forwarder 在短时间内发送过多数据Loki 会对 forwarder 施加背压并对 POST 请求返回429错误导致日志条目出现乱序。处理方式这与 Forwarding Logs to LokiStack 中描述的429问题是同一机制。缓解手段包括提升 LokiStack 规格t-shirt size更大规格带来更多资源与更高摄取速率。kubectl -n openshift-logging edit lokistacksize: 1x.medium手动调整摄取速率限制全局或按租户kubectl -n openshift-logging edit lokistacklimits: tenants: TENANT_NAME: IngestionLimits: IngestionRate: 15其中TENANT_NAME可为application、audit或infrastructure。七、回顾与验证建议完整部署顺序可归纳为部署 Loki Operator不带 Gateway→ 部署 OpenShift Logging Operator → 创建只含collection的 ClusterLogging → 从stack-gateway-ca-bundleConfigMap 提取service-ca.crt并创建含ca-bundle.crt键的 Secret → 创建引用该 Secret 且带tenantKey: log_type的 ClusterLogForwarder。验证建议用kubectl -n openshift-logging get pods确认collectorPodfluentd 或 vector处于 Running在 Grafana 或通过查询前端分别以application、audit、infrastructure租户查询日志确认三类日志已按租户正确落库若流量较大持续观察 distributor 是否返回429据此调整size或租户级IngestionLimits。相关文档Forwarding Logs to LokiStack经 Gateway 的标准转发方式OAuth/OIDC bearer tokenTenancy Modes五种租户模式总览Gateway Configuration外部访问与 Ingress 设置Hacking on OpenShiftLoki Operator 在 OpenShift 上的部署与调试【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考