Loki Helm Chart 监控与告警部署指南内置 Prometheus Operator 资源与 Grafana 仪表盘【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki本文聚焦于通过 Loki 官方 Helm Chart 为部署在 Kubernetes 上的 Loki 集群配置监控与告警如何一次性渲染出 ServiceMonitor、Recording Rules、Alert Rules 与 Grafana 仪表盘以及如何改用 Grafana Operator 自动导入仪表盘。读完本文你将掌握monitoring配置块的完整用法、告警规则的参数调优方式以及官方推荐的替代监控方案Kubernetes monitoring Helm chart从而为 Loki 建立开箱即用的可观测性体系。概述Helm Chart 内置监控能力Loki Helm Chart 提供了一组内置监控资源渲染能力可以直接从上游的 loki-mixin一个用 Jsonnet 编写的、基于 Grafana Cloud 运维 Loki 经验沉淀出的仪表盘/告警/规则集合生成以下四类 Kubernetes 资源ServiceMonitor供 Prometheus Operator 抓取 Loki 各组件/metrics端点的指标PrometheusRuleRecording Rules为仪表盘提供预聚合的录制规则PrometheusRuleAlert Rules内置的 Loki 告警规则Grafana 仪表盘以 ConfigMap 或 Grafana Operator 自定义资源形式提供开箱即用的 Loki 监控面板。这些资源全部统一收拢在 Helm values 的monitoring配置块下见 values.yaml并且在默认情况下全部处于关闭状态——所有enabled字段默认值均为false需要显式开启。最小启用示例monitoring: serviceMonitor: enabled: true rules: enabled: true # recording rules only alerts: enabled: true # alert rules (separate since chart 18.0.0) dashboards: enabled: true版本行为说明chart 18.0.0 起从 chart 18.0.0 开始告警规则被拆分到独立的monitoring.alerts键下管理monitoring.rules仅负责录制规则recording rules。同时用于标识发布实例的指标标签默认名为app_instance由monitoring.appInstanceLabelName控制。⚠️ 注意版本差异当前仓库检出的 Helm Chart 版本为 7.3.0见 Chart.yaml该版本中告警仍由monitoring.rules.alerting开关控制默认truemonitoring.alerts是文档所描述的新版18.0.0行为。升级到新版 Chart 时需将配置迁移到monitoring.alerts下。完整的monitoring.*键值说明可查阅 Helm Chart Reference其中monitoring.alerts.*、monitoring.appInstanceLabelName等条目即为新版字段的权威参考。一、ServiceMonitor让 Prometheus 抓取 Loki 指标Loki 各组件都会在/metrics端点暴露 Prometheus 格式指标ServiceMonitor 是 Prometheus Operator 发现并抓取这些指标的标准方式。monitoring: serviceMonitor: enabled: true namespaceSelector: {} annotations: {} labels: {} interval: 15s scrapeTimeout: null relabelings: [] metricRelabelings: [] scheme: http tlsConfig: null从模板实现 servicemonitor.yaml 可以看到几个值得注意的细节抓取端点固定为port: http-metrics、path: /metrics默认抓取间隔 15svalues.yaml 注释明确说明内置录制规则基于 1m 的 rate 窗口计算抓取间隔至少要达到 rate 窗口的 1/4即 ≤ 15s否则录制规则会失真relabel 逻辑模板内置了两条 relabel 规则——将job标签替换为namespace/job格式便于区分不同命名空间下的同名服务以及写入cluster标签relabelings与metricRelabelings可用于追加自定义 relabel标签排除selector中通过prometheus.io/service-monitor标签的NotIn false表达式允许用户手动为某个 Service 打上prometheus.io/service-monitor: false以跳过抓取条件渲染模板会检测集群是否安装monitoring.coreos.com/v1/ServiceMonitorAPI未安装时不会渲染该资源。此外在旧版 Chart 中还提供metricsInstance为 Grafana Agent Operator 创建 MetricsInstance 资源做 remote write选项但它已被标记为 DEPRECATED。二、Recording Rules仪表盘的数据基础monitoring.rules负责渲染名为release-loki-rules的 PrometheusRule 资源其中包含录制规则recording rules这些规则是多个内置仪表盘的查询基础模板见 loki-rules.yaml规则本体定义在 src/rules.yaml.tpl。monitoring: rules: enabled: true namespace: null # 可选将 PrometheusRule 放到其他命名空间 annotations: {} labels: {} additionalRuleAnnotations: {} additionalRuleLabels: {} additionalGroups: []录制规则覆盖了请求延迟的百分位、均值与速率等典型指标例如- expr: histogram_quantile(0.99, sum(rate(loki_request_duration_seconds_bucket[1m])) by (le, job)) record: job:loki_request_duration_seconds:99quantile每条规则都会被打上cluster标签与 ServiceMonitor 的 relabel 相呼应保证多集群场景下指标可区分。additionalGroups允许追加自定义规则组模板中会将其与内置规则一并渲染进同一个 PrometheusRuleadditionalGroups: - name: additional-loki-rules rules: - record: job:loki_request_duration_seconds_bucket:sum_rate expr: sum(rate(loki_request_duration_seconds_bucket[1m])) by (le, job)三、Alert Rules内置告警与参数调优新版monitoring.alertschart 18.0.0告警规则渲染为名为release-loki-alerts的 PrometheusRule对应模板 loki-alerts.yaml规则本体在 src/alerts.yaml.tpl。新版 Chart 的完整配置项包括配置项说明默认值monitoring.alerts.enabled是否创建包含 Loki 告警规则的 PrometheusRulefalsemonitoring.alerts.disabled按名称选择性禁用单个告警如{ LokiRequestErrors: true }{}monitoring.alerts.overrides覆盖单个告警的for/severity如{ LokiRequestErrors: { for: 5m, severity: warning } }{}monitoring.alerts.keepFiringFor全局应用到所有告警规则的keepFiringFormonitoring.alerts.additionalAggregationLabels追加到所有告警表达式by()聚合子句的额外标签维度[]monitoring.alerts.additionalRuleAnnotations追加到所有告警规则上的注解{}monitoring.alerts.additionalRuleLabels追加到所有告警规则上的标签{}monitoring.alerts.annotations/labelsPrometheusRule 资源本身的注解与标签{}当前仓库版本monitoring.rules.alertingchart 7.3.0当前仓库 Chart7.3.0中告警与录制规则共用monitoring.rules块由alerting开关默认true控制是否同时渲染告警disabled用于逐个关闭告警。values.yaml 中为每个内置告警提供了参数化的configs包括告警名默认阈值默认for默认严重级别说明LokiRequestErrors错误率 10%15mcritical按 namespace/job/route 统计 5xx 错误占比LokiRequestPanicspanic 数 0无critical基于loki_panic_total的增长量LokiRequestLatencyP99 延迟 1s15mcritical请求延迟过高LokiTooManyCompactorsRunning—5mwarningcompactors 实例数异常LokiCanaryLatency延迟 5s15mwarningcanary 端到端延迟异常例如LokiRequestErrors的表达式为100 * sum(rate(loki_request_duration_seconds_count{status_code~5..}[2m])) by (namespace, job, route) / sum(rate(loki_request_duration_seconds_count[2m])) by (namespace, job, route) 10这些告警规则最初源自 alerts.libsonnetChart 将其参数化后供用户直接调整阈值、持续时间与严重级别。若把所有告警都 disable 却仍保留alerting: trueChart 渲染会失败——此时应直接设置alerting: false。四、Dashboards开箱即用的 Loki 监控面板方式一ConfigMap默认渲染方式monitoring: dashboards: enabled: true namespace: null annotations: {} labels: grafana_dashboard: 1启用后Chart 会生成携带grafana_dashboard: 1标签的 ConfigMap模板见 configmap-1.yaml 与 configmap-2.yaml配合 Grafana 的 ConfigMap sidecar如 grafana-sidecar 自动发现机制即可自动导入仪表盘。面板 JSON 同样来自 loki-mixin 项目production/loki-mixin/dashboards 目录包含 loki-operational、loki-reads、loki-writes、loki-logs、loki-chunks、loki-retention、loki-canary 等一系列面板。这些面板需要上文提到的录制规则才能完整工作因此通常建议rules.enabled与dashboards.enabled同时开启。方式二Grafana Operator推荐用于 Operator 管理的 Grafana当你的 Grafana 由 Grafana Operator 管理时Chart 可以改为渲染GrafanaDashboard自定义资源让 Operator 直接把面板导入 Grafana无需再依赖 sidecar 监听 ConfigMapmonitoring: dashboards: enabled: true grafanaOperator: enabled: true instanceSelector: matchLabels: dashboards: grafana folder: Loki关键字段说明instanceSelector标签选择器Grafana Operator 用它匹配 Grafana 自定义资源上的标签来决定把面板导入到哪个实例默认空选择器{}会匹配所有 Grafana 实例folder/folderUID/folderRef三者都用于把面板放入 Grafana 的某个文件夹只能设置其中一个。folder会在根层级创建同名文件夹默认GeneralfolderUID与folderRef则引用已存在的文件夹以支持子目录层级resyncPeriodOperator 重新同步资源的频率默认10mannotations/labels为 GrafanaDashboard 资源附加的注解与标签。完整的monitoring.dashboards.grafanaOperator键列表含默认值见 Helm Chart Referencemonitoring.dashboards.grafanaOperator.*条目。五、release 标识标签app_instance为了让同一集群中不同发布release的 Loki 实例在指标与录制规则中可区分新版 Chart 引入了一个 release 标识标签默认名为app_instancemonitoring.appInstanceLabelName注入到抓取指标与录制规则中的标签名默认app_instancemonitoring.appInstanceLabelValue该标签的取值支持 Helm 模板默认{{ include loki.fullname . }}即当前 release 的完整名称。这取代了旧版 Chart 中的clusterLabelOverride/monitoring.serviceMonitor.clusterLabel方案升级到社区版时的迁移对照可参考 upgrade-to-community 文档。六、推荐替代方案Kubernetes monitoring Helm chart{{ admonition typewarning }} Grafana Labs 已不再推荐使用 meta-monitoring Helm chart即此前的monitoring.selfMonitoring/ Grafana Agent 集成该集成在 chart 9.0.0 中被移除来监控 Loki。为了把监控能力收敛到单一 Helm chart官方推荐使用 Kubernetes monitoring Helm chart 中的 Manage 章节。 {{ /admonition }}这一变化在仓库代码中也有迹可循当前 values.yaml 中monitoring.selfMonitoring整段被标记为 DEPRECATED其下grafanaAgent、podLogs、logsInstance等配置全部标注为依赖已废弃的 Grafana Agent Operatorgrafana-agent.yaml 等模板也仅在selfMonitoring.enabled时才渲染。因此新部署建议直接采用 Kubernetes monitoring Helm chart而不是重新开启这些废弃配置。关于 Kubernetes monitoring Helm chart 的具体部署方式、如何把 Loki 指标发送到独立的 Prometheus/Loki 实例以及 Loki 暴露的全部监控指标清单请继续阅读 meta-monitoring 系列文档。七、验证与排障在应用配置前可以用 Helm 的模板渲染功能先行检查生成的资源是否符合预期helm template loki grafana/loki \ --set monitoring.serviceMonitor.enabledtrue \ --set monitoring.rules.enabledtrue \ --set monitoring.alerts.enabledtrue \ --set monitoring.dashboards.enabledtrue观察输出的ServiceMonitor、PrometheusRuleloki-rules与loki-alerts以及 ConfigMap/GrafanaDashboard 资源是否存在、标签是否正确。仓库中 ci/legacy-monitoring-values.yaml 提供了完整的 CI 验证样例开启 selfMonitoring、安装 Grafana Agent Operator、并为 ServiceMonitor 打上release: prometheus标签以匹配 Prometheus 实例的标签选择器可作为排查“指标抓不到/告警不生效”问题的对照例如 ServiceMonitor 的labels必须与 Prometheus 配置的serviceMonitorSelector匹配monitoring.rules.enabled与仪表盘需成对开启抓取间隔不应大于录制规则 rate 窗口的 1/4 等。总结Loki Helm Chart 将上游 loki-mixin 沉淀的运维经验直接编译为标准的 Prometheus Operator 资源与 Grafana 面板让“部署 Loki 即获得完整可观测性”成为可能。配置时只需记住四个开关serviceMonitor、rules、alerts、dashboards并按版本差异选用monitoring.alerts18.0.0或monitoring.rules.alerting旧版若使用 Operator 管理的 Grafana则通过grafanaOperator以自定义资源方式自动导入面板。对于新的生产部署官方推荐改用 Kubernetes monitoring Helm chart 统一纳管监控并将 Loki 自身的监控数据发送到独立的 LGTM 实例以便在故障时仍能从外部观察集群状态。【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考