早些时分 Erda Show 针对微服务监控、日志等内容做了专场共享，许多同学听完后意犹未尽，想了解更多关于日志剖析的内容。Erda 团队做日志剖析也有一段时刻了，所以这次计划和咱们详细共享一下咱们在做的一些工作，期望对咱们有所协助。

日志剖析途径其实是 Erda 微服务管理子途径下面的一个功用模块，那么今天我将从三个方面来打开共享：

• 日志剖析途径出现的必要性；
• 日志剖析途径架构规划；
• Erda 现在是怎么做的、做了哪些工作以及未来的发展方向。

“微服务”这一概念大概在 2013 年出现，从这一概念初期到现在，大部分应用的事务场景皆是分布式、容器化的布置架构，或许至少是多服务架构，每个服务基本上对错单点的，并且会做单服务多实例的高可用布置。

在这种场景下，咱们需求重点处理关于日志的几个问题。

1. 接口报错了，如安在应用的多个容器中快速的找到详细的反常日志？

第一个要处理的问题是关于反常日志的定位功率问题。比方，前端在请求某个页面，接口报错了，随后反馈给开发人员，惯例的接口报错一般不会直接给用户暴露特别详细的反常信息，只会有一个状态或是扼要的过错概述，这时需求开发者经过日志找到详细的反常信息（比方仓库等）。

一般来说，经过接口途径咱们能够定位是哪个服务的报错，但进一步讲，咱们怎么确认是这个服务下的哪个实例的报错呢？假设说咱们选用这种比较原始的方法，或许需求开发者分别检查每个实例（容器）的日志，这样会直接对开发功率产生影响。

2. 怎么便利的检查现已宕机的应用容器的日志？

别的一个需求处理的问题是日志存储的耐久性问题。比方说在 K8s 途径下，某个应用服务的某个 pod 挂掉了被重新调度到了其他节点，或许本地存储的容器日志由于时刻的翻滚而翻滚没了，这时假设咱们想去回头看一下之前的日志，在机器上现已不太简略找到了。

3. 怎么能及时的发现某个应用容器产生了反常？

前两个问题归于被动型的需求，也便是说前端事务上现已暴露出一些问题，然后咱们去回溯、查找一些日志的详细记录的需求。由于是用户反馈，这个流程链上的毛病处理时刻是相对较长的，那么应该怎么缩短毛病处理时刻？

很天然咱们会想到主动告警，在还没有大面积前端接口被大量用户发现前，后端出现反常时，体系能够更及时的进行告警，并告诉相关人员及时处理，削减毛病时刻。这时咱们就非常需求一个别系能够继续监听一切容器的日志，帮忙开发者发现其间的反常并主动告警。

假设说没有日志剖析途径，其实以上三个问题并不是不能处理，可是会极大程度的影响功率。那么假设有了这样的日志剖析途径，由它来供给集中式查询、耐久化存储以及主动告警等功用，咱们能够快速且高效的处理这三个问题。

日志剖析途径能供给什么

说到日志剖析途径的必要性，咱们务必要了解一下它能为咱们供给什么样的服务，下面咱们就来详细看一下：

1. 集中式、一站式查询

在查询方面，日志剖析途径应该是集中式、一站式的查询，不再需求登录不同机器或许容器去低效地手动检查日志，而只需求在一个一致的页面上输入一些查询语句，就能轻松查询一切容器的日志了。

2. 耐久化，前史可追溯

在存储方面，能够给日志剖析途径配备有预期的专门存储配额，以便能够更好地应对宕机、升级、调度等导致日志跨节点的情况，保持查询前史日志时的简略性。

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

智能化告警一般也是一个必要功用，这儿的智能化有两层意思：

你能够主动装备一些规矩，比方说依据代码或现已产生的一些反常日志，能够知道特定反常是什么姿态，随后配一个规矩，体系就会继续对输入的日志做一些规矩检测，假设发现匹配项，就会进一步经过你提前装备的告警途径，告诉到详细的人；
主动发现“反常”，其实有点类似现在的机器学习、深度学习，也便是说，即便你没有装备任何规矩，可是体系能够经过对日志流的监听和学习，去发现反常的日志，然后告诉你去关注，这是更智能化的一些东西。

咱们现已知道，日志剖析途径能够给咱们带来便利及功率的提升，那么假设咱们想完成这样一个途径，需求怎么进行架构规划呢？

想要做架构规划，首要要了解事务场景和需求，然后结合被处理数据的特色，才能够揣度途径架构规划应该具有哪些才能。之后咱们再依据这些才能去寻觅、规划相匹配的计划，并在这些计划中挑选真正可落地的去执行。

咱们知道日志归于时序数据，只新增、不删去。它有几个字段比较要害：timestamp，tags，fields

• timestamp：时刻字段对时序型数据是用来进行比较和要害的字段；
• tags：tags 代表一组字段，一般关于时序数据来讲，作为标签类型的字段一般都是能够查找的，也便是这些字段需求建立索引，如：服务名、容器名、容器 IP 等；
• fields：fields 也代表一组字段，这些字段相关于 tags 的不同在于，fields 字段是一般存储那些不需求查找的内容，比方：假设关于详细的日志内容你不计划去查找，就能够用 fields 类型字段存储。

日志时序数据的特色提示咱们，能够考虑运用时序数据库来存储日志，比方 cassandra。

关于日志数据来讲，咱们一般只关心一段时刻的数据，关于很早之前的数据，比方一个月、两个月之前，乃至半年之前的数据，咱们基本上是不会去关心的。由于一般有毛病的时分，咱们或许才需求去看一下详细的日志信息，而出现毛病时不大或许会拖到很久之后才去处理和复盘这个问题。

数据量大有两个含义：一是说数据的单条日志或许比较大，比方像 Java 应用的一个反常仓库，特别那种 Caused by 嵌套了好几层的，或许单条日志就会有几百行；别的一个是说，日志的条数多，跟着事务和应用的增多，加上某些应用还或许会开启 DEBUG 等级的日志，全体的日志量也会比较大，而且或许出现短时的峰值。

以上是日志数据的特色，然后咱们对从咱们日志剖析途径这个角度来看看，咱们对体系有什么需求。

1. 查询速度快，秒级呼应

首要，咱们期望它能够快速查询，输入查询要害字，就能够秒级呼应查询结果。

一般，查询会依照一个清晰的时刻规模操作，这有一个优点：后端存储的挑选会更多一些。

什么是高基数值呢？像用户 IP、Trace ID 这类数据，几乎每个用户请求的值都不一样，这就归于高基数。关于这类数据的查询也是一个强需求，比方前端 web 接口报错，而呼应里加了 Trace ID 这样的字段，此时就能够经过 Trace ID 字段去检查整个过程中记录的反常日志或要害日志，这也是一个比较常见的需求。

标签查询一般能够认为是对服务名、容器 IP 这样的字段查询需求，这也归于强需求之一。

全文检索查询是否归于强需求之一，其实是个值得权衡的问题。假设客户端在收集端现已做了一些预处理，如：把整行的日志 content 在收集时拆分成了详细的时刻等级、反常类型等单个要害字段，这样来讲，全文检索查询或许就不是一个强需求了，但一起，备选计划的规模或许会更大一些。这儿需求提醒的是，没有全文检索支撑，并不代表不能含糊检索。凭借列存储的高压缩率和高 IO 功率，在内存中进行含糊过滤的作用也很赞！

聚合计算中最简略的是 Count 计算，更杂乱一点的有依据更多字段维度的杂乱聚合图表支撑，这些功用在一些产品中也有供给，但需依据个别详细需求来判别该项是不是强需求。

主动告警意味着体系不只具备被动查询功用，一起也能够及时发现问题并告警，这样才能削减毛病时刻。

介绍完事务需求方面的 7 个特色后，在规划架构时，就能够助力咱们敏捷 get 到需求考虑哪些方面了。

当然，本钱是一定要的，不管是做什么规划，必定需求考虑本钱，这其间包含软硬的本钱。

硬件本钱指的是咱们的机器数量：CPU、内存、磁盘等这样的资源。这儿面存在一个问题，由于关于日志而言，咱们讲数据量大，单条的体积或许也比较大，假设确认不需求全文检索，或只检索其间很少的几个要害字段，关于那些较长的字段，仅仅只是想跟着查找条件把它展现出来，这个时分咱们或许就会考虑，关于不需求索引的这些数据，是不是能够经过一些更廉价的存储方法（比方像 OSS）存下来，这样能够节省全体的存储本钱。

另一方面需求考虑软件本钱，拿方才 OSS 存储的例子，假设咱们想用很高效的存储方法来存储索引的数据，而那些不需求查询的字段用 OSS 存储，这时的架构计划或许会稍微杂乱一些，开发杂乱度和难度，以及人力投入也会相对高一些，软件的全体本钱也会相应增加。

2. 存储要有过期机制

数据的实效性对存储机制也提出了要求，关于数据的过期机制，需求考虑，怎么确保和约束执行数据过期删去时的功用耗费不会对整个别系的吞吐有过大影响。

3. 异步处理，吞吐要大，不能被事务流量打垮

在数据量大的场景下，要求日志体系在承受采极点数据的时分，需求考虑异步处理等手法，确保不能被事务流量打垮。假设说事务体系有问题了，日志体系也因此出现问题，导致不能运用日志体系来查询、排查事务问题，那这个途径存在的含义就会受到挑战。一般来说咱们会用 MQ 这样的中间件来做异步的削峰填谷处理。

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

依据对查询速度的要求，能够秒级呼应的存储计划会被优先挑选。

5. 存储结构对时刻规模查询友好

依据时刻段的规模查询是最高频的场景之一，针对此类场景，咱们能够考虑挑选时序数据库，因其自身对时刻序列查询做了本钱上的优化，一起也是功率较高的计划。

高基数单点查询对索引才能提出了要求，这将约束咱们关于时序数据库的挑选。由于像 promethus 这样的时序数据库对高基数值的单点查询是存在问题的，这是由于它的存储的特色决议的。一般来说，假设咱们想支撑高基数值的单点查询，需求需求有一个二级特色才能的数据库。

怎么支撑含糊查询，也是咱们要考量的一个要素。由于假设要做完好的全文检索才能支撑，比方：分词、相关性算分排序等，咱们的可选计划会被进一步约束。

8. 存储结构聚合操作友好（如列存储）

们知道关于聚合计算操作对话，列存储的聚合功用是比较高的，由于它有很高对压缩比，一次读盘能够读到许多有效的数据，全体对 IO 功率会很高。

最终一点便是架构里必须规划告警模块怎么去做。

以上内容针对数据特色、事务需求提出的一些架构要求进行介绍，能够看出，核心取舍在于存储。下面一张图，展现了整个架构的处理流程和要害组件，接下来的内容将对存储部分的选型进行打开介绍。

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

上图的计划选型图表对各个计划的描述现已相对比较详细，在此就不再赘述，接下来咱们看下在 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，每一条建议咱们都会认真聆听，等待更多的声音协助咱们变得更好！

中国企业想要挣脱束缚的枷锁，必须让企业的软件实现自主可控，不仅仅是去A（America），而是自主权的把握。

随着向云计算基础设施的转移，我们已经看到了云原生应用的快速增长。这些应用程序是小型，快速且集成的服务的集合。通过创建和运行云原生应用程序，企业可以更快地将新想法推向市场，并立即响应客户需求。这些应用程序通常使企业能够在现代动态云环境（例如公共云，私有云和混合云）中构建和运行可伸缩应用程序。无服务器架构、容器、Kubernetes和其他都是云原生应用程序。尽管这些旨在提供增强的业务价值，但它们也带来了一系列网络安全风险。

企业从根本上转向了云计算，以提高应用程序的可伸缩性和可用性。除了从开发到生产的应用程序生命周期自动化之外，这还可以通过自助服务和按需提供资源来实现。云原生应用程序包含云平台提供的运行时和服务，以创建弹性，敏捷和可扩展的解决方案。

如IBM所述，用于开发和部署应用程序的云基础架构方法依赖于：

微服务体系结构：微服务作为体系结构，是指从较小的独立服务中构建复杂应用程序的方法。

容器化：容器技术提供了一种轻量级，高度可移植的虚拟化解决方案。

使用DevOps进行自动化：开发和IT团队使用工具来自动化，构建，部署和管理应用程序，进行协作。

保护云原生基础架构需要深入了解以检测安全需求。考虑到安全专业人员依赖于他们所使用的服务的职责，也必须对应用实施安全措施。根据Gartner的说法，到2025年，云安全故障中的99％将是客户的故障。为弥合这一安全漏洞，CIO将需要部署和实施有关云所有权，责任和风险接受的政策。

那么，对保护云原生应用程序至关重要的是什么？

可见性是云应用程序网络安全的最关键方面。缺乏集中的管理和可见性会导致出现未发现的错误配置以及无法量化风险的机会。缺少场景并且通常需要人工干预的安全警报也可能导致缓解延迟和警报疲劳。

随着企业在其整个云中利用诸如Kubernetes之类的云原生技术，这些平台的复杂性和分布式性质极大地要求企业不仅为DevOps还为安全性规划策略。要解决云原生开发模型和基础架构中的漏洞和威胁，就需要在整个软件开发生命周期中提供持续的安全性。它还需要共享的安全责任和所有权，以及共享的流程和工具。这将使组织能够保持总体上原生于云的部署，尤其是基础架构，应用程序和数据的安全性和网络安全性。

服务器工作负载的安全性

云工作负载安全性尤其具有挑战性，并且随着工作负载在多个供应商和主机之间传递，因此必须分担保护工作负载的责任。许多公司仍然使用传统的企业安全解决方案来实现端点安全，网络分段和外围保护。但是，在云原生环境中，企业不能依赖这些传统的安全解决方案。如今，服务器工作负载比以往任何时候都更容易受到网络攻击。根据VMware的说法，微分段和裸机管理程序是使用云工作负载保护平台保护工作负载的两种主要方法。

此外，组织需要采用集成的云原生安全平台，以整合人工智能、自动化、情报、威胁检测和数据分析功能以弥合安全漏洞。