日志分析系统

日志分析系统

1.前言

随着江苏中烟信息化程度的不断提升，信息化系统的数目也不断增加，运维任务也不断增加。为了应对日益增加的信息化需求，提升服务质量，减轻运维工作，在信息系统服务化的基础上，迫切需要一个管理平台，实现对所有服务的管理和监控，这就是微服务平台。微服务平台能够实现devOps，服务的注册、发现、权限管理、监控、测试、故障预警，故障恢复等。

日志分析系统是微服务平台的重要组成部分，它能够对各服务的日志进行采集，存储，分析(找出异常的请求、统计报错情况、统计QPS、统计系统功能的使用情况、超负荷预警等)。同时，对系统资源的监控信息也可以以日志的形式，由日志分析系统分析。日志分析系统后台使用大数据平台来存储和分析日志，能够支持大量的日志，不需要担心日志的存储问题。

2.日志分析系统

2.1.功能

日志分析系统主要功能包括日志的采集、存储、分析。

日志采集常见的场景如：对webserver服务器的log文件进行监控，发现有变动时，采集变动的信息；对网络的某个端口监控，当此端口出现数据流时，采集数据流；监控程序定时的获取系统资源信息(同理，也适用于对JVM，tomcat的监控)；采集Http请求和响应(同理适用于rpc远程调用)。

日志的存储使用大数据平台。根据日志的类型，可以以非结构化或者结构化数据存储，也可以使用图数据库存储。

日志分析包括日志的离线和在线分析。离线分析借助大数据平台提供的SQL，对日志数据库中的所有数据进行统计分析，适合于统计QPS，系统功能使用情况。在线分析(实时分析)处理即时产生的日志信息，适合于预警，异常请求的监控。

2.2.结构

3.实现

3.1.要求

✓能够适配不同的日志数据，例如web server log、rpc log、syslog

✓能够处理突发的大流量数据

✓能够检测日志系统的个节点的运行状态，并自动恢复

✓能够方便的和Hive、Spark、Hbase等集成

✓稳定的运行，尽量少占用资源

3.2.日志收集和路由

logstash是一种分布式日志收集框架，非常简洁强大，经常与ElasticSearch，Kibana配置，组成著名的ELK技术栈，非常适合用来做日志数据的分析。Logstash分为Shipper（收集日志），Broker（日志集线器，可以连接多个Shipper），Indexer（日志存储）。Shipper 支持多种类型的日志文件，且可以自定义插件支持更多的种类。Logstash采用JRuby语言实现，插件开发相对困难。Logstash可以通过配置正则表达式的方式，将日志解析为结构化数

据。Broker一般使用Redis实现，Indexer一般将日志存储到EL search。

flume是分布式的日志收集系统，它将各个服务器中的数据收集起来并送到指定的地方去。Flume分为source（数据源）、channel（数据通道和缓存）、sink。Flume支持非常多种类的数据源，包括日志文件、tcp连接、thrift远程调用框架、netcat、定时程序等。Flume 使用java语言开发，能够自定义source、channel、sink。Channel支持file channel，memory channel，kafka channel，JDBC channel等。Sink支持HDFS、Hive、Avro（发送到其他机器的某个端口）、File Roll Sink、Hbase Sink、ES Sink、Solr Sink、Kite Dataset Sink、kafka Sink、http Sink等（或者自定义Sink）。

3.3.方案

Flume(日志收集系统)+ kafka-channel(分布式消息队列) + Spark streaming Sink(消费者) 3.4.监控JVM

常见的监控方案

4.微服务协议比较

rest协议：

优点：

不容易被安全组件拦截

简单、规范、通用，所有语言都可以使用

debug方便，工具、资料非常多，支持很好

缺点：

性能没有rpc好

没有状态

rpc协议：

优点：

直接使用tcp协议，二进制序列化，效率高

同一种语言之间，调用方便

缺点：

工具支持少

有些框架不能跨语言

不能和网页端直接交互

建议：

(12月建议，后端服务使用grpc)人员、组织机构树、工作流服务、权限管理、数据字典、公共数据等可以使用rpc发布服务，业务提供的具体接口使用rest。前端将这些整合在一起。也就是说，以前办公系统common里面的代码通过远程调用的方式独立出去（数据也独立出去，重要），当common修改时，通过适配器或者字节码框架修改调用逻辑。业务代码实现自己的逻辑，但是数据和common中的数据是完全分开的，只能通过接口传递数据（这个非常重要，是微服务的关键）。前端可以根据情况，调用业务系统的接口。

5.问题

5.1.分布式事物

场景：A系统调用B的接口，A系统在调用过程中，需要修改A系统数据和B系统的数据，如何保证此过程的事务性？

5.1.1.两阶段提交

两阶段提交：

1)应用程序client发起一个请求到TC

2)TC先将消息写到本地日志，之后向所有的Si发起消息。以支付

宝转账到余额宝为例，TC给A的prepare消息是通知支付宝数据库相应账目扣款1

万，TC给B的prepare消息是通知余额宝数据库相应账目增加1w。为什么在执行

任务前需要先写本地日志，主要是为了故障后恢复用，本地日志起到现实生活中凭

证的效果，如果没有本地日志（凭证），出问题容易死无对证；

3)Si收到消息后，执行具体本机事务，但不会进行commit，如果成功返回

，不成功返回。同理，返回前都应把要返回的消息写到日志里，当作凭

证。

4)TC收集所有执行器返回的消息，如果所有执行器都返回yes，那么给所有执行器发

生送commit消息，执行器收到commit后执行本地事务的commit操作；如果有任

一个执行器返回no，那么给所有执行器发送abort消息，执行器收到abort消息后

执行事务abort操作。

5.1.2.事务消息

1)支付宝在扣款事务提交之前，向实时消息服务请求发送消息，实时消息服务只记录

消息数据，而不真正发送，只有消息发送成功后才会提交事务；

2)当支付宝扣款事务被提交成功后，向实时消息服务确认发送。只有在得到确认发送

指令后，实时消息服务才真正发送该消息；

3)当支付宝扣款事务提交失败回滚后，向实时消息服务取消发送。在得到取消发送指

令后，该消息将不会被发送；

4)对于那些未确认的消息或者取消的消息，需要有一个消息状态确认系统定时去支付

宝系统查询这个消息的状态并进行更新。为什么需要这一步骤，举个例子：假设在

第2步支付宝扣款事务被成功提交后，系统挂了，此时消息状态并未被更新为“确

认发送”，从而导致消息不能被发送。

消息重复发送：解决方法很简单，在余额宝这边增加消息应用状态表（message_apply），通俗来说就是个账本，用于记录消息的消费情况，每次来一个消息，在真正执行之前，先去消息应用状态表中查询一遍，如果找到说明是重复消息，丢弃即可，如果没找到才执行，同时插入到消息应用状态表（同一事务）。

和TCC类似，Try的过程替换为发送事务消息，另外一个系统异步处理的且不会回滚，会重试多次，保证成功执行。