配置最佳实践

Grafana Loki 正在积极开发中，Loki 团队一直在努力提升性能。以下是一些当前最新的配置最佳实践，它们将为你带来最佳的 Loki 体验。

配置缓存

Loki 可以在多个级别缓存数据，这可以显著提高性能。详细信息将在未来的博文中提供。

日志的时间顺序

Loki 默认接受乱序写入。本节介绍了当 Loki 未配置为接受乱序写入时的最佳实践。

许多人在使用 Loki 时遇到的一个问题是客户端接收到乱序日志条目的错误。这是因为 Loki 中有一条严格的规则：

对于任何单个日志流，日志必须始终按时间递增的顺序发送。如果收到的日志的时间戳早于该流最近收到的日志的时间戳，则该日志将被丢弃。

从这句话中可以分析出几点。首先，这个限制是针对每个流的。我们来看一个例子

{job="syslog"} 00:00:00 i'm a syslog!
{job="syslog"} 00:00:01 i'm a syslog!

如果 Loki 收到这两行属于同一流的日志，一切都会正常。但如果是下面这种情况呢？

{job="syslog"} 00:00:00 i'm a syslog!
{job="syslog"} 00:00:02 i'm a syslog!
{job="syslog"} 00:00:01 i'm a syslog!  <- Rejected out of order!

对此你能做些什么？如果这是因为这些日志的来源是不同的系统呢？你可以通过一个每个系统唯一的附加标签来解决这个问题

{job="syslog", instance="host1"} 00:00:00 i'm a syslog!
{job="syslog", instance="host1"} 00:00:02 i'm a syslog!
{job="syslog", instance="host2"} 00:00:01 i'm a syslog!  <- Accepted, this is a new stream!
{job="syslog", instance="host1"} 00:00:03 i'm a syslog!  <- Accepted, still in order for stream 1
{job="syslog", instance="host2"} 00:00:02 i'm a syslog!  <- Accepted, still in order for stream 2

但如果应用程序本身生成的日志是乱序的呢？好吧，恐怕这是一个问题。如果你使用 Promtail pipeline 阶段等方式从日志行中提取时间戳，你可以选择不这样做，让 Promtail 为日志行分配时间戳。或者你可以尝试在应用程序本身中解决这个问题。

还值得注意的是，Loki push API 的批处理特性可能导致接收到一些乱序错误，这些错误实际上是误报。（可能是某个批处理部分成功并已存在；或者任何之前成功的条目都会返回乱序错误；或者任何新条目都会被接受。）

使用 snappy 压缩算法

Snappy 是目前 Loki 首选的压缩算法。它在速度方面比 gzip 表现出色得多，但在存储效率方面稍逊一筹。对我们来说，这是一个可以接受的权衡。

Grafana Labs 发现 gzip 在压缩方面非常好，但速度很慢，这导致查询响应变慢。

LZ4 在速度和压缩性能之间取得了良好的平衡。虽然压缩速度略慢于 snappy，但压缩率更高，从而在对象存储中生成更小的 chunk。

使用 chunk_target_size

使用 chunk_target_size 指示 Loki 尝试将所有 chunk 填充到目标压缩大小 1.5MB。这些更大的 chunk 对 Loki 处理更高效。

其他配置变量会影响 chunk 的满度。Loki 默认的 max_chunk_age 为 2 小时，chunk_idle_period 为 30 分钟，以限制内存使用量，并减少进程崩溃时丢失日志的可能性。

取决于使用的压缩算法（Loki 一直使用 snappy，其压缩率较低但性能更快），你需要 5-10 倍或 7.5-10MB 的原始日志数据来填充一个 1.5MB 的 chunk。请记住，一个 chunk 是针对每个流的，将日志文件拆分成越多的流，内存中驻留的 chunk 就越多，这些 chunk 在填满之前就越有可能因达到上述超时时间而被刷新。

许多小的、未填满的 chunk 会对 Loki 产生负面影响。团队一直在努力改进这一点，并可能考虑使用压实器 (compactor) 在某些情况下改善这个问题。但是，总的来说，建议保持不变：尽最大努力填满 chunk。

如果你的应用程序生成日志的速度足够快，能够快速填满这些 chunk（远低于 max_chunk_age），那么使用动态标签将其分解成不同的流就变得更加合理了。