Grafana 系列文章（十）：为什么应该使用 Loki

️URL: https://grafana.com/blog/2020/09/09/all-the-non-technical-advantages-of-loki-reduce-costs-streamline-operations-build-better-teams/

Description:

我们都知道为什么 Loki 对日志管理有很大帮助。但这里有所有的原因，为什么你公司的会计和运营团队也会喜欢 Loki。

为什么应该使用 Loki?

—— 降低成本，简化运营，建立更好的团队

除了技术方面的理由，以及它的可伸缩性之外，它的组织收益往往会被低估或忽视。

我想谈谈 Loki 所做的事情——或者更好的是，它能让你避免做什么。这些都是我吃了苦头才学会的。当你扩充人员、团队或项目而不是数据集时，这些事情可能是有意义的。

这大致可以分为两个阵营：成本和过程，假设成本是货币的，过程是组织的。

Loki 技术原理简介

首先是对 Loki 工作原理的简要介绍，这应该有助于其他方面的介绍。Loki 是一个具有成本效益的、可扩展的、无偏见的日志聚合器，它主要基于 Prometheus 标签范式，并与 Cortex 内部结构缝合在一起，以实现扩展。.

Loki 摄取了你的日志，并使它们可以被搜索。你知道，那些包含技术债务的无定形表现的文本文件。你的应用程序的脆弱的、试探性的故事情节。衡量标准的简短性永远无法表达的东西。调试日志在阳光和彩虹下看起来毫无用处，但在故障期间却价值连城。

从本质上讲，Loki 做出了两个选择，其他一切都继承了这个选择。

它只对元数据的一部分进行索引，而不是整个日志行。
它将其存储层解耦为一对可插拔的后端：一个用于索引，一个用于压缩日志。

为什么 Loki 只索引元数据

所以，Loki 只对元数据进行索引。这到底是如何使它的运行更具成本效益的，又有多少？

对于全文索引来说，索引本身最终会比它们所索引的数据大，这很常见。而索引的运行成本很高，因为它们需要更昂贵的硬件（通常是占用大量内存的实例）。

Loki 根本不对日志的内容进行索引，而只是对其来源的元数据进行索引（标签如app=api，environment=prod，machine_id=instance-123-abc）。

因此，Loki 不需要维护昂贵的实例集群来提供大型的全文索引，而只需要担心一小部分的数据。根据经验，这比数据要小 4 个数量级（万分之一）。

因此，一开始，Loki 就把运行索引日志聚合器中通常操作成本最高的部分降到最低。

为什么 Loki 使用对象存储作为日志存储

我们刚刚介绍了 Loki 做出的索引决定；现在我们来看看解耦存储如何帮助降低成本。毕竟，Loki 也需要存储日志。它通过将它们以压缩块的形式发送到 AWS S3 这样的可插拔对象存储中。

与我们之前谈论的昂贵的内存饥饿实例相比，对象存储是白菜价便宜的，非常具有成本效益。日志一直在那里，直到被访问为止。从本质上讲，微小的标签索引被用来将请求路由到对象存储中的压缩日志，然后在商业硬件上以高度并行的方式解压缩和扫描。

为了帮助我们过渡到更多的面向过程的好处，我想指出的是，当日志记录很便宜时，它消除了减少日志记录的反常动机。不记录那些调试日志是一种反模式（因为它们的存储和检索成本很高）。当存储便宜的时候，我们可以避免这些艰难的决定，并确保我们在对抗故障时有我们需要的资源。

Loki 如何减少你的运营头痛问题

现在我们已经介绍了我们的会计人员喜欢 Loki 的原因，让我们来看看我们的运营团队为什么也喜欢 Loki 的细微原因。

因为 Loki 采取了非索引的日志记录方式，它避免了对结构化日志记录的依赖，以推动对日志数据的运营洞察力。这意味着不需要用预处理工具来协调模式定义，也不需要在多个应用程序或团队中尝试改变这些模式时进行后续的打怪游戏。

构建临时管道工具和向后兼容迁移的问题其实并不适用。然而，在避免预处理时，有必要提及权衡。在查询时，我们必须了解如何与数据进行有意义的互动。

但是，这种区分是多么的好啊！查询时间的技术债务可以用任何方式管理，并在很长一段时间内管理，或者根本不管理（这也是我们在查询时间使用logfmt进行可读性/grepping 的一个主要原因）。

另一方面，摄取时间的预处理需要巨大的前期努力，对变化极其脆弱，并导致组织摩擦。

问题始终是，内部各组之间存在着各种各样的使用案例、格式和专业知识。但是这些记录方法中的一个给了我们围绕这个问题的灵活性，而另一个则没有。

Loki 缺乏正式的模式 (202204 有了），这并不是说它不能用于分析。但它是为开发者和操作者量身定做的，更倾向于实现事件响应而不是历史分析。也就是说，Loki 的下一个版本将带来强大的分析能力，用于临时性的指标。

它也不只是 grep。它的 LogQL 查询语言以 Prometheus 的 PromQL 为模型，能够快速证明假设并在日志和指标之间无缝切换。例如，从日志条目中快速生成错误率，就像这样简单。

如前所述，我最喜欢 Loki 的一些东西是它使我们能够避免做的事情。

还记得我们的小索引和无模式的数据模型吗？Loki 允许我们避免处理冷热索引、生命周期管理，以及当审计问题出现时，为重新激活旧数据而进行的一次性归档数据取回处理。只要把你的旧数据运送到廉价的对象存储中，就不用担心在昂贵的硬件上管理连续的以性能为重点的索引层。

Loki 会自动创建、旋转和过期自己的微小索引，确保它不会增长得太大，并使用户能够透明地查询任何数据，只要你指定保留时间。

Loki 还能无缝地处理其内部存储版本的升级。想利用一些新的改进吗？没问题。Loki 为这些之间的边界保持一个参考，在它们之间透明地分割查询，并将它们缝合在一起。不需要担心卸载和重新加载旧的模式版本的兼容性问题。

Loki 如何改善你的团队

接下来，我想谈一谈 dev 和 ops。将这两者结合起来已经变得越来越流行（而且有充分的理由）。

不过这里有一个区别--不要把理解软件的部署方式/地点与运行可观察性系统混为一谈。让你的应用程序开发人员记录他们想要的东西，而不用担心他们需要使用哪种日志模式来确保不会破坏他们的观察工具的一些预处理管道。

如前所述，我们在 Grafana Labs 更喜欢 logfmt，因为它的简单输出可以实现 grep 友好的查询时间过滤/操作。重点是，某种程度的一致性是好的，但不是必须的。让你的开发者和运维专注于他们所需要的本质，而不用担心你的可观察性系统的范式。

Loki 缺乏用户定义的模式，而且它的非索引性质消除了开发人员和运维人员的认知负担，使他们能够重新关注他们工作的本质，然后在需要时转向查询 Loki。

让你的运营团队了解运行和扩展 Loki，包括配置 promtail（或你使用的任何代理）的辅助需求。我建议使用标签来给你的日志附加环境标识符，比如application=api，env=prod，cluster=us-central等。然后，用户可以混合和匹配标签过滤器，以快速细化问题发生的地方，并利用 Loki 的读取路径的大规模并行性质，以低成本在潜在的巨大数据集上进行任意的查询。

而且不用担心-- Loki 是开源的。它确保了解 Loki 的入门门槛相对较低。不需要觉得只从其他大型组织中招聘，也不需要担心新来的工程师没有使用你所选择的工具的经验。

Loki 可以在单机上以单二进制模式运行（像 Prometheus），然后在你的用例因规模、冗余或可用性问题而增长时横向扩展。我们有大量的用户在从树莓派到大规模、水平扩展的集群中运行 Loki。

Loki 并不是什么都能做，但我们认为它对其使用情况做了很好的权衡：一个快速、经济、高度可扩展的日志聚合器，与 Prometheus 标签模型有很好的集成，可以毫不费力地在指标和日志之间切换。