用了日志系统新贵Loki，ELK突然不香了！

图片来自 Pexels

背景和动机

当我们的容器云运行的应用或者某个节点出现问题了，解决思路应该如下：

我们的监控使用的是基于 Prometheus 体系进行改造的，Prometheus 中比较重要的是 Metric 和 Alert。

Metric 是来说明当前或者历史达到了某个值，Alert 设置 Metric 达到某个特定的基数触发了告警，但是这些信息明显是不够的。

我们都知道，Kubernetes 的基本单位是 Pod，Pod 把日志输出到 stdout 和 stderr，平时有什么问题我们通常在界面或者通过命令查看相关的日志。

举个例子： 当我们的某个 Pod 的内存变得很大，触发了我们的 Alert，这个时候管理员，去页面查询确认是哪个 Pod 有问题，然后要确认 Pod 内存变大的原因。

我们还需要去查询 Pod 的日志，如果没有日志系统，那么我们就需要到页面或者使用命令进行查询了：

如果，这个时候应用突然挂了，这个时候我们就无法查到相关的日志了，所以需要引入日志系统，统一收集日志。

而使用 ELK 的话，就需要在 Kibana 和 Grafana 之间切换，影响用户体验。

所以 ，Loki 的第一目的就是最小化度量和日志的切换成本，有助于减少异常事件的响应时间和提高用户的体验。

ELK 存在的问题

现有的很多日志采集的方案都是采用全文检索对日志进行索引（如 ELK 方案），优点是功能丰富，允许复杂的操作。 但是，这些方案往往规模复杂，资源占用高，操作苦难。

很多功能往往用不上，大多数查询只关注一定时间范围和一些简单的参数（如 host、service 等），使用这些解决方案就有点杀鸡用牛刀的感觉了。

因此，Loki 的第二个目的是，在查询语言的易操作性和复杂性之间可以达到一个权衡。

全文检索的方案也带来成本问题，简单的说就是全文搜索（如 ES）的倒排索引的切分和共享的成本较高。

后来出现了其他不同的设计方案如： OKlog（https://github.com/oklog/oklog），采用最终一致的、基于网格的分布策略。

这两个设计决策提供了大量的成本降低和非常简单的操作，但是查询不够方便。因此，Loki 的第三个目的是，提高一个更具成本效益的解决方案。

整体架构

Loki 的架构如下：

不难看出，Loki 的架构非常简单，使用了和 Prometheus 一样的标签来作为索引。

也就是说，你通过这些标签既可以查询日志的内容也可以查询到监控的数据，不但减少了两种查询之间的切换成本，也极大地降低了日志索引的存储。

Loki 将使用与 Prometheus 相同的服务发现和标签重新标记库，编写了 Pormtail，在 Kubernetes 中 Promtail 以 DaemonSet 方式运行在每个节点中，通过 Kubernetes API 等到日志的正确元数据，并将它们发送到 Loki。

下面是日志的存储架构：

读写

可扩展性

Loki 的索引存储可以是 cassandra/bigtable/dynamodb，而 Chuncks 可以是各种对象存储，Querier 和 Distributor 都是无状态的组件。

对于 Ingester 他虽然是有状态的但是，当新的节点加入或者减少，整节点间的 Chunk 会重新分配，已适应新的散列环。

而 Loki 底层存储的实现 Cortex 已经在实际的生产中投入使用多年了。有了这句话，我可以放心的在环境中实验一把了。

作者：linkt1234

编辑： 陶家龙

出处： http://blog.csdn.net/Linkthaha/article/details/100575651

往期 精彩 回顾

【推荐】.NET Core开发实战视频课程   ★★★

.NET Core实战项目之CMS 第一章 入门篇-开篇及总体规划

【.NET Core微服务实战-统一身份认证】开篇及目录索引

Redis基本使用及百亿数据量中的使用技巧分享（附视频地址及观看指南）

.NET Core中的一个接口多种实现的依赖注入与动态选择看这篇就够了

10个小技巧助您写出高性能的ASP.NET Core代码

用abp vNext快速开发Quartz.NET定时任务管理界面

在ASP.NET Core中创建基于Quartz.NET托管服务轻松实现作业调度

现身说法：实际业务出发分析百亿数据量下的多表查询优化

关于C#异步编程你应该了解的几点建议

C#异步编程看这篇就够了

给我好看

好看你就

点点

我