日志分析系统

日志分析系统
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先将<prepare>消息写到本地日志，之后向所有的Si发起<prepare>消息。

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

为什么在执行
任务前需要先写本地日志，主要是为了故障后恢复用，本地日志起到现实生活中凭
证的效果，如果没有本地日志（凭证），出问题容易死无对证；
3)Si收到<prepare>消息后，执行具体本机事务，但不会进行commit，如果成功返回
<yes>，不成功返回<no>。

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

4)TC收集所有执行器返回的消息，如果所有执行器都返回yes，那么给所有执行器发
生送commit消息，执行器收到commit后执行本地事务的commit操作；如果有任
一个执行器返回no，那么给所有执行器发送abort消息，执行器收到abort消息后
执行事务abort操作。

5.1.2.事务消息
1)支付宝在扣款事务提交之前，向实时消息服务请求发送消息，实时消息服务只记录
消息数据，而不真正发送，只有消息发送成功后才会提交事务；
2)当支付宝扣款事务被提交成功后，向实时消息服务确认发送。

只有在得到确认发送
指令后，实时消息服务才真正发送该消息；
3)当支付宝扣款事务提交失败回滚后，向实时消息服务取消发送。

在得到取消发送指
令后，该消息将不会被发送；
4)对于那些未确认的消息或者取消的消息，需要有一个消息状态确认系统定时去支付
宝系统查询这个消息的状态并进行更新。

为什么需要这一步骤，举个例子：假设在
第2步支付宝扣款事务被成功提交后，系统挂了，此时消息状态并未被更新为“确
认发送”，从而导致消息不能被发送。

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

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

5.1.3.TCC事务补偿型
TCC在一个长事务（long-running ）中，一个由两台服务器一起参与的事务，服务器A发起事务，服务器B参与事务，B的事务需要人工参与，所以处理时间可能很长。

如果按照ACID的原则，要保持事务的隔离性、一致性，服务器A中发起的事务中使用到的事务资源将会被锁定，不允许其他应用访问到事务过程中的中间结果，直到整个事务被提交或者回滚。

这就造成事务A中的资源被长时间锁定，系统的可用性将不可接受。

WS-BusinessActivity提供了一种基于补偿的long-running的事务处理模型。

还是上面的例子，服务器A的事务如果执行顺利，那么事务A就先行提交，如果事务B也执行顺利，则事务B也提交，整个事务就算完成。

但是如果事务B执行失败，事务B本身回滚，这时事务A已经被提交，所以需要执行一个补偿操作，将已经提交的事务A执行的操作作反操作，恢复到未执行前事务A的状态。

这样的SAGA事务模型，是牺牲了一定的隔离性和一致性的，但是提高了long-running事务的可用性。

简单的说，TCC就是一个乐观锁版本的2PC。

5.2.异常处理
一般使用一个result类型包装结果和错误信息。

微服务构架包括：
●分布式rpc（支持资源隔离和快速熔断）
●分布式消息队列（事务补偿）
●分布式缓存（快速）
●持续集成、自动部署工具（docker，jenkins）
●监控和分布式日志（flume）
事务的实现原理：
写时复制（这里指内存中的写时复制）、redo undo日志回滚、sharding page（文件写时复制技术，类似于docker镜像的layer）
5.3.微服务结构。