为什么使用loki,loki有什么优势

2020 年 9 月 9 日

我想谈谈 Loki 能做的事情 — — 或者更确切地说，它能让你避免做的事情。我从艰难的经历中学到的东西。当你扩展人员、团队或项目而不是数据集时，这些东西可能很有意义。

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

Loki 如何帮助企业提高盈利能力

首先简要介绍一下 Loki 的工作原理，这应该有助于理解其余部分。Loki 是一种经济高效、可扩展、不受约束的日志聚合器，主要基于Prometheus标签范式，并与Cortex内部结构结合在一起以进行扩展。

Loki 会提取您的日志并使其可搜索。您知道，这些文本文件包含技术债务的无定形表现形式。应用程序脆弱、不确定的故事情节。简洁的指标永远无法表达的东西。调试日志在阳光明媚时似乎毫无用处，但在停机期间却价值连城。

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

• 首先，它仅索引一小部分元数据而不是整个日志行。
• 其次，它将存储层解耦为一对可插入后端：一个用于索引，一个用于压缩日志。

为什么 Loki 只索引元数据

那么，Loki 只索引元数据。这究竟如何使其运行更具成本效益，以及成本效益有多大？

对于全文索引，索引本身的大小通常大于索引的数据。而且索引的运行成本很高，因为它们需要更昂贵的硬件（通常是 RAM 密集型实例）。

Loki 根本不索引日志的内容，而只索引有关它们来源的元数据（如 app=api、environment=prod、machine_id=instance-123-abc 等标签）。

因此，Loki 无需维护大量昂贵的实例来为大型全文索引提供服务，而只需担心一小部分数据。据传，这比数据小约 4 个数量级（1/10,000）。

因此，Loki 从一开始就最大限度地减少了运行索引日志聚合器过程中成本最高的部分。

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

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

与我们之前讨论的昂贵的、内存占用大的情况相比，对象存储便宜得像泥土非常经济高效。日志会一直保存在那里，直到被请求。实际上，微小的标签索引用于将请求路由到对象存储中的压缩日志，然后以高度并行的方式在商用硬件上解压和扫描这些日志。

为了帮助我们实现更面向流程的优势，我想指出，当日志记录成本低廉时，它会消除减少日志记录的不良动机。不记录这些调试日志是一种反模式（因为它们的存储和检索成本很高）。当存储成本低廉时，我们可以避免这些艰难的决定，并确保在应对中断时拥有所需的资源。

Loki 如何减少你的运营难题

现在我们已经了解了为什么我们的会计师喜欢 Loki 的以美元计价的（或您选择的非头韵货币）原因，让我们来探讨一下为什么我们的运营团队也青睐 Loki 的具体原因。

由于 Loki 采用非索引式日志记录方法，因此它避免了依赖结构化日志记录来从日志数据中获取运营见解。这意味着在尝试跨多个应用程序或团队更改这些内容时，无需使用预处理工具协调架构定义，也无需进行随后的打地鼠游戏。

构建临时管道工具和向后兼容迁移的问题实际上并不适用。但是，在避免预处理时，重要的是要提到权衡：在查询时，我们必须了解如何有意义地与数据交互。

但是这种区别有多好！查询时间技术债务可以通过多种方式和长时间进行管理，或者根本不进行管理（这也是我们在查询期间使用 logfmt 提高可读性/grepping 的主要原因）。

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

问题始终在于，内部团队的用例、格式和专业知识千差万别。但其中一种日志记录方法可以让我们灵活地解决这个问题，而另一种则不能。

Loki 缺乏形式化模式并不意味着它不能用于分析。但它是针对开发人员和操作员量身定制的，并且更倾向于启用事件响应而不是历史分析。也就是说，Loki 的下一个版本将为临时指标带来强大的分析功能。

它也不只是 grep。它的 LogQL 查询语言以 Prometheus 的 PromQL 为蓝本，可以快速验证假设，并在日志和指标之间无缝切换。例如，从日志条目快速生成错误率非常简单：

正如之前提到的，我最喜欢 Loki 的一点是它能让我们避免做一些事情。

还记得我们的微型索引和无模式数据模型吗？Loki 使我们无需处理热索引和冷索引、生命周期管理和一次性的魔法过程，即可在出现审计问题时重新激活旧数据。只需将旧数据发送到廉价的对象存储，无需担心在昂贵的硬件上管理连续的以性能为中心的索引层。

Loki 将自动创建、轮换和过期其自己的小索引，确保它不会变得太大，并允许用户在您指定的保留期内透明地查询任何数据。

Loki 还可以无缝处理内部存储版本的升级。想要利用一些新的改进吗？没问题。Loki 保留了这些边界之间的引用，透明地跨它们拆分查询，然后将它们重新拼接在一起。无需担心卸载和重新加载旧架构版本以实现兼容性。

Loki 如何改善你的团队

在结束之前，我想谈谈开发人员与运维人员。将这两者结合起来变得越来越流行（并且有充分的理由）。

不过，这里有一个区别——不要将理解软件部署方式/位置与运行可观察性系统混为一谈。让您的应用程序开发人员记录他们想要的内容，而不必担心他们需要使用哪种日志记录模式，以确保它不会破坏他们的可观察性工具的某些预处理管道。

如前所述，我们更喜欢 Grafana Labs 的 logfmt，因为它的简单输出支持 grep 友好的查询时间过滤/操作。重点是，一定程度的一致性很好，但不是必需的。让您的开发人员和操作员能够专注于他们需要的本质，而不必担心可观察性系统的范例。

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

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

不用担心——开源是可转让的。它确保了理解 Loki 的门槛相对较低。无需感到只能从其他大型组织招聘，也不必担心新来的工程师没有使用您选择的工具的经验。

Loki 可以在单二进制模式下作为一体机在单台机器上运行（如 Prometheus），然后随着您的用例因规模、冗余或可用性问题而增长，水平扩展。我们拥有广泛的用户，他们在从 Raspberry Pi 到大规模、水平扩展的集群等各种设备上运行 Loki。

Loki 并不能完成所有事情，但我们认为它在其用例方面做出了极好的权衡：一个快速、经济高效、高度可扩展的日志聚合器，与Prometheus标签模型完美集成，允许轻松在指标和日志之间切换。

总结起来就是

1.loki更轻量，

2.没有添加数据索引所以更省成本,特别是存储成本以及插入或者搜索时候的资源占用，

3.通过label等进行高性能的匹配，

4.但同时也不支持复杂的搜索等,