通过关键词采集文章采集api( 基于微服务的日志中心架构设计三、中心的流程与实现 )

　　通过关键词采集文章采集api(

基于微服务的日志中心架构设计三、中心的流程与实现

)

　　转载本文须注明出处：微信公众号EAWorld，违者必究。

　　介绍：

　　日志一直是运维和开发人员最关心的问题。运维人员可以通过相关日志信息及时发现系统隐患和系统故障，安排人员及时处理和解决问题。没有日志信息的帮助，开发者无法解决问题。没有日志就等于没有眼睛，没有方向。

　　微服务越来越流行，在享受微服务架构带来的好处的同时，也不得不承担微服务带来的麻烦。日志管理就是其中之一。微服务有一个很大的特点：分布式。由于分布式部署，日志信息分散在各处，给采集日志的存储带来了一定的挑战：

　　本文文章将讨论与日志管理相关的问题。

　　内容：

　　一、日志的重要性和复杂性

　　二、基于微服务的日志中心架构设计

　　三、日志中心的流程及实现

　　四、日志中心关键配置

　　五、总结

　　一、日志的重要性和复杂性

　　要说管理日志，在管理日志之前有一个先决条件。我们需要知道日志是什么，它们能做什么，以及它们有什么用处。根据百度百科，是记录系统操作事件的记录信息。

　　在日志文件中，记录着当前系统的各种生命体征，就像我们在医院体检后得到的体检表，反映了我们的肝功能、肾功能、血常规等具体指标。日志文件在应用系统中的作用就像一个体检清单，反映了系统的健康状况、系统的运行事件、系统的变化情况。

　　日志充当系统中的守护者。它是保证服务高度可靠的基础，记录系统的一举一动。有运维级别、业务级别、安全级别的日志。系统监控、异常处理、安全、审计都离不开日志的辅助。

　　有各种类型的日志，一个健壮的系统可能有各种日志消息。

　　这么复杂多样的日志，有必要一口气抓吗？我们需要哪些？这些都是我们在设计日志中心架构时需要考虑的问题。

　　二、基于微服务

　　日志中心架构设计

　　日志中心是微服务生态中不可或缺的一部分，是监控的第二大师。在这里分享我们的产品级设计实践，了解日志中心在基于微服务架构的技术架构中的位置，以及如何部署。

　　在本设计中，微服务结构由以下部分组成：

　　图中没有log center四个关键词，因为它是由多个独立的组件组成的。这些组件分别是 Filebeat、Kafka、Logstash 和 Elasticsearch，它们共同构成了日志中心。

　　经过考虑和研究，我们确定了一套适合当前微服务架构的日志管理流程。

　　1. 日志选择----确定选择哪些日志记录进行分析

　　2. 日志采集 ---- filebeat 轻采集

　　3. 日志缓冲---- kafka 缓存在本地缓冲

　　4. 日志过滤 ---- logstash 过滤

　　5. 日志存储----elasticsearch索引存储

　　6. 日志检索----使用elasticsearch本身的检索功能

　　7. 日志展示----参考kibana风格实现日志数据可视化

　　在传统的 ELK 上，Logstash 日志 采集 被 Filebeat 取代，在日志存储前增加了 kafka 缓冲和 logstash 过滤。这组流程确保功能完整，同时提高性能并使部署尽可能轻量级。

　　三、日志中心的流程及实现

　　选型：根据业务场景

　　日志内容复杂多样，如何采集有价值的日志是我们关注的重点。日志的价值实际上取决于业务运营。同一种日志在不同业务场景中的价值会完全不同。根据以往的业务实践，结合一些企业级的业务需求，我们选择重点关注以下几类日志。• Trace log [trace.log] 服务器引擎的调试日志，供系统维护人员定位系统运行问题。• 系统日志[system.log] 大粒度引擎运行进出日志，用于调用栈分析，可用于性能分析。• 部署日志[deploy.log] 记录系统启动、停止、组件包部署、集群通知等信息的日志。• 引擎日志[引擎。log] 一个细粒度的引擎运行日志，可以打印上下文数据，定位业务问题。• 组件包日志[contribution.log] 组件包记录的业务日志（使用基础组件库的日志输出API写日志）

　　通过以上几类日志，可以明确我们在分析问题时要查找的位置，通过分类缩小查找范围，提高效率。

　　采集（Filebeat）：专注于轻量级

　　微服务应用分布在各个领域的各个系统中。应用程序的日志在各个域的各个系统中相应生成。日志管理首先要做好日志的采集工作。对于日志采集 作业，我们选择 Elastic Stack 中的 Filebeat。

　　Filebeat与应用程序挂钩，因为我们需要知道如何采集每个位置的日志信息，所以轻量级其实是我们考虑的主要因素。

　　Filebeat 会有一个或多个探测器，称为 Prospector，可以实时监控指定文件或指定文件目录的变化状态，并将变化状态及时传送到下一层——Spooler 进行处理。

　　Filebeat还有一个特性我们介绍给日志过滤，这是定位源头的关键。

　　这两点正好满足了我们实时采集实现日志的需要。新增的日志通过 Filebeat 动态存储和及时采样。至此，如何采集记录信息的问题就完美解决了。

　　缓冲（Kafka）：高吞吐量、易扩展、高上限

　　在日志存储之前，我们引入了一个组件，Kafka，作为日志缓冲层。Kafka 充当缓冲区，避免高峰应用对 ES 的影响。由于 ES 瓶颈问题导致数据丢失问题。同时，它还具有数据聚合的功能。

　　使用 kafka 进行日志缓冲有几个优点：

　　筛选（Logstash）：提前埋点，便于定位

　　日志信息是通过filebeat、kafka等工具采集和传输的，给日志事件增加了很多额外的信息。使用Logstash实现二次处理，可以在过滤器中进行过滤或处理。

　　Filebeat 在采集信息时，我们通过将同一台服务器上的日志信息发送到同一个 Kafka 主题来实现日志聚合。主题名称是服务器的关键信息。在更细粒度的层面上，您还可以将每个应用的信息聚合为一个主题。Kafka 中 Filebeat 接收到的日志信息中收录一个标识符——日志来自哪里。Logstash的作用是在日志导入到ES之前，通过标识符过滤汇总相应的日志信息，然后发送给ES，为后续查找提供依据。方便我们清晰定位问题。

　　存储（ES）：易于扩展，易于使用

　　Elastic 是 Lucene 的一个包，提供开箱即用的 REST API 操作接口。

　　选择 ElasticSearch 的主要原因是：分布式部署，易于扩展；处理海量数据，满足各种需求；强大的搜索功能，基于Lucene可以实现快速搜索；活跃的开发社区，更多信息，易于上手。

　　搜索 (ES)：分类

　　Elasticsearch 本身是一个强大的搜索引擎，支持按系统、应用、应用实例组、应用实例IP、关键字、日志级别、时间间隔来检索所需的日志信息。

　　显示（Kibana）：配置简单，一目了然

　　在查看密密麻麻的日志信息时，往往会有一种头晕目眩的感觉。需要对日志信息进行简化提取，对日志信息进行整合分析，并以图表的形式展示日志信息。在展示的过程中，我们可以借鉴和吸收 Kibana 在日志可视化方面的努力，实现日志的可视化处理。通过简单的配置，我们可以清晰、可视化的看到某个服务或应用的日志分析结果。.