日志分析系统

日志分析系统1.前言随着江苏中烟信息化程度的不断提升，信息化系统的数目也不断增加，运维任务也不断增加。为了应对日益增加的信息化需求，提升服务质量，减轻运维工作，在信息系统服务化的基础上，迫切需要一个管理平台，实现对所有服务的管理和监控，这就是微服务平台。微服务平台能够实现devOps，服务的注册、发现、权限管理、监控、测试、故障预警，故障恢复等。日志分析系统是微服务平台的重要组成部分，它能够对各服务的日志进行采集，存储，分析(找出异常的请求、统计报错情况、统计QPS、统计系统功能的使用情况、超负荷预警等)。同时，对系统资源的监控信息也可以以日志的形式，由日志分析系统分析。日志分析系统后台使用大数据平台来存储和分析日志，能够支持大量的日志，不需要担心日志的存储问题。2.日志分析系统2.1.功能日志分析系统主要功能包括日志的采集、存储、分析。日志采集常见的场景如：对webserver服务器的log文件进行监控，发现有变动时，采集变动的信息；对网络的某个端口监控，当此端口出现数据流时，采集数据流；监控程序定时的获取系统资源信息(同理，也适用于对JVM，tomcat的监控)；采集Http请求和响应(同理适用于rpc远程调用)。日志的存储使用大数据平台。根据日志的类型，可以以非结构化或者结构化数据存储，也可以使用图数据库存储。日志分析包括日志的离线和在线分析。离线分析借助大数据平台提供的SQL，对日志数据库中的所有数据进行统计分析，适合于统计QPS，系统功能使用情况。在线分析(实时分析)处理即时产生的日志信息，适合于预警，异常请求的监控。2.2.结构3.实现3.1.要求能够适配不同的日志数据，例如webserverlog、rpclog、syslog能够处理突发的大流量数据能够检测日志系统的个节点的运行状态，并自动恢复能够方便的和Hive、Spark、Hbase等集成稳定的运行，尽量少占用资源3.2.日志收集和路由logstash是一种分布式日志收集框架，非常简洁强大，经常与ElasticSearch，Kibana配置，组成著名的ELK技术栈，非常适合用来做日志数据的分析。Logstash分为Shipper（收集日志），Broker（日志集线器，可以连接多个Shipper），Indexer（日志存储）。Shipper支持多种类型的日志文件，且可以自定义插件支持更多的种类。Logstash采用JRuby语言实现，插件开发相对困难。Logstash可以通过配置正则表达式的方式，将日志解析为结构化数据。Broker一般使用Redis实现，Indexer一般将日志存储到ELsearch。flume是分布式的日志收集系统，它将各个服务器中的数据收集起来并送到指定的地方去。Flume分为source（数据源）、channel（数据通道和缓存）、sink。Flume支持非常多种类的数据源，包括日志文件、tcp连接、thrift远程调用框架、netcat、定时程序等。Flume使用java语言开发，能够自定义source、channel、sink。Channel支持filechannel，memorychannel，kafkachannel，JDBCchannel等。Sink支持HDFS、Hive、Avro（发送到其他机器的某个端口）、FileRollSink、HbaseSink、ESSink、SolrSink、KiteDatasetSink、kafkaSink、httpSink等（或者自定义Sink）。3.3.方案Flume(日志收集系统)+kafka-channel(分布式消息队列)+SparkstreamingSink(消费者)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发起一个请求到TC2)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）事务的实现原理：写时复制（这里指内存中的写时复制）、redoundo日志回滚、shardingpage（文件写时复制技术，类似于docker镜像的layer）5.3.微服务结构