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

️URL: grafana.com/blog/2020/0…

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 标签模型有很好的集成，能够毫不费力地在目标和日志之间切换。