共计 3115 个字符，预计需要花费 8 分钟才能阅读完成。
👉️URL: https://grafana.com/blog/2020…
📝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 标签模型有很好的集成，能够毫不费力地在指标和日志之间切换。
Grafana 系列文章
Grafana 系列文章
三人行, 必有我师; 常识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.
