微服务实践目录，可以参见连接。
日志的目标是进行行为跟踪，将用户行为、系统行为记录下来用于之后的分析的过程都可以称之为日志。在业界逐渐向微服务迁移的过程中，很多的行为记录手段都逐渐的成为业界热门。例如：调用链跟踪，度量指标(metrics)，日志收集系统，日志分析系统，应用性能监控(APM)等。
随着微服务概念在业界不断的发展与演进，我也针对微服务中行为跟踪进行了一些研究。在针对不同的环境下需要使用不同的方式去完成行为的跟踪与记录：

调用链跟踪，应用性能监控(APM)

在分布式系统中可以主体架构会采用事件驱动架构模式，或者知识库架构模式完成系统整体流程的设计。在这种情况下从用户界面不可能直观的判断系统中的问题具体出现在哪里，为什么出现。所以调用链跟踪营运而生。具体原理可以参见Google论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》。它解决了系统瞬时状态信息的采集工作。限制在于不管是那个开源实现，商业实现都会以为加入调用链跟踪的功能造成系统整体性能下降。所以，一般情况下在生产环境不建议打开，打开也只运行10分钟以内以防止影响业务。

度量指标

度量指标也是一项内容较多的技术，并且也可以在其他地方看到的名词。从技术角度说明在不同的技术栈的不同实现范围内都会有不同的度量指标，可以从不同的角度了解系统的各个方面。方便之后作为企业业务方向、系统运维方向的优化、调整、重构计划的指导。从业务角度讲可以为运营人员提供更加明确的系统运行情况，帮助运营人员从感性的认知系统到理性认知的转变，跳出大概是多少的猜测。现阶段度量指标没有标准规范与通用实现。在Spring Cloud中有部分实现，但也不是很全。

日志收集系统

日志收集系统大家都比较熟悉，如：ELK系列的FileBate、Logstash，Apache旗下的Flume，FaceBook的Scribe等等。这些实现各有千秋，但整体思想没有太大的差异。最主要的目标都为从宿主机将日志收集到日志系统中。下面会详细的说明。

日志分析系统

如下图中的日志处理技术全景中说明的一样，日志分析将日志建立索引，进行全文检索，日志聚合等操作。

系统设计

以上的内容会在之后的文章中做介绍。现在我们拉回来，开始讨论日志。这里深入日志这个话题讨论一点内容。

模式选择

一般的日志收集方式分为两种：拉和推，与消息通信中的Pull和Push的概念是相同的。拉取的方式为由Master主动发起日志获取动作，然后在各个Agent上将日志拉到Master节点。推的方式为由Agent主动的向Master发送日志，Master在接收到日志之后将数据存储起来。

推模式:

对于 event-drive 类型的监控更为灵活方便
应用多点部署不影响监控
可能对监控系统 DDos
要注意推送频率控制，以及失败后的重试机制

拉模式:

方便控制收集频率，对应用压力可控，侵入也小
更及时的发现服务宕机
需要大量配置监控接入点，尤其是应用集群化
指标不够实时，顺序可能错乱
监控指标一般是通过 log 文件或 HTTP 接口对外暴露，parser 较为复杂

对比以上特点之后，推模式更适用于业务日志类型的内容，具体如下：

异步系统，事件驱动架构模式不影响正常业务进行。
实时性可以满足业务日志需求。基本上在用户操作完成之后就可以看到业务日志。
推送频率即为用户使用频率。不会因为系统复杂性而成本增长。

拉模式非常适用于系统日志的收集工作，之后会在微服务实践-系统日志中说明拉模式的使用。

技术选型

选择了日志收集方式之后，我们看一下技术选型：
下图来自于Flume官网：
Flume架构
下图来自于ELK官网:
Logstash架构
根据以上两图，并综合Logstash和Flume的特点对比如下：

各有侧重，Logstash偏重于对数据的预处理；Flume偏重数据的传输；
生态环境，Logstash是老牌的运维日志监控工具，有着非常多的插件，配置灵活；FLume则是强调用户的自定义开发。
持久化，Logstash的input和filter还有output之间都存在buffer，进行缓冲；Flume直接使用channel做持久化（可以理解为没有filter）

从上可以得出结论，更注重稳定性，效率方面的内容使用Flume比较好。比较注重灵活性，可配置性方面可以使用Logstash。我们这里选择Logstash是因为可以满足业务日志需求，是因为业务日志不需要太高的性能、并且可以在Flow中处理简单逻辑、达到数据清洗的目的。

方案制定

接下来看业务日志的部署结构：
本图来自ELK官网：
ELK部署结构
从上图看，要完整的部署Logstash是一件比较复杂的事情。我这里主要的目标是业务日志可以在软件工程师在不修改任何代码的情况下可以将业务日志输出到数据库中，所以，简化后的操作如下图所示：
业务日志架构图
日志又可以分为业务日志，系统日志。业务日志又可以分为操作日志、行为日志、搜索日志等。本次内容设计为业务日志中操作日志的记录系统。操作日志流程：为系统用户访问系统服务。各服务根据业务特点，调用操作日志API，然后API通过Log4J2的Syslog功能将日志信息发送到logstash中。然后由Logstash写入到数据库中。