尧图网页设计 
使用 Kubernetes Monitoring Helm Chart 为 Loki 部署元监控Meta-monitoring【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki本篇指南以 deploy.md 为核心完整讲解如何基于 Grafana Kubernetes Monitoring Helm Chart 为运行在 Kubernetes 上的 Loki 集群部署一套独立、可观测的元监控meta-monitoring体系涵盖前置条件、Grafana Cloud 认证准备、values.yaml配置详解、Helm 部署与结果验证。读完本文后你将掌握一套可复制、可落地的 Loki 集群自监控部署方案并为后续安装 Loki Mixin 仪表盘与告警规则打下基础。什么是 Loki 元监控元监控meta-monitoring指的是监控监控系统本身在收集业务日志的同时Loki 集群自身的运行状况也需要被度量与观测。按照 Loki meta-monitoring 索引页 的最佳实践应当把 Loki 集群产生的观测数据收集到一个独立的 Loki、Prometheus 与 Grafana 实例中例如 Grafana Cloud 账号这样当被监控的 Loki 集群故障时你仍可以借助一套健康的监控环境进行排障避免监控系统与被监控系统一起宕机的窘境。Loki 对外暴露两类核心观测数据Metrics每个 Loki 组件都通过/metrics端点以 Prometheus 格式暴露自身指标默认端口3100用于观察查询响应时间、请求错误率等聚合健康信号LogsLoki 会为每一条查询在metrics.go中输出一条结构化日志行包含查询耗时、返回行数、吞吐量、执行的 LogQL、检索的 chunk 数等可直接用于查询性能的优化与排障。官方推荐的监控组件组合是Kubernetes Monitoring Helm Chart面向 Kubernetes 集群的综合性监控方案内置了对完整 LGTMLoki、Grafana、Tempo、Mimir栈的直接集成Grafana Cloud 或独立的 LGTM 栈作为观测数据的目的地sinkLoki Mixin一套带观点的仪表盘、告警与录制规则集用于在 Grafana 中可视化 Loki 集群状态。本文聚焦第一步——部署 Kubernetes Monitoring Helm Chart。对于不在 Helm chart 内以单二进制monolithic模式运行 Loki 的场景可参考 单二进制元监控指南 的替代方案。前置条件在开始部署前请确认以下环境要素均已就绪kubectl用于与 Kubernetes 集群交互Helm 3 或以上版本用于安装 chartHelm 2 与 3 的命令与行为差异较大请务必使用 Helm 3一个运行中的 Kubernetes 集群且集群内已部署一套正在运行的 Loki 集群一个 Grafana Cloud 账号或一套独立的 LGTM 栈作为监控数据的目的地。官方建议在生产环境中以分布式模式在 Kubernetes 上运行 Loki。虽然 Docker 或虚拟机部署方式下同样可以进行元监控但本文过程仅覆盖 Kubernetes Helm chart 的路径。第一步准备环境在部署 chart 之前需要先完成 Helm 仓库与命名空间的初始化。添加 Grafana 官方 Helm 仓库helm repo add grafana https://grafana.github.io/helm-charts更新本地 Helm 仓库索引确保能拉到最新版本的 charthelm repo update为监控栈创建独立的命名空间meta使监控组件与被监控的 Loki 集群默认位于loki命名空间隔离kubectl create namespace meta将监控栈放入独立命名空间是元监控的关键隔离手段即使 Loki 集群所在的命名空间出现问题监控采集链路依然能够存活。第二步配置认证与凭证Kubernetes Monitoring Helm Chart 需要凭证来向 Grafana Cloud 或独立 LGTM 栈推送遥测数据。下面以 Grafana Cloud 为例说明完整流程。创建 Grafana Cloud 访问策略Access Policy登录 Grafana Cloud进入主菜单Security Access Policies点击Create access policy为策略命名并勾选以下权限Metrics: WriteLogs: Write点击Create完成策略创建点击Add Token为策略添加令牌命名后创建并保存好该令牌供后续写入 Kubernetes Secret 使用。收集 Prometheus 与 Loki 实例的 URL 与用户名进入 Grafana Cloud Portal 的Overview页面点击 Prometheus 实例的Details按钮在Sending metrics using Grafana Alloy一节中收集该实例的username与url返回Overview页面再点击 Loki 实例的Details按钮在Sending Logs to Grafana Cloud using Grafana Alloy一节中收集 Loki 实例的username与url。创建 Kubernetes Secrets使用上一步收集的凭证创建两个 Secret分别对应 Metrics 与 Logs 两个数据目的地kubectl create secret generic metrics -n meta \ --from-literalusernamePROMETHEUS-USER \ --from-literalpasswordCLOUD-TOKEN kubectl create secret generic logs -n meta \ --from-literalusernameLOKI-USER \ --from-literalpasswordCLOUD-TOKEN两个 Secret 均创建在meta命名空间中username是各实例的用户名password都是同一个 Cloud Token。稍后values.yaml中的destinations[].secret会引用这两个 Secret 的名字实现凭证与配置的分离避免把敏感信息直接写进 Helm values。其他认证方式除了基本的用户名/密码Basic Auth外Kubernetes Monitoring Helm Chart 还支持多种认证方式可按需选择Bearer TokensOAuth2SigV4AWS 签名External Secrets外部 Secret 管理第三步下载并定制 values.yamlChart 的配置通过values.yaml注入。Loki 仓库在production/helm/meta-monitoring/目录下维护了一份开箱即用的参考配置部署前先将其下载到本地curl -O https://raw.githubusercontent.com/grafana/loki/main/production/helm/meta-monitoring/values.yaml该文件在仓库内的对应位置为 production/helm/meta-monitoring/values.yaml也可直接克隆 Loki 仓库后在本地查看。配置数据目的地destinations打开values.yaml配置 Prometheus 与 Loki 两个远端端点destinations: - name: prometheus type: prometheus url: https://PROMETHEUS-ENDPOINT/api/prom/push auth: type: basic usernameKey: username passwordKey: password secret: create: false name: metrics namespace: meta - name: loki type: loki url: https://LOKI-ENDPOINT/loki/api/v1/push auth: type: basic usernameKey: username passwordKey: password secret: create: false name: logs namespace: meta各字段含义如下字段说明destinations[].name目的地名称仅用于内部标识destinations[].type目的地类型Metrics 用prometheusLogs 用lokidestinations[].url远端写入端点Prometheus 的远端写入路径为/api/prom/pushLoki 的推送路径为/loki/api/v1/pushauth.type认证方式此处为basicBasic Authauth.usernameKey/passwordKey从 Secret 中取用户名与密码的字段名与上文创建 Secret 时的--from-literalkey 一一对应username、passwordsecret.create设为false表示复用预先创建的 Secret而不是让 chart 自动生成secret.name/namespace引用已创建的 Secret 名称与其所在命名空间metrics/logs均位于meta可选设置集群名称cluster.name会作为全局标签添加到所有遥测数据上建议设置为易识别的集群名便于在 Grafana Cloud 中区分多个集群# Global Label to be added to all telemetry data. Should reflect a recognizable name for the cluster. cluster: name: loki-meta-monitoring-cluster调整被监控的命名空间默认 values 假设 Loki 部署在loki命名空间监控栈部署在meta命名空间。如果你的 Loki 部署在其他命名空间需要同步修改namespaces列表namespaces: - loki如果希望从集群中所有命名空间收集数据直接删除namespaces键即可。仓库自带的 values.yaml 还展示了更多细节例如podLogs.namespaces同样列出了meta与loki两个命名空间。深入仓库 values.yaml 中的监控组件开关仓库中的参考配置远不止上述字段它同时给出了采集组件的完整开关理解这些开关有助于按需调整采集范围与元监控成本meta-monitoring budgetintegrations: collector: alloy-singleton alloy: instances: - name: alloy labelSelectors: app.kubernetes.io/name: [alloy-singleton] namespaces: - meta loki: instances: - name: loki namespaces: - loki labelSelectors: app.kubernetes.io/name: lokiintegrations.loki通过标签选择器app.kubernetes.io/name: loki采集 Loki 组件日志并可通过structuredMetadata提取caller、tenant、org_id、user等 logfmt 字段作为结构化元数据方便后续检索过滤clusterEvents开启后将 Kubernetes 事件作为日志采集默认监听meta与loki命名空间clusterMetrics集中控制各类指标采集器包括 cAdvisor采集 Loki Pod 指标默认自动部署、kubelet、kubeletResource、kube-state-metrics、node-exporter 等可按需关闭以控制数据量与成本podLogs开启 Pod 日志采集并通过labelsToKeep保留app、namespace、component、container、job等关键标签alloy-singleton以单实例模式部署 Alloy Collector作为上述所有采集任务的执行者alloy-metrics、alloy-logs、alloy-profiles、alloy-receiver默认关闭。默认的global.scrapeInterval为15s即 Alloy 组件的全局抓取间隔。第四步部署 Helm Chart使用定制好的values.yaml执行安装helm install meta-loki grafana/k8s-monitoring \ --namespace meta \ -f values.yaml该命令会以meta-loki为 release 名称将 Kubernetes Monitoring Chart 安装到meta命名空间。关于 chart 的更多背景可阅读仓库中的 production/helm/meta-monitoring/README.md其中还包含自管理self-managedPrometheus/Loki/Grafana 栈的 Secret 创建示例。第五步验证部署结果检查meta命名空间下的 Pod 运行状态kubectl get pods -n meta正常情况下你会看到一批运行中的 Pod大致如下NAME READY STATUS RESTARTS ... meta-loki-alloy-singleton-6d7f8d8b86-sg4wx 2/2 Running 0 ... meta-loki-kube-state-metrics-64bdcfcbd-5snqz 1/1 Running 0 ... meta-loki-node-exporter-855l5 1/1 Running 0 ... meta-loki-node-exporter-b976b 1/1 Running 0 ... meta-loki-node-exporter-vsm4s 1/1 Running 0 ...alloy-singleton承担指标与日志采集、转发任务的 Alloy 采集器kube-state-metrics监听 Kubernetes API Server生成集群对象状态指标node-exporter每个节点一个采集节点级指标。全部 Pod 处于Running状态即表示元监控链路已打通。此后Loki 集群的指标与日志会持续写入 Grafana Cloud或你配置的 LGTM 栈。下一步安装 Loki Mixin部署成功后即可进入元监控的下一环节——安装 Loki Mixin用预置的仪表盘与告警规则可视化 Loki 集群状态。Loki 每个版本都会发布一份 mixin包含面向整体集群与单个组件的 Grafana 仪表盘、录制规则recording rules以及异常触发告警具体安装步骤见 安装仪表盘、告警与录制规则。需要特别留意的是mixins 中的仪表盘与告警期望指标带有cluster、namespace、job、container、pod、instance这些标签。Kubernetes Monitoring Helm Chart 之所以能与之配合正是因为它把集群名作为全局标签注入并通过 cAdvisor、kube-state-metrics、Node Exporter 采集了容器与节点指标。如果你的采集链路标签命名不同需要做 relabel 后才能让面板与告警正常显示数据。附录理解 Loki 暴露的观测数据为了让元监控真正发挥作用还需要理解被监控数据的语义相关细节可参考 Loki meta-monitoring 索引页 与 关键监控指标指南。指标Metrics所有 Loki 组件都暴露以下两个通用指标指标名类型说明loki_internal_log_messages_totalCounterLoki 自身产生的日志消息总数loki_request_duration_secondsHistogramHTTP 请求耗时秒可借助_count与_bucket后缀推导请求速率与延迟分位数完整的指标列表可通过各组件暴露的端点获取http://host:http_listen_port/metricsLoki 默认3100Alloy 默认12345。metrics.go查询日志行Loki 的 Querier、Query Frontend 与 Ruler 组件会为每次查询输出一条metrics.go日志行。以 Query Frontend 为例典型内容形如levelinfo ... callermetrics.go:285 componentfrontend org_idmycompany latencyfast querysum(count_over_time({kind\auditing\} | json [1m])) query_hash3897857977 query_typemetric range_typerange length10m0s step1s duration47.61044ms status200 throughput9.8MB total_bytes467kB total_lines8734 post_filter_lines1 total_entries1 splits2 shards0 cache_chunk_req1 cache_chunk_hit1 cache_index_req19 cache_index_hit19其中最有价值的字段包括query_hash查询文本的哈希用于关联同一条查询在 Query Frontend 与 Querier 两侧的日志行total_bytes / total_lines查询处理的总字节数与总行数duration / throughput查询执行耗时与吞吐throughput total_bytes / durationpost_filter_lines匹配查询过滤条件的行数splits / shards查询按时间split_queries_by_interval切分的片段数与按分片切分的数量cache_chunk_req为查询请求的 chunk 总数。日志行会带component字段区分来源componentfrontendQuery Frontend、componentquerierQuerier、componentrulerRuler额外带evaluation_mode字段。排障时建议优先看 Querier 的metrics.go行因为它能揭示 querier 在子查询执行上的时间开销。Loki 的日志级别默认是info可通过配置参数调整# Only log messages with the given severity or above. Valid levels: [debug, # info, warn, error] # CLI flag: -log.level [log_level: string | default info]在排查故障时还可以通过/log_levelHTTP 端点 在运行时动态调整日志级别而无需重启进程微服务模式下每个组件独立暴露该端点。小结至此你已经通过 Kubernetes Monitoring Helm Chart 为 Loki 集群建立了一套完整的元监控链路独立命名空间、凭证隔离、指标与日志双通道写入 Grafana Cloud或自管理 LGTM 栈并理解了仓库参考配置中各个采集组件的含义。接下来的重点是把 Loki Mixin 的仪表盘、录制规则与告警规则安装进 Grafana并定期在 Loki 升级时同步更新 mixin确保告警与指标始终匹配当前版本。【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 使用 Kubernetes Monitoring Helm Chart 为 Loki 部署元监控（Meta-monitoring）
使用 Kubernetes Monitoring Helm Chart 为 Loki 部署元监控Meta-monitoring【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki本篇指南以 deploy.md 为核心完整讲解如何基于 Grafana Kubernetes Monitoring Helm Chart 为运行在 Kubernetes 上的 Loki 集群部署一套独立、可观测的元监控meta-monitoring体系涵盖前置条件、Grafana Cloud 认证准备、values.yaml配置详解、Helm 部署与结果验证。读完本文后你将掌握一套可复制、可落地的 Loki 集群自监控部署方案并为后续安装 Loki Mixin 仪表盘与告警规则打下基础。什么是 Loki 元监控元监控meta-monitoring指的是监控监控系统本身在收集业务日志的同时Loki 集群自身的运行状况也需要被度量与观测。按照 Loki meta-monitoring 索引页 的最佳实践应当把 Loki 集群产生的观测数据收集到一个独立的 Loki、Prometheus 与 Grafana 实例中例如 Grafana Cloud 账号这样当被监控的 Loki 集群故障时你仍可以借助一套健康的监控环境进行排障避免监控系统与被监控系统一起宕机的窘境。Loki 对外暴露两类核心观测数据Metrics每个 Loki 组件都通过/metrics端点以 Prometheus 格式暴露自身指标默认端口3100用于观察查询响应时间、请求错误率等聚合健康信号LogsLoki 会为每一条查询在metrics.go中输出一条结构化日志行包含查询耗时、返回行数、吞吐量、执行的 LogQL、检索的 chunk 数等可直接用于查询性能的优化与排障。官方推荐的监控组件组合是Kubernetes Monitoring Helm Chart面向 Kubernetes 集群的综合性监控方案内置了对完整 LGTMLoki、Grafana、Tempo、Mimir栈的直接集成Grafana Cloud 或独立的 LGTM 栈作为观测数据的目的地sinkLoki Mixin一套带观点的仪表盘、告警与录制规则集用于在 Grafana 中可视化 Loki 集群状态。本文聚焦第一步——部署 Kubernetes Monitoring Helm Chart。对于不在 Helm chart 内以单二进制monolithic模式运行 Loki 的场景可参考 单二进制元监控指南 的替代方案。前置条件在开始部署前请确认以下环境要素均已就绪kubectl用于与 Kubernetes 集群交互Helm 3 或以上版本用于安装 chartHelm 2 与 3 的命令与行为差异较大请务必使用 Helm 3一个运行中的 Kubernetes 集群且集群内已部署一套正在运行的 Loki 集群一个 Grafana Cloud 账号或一套独立的 LGTM 栈作为监控数据的目的地。官方建议在生产环境中以分布式模式在 Kubernetes 上运行 Loki。虽然 Docker 或虚拟机部署方式下同样可以进行元监控但本文过程仅覆盖 Kubernetes Helm chart 的路径。第一步准备环境在部署 chart 之前需要先完成 Helm 仓库与命名空间的初始化。添加 Grafana 官方 Helm 仓库helm repo add grafana https://grafana.github.io/helm-charts更新本地 Helm 仓库索引确保能拉到最新版本的 charthelm repo update为监控栈创建独立的命名空间meta使监控组件与被监控的 Loki 集群默认位于loki命名空间隔离kubectl create namespace meta将监控栈放入独立命名空间是元监控的关键隔离手段即使 Loki 集群所在的命名空间出现问题监控采集链路依然能够存活。第二步配置认证与凭证Kubernetes Monitoring Helm Chart 需要凭证来向 Grafana Cloud 或独立 LGTM 栈推送遥测数据。下面以 Grafana Cloud 为例说明完整流程。创建 Grafana Cloud 访问策略Access Policy登录 Grafana Cloud进入主菜单Security Access Policies点击Create access policy为策略命名并勾选以下权限Metrics: WriteLogs: Write点击Create完成策略创建点击Add Token为策略添加令牌命名后创建并保存好该令牌供后续写入 Kubernetes Secret 使用。收集 Prometheus 与 Loki 实例的 URL 与用户名进入 Grafana Cloud Portal 的Overview页面点击 Prometheus 实例的Details按钮在Sending metrics using Grafana Alloy一节中收集该实例的username与url返回Overview页面再点击 Loki 实例的Details按钮在Sending Logs to Grafana Cloud using Grafana Alloy一节中收集 Loki 实例的username与url。创建 Kubernetes Secrets使用上一步收集的凭证创建两个 Secret分别对应 Metrics 与 Logs 两个数据目的地kubectl create secret generic metrics -n meta \ --from-literalusernamePROMETHEUS-USER \ --from-literalpasswordCLOUD-TOKEN kubectl create secret generic logs -n meta \ --from-literalusernameLOKI-USER \ --from-literalpasswordCLOUD-TOKEN两个 Secret 均创建在meta命名空间中username是各实例的用户名password都是同一个 Cloud Token。稍后values.yaml中的destinations[].secret会引用这两个 Secret 的名字实现凭证与配置的分离避免把敏感信息直接写进 Helm values。其他认证方式除了基本的用户名/密码Basic Auth外Kubernetes Monitoring Helm Chart 还支持多种认证方式可按需选择Bearer TokensOAuth2SigV4AWS 签名External Secrets外部 Secret 管理第三步下载并定制 values.yamlChart 的配置通过values.yaml注入。Loki 仓库在production/helm/meta-monitoring/目录下维护了一份开箱即用的参考配置部署前先将其下载到本地curl -O https://raw.githubusercontent.com/grafana/loki/main/production/helm/meta-monitoring/values.yaml该文件在仓库内的对应位置为 production/helm/meta-monitoring/values.yaml也可直接克隆 Loki 仓库后在本地查看。配置数据目的地destinations打开values.yaml配置 Prometheus 与 Loki 两个远端端点destinations: - name: prometheus type: prometheus url: https://PROMETHEUS-ENDPOINT/api/prom/push auth: type: basic usernameKey: username passwordKey: password secret: create: false name: metrics namespace: meta - name: loki type: loki url: https://LOKI-ENDPOINT/loki/api/v1/push auth: type: basic usernameKey: username passwordKey: password secret: create: false name: logs namespace: meta各字段含义如下字段说明destinations[].name目的地名称仅用于内部标识destinations[].type目的地类型Metrics 用prometheusLogs 用lokidestinations[].url远端写入端点Prometheus 的远端写入路径为/api/prom/pushLoki 的推送路径为/loki/api/v1/pushauth.type认证方式此处为basicBasic Authauth.usernameKey/passwordKey从 Secret 中取用户名与密码的字段名与上文创建 Secret 时的--from-literalkey 一一对应username、passwordsecret.create设为false表示复用预先创建的 Secret而不是让 chart 自动生成secret.name/namespace引用已创建的 Secret 名称与其所在命名空间metrics/logs均位于meta可选设置集群名称cluster.name会作为全局标签添加到所有遥测数据上建议设置为易识别的集群名便于在 Grafana Cloud 中区分多个集群# Global Label to be added to all telemetry data. Should reflect a recognizable name for the cluster. cluster: name: loki-meta-monitoring-cluster调整被监控的命名空间默认 values 假设 Loki 部署在loki命名空间监控栈部署在meta命名空间。如果你的 Loki 部署在其他命名空间需要同步修改namespaces列表namespaces: - loki如果希望从集群中所有命名空间收集数据直接删除namespaces键即可。仓库自带的 values.yaml 还展示了更多细节例如podLogs.namespaces同样列出了meta与loki两个命名空间。深入仓库 values.yaml 中的监控组件开关仓库中的参考配置远不止上述字段它同时给出了采集组件的完整开关理解这些开关有助于按需调整采集范围与元监控成本meta-monitoring budgetintegrations: collector: alloy-singleton alloy: instances: - name: alloy labelSelectors: app.kubernetes.io/name: [alloy-singleton] namespaces: - meta loki: instances: - name: loki namespaces: - loki labelSelectors: app.kubernetes.io/name: lokiintegrations.loki通过标签选择器app.kubernetes.io/name: loki采集 Loki 组件日志并可通过structuredMetadata提取caller、tenant、org_id、user等 logfmt 字段作为结构化元数据方便后续检索过滤clusterEvents开启后将 Kubernetes 事件作为日志采集默认监听meta与loki命名空间clusterMetrics集中控制各类指标采集器包括 cAdvisor采集 Loki Pod 指标默认自动部署、kubelet、kubeletResource、kube-state-metrics、node-exporter 等可按需关闭以控制数据量与成本podLogs开启 Pod 日志采集并通过labelsToKeep保留app、namespace、component、container、job等关键标签alloy-singleton以单实例模式部署 Alloy Collector作为上述所有采集任务的执行者alloy-metrics、alloy-logs、alloy-profiles、alloy-receiver默认关闭。默认的global.scrapeInterval为15s即 Alloy 组件的全局抓取间隔。第四步部署 Helm Chart使用定制好的values.yaml执行安装helm install meta-loki grafana/k8s-monitoring \ --namespace meta \ -f values.yaml该命令会以meta-loki为 release 名称将 Kubernetes Monitoring Chart 安装到meta命名空间。关于 chart 的更多背景可阅读仓库中的 production/helm/meta-monitoring/README.md其中还包含自管理self-managedPrometheus/Loki/Grafana 栈的 Secret 创建示例。第五步验证部署结果检查meta命名空间下的 Pod 运行状态kubectl get pods -n meta正常情况下你会看到一批运行中的 Pod大致如下NAME READY STATUS RESTARTS ... meta-loki-alloy-singleton-6d7f8d8b86-sg4wx 2/2 Running 0 ... meta-loki-kube-state-metrics-64bdcfcbd-5snqz 1/1 Running 0 ... meta-loki-node-exporter-855l5 1/1 Running 0 ... meta-loki-node-exporter-b976b 1/1 Running 0 ... meta-loki-node-exporter-vsm4s 1/1 Running 0 ...alloy-singleton承担指标与日志采集、转发任务的 Alloy 采集器kube-state-metrics监听 Kubernetes API Server生成集群对象状态指标node-exporter每个节点一个采集节点级指标。全部 Pod 处于Running状态即表示元监控链路已打通。此后Loki 集群的指标与日志会持续写入 Grafana Cloud或你配置的 LGTM 栈。下一步安装 Loki Mixin部署成功后即可进入元监控的下一环节——安装 Loki Mixin用预置的仪表盘与告警规则可视化 Loki 集群状态。Loki 每个版本都会发布一份 mixin包含面向整体集群与单个组件的 Grafana 仪表盘、录制规则recording rules以及异常触发告警具体安装步骤见 安装仪表盘、告警与录制规则。需要特别留意的是mixins 中的仪表盘与告警期望指标带有cluster、namespace、job、container、pod、instance这些标签。Kubernetes Monitoring Helm Chart 之所以能与之配合正是因为它把集群名作为全局标签注入并通过 cAdvisor、kube-state-metrics、Node Exporter 采集了容器与节点指标。如果你的采集链路标签命名不同需要做 relabel 后才能让面板与告警正常显示数据。附录理解 Loki 暴露的观测数据为了让元监控真正发挥作用还需要理解被监控数据的语义相关细节可参考 Loki meta-monitoring 索引页 与 关键监控指标指南。指标Metrics所有 Loki 组件都暴露以下两个通用指标指标名类型说明loki_internal_log_messages_totalCounterLoki 自身产生的日志消息总数loki_request_duration_secondsHistogramHTTP 请求耗时秒可借助_count与_bucket后缀推导请求速率与延迟分位数完整的指标列表可通过各组件暴露的端点获取http://host:http_listen_port/metricsLoki 默认3100Alloy 默认12345。metrics.go查询日志行Loki 的 Querier、Query Frontend 与 Ruler 组件会为每次查询输出一条metrics.go日志行。以 Query Frontend 为例典型内容形如levelinfo ... callermetrics.go:285 componentfrontend org_idmycompany latencyfast querysum(count_over_time({kind\auditing\} | json [1m])) query_hash3897857977 query_typemetric range_typerange length10m0s step1s duration47.61044ms status200 throughput9.8MB total_bytes467kB total_lines8734 post_filter_lines1 total_entries1 splits2 shards0 cache_chunk_req1 cache_chunk_hit1 cache_index_req19 cache_index_hit19其中最有价值的字段包括query_hash查询文本的哈希用于关联同一条查询在 Query Frontend 与 Querier 两侧的日志行total_bytes / total_lines查询处理的总字节数与总行数duration / throughput查询执行耗时与吞吐throughput total_bytes / durationpost_filter_lines匹配查询过滤条件的行数splits / shards查询按时间split_queries_by_interval切分的片段数与按分片切分的数量cache_chunk_req为查询请求的 chunk 总数。日志行会带component字段区分来源componentfrontendQuery Frontend、componentquerierQuerier、componentrulerRuler额外带evaluation_mode字段。排障时建议优先看 Querier 的metrics.go行因为它能揭示 querier 在子查询执行上的时间开销。Loki 的日志级别默认是info可通过配置参数调整# Only log messages with the given severity or above. Valid levels: [debug, # info, warn, error] # CLI flag: -log.level [log_level: string | default info]在排查故障时还可以通过/log_levelHTTP 端点 在运行时动态调整日志级别而无需重启进程微服务模式下每个组件独立暴露该端点。小结至此你已经通过 Kubernetes Monitoring Helm Chart 为 Loki 集群建立了一套完整的元监控链路独立命名空间、凭证隔离、指标与日志双通道写入 Grafana Cloud或自管理 LGTM 栈并理解了仓库参考配置中各个采集组件的含义。接下来的重点是把 Loki Mixin 的仪表盘、录制规则与告警规则安装进 Grafana并定期在 Loki 升级时同步更新 mixin确保告警与指标始终匹配当前版本。【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考