早些时候 Erda Show 针对微服务监控、日志等内容做了专场分享，很多同学听完后意犹未尽，想理解更多对于日志剖析的内容。Erda 团队做日志剖析也有一段时间了，所以这次打算和大家具体分享一下咱们在做的一些事件，心愿对大家有所帮忙。

日志剖析平台其实是 Erda 微服务治理子平台上面的一个功能模块，那么明天我将从三个方面来开展分享：

• 日志剖析平台呈现的必要性；
• 日志剖析平台架构设计；
• Erda 目前是怎么做的、做了哪些工作以及将来的倒退方向。

日志剖析平台的必要性

“微服务”这一概念大略在 2013 年呈现，从这一概念初期到当初，大部分利用的业务场景皆是分布式、容器化的部署架构，或者至多是多服务架构，每个服务基本上是非单点的，并且会做单服务多实例的高可用部署。

在这种场景下，咱们须要重点解决对于日志的几个问题。

须要解决的问题

1. 接口报错了，如何在利用的多个容器中疾速的找到具体的异样日志？

第一个要解决的问题是对于异样日志的定位效率问题。比方，前端在申请某个页面，接口报错了，随后反馈给开发人员，惯例的接口报错通常不会间接给用户裸露特地具体的异样信息，只会有一个状态或是简要的谬误概述，这时须要开发者通过日志找到具体的异样信息（比方堆栈等）。

一般来说，通过接口门路咱们能够定位是哪个服务的报错，但进一步讲，咱们如何确定是这个服务下的哪个实例的报错呢？如果说咱们采纳这种比拟原始的形式，可能须要开发者别离查看每个实例（容器）的日志，这样会间接对开发效率产生影响。

2. 如何不便的查看曾经宕机的利用容器的日志？

另外一个须要解决的问题是日志存储的持久性问题。比如说在 K8s 平台下，某个应用服务的某个 pod 挂掉了被从新调度到了其余节点，或者本地存储的容器日志因为工夫的滚动而滚动没了，这时如果咱们想去回头看一下之前的日志，在机器上曾经不太容易找到了。

3. 如何能及时的发现某个利用容器产生了异样？

前两个问题属于被动型的需要，也就是说前端业务上曾经暴露出一些问题，而后咱们去回溯、查找一些日志的具体记录的需要。因为是用户反馈，这个流程链上的故障解决工夫是绝对较长的，那么应该如何缩短故障解决工夫？

很天然咱们会想到被动告警，在还没有大面积前端接口被大量用户发现前，后端出现异常时，零碎可能更及时的进行告警，并告诉相干人员及时处理，缩小故障工夫。这时咱们就十分须要一个零碎能够继续监听所有容器的日志，帮助开发者发现其中的异样并被动告警。

如果说没有日志剖析平台，其实以上三个问题并不是不能解决，然而会极大水平的影响效率。那么如果有了这样的日志剖析平台，由它来提供集中式查问、长久化存储以及被动告警等性能，咱们能够疾速且高效的解决这三个问题。

日志剖析平台能提供什么

说到日志剖析平台的必要性，咱们务必要理解一下它能为咱们提供什么样的服务，上面咱们就来具体看一下：

1. 集中式、一站式查问

在查问方面，日志剖析平台应该是集中式、一站式的查问，不再须要登录不同机器或者容器去低效地手动查看日志，而只须要在一个对立的页面上输出一些查问语句，就能轻松查问所有容器的日志了。

2. 长久化，历史可追溯

在存储方面，能够给日志剖析平台装备有预期的专门存储配额，以便可能更好地应答宕机、降级、调度等导致日志跨节点的状况，放弃查问历史日志时的简略性。

3. 智能化，被动发现问题

智能化告警通常也是一个必要性能，这里的智能化有两层意思：

你能够被动配置一些规定，比如说依据代码或曾经产生的一些异样日志，能够晓得特定异样是什么样子，随后配一个规定，零碎就会继续对输出的日志做一些规定检测，如果发现匹配项，就会进一步通过你提前配置的告警渠道，告诉到具体的人；

主动发现“异样”，其实有点相似目前的机器学习、深度学习，也就是说，即便你没有配置任何规定，然而零碎能够通过对日志流的监听和学习，去发现异常的日志，而后告诉你去关注，这是更智能化的一些货色。

日志剖析平台架构设计

咱们曾经晓得，日志剖析平台能够给咱们带来便当及效率的晋升，那么如果咱们想实现这样一个平台，须要如何进行架构设计呢？

想要做架构设计，首先要理解业务场景和需要，而后联合被解决数据的特点，才可能推断平台架构设计应该具备哪些能力。之后咱们再依据这些能力去寻找、设计相匹配的计划，并在这些计划中筛选真正可落地的去执行。

数据特点

1. 时序数据

咱们晓得日志属于时序数据，只新增、不删除。它有几个字段比拟要害：timestamp，tags，fields

• timestamp：工夫字段对时序型数据是用来进行比拟和要害的字段；
• tags：tags 代表一组字段，通常对于时序数据来讲，作为标签类型的字段个别都是能够搜寻的，也就是这些字段须要建设索引，如：服务名、容器名、容器 IP 等；
• fields：fields 也代表一组字段，这些字段绝对于 tags 的不同在于，fields 字段是通常存储那些不须要搜寻的内容，比方：如果对于具体的日志内容你不打算去搜寻，就能够用 fields 类型字段存储。

日志时序数据的特点提醒咱们，能够思考应用时序数据库来存储日志，比方 cassandra。

2. 时效性强

对于日志数据来讲，咱们个别只关怀一段时间的数据，对于很早之前的数据，比方一个月、两个月之前，甚至半年之前的数据，咱们基本上是不会去关怀的。因为个别有故障的时候，咱们可能才须要去看一下具体的日志信息，而呈现故障时不大可能会拖到很久之后才去解决和复盘这个问题。

3. 数据量大

数据量大有两个含意：一是说数据的单条日志可能比拟大，比方像 Java 利用的一个异样堆栈，尤其那种 Caused by 嵌套了好几层的，可能单条日志就会有几百行；另外一个是说，日志的条数多，随着业务和利用的增多，加上某些利用还可能会开启 DEBUG 级别的日志，整体的日志量也会比拟大，而且可能呈现短时的峰值。

以上是日志数据的特点，而后咱们对从咱们日志剖析平台这个角度来看看，咱们对系统有什么需要。

业务需要特点

1. 查问速度快，秒级响应

首先，咱们心愿它可能疾速查问，输出查问关键字，就可能秒级响应查问后果。

2. 时间段范畴查问

通常，查问会依照一个明确的工夫范畴操作，这有一个益处：后端存储的抉择会更多一些。

3. 高基数值点查问

什么是高基数值呢？像用户 IP、Trace ID 这类数据，简直每个用户申请的值都不一样，这就属于高基数。对于这类数据的查问也是一个强需要，比方前端 web 接口报错，而响应里加了 Trace ID 这样的字段，此时就能够通过 Trace ID 字段去查看整个过程中记录的异样日志或要害日志，这也是一个比拟常见的需要。

4. 标签查问

标签查问个别能够认为是对服务名、容器 IP 这样的字段查问需要，这也属于强需要之一。

5. 全文检索查问

全文检索查问是否属于强需要之一，其实是个值得衡量的问题。如果客户端在采集端曾经做了一些预处理，如：把整行的日志 content 在采集时拆分成了具体的工夫级别、异样类型等单个关键字段，这样来讲，全文检索查问可能就不是一个强需要了，但同时，备选计划的范畴可能会更大一些。这里须要揭示的是，没有全文检索反对，并不代表不能含糊检索。借助列存储的高压缩率和高 IO 效率，在内存中进行含糊过滤的成果也很赞！

6. 聚合统计

聚合统计中最简略的是 Count 统计，更简单一点的有基于更多字段维度的简单聚合图表反对，这些性能在一些产品中也有提供，但需依据个体具体需要来判断该项是不是强需要。

7. 被动告警

被动告警意味着零碎不仅具备被动查问性能，同时也可能及时发现问题并告警，这样能力缩小故障工夫。

介绍完业务需要方面的 7 个特点后，在设计架构时，就可能助力咱们迅速 get 到须要思考哪些方面了。

架构要求

1. 软硬老本

当然，老本是肯定要的，不论是做什么设计，必定须要思考老本，这其中包含软硬的老本。

硬件老本指的是咱们的机器数量：CPU、内存、磁盘等这样的资源。这外面存在一个问题，因为对于日志而言，咱们讲数据量大，单条的体积可能也比拟大，如果确定不须要全文检索，或只检索其中很少的几个关键字段，对于那些较长的字段，仅仅只是想随着搜寻条件把它展现进去，这个时候咱们可能就会思考，对于不须要索引的这些数据，是不是能够通过一些更便宜的存储形式（比方像 OSS）存下来，这样能够节俭整体的存储老本。

另一方面须要思考软件老本，拿方才 OSS 存储的例子，如果咱们想用很高效的存储形式来存储索引的数据，而那些不须要查问的字段用 OSS 存储，这时的架构计划可能会略微简单一些，开发复杂度和难度，以及人力投入也会绝对高一些，软件的整体老本也会相应减少。

2. 存储要有过期机制

数据的 实效性 对存储机制也提出了要求，对于数据的过期机制，须要思考，如何保障和限度执行数据过期删除时的性能耗费不会对整个零碎的吞吐有过大影响。

3. 异步解决，吞吐要大，不能被业务流量打垮

在 数据量大 的场景下，要求日志零碎在承受采极其数据的时候，须要思考异步解决等伎俩，保障不能被业务流量打垮。如果说业务零碎有问题了，日志零碎也因而呈现问题，导致不能应用日志零碎来查问、排查业务问题，那这个平台存在的意义就会受到挑战。一般来说咱们会用 MQ 这样的中间件来做异步的削峰填谷解决。

4. 即席查问能力（内存、缓存、并行、高效过滤等机制）

基于对查问速度的要求，可能秒级响应的存储计划会被优先选择。

5. 存储构造对工夫范畴查问敌对

基于时间段的范畴查问是最高频的场景之一，针对此类场景，咱们能够思考抉择时序数据库，因其自身对工夫序列查问做了老本上的优化，同时也是效率较高的计划。

6. 二级索引能力

高基数单点查问对索引能力提出了要求，这将限度咱们对于时序数据库的抉择。因为像 promethus 这样的时序数据库对高基数值的单点查问是存在问题的，这是因为它的存储的特点决定的。一般来说，如果咱们想反对高基数值的单点查问，须要须要有一个二级属性能力的数据库。

7. 全文检索能力

如何反对含糊查问，也是咱们要考量的一个因素。因为如果要做残缺的全文检索能力反对，比方：分词、相关性算分排序等，咱们的可选计划会被进一步限度。

8. 存储构造聚合操作敌对（如列存储）

们晓得对于聚合统计操作对话，列存储的聚合性能是比拟高的，因为它有很高对压缩比，一次读盘能够读到很多无效的数据，整体对 IO 效率会很高。

9. 告警模块

最初一点就是架构里必须布局告警模块如何去做。

以上内容针对数据特点、业务需要提出的一些架构要求进行介绍，能够看出，外围取舍在于存储。上面一张图，展现了整个架构的解决流程和要害组件，接下来的内容将对存储局部的选型进行开展介绍。

存储计划选型

上图中对于存储局部，有几个开源的可选存储中间件：像 Cassandra、Hbase、ElasticSearch、ClickHouse、Grafana Loki 等。下图将会针对这些中间件的优缺点进行比照剖析：

上图的计划选型图表对各个计划的形容曾经绝对比拟具体，在此就不再赘述，接下来咱们看下在 Erda 中是如何做的。

Erda 日志剖析平台实际

Erda 目前采纳的其实是比拟常见的实现计划：应用 Elasticsearch 作为底层存储。当然，其中也存在历史起因，Erda 的开源工夫尽管并不是很长，然而其存在历史能够算比拟久了。在过后看来，抉择 Elasticsearch 也是比拟正当的抉择。当然，现状并不是起点，咱们前面仍会继续摸索在老本、效率方面更优的计划。

如果说抉择 ES 这样的一个计划的话，具体应该怎么做呢？

方才的计划选型图表中列出了应用 Elasticsearch 的大抵外围思路，接下来咱们具体深刻看下如何去做。

之前提到，应用 Elasticsearch 计划的特点就是性能全和开箱即用，上图中列出了在 Erda 中所利用的一些要害能力来实现目前 Erda 想要提供的局部要害性能，如下图所示。

总的来说，Erda 目前采纳的其实还是比拟惯例的计划，并在此基础上有一些小的优化，整个代码构造上也是做了一层形象，并没有说当前就是绑死在 Elasticsearch 下面，后续咱们还会思考反对一些其余可替换计划。

Erda 日志剖析平台将来的方向

对 Erda 日志剖析平台而言，将来咱们有几个致力的方向：

1. 存储更高效、可扩大

首先是存储方面，上文咱们也提到，Erda 目前次要采纳基于 Elasticsearch 的存储计划，但应用 Elasticsearch 有一个不可漠视的毛病，那就是它的整体资源占用老本绝对较高，而像 Clickhouse、Grafana Loki 等，的确有各自的劣势须要咱们去借鉴。所以说 Erda 作为一个开源产品，后续可能会反对更多的底层存储，用户能够在这些计划之间依据本身的需要和老本来进行抉择。

另外，自研存储也将会是咱们的一个投入方向，因为监控畛域除了日志，还有指标、Trace 数据。这些数据是否采纳一个对立的存储内核来升高零碎的复杂度，同时能够对不同数据类型做专项优化来均衡老本和性能，这些都是咱们思考自研存储的出发点。

2. 告警更便捷、更智能

目前在 Erda 平台上，如果想从日志剖析登程去创立告警规定，理论应用的链路还是有点长，所以后续咱们会优化这条链路上的产品和性能体验。

另外的一个方向就是智能化，基于日志的主动异样检测。在上文中有简略提到这点，就是说即便用户没有显式的去配置任何规定，零碎也能够帮忙用户去发现预期之外的一些异样。这里的异样，不肯定非得是业务利用抛出的谬误的堆栈，它是一个绝对于“失常”的概念，即失常数据流中忽然呈现了一个十分不同寻常的数据，这可能会须要用到一些机器学习的模型来检测。

以上就是本次想要和大家分享的无关日志剖析架构的一些内容，后续咱们也将不忘初心，继续优化产品性能和用户体验，也十分期待有更多对此感兴趣的开发者参加进来与咱们共建 Erda，每一条倡议咱们都会认真凝听，期待更多的声音帮忙咱们变得更好！

更多技术干货请关注【尔达 Erda】公众号，与泛滥开源爱好者独特成长～