嗨，我是欧文，洛基的维护者之一，我要用众所周知的笔头来说服你洛基的重要性。这并不是因为它规模(它确实)或者因为我在Grafanabob电竞频道实验室工作(我)。这是因为经常被忽视和未被充分体现的组织利益。
组织的利益? !这是什么，某种邪教吗?你为什么要回避技术问题?
哇，哇，哇。现在，稍等。这些技术指标仍然有效。但是它们在其他地方(比如在这里，在这里,在这里)，我认为我们给了他们足够的播出时间。
我想谈谈洛基做的事情——或者更好的是，它让你避免做什么。这是我好不容易才学会的。当你在扩展人员、团队或项目而不是数据集时，这些事情可能是有意义的。
这可以大致分为两个阵营:成本而且过程假设成本是货币的，过程是组织的。
洛基对底线有什么帮助
首先是关于洛基如何工作的简单入门，这应该有助于框架剩下的内容。Loki是一种具有成本效益的、可扩展的、无分类的日志聚合器，它主要基于普罗米修斯标签范式与缝合在一起皮质内部缩放。
洛基会吸收你的日志，让它们可以被搜索到。你知道的，那些文本文件包含了技术债务的无定形表现。你的应用程序的脆弱、试探性的故事情节。这些都是简单的度量标准无法表达的。当一切都是阳光和彩虹时，调试日志似乎毫无用处，但在停机期间却价值不菲。
本质上，洛基做了两个选择，其他一切都继承了这两个选择:
- 首先，它只索引元数据的一小部分，而不是整个日志行。
- 其次，它将其存储层解耦为一对可插入后端:一个用于索引，另一个用于压缩日志。
为什么洛基只索引元数据
洛基只索引元数据。这究竟是如何使运行更具成本效益的，以及成本效益是多少?
使用全文索引时，索引本身比它们所索引的数据更大是很常见的。而且索引的运行成本很高，因为它们需要更昂贵的硬件(通常是ram消耗大的实例)。
Loki根本不索引日志的内容，而是只索引关于它们来自哪里的元数据(标签如app=api, environment=prod, machine_id=instance-123-abc)。
因此，Loki不需要维护大量昂贵的实例来服务大型全文索引，而是只需要担心一小部分数据。有趣的是，这大约比数据小4个数量级(万分之一)。
因此，Loki立即将运行索引日志聚合器的操作成本最高的部分最小化。
为什么Loki使用对象存储来存储日志
我们刚刚介绍了Loki所做的索引决策;现在让我们看看解耦存储如何帮助降低成本。毕竟，洛基也需要存储日志。它通过将它们以压缩块的形式发送到AWS S3这样的可插拔对象存储库来实现这一点。
与我们之前讨论的消耗大量内存的实例相比，对象存储是廉价如土很划算的。日志保存在那里，直到被请求。本质上，微小的标签索引用于将请求路由到对象存储中的压缩日志，然后以高度并行的方式在商用硬件上对这些日志进行解压缩和扫描。
为了帮助我们过渡到更面向流程的好处，我想指出，当日志记录很便宜时，它消除了减少日志记录的不正当动机。不记录这些调试日志是一种反模式(因为存储和检索它们的开销很大)。当存储价格低廉时，我们可以避免做出这些艰难的决定，并确保在应对停机时拥有所需的资源。
洛基是怎么帮你减少行动上的麻烦的
现在我们已经讨论了以美元计价(或者你选择的非头韵货币)的原因，为什么我们的会计师喜欢洛基，让我们进入我们的运营团队也喜欢洛基的本质原因。
由于Loki采用无索引的日志记录方法，它避免了依赖结构化日志记录来驱动对日志数据的操作洞察。这意味着在尝试跨多个应用程序或团队更改模式定义时，不需要将模式定义与预处理工具进行协调，并且需要进行打地鼠游戏。
构建特别管道工具和向后兼容迁移的问题并不真正适用。但是，在避免预处理时，有必要提到一些权衡:在查询时，我们必须了解如何与数据进行有意义的交互。
但是这种区别是多么好啊!查询时技术债可以通过多种方式进行管理，可以在很长一段时间内进行管理，也可以根本不进行管理(这也是为什么我们在查询时使用logfmt来实现可读性/grepping的主要原因)。
另一方面，摄入时间预处理需要大量的前期工作，对变化非常脆弱，并引起组织摩擦。
问题总是存在于内部组之间有各种各样的用例、格式和专业知识。但是其中一种日志记录方法为我们提供了解决该问题的灵活性，而另一种则没有。
Loki缺乏形式化的模式并不是说它不能用于分析。但它是为开发人员和运营商量身定制的，更倾向于支持事件响应而不是历史分析。也就是说，洛基的下一个版本将带来强大的分析功能对于特别指标。
也不仅仅是grep。它的LogQL查询语言模仿了Prometheus的PromQL，支持快速假设证明和在日志和指标之间无缝切换。例如，从日志条目中快速生成错误率就像这样简单:
正如之前提到的，我最喜欢洛基的一些事情是它让我们可以避免做的事情。
还记得我们的小型索引和无模式数据模型吗?Loki允许我们避免处理冷热指数、生命周期管理以及在出现审计问题时重新激活旧数据的一次性死灵过程。只需将旧数据转移到廉价的对象存储中，不必担心在昂贵的硬件上管理以性能为重点的连续索引层。
Loki将自动创建、旋转和过期它自己的小索引，确保它不会变得太大，并允许用户透明地查询任何数据，只要您指定了保留。
洛基还可以无缝地处理内部存储版本的升级。想要利用一些新的改进?没有问题。Loki为它们之间的边界保留了一个引用，在它们之间透明地分割查询，并将它们缝合在一起。不需要担心卸载和重新加载旧的模式版本以获得兼容性。
(如果您想进一步减少操作开销，请查看Grafana云Grbob电竞频道afana Labs的全面管理可观察性平台，用于大规模的指标、日志和仪表板。在这里注册免费试用.）
洛基如何提高你的团队
在我离开你们之前，我想谈谈开发vs.运维。这两个人结婚变得越来越流行(而且有很好的理由)。
但这里有一个区别——不要把理解软件如何/在哪里部署与运行可观察性系统混为一谈。让应用程序开发人员记录他们想要的内容，而不用担心需要使用哪种日志模式，以确保它不会破坏可观察性工具的预处理管道。
如前所述，我们更喜欢在Grafana Labs中使用logfmt，因为它简单的输出支持grbob电竞频道ep友好的查询时间过滤/操作。重点是，一定程度的一致性是好的，但不是必要的。允许开发人员和操作人员专注于他们需要的本质，而不必担心可观察系统的范例。
Loki缺乏用户定义的模式，它的无索引特性消除了开发人员和操作员的认知负担，允许他们重新关注他们工作的本质，然后在需要时转向查询Loki。
让您的操作团队了解运行和扩展Loki，包括配置promtail(或任何您使用的代理)的辅助需求。我建议使用标签将环境标识符附加到您的日志，如application=api, env=prod, cluster=us-central，等等。然后，用户可以混合和匹配标签过滤器，以快速优化问题发生的位置，并利用Loki读取路径的大规模可并行特性，以低成本在潜在的巨大数据集上进行任意查询。
别担心，开源就是这样可转让的．这保证了了解洛基的门槛相对较低。不必拘于只从其他大公司招聘，也不必担心新来的工程师没有使用您选择的工具的经验。
Loki可以在单一二进制模式下作为一台机器上的一体化运行(如Prometheus)，然后随着您的用例由于规模、冗余或可用性问题而增长而水平扩展。我们有很多用户在各种平台上运行Loki，从树莓派到大规模的、水平扩展的集群。
Loki并不能做所有的事情，但我们认为它在用例方面做了很好的权衡:一个快速、经济有效、高度可伸缩的日志聚合器，并出色地集成到普罗米修斯标签模型，允许在指标和日志之间轻松切换。
