用 Kubernetes Monitoring Helm Chart 为 Loki 构建 Meta-monitoring 可观测体系【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/lokiLoki 自身会通过/metrics端点暴露大量运行指标本篇文章讲解如何基于 Grafana Kubernetes Monitoring Helm Chartk8s-monitoring为 Loki 部署一套“元监控meta-monitoring”方案用 Grafana Alloy 采集 Loki 的指标与日志配合仓库内预编译的 Loki mixin 面板和告警规则实现开箱即用的集群监控。读完本文你将掌握 chart 4.x / 3.8.x 两个版本线的 values 文件选用、凭证与 Secret 配置、命名空间作用域调整以及 dashboards / alerts / recording rules 的完整安装流程。目录与文件结构meta-monitoring 的 Helm 资源位于仓库的 production/helm/meta-monitoring 目录包含三个文件文件用途README.md本篇文章对应的源文档说明部署与配置方法values.yaml面向k8s-monitoring chart 4.x的默认 values 文件values-chart-v3.yaml面向k8s-monitoring chart 3.8.x维护中的稳定线的 values 文件对应的监控告警资产位于 production/loki-mixin-compiled而官方配套的逐步部署指南可在 docs/sources/operations/meta-monitoring/deploy.md 与 docs/sources/operations/meta-monitoring/mixins.md 中找到。方案概览Alloy 采集 Loki mixin 消费Meta-monitoring 的核心思路是用另一套可观测后端来监控 Loki 自己。该 chart 基于 Grafana Kubernetes Monitoring Helm Chartk8s-monitoring构建使用 Grafana Alloy一个 OpenTelemetry Collector 发行版作为采集器收集 Loki 部署的指标metrics与日志logs然后发送到你所选的可观测性后端Grafana Cloud或自建 Prometheus/Loki/Grafana 栈。它被设计为与 Loki 预编译的 mixin 配合使用采集的指标落入 Prometheus 兼容的时间序列库Grafana Cloud Metrics / Mimir / 自建 Prometheusproduction/loki-mixin-compiled 中的 Grafana 面板与告警规则直接消费这些指标采集的日志落入 Loki 后端用于日志检索与排障。两个 values 文件两个 chart 版本线k8s-monitoring 在 4.0.0 版本引入了破坏性变更destinations与collectors的格式改变日志采集结构重组因此本目录维护两份 values 文件两个版本线目前都由上游持续维护values.yaml面向chart 4.x当前主线安装时固定--version ^4values-chart-v3.yaml面向chart 3.8.x受支持的稳定线安装时固定--version ^3。务必始终用--version固定与 values 文件匹配的 chart 版本。若以未固定的 chart 版本安装可能解析到错误的大版本而导致安装失败。前置条件kubectl且有一个可访问的 Kubernetes 集群集群上已运行 Loki 部署Helm 3.x可访问 Grafana Cloud或自建 Prometheus/Loki/Grafana 栈作为监控目的地自建目的地时凭据需预先存入 Kubernetes Secret。官方文档 deploy.md 强调推荐以分布式模式在 Kubernetes 上运行生产级 Loki。若你在 Helm chart 之外以单二进制模式运行 Loki可参考 single-binary.md 的单二进制元监控方案。安装步骤1. 准备 Helm 仓库与命名空间helm repo add grafana https://grafana.github.io/helm-charts helm repo update kubectl create namespace meta监控栈默认部署在meta命名空间Loki 默认假设部署在loki命名空间。2. 为可观测后端创建 Secretchart 的默认认证方式是 basic auth凭据来自 Kubernetes Secret# 面向 Grafana Cloud 或自建栈 kubectl create namespace meta kubectl create secret generic metrics --namespace meta \ --from-literalusernameYOUR_PROMETHEUS_USERNAME \ --from-literalpasswordYOUR_PROMETHEUS_PASSWORD kubectl create secret generic logs --namespace meta \ --from-literalusernameYOUR_LOKI_USERNAME \ --from-literalpasswordYOUR_LOKI_PASSWORD使用 Grafana Cloud 时官方流程是先创建 Cloud Access Policy授予 Metrics: Write、Logs: Write 权限并生成 token再从 Portal Overview 中收集 Prometheus 与 Loki 实例的username与url最后以上述形式写入 Secret详见 deploy.md。除 basic auth 外chart 还支持 Bearer Token、OAuth2、SigV4、External Secrets 等更高级的认证方式对应示例可在 k8s-monitoring chart 的 auth examples 目录中查看。3. 安装 chart按版本线选择 values 文件# Chart 4.x当前主线 helm install meta-loki grafana/k8s-monitoring \ --namespace meta \ --version ^4 \ -f values.yaml # Chart 3.8.x受支持的稳定线 helm install meta-loki grafana/k8s-monitoring \ --namespace meta \ --version ^3 \ -f values-chart-v3.yaml安装完成后验证kubectl get pods -n meta预期会看到meta-loki-alloy-operator、meta-loki-alloy-singleton、meta-loki-kube-state-metrics、meta-loki-node-exporter等 Pod 处于 Running 状态具体名称与数量取决于集群规模与启用的特性。配置解析destinations 与两个版本线的差异默认配置面向 Grafana Cloud若要指向自建监控栈只需修改所用 values 文件中的destinations。两个版本线的格式不同4.x 使用以目的地名称为键的 map3.8.x 使用带name字段的 list。# values.yaml (chart 4.x)map 形式键为目的地名 destinations: prometheus: type: prometheus url: https://PROMETHEUS-ENDPOINT/api/prom/push auth: type: basic usernameKey: username passwordKey: password secret: create: false name: metrics namespace: meta 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# values-chart-v3.yaml (chart 3.8.x)list 形式带 name 字段 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要点说明url中 Prometheus 使用/api/prom/pushremote write 推送端点Loki 使用/loki/api/v1/push日志推送端点auth.type: basic表示从 Secret 中读取usernameKey/passwordKey指定的键作为用户名与密码secret.create: false表示不由 chart 创建 Secret而是引用已有的metrics/logsSecretsecret.namespace必须与 Secret 实际所在命名空间一致默认meta。全局与集群标识# 全局抓取间隔作用于所有 Alloy 组件 global: scrapeInterval: 15s # 追加到所有遥测数据上的全局标签建议设为可识别的集群名 cluster: name: loki-meta-monitoring-clustercluster.name会作为全局标签附加到所有指标与日志上——这正是 mixin 面板与告警中cluster标签的来源。核心特性与采集配置README 中列出的核心特性均能在 values.yaml 中找到对应配置特性说明values 配置键集群事件采集将 Kubernetes 事件作为日志捕获并附加元数据便于检索过滤clusterEvents指标采集使用 cAdvisor、kubelet、kube-state-metrics 采集容器/节点/资源对象指标clusterMetrics、hostMetricsPod 日志采集采集 Loki 各组件 Pod 的日志podLogsViaKubernetesApi4.x/podLogs3.8.x集成面板与预编译的 Loki mixin 面板联动对应production/loki-mixin-compiled告警规则针对 Loki 各组件的预配置告警对应production/loki-mixin-compiled/alerts.yamlintegrations监控对象发现integrations: collector: alloy-singleton alloy: instances: # 监控本集群内负责采集与发送的 Alloy 采集器自身 - name: alloy labelSelectors: app.kubernetes.io/name: [alloy-singleton] namespaces: - meta loki: instances: - name: loki namespaces: - loki labelSelectors: app.kubernetes.io/name: loki logs: tuning: # 提取 logfmt 字段并设置为结构化元数据 structuredMetadata: caller: tenant: org_id: user:integrations.alloy监控元监控栈自身的 Alloy 采集器通过app.kubernetes.io/name: alloy-singleton标签选择integrations.loki通过app.kubernetes.io/name: loki标签选择 Loki 组件并对其日志做结构化元数据提取caller、tenant、org_id、user等 logfmt 字段会被提升为结构化元数据便于后续 LogQL 过滤。集群指标与主机指标clusterMetrics: enabled: true collector: alloy-singleton kubelet: enabled: true kubeletResource: enabled: true cadvisor: enabled: true metricsTuning: includeNamespaces: - loki - meta kube-state-metrics: enabled: true metricsTuning: useDefaultAllowList: false includeMetrics: [(.)]cAdvisor采集 Loki Pod 的容器指标自动部署此处将指标过滤范围限定在loki与meta命名空间kubelet / kubeletResource采集节点上的 Kubernetes 信息与资源指标kube-state-metrics监听 Kubernetes API Server 并生成资源对象状态指标此处关闭默认允许列表、抓取全部指标includeMetrics: [(.)]。chart 4.x 将 node-exporter 等从clusterMetrics中移出改由hostMetrics承载hostMetrics: enabled: true collector: alloy-singleton linuxHosts: enabled: true metricsTuning: useIntegrationAllowList: true配套的telemetryServices负责部署上述特性依赖的服务kube-state-metrics供 clusterMetrics 使用其命名空间作用域在 4.x 中必须在这里设置格式支持 list 或逗号分隔字符串如loki,meta和 node-exporter供 hostMetrics.linuxHosts 使用。Pod 日志采集4.x 与 3.8.x 的结构差异chart 4.x 将原来的单一podLogs特性拆分为podLogsViaKubernetesApi、podLogsViaLoki、podLogsViaOpenTelemetry三个子特性。4.x 的 values 文件保留了原先的kubernetesApi采集方式podLogsViaKubernetesApi: enabled: true collector: alloy-singleton namespaces: - meta - loki labels: app: app app_kubernetes_io_name: app.kubernetes.io/name component: app.kubernetes.io/component structuredMetadata: # chart 会跳过 null 值因此标签名必须显式重复写出 pod: pod值得注意的标签说明来自 values 文件注释namespace、pod、container、job由该特性自动附加无需在此列出level、service_name、cluster来自日志行处理与全局 cluster 标签而app、component来自 Kubernetes Pod 标签而非 Alloy 的发现元数据因此需要显式映射。若你依赖其他 Kubernetes Pod 标签成为 Loki 标签请检查并扩展此映射。3.8.x 版本线则使用podLogslabelsToKeep的旧式配置podLogs: enabled: true collector: alloy-singleton labelsToKeep: - app - app_kubernetes_io_name - component - container - job - level - namespace - service_name - cluster gatherMethod: kubernetesApi namespaces: - meta - loki集群事件采集clusterEvents: enabled: true collector: alloy-singleton namespaces: - meta - loki可选特性将meta与loki命名空间的 Kubernetes 事件捕获为日志并附加额外元数据使其更易检索与过滤。采集器定义# 4.xcollectors 是必填键缺少或为空会导致安装失败 collectors: alloy-singleton: presets: [singleton] # 3.8.x以顶层键声明各采集器只启用 alloy-singleton alloy-singleton: enabled: true alloy-metrics: enabled: false alloy-logs: enabled: falsealloy-singleton是在集群中部署的单实例 Alloy Collector本目录所有特性都指派给它。4.x 中若新增或重命名采集器必须同步更新文件中所有collector: alloy-singleton引用否则安装会以缺失采集器的报错失败。命名空间作用域调整如果 Loki 不在loki命名空间、或监控栈不在meta命名空间需要修改多个配置键——不存在单一的namespaces键每个特性的命名空间作用域是独立设置的。下表来自 deploy.mdKey格式用途integrations.loki.instances[0].namespaceslist发现 Loki 实例的命名空间integrations.alloy.instances[0].namespaceslist发现监控栈自身 Alloy 采集器的命名空间clusterEvents.namespaceslist采集 Kubernetes 事件的命名空间clusterMetrics.cadvisor.metricsTuning.includeNamespaceslist保留 cAdvisor 指标的命名空间指标过滤器非发现范围telemetryServices.kube-state-metrics.namespaceslist 或逗号分隔字符串采集 Kubernetes 资源状态的命名空间4.x 中必须在此键下设置写在clusterMetrics下无效podLogsViaKubernetesApi.namespaceslist采集 Pod 日志的命名空间例如向 Loki 发现范围追加命名空间integrations: loki: instances: - name: loki namespaces: - loki每个键默认为空列表表示从所有命名空间采集移除某个键只会恢复该特性自身的默认值不影响表中其他键。同时注意destinations.prometheus.secret.namespace与destinations.loki.secret.namespace必须与你创建metrics/logsSecret 的命名空间一致默认meta。监控范围综合来看该 meta-monitoring chart 监控以下对象Loki 组件通过标签选择器app.kubernetes.io/name: loki发现meta命名空间中的 Alloy 采集器自身app.kubernetes.io/name: alloy-singletonloki与meta命名空间中的 Kubernetes 资源事件、节点指标、Pod 日志等。安装 Loki Mixin 编译资产部署 chart 后metrics 会持续写入 Prometheus 兼容后端。接下来安装预编译的 mixin 资产来消费这些数据。编译产物位于 production/loki-mixin-compiledproduction/loki-mixin-compiled/ ├── dashboards/ # 预编译的 Grafana 面板JSON ├── alerts.yaml # 面向 Loki 组件的告警规则 └── rules.yaml # 供面板与告警使用的 recording rulesdashboards 目录清单dashboards 包含 12 个可直接导入 Grafana 的 JSON 面板loki-operational.json、loki-logs.json整体运行与日志检索总览loki-reads.json、loki-reads-resources.json查询/读取路径及其资源占用loki-writes.json、loki-writes-resources.json写入路径及其资源占用loki-chunks.jsonchunk 生命周期与压缩情况loki-retention.json、loki-deletion.json保留策略与删除操作loki-bloom-gateway.jsonBloom 网关相关loki-thanos-object-storage.json对象存储兼容 Thanos 语义相关loki-mixin-recording-rules.jsonrecording rules 结果的展示面板导入 Grafana 面板界面操作进入 Grafana UI选择Dashboards → Import上传 JSON 文件或粘贴其内容配置数据源应指向你的 Prometheus/Mimir点击Import。建议先创建一个文件夹例如 Loki Monitoring统一存放导入的面板面板一次只能导入一个官方建议全部安装。也可通过 Grafana API 编程导入curl -X POST -H Content-Type: application/json \ -H Authorization: Bearer YOUR_API_KEY \ -d path/to/dashboard.json \ https://your-grafana-instance/api/dashboards/db重要前提来自 mixins.md面板与告警期望指标携带cluster、namespace、job、container、pod、instance这些标签。Kubernetes Monitoring chart 恰好提供它们——通过全局 cluster 标签、cAdvisor 与 kube-state-metrics 的容器/节点指标。若你的采集链路使用了不同标签名或未采集容器与节点指标部分面板与告警会无数据直到你 relabel 指标以匹配预期标签。加载告警与记录规则面向 Grafana Cloud Prometheus / Mimir使用 mimirtool# 安装 mimirtool go install github.com/grafana/mimir/pkg/mimirtoollatest # 加载告警规则 mimirtool rules load alerts.yaml \ --addresshttps://prometheus-prod-xxx.grafana.net/api/prom \ --idYour-Stack-ID \ --keyYour-API-Key # 加载记录规则 mimirtool rules load rules.yaml \ --addresshttps://prometheus-prod-xxx.grafana.net/api/prom \ --idYour-Stack-ID \ --keyYour-API-Keymixins.md 提供了更简洁的凭据方式先创建带 Alerts/Rules 读写权限的 Access Policy 获取 token然后导出环境变量MIMIR_ADDRESS、MIMIR_API_USER、MIMIR_API_KEY、MIMIR_TENANT_ID即可直接运行mimirtool rules load rules.yaml # 记录规则部分面板显示数据所必需 mimirtool rules load alerts.yaml # 可选告警规则面向自建 Prometheuscp rules.yaml alerts.yaml /etc/prometheus/rules/ # 然后重载 Prometheus 配置 curl -X POST http://prometheus:9090/-/reload告警与记录规则的内容构成alerts.yaml 中的告警组loki_alerts包含告警名触发条件严重级别LokiRequestErrors按 cluster/namespace/job/route 统计的 5xx 错误率 10%持续 15 分钟criticalLokiRequestPanics10 分钟内loki_panic_total增量 0代码 paniccriticalLokiRequestLatency99 分位延迟 1s持续 15 分钟排除 tail 与 scheduler 路由criticalLokiTooManyCompactorsRunning同时运行超过 1 个 compactor持续 5 分钟warningLokiCompactorHasNotSuccessfullyRunCompaction距离上次成功压缩超过 3 小时或启动后 3 小时内从未成功压缩criticalrules.yaml 中的规则组loki_rules基于loki_request_duration_seconds直方图预聚合出一批 recording rules例如- expr: histogram_quantile(0.99, sum(rate(loki_request_duration_seconds_bucket[1m])) by (le, cluster, job)) record: cluster_job:loki_request_duration_seconds:99quantile - expr: histogram_quantile(0.99, sum(rate(loki_request_duration_seconds_bucket[1m])) by (le, cluster, namespace, job, route)) record: cluster_namespace_job_route:loki_request_duration_seconds:99quantile这些预聚合指标正是上述LokiRequestLatency告警表达式cluster_namespace_job_route:loki_request_duration_seconds:99quantile与各面板的数据来源——rules.yaml对部分面板显示数据是必需的应优先加载。若需自定义 mixin修改源文件位于 production/loki-mixinjsonnet 源并按该目录 README 说明重新生成编译产物到loki-mixin-compiled。关键监控指标速查配合 metrics.md 中的高信号指标你可以不依赖面板直接用 PromQL 排查问题注意cluster、namespace、job来自抓取配置并非指标自带标签请求错误率——优先观察 5xx 比例的持续上升100 * sum(rate(loki_request_duration_seconds_count{status_code~5..}[2m])) by (cluster, namespace, job, route) / sum(rate(loki_request_duration_seconds_count[2m])) by (cluster, namespace, job, route)请求延迟 p99——关注 query-frontend 与 distributor 路径histogram_quantile(0.99, sum(rate(loki_request_duration_seconds_bucket[1m])) by (le, cluster, namespace, job, route))Panic 计数——应始终为零sum(increase(loki_panic_total[10m])) by (cluster, namespace, job)后续步骤发送日志部署完成后即可向 Loki 发送业务日志相关方式可查阅仓库 docs/sources/send-data查询日志使用 LogQL 检索与洞察日志参考 docs/sources/query告警可基于日志查询利用 Loki ruler 组件创建告警参考 docs/sources/alert升级注意每次升级 Loki 后应重新核对 mixin 资产确保面板与告警与当前版本的指标保持一致。在 docs/sources/operations/meta-monitoring 目录下还有更多相关文档如 chart 3 版本的部署指南 deploy-chart-v3.md可作为本文的延伸阅读。【免费下载链接】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/lokiLoki 自身会通过/metrics端点暴露大量运行指标本篇文章讲解如何基于 Grafana Kubernetes Monitoring Helm Chartk8s-monitoring为 Loki 部署一套“元监控meta-monitoring”方案用 Grafana Alloy 采集 Loki 的指标与日志配合仓库内预编译的 Loki mixin 面板和告警规则实现开箱即用的集群监控。读完本文你将掌握 chart 4.x / 3.8.x 两个版本线的 values 文件选用、凭证与 Secret 配置、命名空间作用域调整以及 dashboards / alerts / recording rules 的完整安装流程。目录与文件结构meta-monitoring 的 Helm 资源位于仓库的 production/helm/meta-monitoring 目录包含三个文件文件用途README.md本篇文章对应的源文档说明部署与配置方法values.yaml面向k8s-monitoring chart 4.x的默认 values 文件values-chart-v3.yaml面向k8s-monitoring chart 3.8.x维护中的稳定线的 values 文件对应的监控告警资产位于 production/loki-mixin-compiled而官方配套的逐步部署指南可在 docs/sources/operations/meta-monitoring/deploy.md 与 docs/sources/operations/meta-monitoring/mixins.md 中找到。方案概览Alloy 采集 Loki mixin 消费Meta-monitoring 的核心思路是用另一套可观测后端来监控 Loki 自己。该 chart 基于 Grafana Kubernetes Monitoring Helm Chartk8s-monitoring构建使用 Grafana Alloy一个 OpenTelemetry Collector 发行版作为采集器收集 Loki 部署的指标metrics与日志logs然后发送到你所选的可观测性后端Grafana Cloud或自建 Prometheus/Loki/Grafana 栈。它被设计为与 Loki 预编译的 mixin 配合使用采集的指标落入 Prometheus 兼容的时间序列库Grafana Cloud Metrics / Mimir / 自建 Prometheusproduction/loki-mixin-compiled 中的 Grafana 面板与告警规则直接消费这些指标采集的日志落入 Loki 后端用于日志检索与排障。两个 values 文件两个 chart 版本线k8s-monitoring 在 4.0.0 版本引入了破坏性变更destinations与collectors的格式改变日志采集结构重组因此本目录维护两份 values 文件两个版本线目前都由上游持续维护values.yaml面向chart 4.x当前主线安装时固定--version ^4values-chart-v3.yaml面向chart 3.8.x受支持的稳定线安装时固定--version ^3。务必始终用--version固定与 values 文件匹配的 chart 版本。若以未固定的 chart 版本安装可能解析到错误的大版本而导致安装失败。前置条件kubectl且有一个可访问的 Kubernetes 集群集群上已运行 Loki 部署Helm 3.x可访问 Grafana Cloud或自建 Prometheus/Loki/Grafana 栈作为监控目的地自建目的地时凭据需预先存入 Kubernetes Secret。官方文档 deploy.md 强调推荐以分布式模式在 Kubernetes 上运行生产级 Loki。若你在 Helm chart 之外以单二进制模式运行 Loki可参考 single-binary.md 的单二进制元监控方案。安装步骤1. 准备 Helm 仓库与命名空间helm repo add grafana https://grafana.github.io/helm-charts helm repo update kubectl create namespace meta监控栈默认部署在meta命名空间Loki 默认假设部署在loki命名空间。2. 为可观测后端创建 Secretchart 的默认认证方式是 basic auth凭据来自 Kubernetes Secret# 面向 Grafana Cloud 或自建栈 kubectl create namespace meta kubectl create secret generic metrics --namespace meta \ --from-literalusernameYOUR_PROMETHEUS_USERNAME \ --from-literalpasswordYOUR_PROMETHEUS_PASSWORD kubectl create secret generic logs --namespace meta \ --from-literalusernameYOUR_LOKI_USERNAME \ --from-literalpasswordYOUR_LOKI_PASSWORD使用 Grafana Cloud 时官方流程是先创建 Cloud Access Policy授予 Metrics: Write、Logs: Write 权限并生成 token再从 Portal Overview 中收集 Prometheus 与 Loki 实例的username与url最后以上述形式写入 Secret详见 deploy.md。除 basic auth 外chart 还支持 Bearer Token、OAuth2、SigV4、External Secrets 等更高级的认证方式对应示例可在 k8s-monitoring chart 的 auth examples 目录中查看。3. 安装 chart按版本线选择 values 文件# Chart 4.x当前主线 helm install meta-loki grafana/k8s-monitoring \ --namespace meta \ --version ^4 \ -f values.yaml # Chart 3.8.x受支持的稳定线 helm install meta-loki grafana/k8s-monitoring \ --namespace meta \ --version ^3 \ -f values-chart-v3.yaml安装完成后验证kubectl get pods -n meta预期会看到meta-loki-alloy-operator、meta-loki-alloy-singleton、meta-loki-kube-state-metrics、meta-loki-node-exporter等 Pod 处于 Running 状态具体名称与数量取决于集群规模与启用的特性。配置解析destinations 与两个版本线的差异默认配置面向 Grafana Cloud若要指向自建监控栈只需修改所用 values 文件中的destinations。两个版本线的格式不同4.x 使用以目的地名称为键的 map3.8.x 使用带name字段的 list。# values.yaml (chart 4.x)map 形式键为目的地名 destinations: prometheus: type: prometheus url: https://PROMETHEUS-ENDPOINT/api/prom/push auth: type: basic usernameKey: username passwordKey: password secret: create: false name: metrics namespace: meta 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# values-chart-v3.yaml (chart 3.8.x)list 形式带 name 字段 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要点说明url中 Prometheus 使用/api/prom/pushremote write 推送端点Loki 使用/loki/api/v1/push日志推送端点auth.type: basic表示从 Secret 中读取usernameKey/passwordKey指定的键作为用户名与密码secret.create: false表示不由 chart 创建 Secret而是引用已有的metrics/logsSecretsecret.namespace必须与 Secret 实际所在命名空间一致默认meta。全局与集群标识# 全局抓取间隔作用于所有 Alloy 组件 global: scrapeInterval: 15s # 追加到所有遥测数据上的全局标签建议设为可识别的集群名 cluster: name: loki-meta-monitoring-clustercluster.name会作为全局标签附加到所有指标与日志上——这正是 mixin 面板与告警中cluster标签的来源。核心特性与采集配置README 中列出的核心特性均能在 values.yaml 中找到对应配置特性说明values 配置键集群事件采集将 Kubernetes 事件作为日志捕获并附加元数据便于检索过滤clusterEvents指标采集使用 cAdvisor、kubelet、kube-state-metrics 采集容器/节点/资源对象指标clusterMetrics、hostMetricsPod 日志采集采集 Loki 各组件 Pod 的日志podLogsViaKubernetesApi4.x/podLogs3.8.x集成面板与预编译的 Loki mixin 面板联动对应production/loki-mixin-compiled告警规则针对 Loki 各组件的预配置告警对应production/loki-mixin-compiled/alerts.yamlintegrations监控对象发现integrations: collector: alloy-singleton alloy: instances: # 监控本集群内负责采集与发送的 Alloy 采集器自身 - name: alloy labelSelectors: app.kubernetes.io/name: [alloy-singleton] namespaces: - meta loki: instances: - name: loki namespaces: - loki labelSelectors: app.kubernetes.io/name: loki logs: tuning: # 提取 logfmt 字段并设置为结构化元数据 structuredMetadata: caller: tenant: org_id: user:integrations.alloy监控元监控栈自身的 Alloy 采集器通过app.kubernetes.io/name: alloy-singleton标签选择integrations.loki通过app.kubernetes.io/name: loki标签选择 Loki 组件并对其日志做结构化元数据提取caller、tenant、org_id、user等 logfmt 字段会被提升为结构化元数据便于后续 LogQL 过滤。集群指标与主机指标clusterMetrics: enabled: true collector: alloy-singleton kubelet: enabled: true kubeletResource: enabled: true cadvisor: enabled: true metricsTuning: includeNamespaces: - loki - meta kube-state-metrics: enabled: true metricsTuning: useDefaultAllowList: false includeMetrics: [(.)]cAdvisor采集 Loki Pod 的容器指标自动部署此处将指标过滤范围限定在loki与meta命名空间kubelet / kubeletResource采集节点上的 Kubernetes 信息与资源指标kube-state-metrics监听 Kubernetes API Server 并生成资源对象状态指标此处关闭默认允许列表、抓取全部指标includeMetrics: [(.)]。chart 4.x 将 node-exporter 等从clusterMetrics中移出改由hostMetrics承载hostMetrics: enabled: true collector: alloy-singleton linuxHosts: enabled: true metricsTuning: useIntegrationAllowList: true配套的telemetryServices负责部署上述特性依赖的服务kube-state-metrics供 clusterMetrics 使用其命名空间作用域在 4.x 中必须在这里设置格式支持 list 或逗号分隔字符串如loki,meta和 node-exporter供 hostMetrics.linuxHosts 使用。Pod 日志采集4.x 与 3.8.x 的结构差异chart 4.x 将原来的单一podLogs特性拆分为podLogsViaKubernetesApi、podLogsViaLoki、podLogsViaOpenTelemetry三个子特性。4.x 的 values 文件保留了原先的kubernetesApi采集方式podLogsViaKubernetesApi: enabled: true collector: alloy-singleton namespaces: - meta - loki labels: app: app app_kubernetes_io_name: app.kubernetes.io/name component: app.kubernetes.io/component structuredMetadata: # chart 会跳过 null 值因此标签名必须显式重复写出 pod: pod值得注意的标签说明来自 values 文件注释namespace、pod、container、job由该特性自动附加无需在此列出level、service_name、cluster来自日志行处理与全局 cluster 标签而app、component来自 Kubernetes Pod 标签而非 Alloy 的发现元数据因此需要显式映射。若你依赖其他 Kubernetes Pod 标签成为 Loki 标签请检查并扩展此映射。3.8.x 版本线则使用podLogslabelsToKeep的旧式配置podLogs: enabled: true collector: alloy-singleton labelsToKeep: - app - app_kubernetes_io_name - component - container - job - level - namespace - service_name - cluster gatherMethod: kubernetesApi namespaces: - meta - loki集群事件采集clusterEvents: enabled: true collector: alloy-singleton namespaces: - meta - loki可选特性将meta与loki命名空间的 Kubernetes 事件捕获为日志并附加额外元数据使其更易检索与过滤。采集器定义# 4.xcollectors 是必填键缺少或为空会导致安装失败 collectors: alloy-singleton: presets: [singleton] # 3.8.x以顶层键声明各采集器只启用 alloy-singleton alloy-singleton: enabled: true alloy-metrics: enabled: false alloy-logs: enabled: falsealloy-singleton是在集群中部署的单实例 Alloy Collector本目录所有特性都指派给它。4.x 中若新增或重命名采集器必须同步更新文件中所有collector: alloy-singleton引用否则安装会以缺失采集器的报错失败。命名空间作用域调整如果 Loki 不在loki命名空间、或监控栈不在meta命名空间需要修改多个配置键——不存在单一的namespaces键每个特性的命名空间作用域是独立设置的。下表来自 deploy.mdKey格式用途integrations.loki.instances[0].namespaceslist发现 Loki 实例的命名空间integrations.alloy.instances[0].namespaceslist发现监控栈自身 Alloy 采集器的命名空间clusterEvents.namespaceslist采集 Kubernetes 事件的命名空间clusterMetrics.cadvisor.metricsTuning.includeNamespaceslist保留 cAdvisor 指标的命名空间指标过滤器非发现范围telemetryServices.kube-state-metrics.namespaceslist 或逗号分隔字符串采集 Kubernetes 资源状态的命名空间4.x 中必须在此键下设置写在clusterMetrics下无效podLogsViaKubernetesApi.namespaceslist采集 Pod 日志的命名空间例如向 Loki 发现范围追加命名空间integrations: loki: instances: - name: loki namespaces: - loki每个键默认为空列表表示从所有命名空间采集移除某个键只会恢复该特性自身的默认值不影响表中其他键。同时注意destinations.prometheus.secret.namespace与destinations.loki.secret.namespace必须与你创建metrics/logsSecret 的命名空间一致默认meta。监控范围综合来看该 meta-monitoring chart 监控以下对象Loki 组件通过标签选择器app.kubernetes.io/name: loki发现meta命名空间中的 Alloy 采集器自身app.kubernetes.io/name: alloy-singletonloki与meta命名空间中的 Kubernetes 资源事件、节点指标、Pod 日志等。安装 Loki Mixin 编译资产部署 chart 后metrics 会持续写入 Prometheus 兼容后端。接下来安装预编译的 mixin 资产来消费这些数据。编译产物位于 production/loki-mixin-compiledproduction/loki-mixin-compiled/ ├── dashboards/ # 预编译的 Grafana 面板JSON ├── alerts.yaml # 面向 Loki 组件的告警规则 └── rules.yaml # 供面板与告警使用的 recording rulesdashboards 目录清单dashboards 包含 12 个可直接导入 Grafana 的 JSON 面板loki-operational.json、loki-logs.json整体运行与日志检索总览loki-reads.json、loki-reads-resources.json查询/读取路径及其资源占用loki-writes.json、loki-writes-resources.json写入路径及其资源占用loki-chunks.jsonchunk 生命周期与压缩情况loki-retention.json、loki-deletion.json保留策略与删除操作loki-bloom-gateway.jsonBloom 网关相关loki-thanos-object-storage.json对象存储兼容 Thanos 语义相关loki-mixin-recording-rules.jsonrecording rules 结果的展示面板导入 Grafana 面板界面操作进入 Grafana UI选择Dashboards → Import上传 JSON 文件或粘贴其内容配置数据源应指向你的 Prometheus/Mimir点击Import。建议先创建一个文件夹例如 Loki Monitoring统一存放导入的面板面板一次只能导入一个官方建议全部安装。也可通过 Grafana API 编程导入curl -X POST -H Content-Type: application/json \ -H Authorization: Bearer YOUR_API_KEY \ -d path/to/dashboard.json \ https://your-grafana-instance/api/dashboards/db重要前提来自 mixins.md面板与告警期望指标携带cluster、namespace、job、container、pod、instance这些标签。Kubernetes Monitoring chart 恰好提供它们——通过全局 cluster 标签、cAdvisor 与 kube-state-metrics 的容器/节点指标。若你的采集链路使用了不同标签名或未采集容器与节点指标部分面板与告警会无数据直到你 relabel 指标以匹配预期标签。加载告警与记录规则面向 Grafana Cloud Prometheus / Mimir使用 mimirtool# 安装 mimirtool go install github.com/grafana/mimir/pkg/mimirtoollatest # 加载告警规则 mimirtool rules load alerts.yaml \ --addresshttps://prometheus-prod-xxx.grafana.net/api/prom \ --idYour-Stack-ID \ --keyYour-API-Key # 加载记录规则 mimirtool rules load rules.yaml \ --addresshttps://prometheus-prod-xxx.grafana.net/api/prom \ --idYour-Stack-ID \ --keyYour-API-Keymixins.md 提供了更简洁的凭据方式先创建带 Alerts/Rules 读写权限的 Access Policy 获取 token然后导出环境变量MIMIR_ADDRESS、MIMIR_API_USER、MIMIR_API_KEY、MIMIR_TENANT_ID即可直接运行mimirtool rules load rules.yaml # 记录规则部分面板显示数据所必需 mimirtool rules load alerts.yaml # 可选告警规则面向自建 Prometheuscp rules.yaml alerts.yaml /etc/prometheus/rules/ # 然后重载 Prometheus 配置 curl -X POST http://prometheus:9090/-/reload告警与记录规则的内容构成alerts.yaml 中的告警组loki_alerts包含告警名触发条件严重级别LokiRequestErrors按 cluster/namespace/job/route 统计的 5xx 错误率 10%持续 15 分钟criticalLokiRequestPanics10 分钟内loki_panic_total增量 0代码 paniccriticalLokiRequestLatency99 分位延迟 1s持续 15 分钟排除 tail 与 scheduler 路由criticalLokiTooManyCompactorsRunning同时运行超过 1 个 compactor持续 5 分钟warningLokiCompactorHasNotSuccessfullyRunCompaction距离上次成功压缩超过 3 小时或启动后 3 小时内从未成功压缩criticalrules.yaml 中的规则组loki_rules基于loki_request_duration_seconds直方图预聚合出一批 recording rules例如- expr: histogram_quantile(0.99, sum(rate(loki_request_duration_seconds_bucket[1m])) by (le, cluster, job)) record: cluster_job:loki_request_duration_seconds:99quantile - expr: histogram_quantile(0.99, sum(rate(loki_request_duration_seconds_bucket[1m])) by (le, cluster, namespace, job, route)) record: cluster_namespace_job_route:loki_request_duration_seconds:99quantile这些预聚合指标正是上述LokiRequestLatency告警表达式cluster_namespace_job_route:loki_request_duration_seconds:99quantile与各面板的数据来源——rules.yaml对部分面板显示数据是必需的应优先加载。若需自定义 mixin修改源文件位于 production/loki-mixinjsonnet 源并按该目录 README 说明重新生成编译产物到loki-mixin-compiled。关键监控指标速查配合 metrics.md 中的高信号指标你可以不依赖面板直接用 PromQL 排查问题注意cluster、namespace、job来自抓取配置并非指标自带标签请求错误率——优先观察 5xx 比例的持续上升100 * sum(rate(loki_request_duration_seconds_count{status_code~5..}[2m])) by (cluster, namespace, job, route) / sum(rate(loki_request_duration_seconds_count[2m])) by (cluster, namespace, job, route)请求延迟 p99——关注 query-frontend 与 distributor 路径histogram_quantile(0.99, sum(rate(loki_request_duration_seconds_bucket[1m])) by (le, cluster, namespace, job, route))Panic 计数——应始终为零sum(increase(loki_panic_total[10m])) by (cluster, namespace, job)后续步骤发送日志部署完成后即可向 Loki 发送业务日志相关方式可查阅仓库 docs/sources/send-data查询日志使用 LogQL 检索与洞察日志参考 docs/sources/query告警可基于日志查询利用 Loki ruler 组件创建告警参考 docs/sources/alert升级注意每次升级 Loki 后应重新核对 mixin 资产确保面板与告警与当前版本的指标保持一致。在 docs/sources/operations/meta-monitoring 目录下还有更多相关文档如 chart 3 版本的部署指南 deploy-chart-v3.md可作为本文的延伸阅读。【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考