你应该使用的基本配置设置，这样你就不会在洛基中掉落日志

在这篇文章中，我们将讨论确保Loki写路径(Loki摄取日志的地方)可靠性的技巧。更简洁的洛基怎么能保证我们不会丢失日志？对于那些尝试过单一二进制Loki部署并决定构建更适合生产的部署的人来说，这是一个常见的起点。现在，让我们看看这两个工具洛基用于防止日志丢失。

复制因子

洛基在摄取组件，基于一个可配置的复制因子，一般为3。洛基只会在法定人数(Replication_factor / 2 + 1)接受它(在这种情况下是2)。这意味着，通常情况下，我们最多可以丢失2个摄取器而不会看到数据丢失。注意，在最坏的情况下，如果3个副本写操作中只有2个成功，我们只能丢失1个ingester而不会丢失数据。让我们来看看这个过程中涉及的几个组件。

经销商

分发服务器负责接收写操作、验证它们并对它们进行预处理。它是一个无状态的服务，可以通过伸缩来处理这些初始步骤，从而最大限度地减少ingesters工作负载。它还使用环来找出replication_factor将数据转发到的摄取器。

环

环是一个子组件，负责处理摄取器之间的协调责任。它可以由外部服务支持，例如领事或etcd，或透过流言蜚语协议(memberlist)。我们不会在这篇文章中讨论戒指的细节，但它创造了散列环使用一致性哈希来帮助将日志流调度到replication_factor摄食者的数量。

环/ ^ / \ / \ v v分配器->摄取器->存储器

摄取

摄取器接收来自分发器的写操作，将它们缓冲到内存中，并最终将压缩的日志“块”刷新到对象存储中。这是最重要的组件，因为它保存已确认但尚未刷新到持久对象存储的日志。通过在刷新日志之前在内存中缓冲日志，Loki减少了对对象存储的写入，从而获得了性能和成本降低的好处。

基本配置设置

下面是一些配置设置ingester_config这对洛基的正常运行时间和耐久性保证很重要。

1. replication_factor前面已经提到过的复制因素是Loki应该复制多少份日志数据，以防止在刷新到存储之前丢失这些数据。我们建议将此设置为3.．
2. heartbeat_timeout心跳超时是在传入写入时跳过摄取器的时间。一个重要的结果是也这是之前，环可以无反应的最长时间所有写入时会跳过摄取器，本质上是停止集群范围内的摄取。我们建议将此设置为10米(游戏邦注:也就是说，执政官可能会在这段时间内被杀死并复活)。

现在，让我们来看看一些不那么重要，但很好的配置:

1. chunk_target_size块目标大小是“块”日志在被刷新到存储之前将达到的理想大小。我们建议将此设置为1.5MB (1572864字节)，这对于查询充分利用的块来说是一个很好的大小。
2. chunk_encoding数据块编码决定存储中的数据块使用哪种压缩算法。gzip是默认和有最好的压缩比，但我们建议时髦的因为它更快的解压速度，从而导致更好的查询速度。
3. max_chunk_age最大块年龄是一个日志流(一组具有相同标签名和标签值的日志)在被刷新之前可以在内存中被摄取器缓冲的最长时间。对于低吞吐量日志流，通常会达到这个阈值。为了在不让块覆盖太长时间范围和不创建太多小块之间找到一个良好的平衡，我们建议将此设置为2 h．
4. chunk_idle_period块空闲时间是Loki等待日志条目的最长时间，在此之前，Loki将认为流是空闲的或陈旧的，因此块将被刷新。在缓慢写入的日志流上设置过低会导致太多小块被刷新;将该值设置得太高可能会导致由于基数原因而被搅动的流消耗内存的时间超过必要的时间。我们建议将此设置为1 h来2 h的范围内。它可以和max_chunk_age，但将其设置更长意味着流将始终在max_chunk_age设置和将使一些指标不太准确。

细胞膜

我们将要讨论的第二种技术是预写日志(Write Ahead Log, WAL)。这是一个新特性，从2.2发行版开始可用，它有助于确保Loki不会在确认写入之前将所有传入数据写入磁盘，从而丢弃日志。如果摄取器由于某种原因死亡，它将在启动时重放该日志，安全地确保它之前在内存中的所有数据都已恢复。

专家提示:在使用WAL时，如果可能的话，我们建议给它一个隔离的磁盘。这样做可以帮助防止WAL受到不相关的磁盘压力、噪声邻居等的不利影响。还要确保磁盘写性能能够处理传入数据到摄取器的速率。洛基可以水平缩放以降低这种压力。

基本配置设置

下面是一些WAL配置，我们建议它们驻留在ingester_config：

1. 启用我们建议启用WAL作为防止数据丢失的第二层保护。
2. dir我们建议在隔离磁盘上指定一个目录供WAL使用。
3. replay_memory_ceiling在中断场景之后，WAL可能比摄取器的可用内存还要大。幸运的是，WAL实现了一种形式的反压，即使在内存受限的情况下也允许大量的回放。这replay_memory_ceilingconfig是WAL暂停重放的阈值，并在继续播放之前向摄取器发出清除数据的信号。因为这是一种效率较低的操作，所以我们建议将此阈值设置为一个较高但合理的边界或大约75％摄入者的正常记忆极限。对于我们的部署，这通常是存在的10 gb．

分别指出

这就是我们关于确保Loki不会丢失任何日志的简短指南。我们发现，在组合保证之间细胞膜和我们的replication_factor，我们可以肯定地说，不会留下任何原木。

开始使用Grafana、Prometheus、Loki和Tempo进行跟踪的最简单方法是Grafana Cloud和我们最近增加了一个新的免费计划，并升级了我们的付费计划．如果你还没有使用Grafana Cloud，今天免费注册并查看哪个计划符合您的用例。