拓冰网站定制 
Loki 2.5 版本深度解析查询性能增强、配置迁移与升级实战指南【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/lokiLoki 2.5 是距离 2.4 发布近 6 个月后的重要版本围绕查询更快的并行化与更灵活的数据摄入两条主线引入了 regexp 匹配加速、二进制运算并行化、新对象存储 Schema、存储请求 Hedging 以及 Promtail 的多项新摄入方式。本文基于 v2-5 版本说明结合当前仓库源码与 2.x 升级指南 中的迁移细节系统梳理 2.5 的全部增强点、必须执行的配置迁移动作、默认值变化以及关键 Bug 修复帮助你在升级前后准确评估影响面并完成平滑迁移。版本概览从 2.4 到 2.5Loki 2.5 延续了项目Like Prometheus, but for logs的设计哲学在保持日志查询体验一致的同时把优化重点放在了三件事上查询性能让常见 LogQL 正则表达式、二元运算与大规模并行查询跑得更快存储架构通过新 Schema 缓解对象存储限流引入请求 Hedging 对抗长尾延迟摄入能力Promtail 获得 Docker Daemon 直连、Cloudflare、GELF 等多种新数据源接入方式。同时2.5 也包含了一批影响启动行为的配置变更尤其是split_queries_by_interval的位置迁移以及大量查询正确性、查询取消与稳定性相关的 Bug 修复。以下逐一展开。核心性能与架构增强Go regexp 性能优化为常见日志正则场景加速Loki 2.5 引入了对 Go 标准库regexp的深度优化成果。社区开发者 bboreham 深入分析了 Goregexp库的实现对应 PR 5315并创建了一个性能改进的 fork大幅提升了 Loki 中最常见正则使用场景的执行速度。在日志查询中|~ regex与| filter等 LogQL 过滤操作是最高频路径之一正则引擎的每次微小改进都会在长时间窗口、大标签基数查询中被显著放大。这一改动直接作用于 pkg/logql 下的 LogQL 执行引擎属于对查询热路径的底层提速。二进制运算显著加速充分利用 Loki 的并行能力版本说明指出二进制运算binary operations现在显著更快其关键在于充分发挥 Loki 的并行性PR 5317。在 LogQL 中诸如rate(...) / sum(...)、count_over_time(...) * 2等运算会在查询引擎中被拆解为可并行执行的子任务。从当前源码结构可以印证这一点Loki 的查询执行由 pkg/engine 统一编排而 2.5 通过让二进制运算也走并行调度路径使拆分后的每个分片在独立 goroutine 中完成计算后再合并结果从而把多核能力真正用起来。新 Schema更多路径前缀规避 S3 限流2.5 提供了一种新的存储 SchemaPR 5054其核心思路是使用更多路径前缀来避免触发 S3 的速率限制。对象存储如 S3在单个前缀下的请求速率存在上限当大量 chunk 落在同一目录前缀下时高并发查询容易撞上限流新 Schema 通过增加路径前缀的分散程度把请求均匀打散到更多前缀上从而降低单前缀压力。同样的 Schema 变更也同步应用到了文件系统存储filesystem storePR 5291此前所有 chunk 都被放进同一个目录升级后改为分散到多个子目录既避免单目录文件数量过大也减少了文件系统层面的压力。相关 Schema 定义与对象存储客户端实现可参见 pkg/storage 目录。存储请求 Hedging对抗长尾延迟Hedging对冲请求是一种经典的分布式系统技巧当一个请求超过设定延迟仍未返回时并发发出第二个乃至更多重复请求取先返回者作为结果从而显著压缩高并发查询场景下的长尾延迟。Loki 2.5 将这一能力引入对象存储访问层PR 4826对应配置位于storage_config块下。从当前仓库源码看Hedging 的实现位于 pkg/storage/chunk/client/hedging/hedging.go其配置结构体如下type Config struct { // At is the duration after which a second request will be issued. At time.Duration yaml:at // UpTo is the maximum number of requests that will be issued. UpTo int yaml:up_to // The maximun of hedge requests allowed per second. MaxPerSecond int yaml:max_per_second }对应的 YAML 配置形如storage_config: hedging: at: 250ms # 超过该时长未返回则发起第二个请求默认为 0禁用 up_to: 2 # 最多并发发出的请求数默认为 2 max_per_second: 5 # 每秒允许的最大对冲请求数默认为 5从源码可以看到其底层基于hedgedhttp库构建http.RoundTripper并实现了请求级速率限制与winner 追踪当对冲请求总数超过MaxPerSecond时返回ErrTooManyHedgeRequests。在 pkg/storage/chunk/client/aws/s3_storage_client.go 的NewS3ObjectClient中会基于同一份hedgingCfg同时构建普通与 Hedged 两套 S3 客户端供不同场景选用。Hedging 还自带完整可观测性指标前缀loki_便于验证其实际效果hedged_requests_total发出的对冲请求总数hedged_requests_rate_limited_total因速率限制被拒绝的对冲请求数hedged_requests_won_total在对冲请求或原始请求中率先完成的请求数按type维度区分。使用建议at的取值应略高于对象存储的典型 P50/P75 延迟若设得过小会频繁触发重复请求反而放大存储压力。默认0表示禁用需要显式开启。Promtail 新摄入能力2.5 为 Promtail 引入了三种全新的日志接入方式与两级速率限制能力让日志采集的覆盖面与可控性同时提升直接从 Docker Daemon 做服务发现与 TailPromtail 现在可以直接对接 Docker DaemonPR 4911通过 Docker API 动态发现容器并直接 Tail 容器日志无需依赖 Docker 的 json-file 日志驱动落盘解析。这对于短生命周期容器、以及需要动态跟随容器启停的场景尤其实用避免了日志文件尚未刷盘导致的采集缺口。直接从 Cloudflare 拉取日志新增 Cloudflare 数据源支持PR 4813Promtail 可以直接从 Cloudflare 拉取日志。该能力通常配合 Cloudflare 的 Logpush/API 接口使用将边缘日志直接送入 Loki省去中间转发环节。接收 GELF 格式日志Promtail 现在可以以 Graylog Extended Log FormatGELF接收日志PR 4744即 Promtail 本身可以作为 GELF 协议的服务端监听并解析上报的日志。对于已按 GELF 标准输出日志的既有系统许多日志库与中间件原生支持 GELF可以零改造接入 Loki。客户端侧全局速率限制与 Pipeline 级速率限制2.5 为 Promtail 增加了两层级联的速率限制能力客户端全局速率限制PR 5031在 Promtail 的客户端client层面限制整体推送速率防止采集量超过 Loki 的接收能力Pipeline 可配置速率限制PR 5051在 pipeline 内部按 stage 进行限流允许对特定标签或特定来源的日志做差异化速率控制。两者结合可以在采集源头就做好流量整形而不是等到 Distributor 侧触发全局限额再被拒绝。升级注意事项必须执行的配置迁移升级到 2.5 之前请务必通读 2.x 升级指南 中 2.5.0 一节。本节列出最关键、影响面最大的变更。split_queries_by_interval配置迁移启动阻断项这是 2.5 中最可能直接导致 Loki 启动失败的变更。在 2.4 及之前split_queries_by_interval可以同时定义在两个位置query_range: split_queries_by_interval: 10m和/或limits_config: split_queries_by_interval: 10m在2.5.0 中它只能定义在limits_config区块limits_config: split_queries_by_interval: 30m如果你没有把该参数从query_range区块中删除Loki 将直接启动失败。这是升级前必须完成的清理动作。同时注意两点行为变化默认值变化split_queries_by_interval的默认值由0禁用拆分变为30m即未显式配置时也会按 30 分钟间隔拆分查询CLI 标志不变对应的命令行参数仍然是querier.split-queries-by-interval习惯用 flag 配置的部署无需改动。从当前仓库源码 pkg/validation/limits.go 可以确认其最终归属QuerySplitDuration字段的 YAML 标签即为split_queries_by_interval位于 limits 配置结构中并通过 flagquerier.split-queries-by-interval注册注释明确说明按时间间隔拆分查询并并行执行值 0 禁用时间拆分同时也决定启用结果缓存时缓存键的选取方式。拆分逻辑本身由 pkg/querier/queryrange/split_by_interval.go 执行在 query-frontend 侧按时间区间把大查询切成多个子查询并并行下发而在 pkg/querier/queryrange/limits/definitions.go 中可以看到除了split_queries_by_interval外2.5 之后还陆续细化了指标查询split_instant_metric_queries_by_interval、元数据查询split_metadata_queries_by_interval等独立拆分间隔演进方向是按查询类型差异化拆分。默认开启更多并行化所有查询默认拆分与分片2.5 继续推动所有部署形态包括单二进制模式都默认利用并行性。升级后所有查询默认会被拆分split并分片shard对应配置项parallelize_shardable_queries的默认值变为true如果你此前未显式开启这些选项升级后 Loki 进程在查询期间的内存和 CPU 占用会上升这是并行化的预期代价需要通过容量评估确认资源余量。分片sharding会将一次查询按标签集进一步切分为更细粒度的子查询与时间拆分叠加后单个用户查询会被拆成大量可并行的工作单元。这也解释了为何 2.5 要同步修复一批sharding 下的查询正确性问题见下文 Bug 修复章节。其他默认配置值变化2.5.0 还调整了多项默认值升级指南中均有列出摘录关键几项配置项所属区块旧默认值新默认值影响说明parallelize_shardable_queriesquery_range—true所有可分片查询默认并行分片执行split_queries_by_intervallimits_config0s30m查询默认按 30 分钟间隔拆分max_chunk_ageingester1h2h块在内存中驻留更久再刷盘减少对象存储写入次数query_ingesters_withinquerier0s3h结束时间超过 3h 的查询不再下发到 ingester若经常写入旧数据需改回0smax_concurrentquerier2010单进程最大并发查询数下调match_max_concurrentfrontend_worker—true取代parallelism设置单进程查询并行度改由querier.max_concurrent控制flush_op_timeoutingester10s10m启动重放大 WAL 时避免context deadline exceeded刷盘失败其中query_ingesters_within从0s变为3h值得特别留意如果你有回填旧数据的习惯需要主动把它改回0s否则超过 3 小时的旧数据查询将不会命中 ingester 中的新写入数据。丢弃旧的 Prometheus Rules 配置格式2.5 移除了对旧版内部命名为v0Prometheus 告警规则格式的支持仅保留 2.x 格式。若你仍在用类似下面的旧格式字符串需要在升级前转换为新版groups: - name: example rules: - alert: HighErrorRate expr: job:request_latency_seconds:mean5m{jobmyjob} 0.5 for: 10m labels: severity: page annotations: summary: High request latency旧格式形如ALERT name IF expr [FOR duration] [LABELS ...] [ANNOTATIONS ...]的文本声明2.5 后不再被 Ruler 解析。使用情况上报Usage ReportingLoki 2.5 加入了匿名使用统计上报功能将使用情况以匿名形式回报给 Grafana Labs用于指导功能与文档的优先级决策。官方承诺不收集任何私有信息所有报告完全匿名并希望用户默认保持开启以帮助项目成长。该功能的实现位于 pkg/analytics/reporter.goReporter服务按约 4 小时为周期上报统计通过对象存储中的种子文件loki_cluster_seed.json与 KV 存储中的 token 来为集群生成稳定且匿名的身份标识同时采集进程级指标不涉及日志内容本身。若你希望关闭该功能在配置中显式设置即可analytics: reporting_enabled: false对应的 CLI 标志为reporting.enabled默认true。从源码可见当reporting_enabled为false时NewReporter直接返回 nil上报服务不会被启动因此该开关是完全关闭而非降低频率。Bug 修复总结2.5.0 修复了大量问题完整列表见仓库根目录的 CHANGELOG。以下是按类别归纳的重要修复查询正确性Query Correctness分片/拆分的默认开启使得这批正确性修复尤为关键PR 5474当 LogQL 表达式变更了标签labels mutated时禁用 count/avg 聚合的分片避免聚合结果错误PR 5444分片执行时不再插入缺失的数据点保证采样/步长对齐的准确性PR 5423正确设置 headblock 迭代器的 hash 值避免分片合并时数据错位PR 5289修复使用 LogQL 变更 Labels 时日志去重deduplication失效的问题PR 5006修复查询 step 大于拆分间隔时查询拆分异常的问题。查询取消Query CancellationPR 5113修复 query-frontend 与 query-scheduler 之间的取消cancel传递问题避免已取消查询继续占用资源PR 5080在 querier 的部分下游请求中正确处理context取消PR 5075修复 frontend 中一个可能的取消cancellation问题。其他重要修复PR 5413修复 Azure blob 客户端中的一个死锁PR 5334修复 live tailing实时追踪中可能导致内存爆炸的问题PR 5144修复 ruler 使用 Basic Auth 进行 remote write 时的问题PR 4741修复 retention 未能完全清理索引的问题。升级检查清单综合以上内容升级到 Loki 2.5 建议按如下清单逐项核对移除query_range区块中的split_queries_by_interval否则启动失败改由limits_config统一配置或依赖新的30m默认值评估并行化默认开启带来的内存/CPU 增量必要时通过querier.max_concurrent与parallelize_shardable_queries调整若存在旧数据回填场景将querier.query_ingesters_within显式设回0s检查 Ruler 告警规则文件是否仍在使用已废弃的 Prometheus 1.x 格式提前转换为 2.x 格式如业务对数据隐私有严格要求显式设置analytics.reporting_enabled: false关注存储层可选优化项storage_config.hedging结合对象存储延迟基线评估是否开启核对升级后的查询结果与旧版本是否一致尤其是使用了标签变更、聚合分片路径的 LogQL 查询。详细升级步骤与全部变更点请参阅 2.x 升级指南2.5.0 一节与 CHANGELOG发行说明原文见 v2-5.md。【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Loki 2.5 版本深度解析：查询性能增强、配置迁移与升级实战指南
Loki 2.5 版本深度解析查询性能增强、配置迁移与升级实战指南【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/lokiLoki 2.5 是距离 2.4 发布近 6 个月后的重要版本围绕查询更快的并行化与更灵活的数据摄入两条主线引入了 regexp 匹配加速、二进制运算并行化、新对象存储 Schema、存储请求 Hedging 以及 Promtail 的多项新摄入方式。本文基于 v2-5 版本说明结合当前仓库源码与 2.x 升级指南 中的迁移细节系统梳理 2.5 的全部增强点、必须执行的配置迁移动作、默认值变化以及关键 Bug 修复帮助你在升级前后准确评估影响面并完成平滑迁移。版本概览从 2.4 到 2.5Loki 2.5 延续了项目Like Prometheus, but for logs的设计哲学在保持日志查询体验一致的同时把优化重点放在了三件事上查询性能让常见 LogQL 正则表达式、二元运算与大规模并行查询跑得更快存储架构通过新 Schema 缓解对象存储限流引入请求 Hedging 对抗长尾延迟摄入能力Promtail 获得 Docker Daemon 直连、Cloudflare、GELF 等多种新数据源接入方式。同时2.5 也包含了一批影响启动行为的配置变更尤其是split_queries_by_interval的位置迁移以及大量查询正确性、查询取消与稳定性相关的 Bug 修复。以下逐一展开。核心性能与架构增强Go regexp 性能优化为常见日志正则场景加速Loki 2.5 引入了对 Go 标准库regexp的深度优化成果。社区开发者 bboreham 深入分析了 Goregexp库的实现对应 PR 5315并创建了一个性能改进的 fork大幅提升了 Loki 中最常见正则使用场景的执行速度。在日志查询中|~ regex与| filter等 LogQL 过滤操作是最高频路径之一正则引擎的每次微小改进都会在长时间窗口、大标签基数查询中被显著放大。这一改动直接作用于 pkg/logql 下的 LogQL 执行引擎属于对查询热路径的底层提速。二进制运算显著加速充分利用 Loki 的并行能力版本说明指出二进制运算binary operations现在显著更快其关键在于充分发挥 Loki 的并行性PR 5317。在 LogQL 中诸如rate(...) / sum(...)、count_over_time(...) * 2等运算会在查询引擎中被拆解为可并行执行的子任务。从当前源码结构可以印证这一点Loki 的查询执行由 pkg/engine 统一编排而 2.5 通过让二进制运算也走并行调度路径使拆分后的每个分片在独立 goroutine 中完成计算后再合并结果从而把多核能力真正用起来。新 Schema更多路径前缀规避 S3 限流2.5 提供了一种新的存储 SchemaPR 5054其核心思路是使用更多路径前缀来避免触发 S3 的速率限制。对象存储如 S3在单个前缀下的请求速率存在上限当大量 chunk 落在同一目录前缀下时高并发查询容易撞上限流新 Schema 通过增加路径前缀的分散程度把请求均匀打散到更多前缀上从而降低单前缀压力。同样的 Schema 变更也同步应用到了文件系统存储filesystem storePR 5291此前所有 chunk 都被放进同一个目录升级后改为分散到多个子目录既避免单目录文件数量过大也减少了文件系统层面的压力。相关 Schema 定义与对象存储客户端实现可参见 pkg/storage 目录。存储请求 Hedging对抗长尾延迟Hedging对冲请求是一种经典的分布式系统技巧当一个请求超过设定延迟仍未返回时并发发出第二个乃至更多重复请求取先返回者作为结果从而显著压缩高并发查询场景下的长尾延迟。Loki 2.5 将这一能力引入对象存储访问层PR 4826对应配置位于storage_config块下。从当前仓库源码看Hedging 的实现位于 pkg/storage/chunk/client/hedging/hedging.go其配置结构体如下type Config struct { // At is the duration after which a second request will be issued. At time.Duration yaml:at // UpTo is the maximum number of requests that will be issued. UpTo int yaml:up_to // The maximun of hedge requests allowed per second. MaxPerSecond int yaml:max_per_second }对应的 YAML 配置形如storage_config: hedging: at: 250ms # 超过该时长未返回则发起第二个请求默认为 0禁用 up_to: 2 # 最多并发发出的请求数默认为 2 max_per_second: 5 # 每秒允许的最大对冲请求数默认为 5从源码可以看到其底层基于hedgedhttp库构建http.RoundTripper并实现了请求级速率限制与winner 追踪当对冲请求总数超过MaxPerSecond时返回ErrTooManyHedgeRequests。在 pkg/storage/chunk/client/aws/s3_storage_client.go 的NewS3ObjectClient中会基于同一份hedgingCfg同时构建普通与 Hedged 两套 S3 客户端供不同场景选用。Hedging 还自带完整可观测性指标前缀loki_便于验证其实际效果hedged_requests_total发出的对冲请求总数hedged_requests_rate_limited_total因速率限制被拒绝的对冲请求数hedged_requests_won_total在对冲请求或原始请求中率先完成的请求数按type维度区分。使用建议at的取值应略高于对象存储的典型 P50/P75 延迟若设得过小会频繁触发重复请求反而放大存储压力。默认0表示禁用需要显式开启。Promtail 新摄入能力2.5 为 Promtail 引入了三种全新的日志接入方式与两级速率限制能力让日志采集的覆盖面与可控性同时提升直接从 Docker Daemon 做服务发现与 TailPromtail 现在可以直接对接 Docker DaemonPR 4911通过 Docker API 动态发现容器并直接 Tail 容器日志无需依赖 Docker 的 json-file 日志驱动落盘解析。这对于短生命周期容器、以及需要动态跟随容器启停的场景尤其实用避免了日志文件尚未刷盘导致的采集缺口。直接从 Cloudflare 拉取日志新增 Cloudflare 数据源支持PR 4813Promtail 可以直接从 Cloudflare 拉取日志。该能力通常配合 Cloudflare 的 Logpush/API 接口使用将边缘日志直接送入 Loki省去中间转发环节。接收 GELF 格式日志Promtail 现在可以以 Graylog Extended Log FormatGELF接收日志PR 4744即 Promtail 本身可以作为 GELF 协议的服务端监听并解析上报的日志。对于已按 GELF 标准输出日志的既有系统许多日志库与中间件原生支持 GELF可以零改造接入 Loki。客户端侧全局速率限制与 Pipeline 级速率限制2.5 为 Promtail 增加了两层级联的速率限制能力客户端全局速率限制PR 5031在 Promtail 的客户端client层面限制整体推送速率防止采集量超过 Loki 的接收能力Pipeline 可配置速率限制PR 5051在 pipeline 内部按 stage 进行限流允许对特定标签或特定来源的日志做差异化速率控制。两者结合可以在采集源头就做好流量整形而不是等到 Distributor 侧触发全局限额再被拒绝。升级注意事项必须执行的配置迁移升级到 2.5 之前请务必通读 2.x 升级指南 中 2.5.0 一节。本节列出最关键、影响面最大的变更。split_queries_by_interval配置迁移启动阻断项这是 2.5 中最可能直接导致 Loki 启动失败的变更。在 2.4 及之前split_queries_by_interval可以同时定义在两个位置query_range: split_queries_by_interval: 10m和/或limits_config: split_queries_by_interval: 10m在2.5.0 中它只能定义在limits_config区块limits_config: split_queries_by_interval: 30m如果你没有把该参数从query_range区块中删除Loki 将直接启动失败。这是升级前必须完成的清理动作。同时注意两点行为变化默认值变化split_queries_by_interval的默认值由0禁用拆分变为30m即未显式配置时也会按 30 分钟间隔拆分查询CLI 标志不变对应的命令行参数仍然是querier.split-queries-by-interval习惯用 flag 配置的部署无需改动。从当前仓库源码 pkg/validation/limits.go 可以确认其最终归属QuerySplitDuration字段的 YAML 标签即为split_queries_by_interval位于 limits 配置结构中并通过 flagquerier.split-queries-by-interval注册注释明确说明按时间间隔拆分查询并并行执行值 0 禁用时间拆分同时也决定启用结果缓存时缓存键的选取方式。拆分逻辑本身由 pkg/querier/queryrange/split_by_interval.go 执行在 query-frontend 侧按时间区间把大查询切成多个子查询并并行下发而在 pkg/querier/queryrange/limits/definitions.go 中可以看到除了split_queries_by_interval外2.5 之后还陆续细化了指标查询split_instant_metric_queries_by_interval、元数据查询split_metadata_queries_by_interval等独立拆分间隔演进方向是按查询类型差异化拆分。默认开启更多并行化所有查询默认拆分与分片2.5 继续推动所有部署形态包括单二进制模式都默认利用并行性。升级后所有查询默认会被拆分split并分片shard对应配置项parallelize_shardable_queries的默认值变为true如果你此前未显式开启这些选项升级后 Loki 进程在查询期间的内存和 CPU 占用会上升这是并行化的预期代价需要通过容量评估确认资源余量。分片sharding会将一次查询按标签集进一步切分为更细粒度的子查询与时间拆分叠加后单个用户查询会被拆成大量可并行的工作单元。这也解释了为何 2.5 要同步修复一批sharding 下的查询正确性问题见下文 Bug 修复章节。其他默认配置值变化2.5.0 还调整了多项默认值升级指南中均有列出摘录关键几项配置项所属区块旧默认值新默认值影响说明parallelize_shardable_queriesquery_range—true所有可分片查询默认并行分片执行split_queries_by_intervallimits_config0s30m查询默认按 30 分钟间隔拆分max_chunk_ageingester1h2h块在内存中驻留更久再刷盘减少对象存储写入次数query_ingesters_withinquerier0s3h结束时间超过 3h 的查询不再下发到 ingester若经常写入旧数据需改回0smax_concurrentquerier2010单进程最大并发查询数下调match_max_concurrentfrontend_worker—true取代parallelism设置单进程查询并行度改由querier.max_concurrent控制flush_op_timeoutingester10s10m启动重放大 WAL 时避免context deadline exceeded刷盘失败其中query_ingesters_within从0s变为3h值得特别留意如果你有回填旧数据的习惯需要主动把它改回0s否则超过 3 小时的旧数据查询将不会命中 ingester 中的新写入数据。丢弃旧的 Prometheus Rules 配置格式2.5 移除了对旧版内部命名为v0Prometheus 告警规则格式的支持仅保留 2.x 格式。若你仍在用类似下面的旧格式字符串需要在升级前转换为新版groups: - name: example rules: - alert: HighErrorRate expr: job:request_latency_seconds:mean5m{jobmyjob} 0.5 for: 10m labels: severity: page annotations: summary: High request latency旧格式形如ALERT name IF expr [FOR duration] [LABELS ...] [ANNOTATIONS ...]的文本声明2.5 后不再被 Ruler 解析。使用情况上报Usage ReportingLoki 2.5 加入了匿名使用统计上报功能将使用情况以匿名形式回报给 Grafana Labs用于指导功能与文档的优先级决策。官方承诺不收集任何私有信息所有报告完全匿名并希望用户默认保持开启以帮助项目成长。该功能的实现位于 pkg/analytics/reporter.goReporter服务按约 4 小时为周期上报统计通过对象存储中的种子文件loki_cluster_seed.json与 KV 存储中的 token 来为集群生成稳定且匿名的身份标识同时采集进程级指标不涉及日志内容本身。若你希望关闭该功能在配置中显式设置即可analytics: reporting_enabled: false对应的 CLI 标志为reporting.enabled默认true。从源码可见当reporting_enabled为false时NewReporter直接返回 nil上报服务不会被启动因此该开关是完全关闭而非降低频率。Bug 修复总结2.5.0 修复了大量问题完整列表见仓库根目录的 CHANGELOG。以下是按类别归纳的重要修复查询正确性Query Correctness分片/拆分的默认开启使得这批正确性修复尤为关键PR 5474当 LogQL 表达式变更了标签labels mutated时禁用 count/avg 聚合的分片避免聚合结果错误PR 5444分片执行时不再插入缺失的数据点保证采样/步长对齐的准确性PR 5423正确设置 headblock 迭代器的 hash 值避免分片合并时数据错位PR 5289修复使用 LogQL 变更 Labels 时日志去重deduplication失效的问题PR 5006修复查询 step 大于拆分间隔时查询拆分异常的问题。查询取消Query CancellationPR 5113修复 query-frontend 与 query-scheduler 之间的取消cancel传递问题避免已取消查询继续占用资源PR 5080在 querier 的部分下游请求中正确处理context取消PR 5075修复 frontend 中一个可能的取消cancellation问题。其他重要修复PR 5413修复 Azure blob 客户端中的一个死锁PR 5334修复 live tailing实时追踪中可能导致内存爆炸的问题PR 5144修复 ruler 使用 Basic Auth 进行 remote write 时的问题PR 4741修复 retention 未能完全清理索引的问题。升级检查清单综合以上内容升级到 Loki 2.5 建议按如下清单逐项核对移除query_range区块中的split_queries_by_interval否则启动失败改由limits_config统一配置或依赖新的30m默认值评估并行化默认开启带来的内存/CPU 增量必要时通过querier.max_concurrent与parallelize_shardable_queries调整若存在旧数据回填场景将querier.query_ingesters_within显式设回0s检查 Ruler 告警规则文件是否仍在使用已废弃的 Prometheus 1.x 格式提前转换为 2.x 格式如业务对数据隐私有严格要求显式设置analytics.reporting_enabled: false关注存储层可选优化项storage_config.hedging结合对象存储延迟基线评估是否开启核对升级后的查询结果与旧版本是否一致尤其是使用了标签变更、聚合分片路径的 LogQL 查询。详细升级步骤与全部变更点请参阅 2.x 升级指南2.5.0 一节与 CHANGELOG发行说明原文见 v2-5.md。【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考