Loki 2.4 发布深度解析乱序写入、简单可扩展部署与配置体系革新【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/lokiLoki 2.4 是该项目发展历程中的一个里程碑版本其发布说明围绕两大核心目标展开让日志更易于进入 Loki以及让 Loki 更易于运行和运维。本指南基于仓库中的官方发布说明docs/sources/release-notes/v2-4.md结合当前仓库源码与配置示例系统梳理 2.4 的关键特性、默认值变更、升级注意事项、Bug 修复与安全修复帮助你全面理解该版本的技术内涵与迁移影响。读完本文你将掌握乱序写入的底层机制、简单可扩展read/write部署模式的要点、common配置块带来的配置精简方式以及升级 2.4 前后必须关注的默认值差异清单。版本概览2.4 的两大核心目标Loki 2.4 的发布说明release notes开宗明义地指出该版本聚焦于两个方向让日志更容易进入 Loki降低日志接入的门槛包括支持乱序日志写入、新增 Promtail Kafka Consumer、允许 Promtail 通过 HTTP 直接接收 ndjson 与纯文本日志等。让 Loki 更容易运行和运维引入介于单二进制与微服务之间的简单可扩展部署Simple Scalable Deployment模式新增common配置块将配置体积缩减约 70%并同步优化了默认值与限制。发布说明同时强调不使用 Kubernetes、或想避开微服务复杂度的用户在本版本中将获得大量收益。这直接呼应了简单可扩展部署模式的出现——此前要发挥 Loki 的扩展潜力往往需要 Kubernetes 与微服务架构2.4 让这一切可以更简单地实现。据统计Loki 2.4 共合并了约 260 个 PRPull Request。完整的变更清单可查阅仓库根目录的 CHANGELOG.md。核心特性一乱序日志写入不再被拒绝Loki 不再要求日志必须按严格时间顺序perfect chronological order发送这是 2.4 中呼声最高的功能之一——严格的有序性约束被移除。在此之前Loki 要求同一 stream 内的日志条目时间戳必须单调递增任何乱序的推送都会被拒绝。这一约束对日志采集链路提出了额外要求采集端必须保证投递顺序或在本地做缓冲排序这在多副本、网络抖动、重试等场景下极易引发写入失败。2.4 之后客户端可以更自由地推送日志采集与投递链路显著简化。从当前仓库源码可以看到该机制的延续与细节在 pkg/distributor/distributor.go 中distributor 对 stream 内条目做逐条校验时明确区分了回填数据backfilled data与普通数据——回填数据允许比reject_old_samples_max_age更旧且通过保留的X-Loki-Backfill-Shard头标记推送解析器会拒绝已携带该标签的流从而防止该标签被伪造绕过校验。代码注释也指出因为 Loki 接受乱序写入对于跨多次推送、时间范围重叠而产生的重复时间戳系统无法完全去重这正是 pkg/validation/limits.go 中validation.increment-duplicate-timestamps选项存在的原因为同一 stream 中与前一条时间戳完全相同的日志行增加 1 纳秒从而在查询时尽量保持日志行的接收顺序。值得注意的是乱序支持并非无限制放行它受到一系列与时间相关的 limits 约束详见下文升级注意事项部分。核心特性二简单可扩展部署模式read / write targets2.4 引入了一种介于单二进制与微服务之间的混合部署模式即简单可扩展部署Simple Scalable Deployment。它通过新增的read与write两类 target 来横向扩展 Lokiwrite target负责写入路径包含 distributor、ingester 等组件read target负责读取路径包含 querier、query frontend 等组件。在 2.4 之前想要横向扩展 Loki 基本只能选择 Kubernetes 微服务方案而简单可扩展部署让运维者不必管理每个微服务就能获得中等程度的横向扩展能力。这一模式的历史地位在当前仓库的 docs/sources/get-started/deployment-modes.md 中仍有完整叙述文档将部署模式划分为单体Monolithic-targetall、高可用单体HA Monolithic与微服务Microservices三种其中 HA 单体模式即取代已废弃的简单可扩展部署SSD的方案。从演进脉络可以推断简单可扩展部署正是 2.4 在单二进制与全微服务之间补上的中间台阶。无论采用哪种模式Loki 都通过-target命令行参数指定启动时运行哪些微服务组件所有组件都打包在同一个二进制中docs/sources/get-started/deployment-modes.md。在 2.4 时代运行简单可扩展部署只需将部分实例以-targetread、其余以-targetwrite启动并共享同一对象存储与 ring 状态即可。核心特性三common配置块与 70% 的配置缩减2.4 新增了common配置区块它允许将大量重复的配置项集中定义一次例如存储、ring、复制因子、地址等公共信息。配合更新后的默认值Loki 的配置体积平均缩小约 70%并且开箱即用即可获得更合理的默认值与限制。发布说明将示例本地配置example local configuration确立为运行 Loki 的新参考。当前仓库中的 cmd/loki/loki-local-config.yaml 即是这一配置哲学的直观体现——该文件是目前仓库版本已演进到 tsdb 存储与 schema v13的参考配置但其骨架与 2.4 引入的common思想一脉相承auth_enabled: false server: http_listen_port: 3100 grpc_listen_port: 9096 log_level: debug grpc_server_max_concurrent_streams: 1000 common: instance_addr: 127.0.0.1 path_prefix: /tmp/loki storage: filesystem: chunks_directory: /tmp/loki/chunks rules_directory: /tmp/loki/rules replication_factor: 1 ring: kvstore: store: inmemory query_range: results_cache: cache: embedded_cache: enabled: true max_size_mb: 100 limits_config: metric_aggregation_enabled: true schema_config: configs: - from: 2020-10-24 store: tsdb object_store: filesystem schema: v13 index: prefix: index_ period: 24h ruler: alertmanager_url: http://localhost:9093 frontend: encoding: protobuf可以看到common块统一收纳了实例地址、路径前缀、文件系统存储、复制因子与 ring 的 KV 存储内存模式schema、limits、查询缓存等再各自按需补充整份配置非常精简。对于需要外部缓存与更高性能的场景仓库还提供了 cmd/loki/loki-local-with-memcached.yaml 作为对照参考。另外2.4 在未配置任何外部缓存时默认启用内存 FIFO 缓存对应 PR 4519这有助于提升查询性能但也意味着 Loki 会消耗更多内存运维时需预留相应的内存资源。核心特性四Recording Rules 正式化Recording rules记录规则在 2.4 不再是实验性功能。该版本为其实现了更健壮的底层支撑——复用 Prometheus 已有的写前日志Write Ahead LogWAL代码从而显著提升规则评估与结果落盘的可靠性。Recording rules 的价值在于把频繁使用或计算昂贵的查询预先计算并将结果保存为新的时序指标。当前仓库的 docs/sources/alert/_index.md 对此有精确定义与告警规则类似记录规则也会周期性评估区别在于它把查询结果落盘为新指标供后续查询与告警复用。Loki 中负责持续评估这组可配置查询并基于结果执行动作的组件是ruler该文档同时强调这一机制还可以把没有暴露任何指标的组件通过日志纳入可观测体系即所谓的黑盒监控与事件告警场景。2.4 使 ruler 的记录规则在可靠性上向 Prometheus 看齐这一特性对于从日志中派生业务指标、做容量规划与长周期趋势分析的用户尤为实用。核心特性五Promtail Kafka Consumer2.4 新增了Promtail Kafka Consumer可以轻松将日志从 Kafka 取出并送入 Loki。这对于已经用 Kafka 作为日志传输总线例如对接 Fluentd、Logstash 或自研采集器的场景的团队来说是接入 Loki 的一条低成本捷径。随着项目演进Kafka 摄取能力在后续版本中持续强化当前仓库中 docs/sources/send-data/alloy/examples/alloy-kafka-logs.md 提供了面向 Alloy 的 Kafka 日志摄取示例而pkg/kafka、pkg/kafkav2目录则展示了 Kafka 消费在 Loki 内部实现层面的不断迭代包括分区消费、编码解码、offset 管理等说明从 Kafka 取日志已成为 Loki 生态中的一等公民能力。核心特性六LogQL 增强——分组匹配与日期时间模板函数得益于社区贡献2.4 为 LogQL 带来了多项增强group_left 与 group_right多对一 / 一对多向量匹配LogQL 新增了group_left与group_right修饰符用于处理多对一many-to-one与一对多one-to-many向量匹配。其语义与 PromQL 一致当一侧的每个向量元素可以与多侧的多个元素匹配时必须显式使用group_left或group_right指定哪一侧拥有更高的基数。语法形式如下见 docs/sources/query/query_reference.mdvector expr bin-op ignoring(labels) group_left(labels) vector expr vector expr bin-op ignoring(labels) group_right(labels) vector expr vector expr bin-op on(labels) group_left(labels) vector expr vector expr bin-op on(labels) group_right(labels) vector expr其中group修饰符携带的标签列表表示从一侧额外纳入结果指标的标签同一个标签只能出现在on与group_x之一。分组修饰符仅能用于比较与算术运算而and、unless、or默认与右向量的全部条目匹配。典型应用示例按app与status计算各状态请求占比并将结果与总请求数做除法sum by (app, status) ( rate( {jobhttp-server} | json [5m] ) ) / on (app) group_left sum by (app) ( rate( {jobhttp-server} | json [5m] ) )另一个使用group_left(organization)从右侧向量带出附加标签、计算每个用户、组织、命名空间下被丢弃事件成本占比的完整示例同样记录在 docs/sources/query/query_reference.md。label_format与line_format支持日期时间处理label_format与line_format模板函数新增了日期时间处理能力核心是now与date等函数详见 docs/sources/query/template_functions.mddate(fmt string, date interface{}) string按给定的 Go 时间布局golang datetime layout返回时间的文本表示例如{{ date 2006-01-02 now }}now返回 Loki 服务器本地时区的当前时间例如{{ now }}模板中还可直接使用__timestamp__与管道组合例如{{ __timestamp__ | date 2006-01-02T15:04:05.00Z-07:00 }}与{{ __timestamp__ | unixEpoch }}。这使日志解析、标签改写与输出格式化时可以就地完成时间换算而无需预先在采集端处理显著提升了日志管线pipeline的表达力。核心特性七Promtail 通过 HTTP 接收 ndjson 与纯文本日志另一项社区贡献是让Promtail 可以接受 ndjson 与纯文本日志文件plaintext并通过 HTTP 推送即增强loki_push_api的摄取方式。这意味着除了主动抓取文件之外Promtail 还可以作为一个 HTTP 接收端点供其他程序或脚本以 ndjson 或纯文本格式直接 POST 日志再统一转发给 Loki。这一能力打通了非日志文件形态的数据接入场景例如脚本输出、API 回调、命令行工具的结果等都能以极低的成本汇入 Loki进一步呼应了 2.4 让日志更容易进入 Loki的版本主题。升级注意事项默认值变更清单2.4 对配置体系做了大量调整。官方态度是已尽力保证与既有配置兼容但部分默认限制值的变化可能会影响到那些未在配置文件中显式设置这些限制的用户。因此升级前务必阅读升级指南当前仓库中可参考 docs/sources/setup/upgrade/_index.md。v2.4.0 默认值变更以下为 2.4.0 中发生变化的 limits 默认值完整表格来自 docs/sources/release-notes/v2-4.mdconfignew defaultold defaultingestion_rate_strategygloballocalmax_global_streams_per_user50000 (no limit)max_query_length721h0h (no limit)max_query_parallelism3214max_streams_per_user0 (no limit)10000reject_old_samplestruefalsereject_old_samples_max_age168h336hper_stream_rate_limit3MB-per_stream_rate_limit_burst15MB-逐项解读其中的关键变化ingestion_rate_strategy 从 local 变为 global限流策略从按实例本地统计改为按租户全局统计配合 ring 数据实现全集群维度的速率控制避免多副本下各自为政导致的总吞吐失控。max_global_streams_per_user 从无限制收紧为 5000这是对单租户全局流数量的硬性保护防止高基数标签组合打垮 ingester。max_query_length 从无限制收紧为 721h约 30 天限制单次查询覆盖的时间跨度避免超长范围查询压垮存储层。reject_old_samples 从 false 变为 true、reject_old_samples_max_age 从 336h 缩短为 168h默认开始拒绝过旧的样本。这与乱序写入特性形成平衡——乱序被接受但超出 168 小时7 天的旧样本默认会被拒绝。当前仓库 pkg/validation/limits.go 中validation.reject-old-samples默认true、reject-old-samples.max-age默认7d即 168h正是这一策略的延续。per_stream_rate_limit / per_stream_rate_limit_burst3MB / 15MB新增的单流级速率限制用于防止某一条高流量日志流独占写入带宽。这些变更意味着升级前请检查自己的配置是否显式设置了上述项。若此前依赖无限制的旧默认值例如超长查询、超多流、超旧样本升级后可能突然被新默认值拦截需要在limits_config中按需显式覆盖。v2.4.2 默认值变更2.4.2 又追加了一批默认值调整源自 PR 5077confignew defaultold defaultparallelise_shardable_queriestruefalsesplit_queries_by_interval30m0squery_ingesters_within3h0smax_chunk_age2h1hmax_concurrent1020这批变更进一步朝着开箱即用更优的方向演进parallelise_shardable_queries 从 false 变为 true默认对可分片的查询启用并行化查询性能受益split_queries_by_interval 从 0s 变为 30m查询默认按 30 分钟间隔拆分配合并行化降低单次查询压力query_ingesters_within 从 0s 变为 3h只查询最近 3 小时内的 ingester 数据更早的数据走存储层减少 ingester 压力max_chunk_age 从 1h 变为 2hchunk 在内存中停留更久再刷新提升写入批量效率max_concurrent 从 20 降为 10降低默认并发上限更保守地保护资源。2.4 系列 Bug 修复2.4.2 修复的 Bug[PR 4968]trevorwhitney修复查询 ingester 时错误返回 ruler、导致内部服务器错误code Unimplemented的问题[PR 4875]trevorwhitney当使用memberlist作为一致性哈希 ring 存储时正确遵循common配置块中指定的复制因子[PR 4792]AndreZiviani修正文档中以下配置项的错误默认值scheduler_dns_lookup_period、min_ready_duration、final_sleep、max_transfer_retries、chunk_retain_period、chunk_target_size、batch_size、timeoutRedis 请求。2.4.1 修复的 Bug2.4.1 修复了 2.4.0 引入的两个问题[PR 4687]owen-d消除未使用租户 overrides 文件时 compactor 的 panic[PR 4681]slim-bean修正readtarget 的初始化逻辑——错误的初始化会导致 chunk 刷新后、querier 下载新索引表之前出现查询空洞query gaps。2.4.0 修复的重要 Bug[PR 4598]kavirajk修复 IP 匹配器词法分析器使其能区分过滤器与标识符[PR 4563]cyriltovena修复 Series 函数在分片场景下的处理[PR 4518]slim-bean修复对象被错误归还到sync.Pool的问题[PR 4411]slim-bean修复 frontend 等待永不到达的结果导致卡死的问题[PR 4238]liguozhong修复 distributor 的 goroutine 泄漏。安全修复限制 HTTP 方法2.4.0 包含一项安全相关修复[PR 4627]在 HTTP 端点上显式限定允许的 HTTP 方法。背景是社区用户发现 Loki 的所有端点都会响应 HTTP OPTIONS 请求而部署在 Loki 前面、负责 HTTP 认证的代理会将 OPTIONS 请求未认证地透传给 Loki从而允许用户发起未认证/未授权的查询。该修复为每个端点限定了允许的 HTTP 方法类型并禁止 OPTIONS 请求堵住了这条未授权访问通道。对于任何将 Loki 置于反向代理或网关之后的部署这是一条值得特别关注的加固措施——升级到 2.4.0 及以上版本即可获得该防护。总结Loki 2.4 以接入更简单、运维更简单为核心交出了一份内容密集的版本答卷乱序写入移除长期存在的时序约束简单可扩展部署为中等规模用户提供了微服务之外的扩展路径common配置块与全新默认值让配置大幅瘦身且更合理Recording rules 借助 Prometheus WAL 正式化Promtail 获得 Kafka 消费与 HTTP 摄取能力LogQL 的分组匹配与日期时间函数则显著增强了查询表达力。对于升级用户最需要关注的是文中两张默认值变更表——尤其是ingestion_rate_strategy、max_global_streams_per_user、reject_old_samples、max_query_length等项的收紧。若你的存量配置未显式设置这些项请在升级前评估实际影响并在limits_config中按需覆盖。完整的变更明细可继续查阅仓库根目录的 CHANGELOG.md 中 2.4.0 至 2.4.2 的条目。【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Loki 2.4 发布深度解析：乱序写入、简单可扩展部署与配置体系革新
Loki 2.4 发布深度解析乱序写入、简单可扩展部署与配置体系革新【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/lokiLoki 2.4 是该项目发展历程中的一个里程碑版本其发布说明围绕两大核心目标展开让日志更易于进入 Loki以及让 Loki 更易于运行和运维。本指南基于仓库中的官方发布说明docs/sources/release-notes/v2-4.md结合当前仓库源码与配置示例系统梳理 2.4 的关键特性、默认值变更、升级注意事项、Bug 修复与安全修复帮助你全面理解该版本的技术内涵与迁移影响。读完本文你将掌握乱序写入的底层机制、简单可扩展read/write部署模式的要点、common配置块带来的配置精简方式以及升级 2.4 前后必须关注的默认值差异清单。版本概览2.4 的两大核心目标Loki 2.4 的发布说明release notes开宗明义地指出该版本聚焦于两个方向让日志更容易进入 Loki降低日志接入的门槛包括支持乱序日志写入、新增 Promtail Kafka Consumer、允许 Promtail 通过 HTTP 直接接收 ndjson 与纯文本日志等。让 Loki 更容易运行和运维引入介于单二进制与微服务之间的简单可扩展部署Simple Scalable Deployment模式新增common配置块将配置体积缩减约 70%并同步优化了默认值与限制。发布说明同时强调不使用 Kubernetes、或想避开微服务复杂度的用户在本版本中将获得大量收益。这直接呼应了简单可扩展部署模式的出现——此前要发挥 Loki 的扩展潜力往往需要 Kubernetes 与微服务架构2.4 让这一切可以更简单地实现。据统计Loki 2.4 共合并了约 260 个 PRPull Request。完整的变更清单可查阅仓库根目录的 CHANGELOG.md。核心特性一乱序日志写入不再被拒绝Loki 不再要求日志必须按严格时间顺序perfect chronological order发送这是 2.4 中呼声最高的功能之一——严格的有序性约束被移除。在此之前Loki 要求同一 stream 内的日志条目时间戳必须单调递增任何乱序的推送都会被拒绝。这一约束对日志采集链路提出了额外要求采集端必须保证投递顺序或在本地做缓冲排序这在多副本、网络抖动、重试等场景下极易引发写入失败。2.4 之后客户端可以更自由地推送日志采集与投递链路显著简化。从当前仓库源码可以看到该机制的延续与细节在 pkg/distributor/distributor.go 中distributor 对 stream 内条目做逐条校验时明确区分了回填数据backfilled data与普通数据——回填数据允许比reject_old_samples_max_age更旧且通过保留的X-Loki-Backfill-Shard头标记推送解析器会拒绝已携带该标签的流从而防止该标签被伪造绕过校验。代码注释也指出因为 Loki 接受乱序写入对于跨多次推送、时间范围重叠而产生的重复时间戳系统无法完全去重这正是 pkg/validation/limits.go 中validation.increment-duplicate-timestamps选项存在的原因为同一 stream 中与前一条时间戳完全相同的日志行增加 1 纳秒从而在查询时尽量保持日志行的接收顺序。值得注意的是乱序支持并非无限制放行它受到一系列与时间相关的 limits 约束详见下文升级注意事项部分。核心特性二简单可扩展部署模式read / write targets2.4 引入了一种介于单二进制与微服务之间的混合部署模式即简单可扩展部署Simple Scalable Deployment。它通过新增的read与write两类 target 来横向扩展 Lokiwrite target负责写入路径包含 distributor、ingester 等组件read target负责读取路径包含 querier、query frontend 等组件。在 2.4 之前想要横向扩展 Loki 基本只能选择 Kubernetes 微服务方案而简单可扩展部署让运维者不必管理每个微服务就能获得中等程度的横向扩展能力。这一模式的历史地位在当前仓库的 docs/sources/get-started/deployment-modes.md 中仍有完整叙述文档将部署模式划分为单体Monolithic-targetall、高可用单体HA Monolithic与微服务Microservices三种其中 HA 单体模式即取代已废弃的简单可扩展部署SSD的方案。从演进脉络可以推断简单可扩展部署正是 2.4 在单二进制与全微服务之间补上的中间台阶。无论采用哪种模式Loki 都通过-target命令行参数指定启动时运行哪些微服务组件所有组件都打包在同一个二进制中docs/sources/get-started/deployment-modes.md。在 2.4 时代运行简单可扩展部署只需将部分实例以-targetread、其余以-targetwrite启动并共享同一对象存储与 ring 状态即可。核心特性三common配置块与 70% 的配置缩减2.4 新增了common配置区块它允许将大量重复的配置项集中定义一次例如存储、ring、复制因子、地址等公共信息。配合更新后的默认值Loki 的配置体积平均缩小约 70%并且开箱即用即可获得更合理的默认值与限制。发布说明将示例本地配置example local configuration确立为运行 Loki 的新参考。当前仓库中的 cmd/loki/loki-local-config.yaml 即是这一配置哲学的直观体现——该文件是目前仓库版本已演进到 tsdb 存储与 schema v13的参考配置但其骨架与 2.4 引入的common思想一脉相承auth_enabled: false server: http_listen_port: 3100 grpc_listen_port: 9096 log_level: debug grpc_server_max_concurrent_streams: 1000 common: instance_addr: 127.0.0.1 path_prefix: /tmp/loki storage: filesystem: chunks_directory: /tmp/loki/chunks rules_directory: /tmp/loki/rules replication_factor: 1 ring: kvstore: store: inmemory query_range: results_cache: cache: embedded_cache: enabled: true max_size_mb: 100 limits_config: metric_aggregation_enabled: true schema_config: configs: - from: 2020-10-24 store: tsdb object_store: filesystem schema: v13 index: prefix: index_ period: 24h ruler: alertmanager_url: http://localhost:9093 frontend: encoding: protobuf可以看到common块统一收纳了实例地址、路径前缀、文件系统存储、复制因子与 ring 的 KV 存储内存模式schema、limits、查询缓存等再各自按需补充整份配置非常精简。对于需要外部缓存与更高性能的场景仓库还提供了 cmd/loki/loki-local-with-memcached.yaml 作为对照参考。另外2.4 在未配置任何外部缓存时默认启用内存 FIFO 缓存对应 PR 4519这有助于提升查询性能但也意味着 Loki 会消耗更多内存运维时需预留相应的内存资源。核心特性四Recording Rules 正式化Recording rules记录规则在 2.4 不再是实验性功能。该版本为其实现了更健壮的底层支撑——复用 Prometheus 已有的写前日志Write Ahead LogWAL代码从而显著提升规则评估与结果落盘的可靠性。Recording rules 的价值在于把频繁使用或计算昂贵的查询预先计算并将结果保存为新的时序指标。当前仓库的 docs/sources/alert/_index.md 对此有精确定义与告警规则类似记录规则也会周期性评估区别在于它把查询结果落盘为新指标供后续查询与告警复用。Loki 中负责持续评估这组可配置查询并基于结果执行动作的组件是ruler该文档同时强调这一机制还可以把没有暴露任何指标的组件通过日志纳入可观测体系即所谓的黑盒监控与事件告警场景。2.4 使 ruler 的记录规则在可靠性上向 Prometheus 看齐这一特性对于从日志中派生业务指标、做容量规划与长周期趋势分析的用户尤为实用。核心特性五Promtail Kafka Consumer2.4 新增了Promtail Kafka Consumer可以轻松将日志从 Kafka 取出并送入 Loki。这对于已经用 Kafka 作为日志传输总线例如对接 Fluentd、Logstash 或自研采集器的场景的团队来说是接入 Loki 的一条低成本捷径。随着项目演进Kafka 摄取能力在后续版本中持续强化当前仓库中 docs/sources/send-data/alloy/examples/alloy-kafka-logs.md 提供了面向 Alloy 的 Kafka 日志摄取示例而pkg/kafka、pkg/kafkav2目录则展示了 Kafka 消费在 Loki 内部实现层面的不断迭代包括分区消费、编码解码、offset 管理等说明从 Kafka 取日志已成为 Loki 生态中的一等公民能力。核心特性六LogQL 增强——分组匹配与日期时间模板函数得益于社区贡献2.4 为 LogQL 带来了多项增强group_left 与 group_right多对一 / 一对多向量匹配LogQL 新增了group_left与group_right修饰符用于处理多对一many-to-one与一对多one-to-many向量匹配。其语义与 PromQL 一致当一侧的每个向量元素可以与多侧的多个元素匹配时必须显式使用group_left或group_right指定哪一侧拥有更高的基数。语法形式如下见 docs/sources/query/query_reference.mdvector expr bin-op ignoring(labels) group_left(labels) vector expr vector expr bin-op ignoring(labels) group_right(labels) vector expr vector expr bin-op on(labels) group_left(labels) vector expr vector expr bin-op on(labels) group_right(labels) vector expr其中group修饰符携带的标签列表表示从一侧额外纳入结果指标的标签同一个标签只能出现在on与group_x之一。分组修饰符仅能用于比较与算术运算而and、unless、or默认与右向量的全部条目匹配。典型应用示例按app与status计算各状态请求占比并将结果与总请求数做除法sum by (app, status) ( rate( {jobhttp-server} | json [5m] ) ) / on (app) group_left sum by (app) ( rate( {jobhttp-server} | json [5m] ) )另一个使用group_left(organization)从右侧向量带出附加标签、计算每个用户、组织、命名空间下被丢弃事件成本占比的完整示例同样记录在 docs/sources/query/query_reference.md。label_format与line_format支持日期时间处理label_format与line_format模板函数新增了日期时间处理能力核心是now与date等函数详见 docs/sources/query/template_functions.mddate(fmt string, date interface{}) string按给定的 Go 时间布局golang datetime layout返回时间的文本表示例如{{ date 2006-01-02 now }}now返回 Loki 服务器本地时区的当前时间例如{{ now }}模板中还可直接使用__timestamp__与管道组合例如{{ __timestamp__ | date 2006-01-02T15:04:05.00Z-07:00 }}与{{ __timestamp__ | unixEpoch }}。这使日志解析、标签改写与输出格式化时可以就地完成时间换算而无需预先在采集端处理显著提升了日志管线pipeline的表达力。核心特性七Promtail 通过 HTTP 接收 ndjson 与纯文本日志另一项社区贡献是让Promtail 可以接受 ndjson 与纯文本日志文件plaintext并通过 HTTP 推送即增强loki_push_api的摄取方式。这意味着除了主动抓取文件之外Promtail 还可以作为一个 HTTP 接收端点供其他程序或脚本以 ndjson 或纯文本格式直接 POST 日志再统一转发给 Loki。这一能力打通了非日志文件形态的数据接入场景例如脚本输出、API 回调、命令行工具的结果等都能以极低的成本汇入 Loki进一步呼应了 2.4 让日志更容易进入 Loki的版本主题。升级注意事项默认值变更清单2.4 对配置体系做了大量调整。官方态度是已尽力保证与既有配置兼容但部分默认限制值的变化可能会影响到那些未在配置文件中显式设置这些限制的用户。因此升级前务必阅读升级指南当前仓库中可参考 docs/sources/setup/upgrade/_index.md。v2.4.0 默认值变更以下为 2.4.0 中发生变化的 limits 默认值完整表格来自 docs/sources/release-notes/v2-4.mdconfignew defaultold defaultingestion_rate_strategygloballocalmax_global_streams_per_user50000 (no limit)max_query_length721h0h (no limit)max_query_parallelism3214max_streams_per_user0 (no limit)10000reject_old_samplestruefalsereject_old_samples_max_age168h336hper_stream_rate_limit3MB-per_stream_rate_limit_burst15MB-逐项解读其中的关键变化ingestion_rate_strategy 从 local 变为 global限流策略从按实例本地统计改为按租户全局统计配合 ring 数据实现全集群维度的速率控制避免多副本下各自为政导致的总吞吐失控。max_global_streams_per_user 从无限制收紧为 5000这是对单租户全局流数量的硬性保护防止高基数标签组合打垮 ingester。max_query_length 从无限制收紧为 721h约 30 天限制单次查询覆盖的时间跨度避免超长范围查询压垮存储层。reject_old_samples 从 false 变为 true、reject_old_samples_max_age 从 336h 缩短为 168h默认开始拒绝过旧的样本。这与乱序写入特性形成平衡——乱序被接受但超出 168 小时7 天的旧样本默认会被拒绝。当前仓库 pkg/validation/limits.go 中validation.reject-old-samples默认true、reject-old-samples.max-age默认7d即 168h正是这一策略的延续。per_stream_rate_limit / per_stream_rate_limit_burst3MB / 15MB新增的单流级速率限制用于防止某一条高流量日志流独占写入带宽。这些变更意味着升级前请检查自己的配置是否显式设置了上述项。若此前依赖无限制的旧默认值例如超长查询、超多流、超旧样本升级后可能突然被新默认值拦截需要在limits_config中按需显式覆盖。v2.4.2 默认值变更2.4.2 又追加了一批默认值调整源自 PR 5077confignew defaultold defaultparallelise_shardable_queriestruefalsesplit_queries_by_interval30m0squery_ingesters_within3h0smax_chunk_age2h1hmax_concurrent1020这批变更进一步朝着开箱即用更优的方向演进parallelise_shardable_queries 从 false 变为 true默认对可分片的查询启用并行化查询性能受益split_queries_by_interval 从 0s 变为 30m查询默认按 30 分钟间隔拆分配合并行化降低单次查询压力query_ingesters_within 从 0s 变为 3h只查询最近 3 小时内的 ingester 数据更早的数据走存储层减少 ingester 压力max_chunk_age 从 1h 变为 2hchunk 在内存中停留更久再刷新提升写入批量效率max_concurrent 从 20 降为 10降低默认并发上限更保守地保护资源。2.4 系列 Bug 修复2.4.2 修复的 Bug[PR 4968]trevorwhitney修复查询 ingester 时错误返回 ruler、导致内部服务器错误code Unimplemented的问题[PR 4875]trevorwhitney当使用memberlist作为一致性哈希 ring 存储时正确遵循common配置块中指定的复制因子[PR 4792]AndreZiviani修正文档中以下配置项的错误默认值scheduler_dns_lookup_period、min_ready_duration、final_sleep、max_transfer_retries、chunk_retain_period、chunk_target_size、batch_size、timeoutRedis 请求。2.4.1 修复的 Bug2.4.1 修复了 2.4.0 引入的两个问题[PR 4687]owen-d消除未使用租户 overrides 文件时 compactor 的 panic[PR 4681]slim-bean修正readtarget 的初始化逻辑——错误的初始化会导致 chunk 刷新后、querier 下载新索引表之前出现查询空洞query gaps。2.4.0 修复的重要 Bug[PR 4598]kavirajk修复 IP 匹配器词法分析器使其能区分过滤器与标识符[PR 4563]cyriltovena修复 Series 函数在分片场景下的处理[PR 4518]slim-bean修复对象被错误归还到sync.Pool的问题[PR 4411]slim-bean修复 frontend 等待永不到达的结果导致卡死的问题[PR 4238]liguozhong修复 distributor 的 goroutine 泄漏。安全修复限制 HTTP 方法2.4.0 包含一项安全相关修复[PR 4627]在 HTTP 端点上显式限定允许的 HTTP 方法。背景是社区用户发现 Loki 的所有端点都会响应 HTTP OPTIONS 请求而部署在 Loki 前面、负责 HTTP 认证的代理会将 OPTIONS 请求未认证地透传给 Loki从而允许用户发起未认证/未授权的查询。该修复为每个端点限定了允许的 HTTP 方法类型并禁止 OPTIONS 请求堵住了这条未授权访问通道。对于任何将 Loki 置于反向代理或网关之后的部署这是一条值得特别关注的加固措施——升级到 2.4.0 及以上版本即可获得该防护。总结Loki 2.4 以接入更简单、运维更简单为核心交出了一份内容密集的版本答卷乱序写入移除长期存在的时序约束简单可扩展部署为中等规模用户提供了微服务之外的扩展路径common配置块与全新默认值让配置大幅瘦身且更合理Recording rules 借助 Prometheus WAL 正式化Promtail 获得 Kafka 消费与 HTTP 摄取能力LogQL 的分组匹配与日期时间函数则显著增强了查询表达力。对于升级用户最需要关注的是文中两张默认值变更表——尤其是ingestion_rate_strategy、max_global_streams_per_user、reject_old_samples、max_query_length等项的收紧。若你的存量配置未显式设置这些项请在升级前评估实际影响并在limits_config中按需覆盖。完整的变更明细可继续查阅仓库根目录的 CHANGELOG.md 中 2.4.0 至 2.4.2 的条目。【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考