系统日志

4月19日更新 : 已在Github中上传了精简的SpringMVC框架的MAVEN工程包。可以在进行简单配置后使用。 链接： springMVC 本文仅作SpringMVC框架使用过程中的一些个人总结。 项目结构 项目大致分为公共包(common-utils)、核心(core)、前端(web)三个工程。 大致目录: Worksapce |-common-utils |-core |-web 公共包 common-utils 全系统（包括其它模块）公用的部分: common-utils |-exception |-utils |-Generic |-GenericDao |-GenericService 异常处理 根据业务逻辑分成：系统异常 SystemException 、业务异常 BusinessException 两大类。 业务异常 通常指业务处理中可能出现的异常情况，通常是违反业务正常进行规则出现的异常，而不是系统错误。 应该给前台反馈适当的异常信息。而不是单纯的错误代码。且一般是业务逻辑判断后主动抛出的异常，而不是程序错误抛出的异常。 系统异常 一般是程序错误，或者违规操作造成程序无法继续运行的状况。为了提高用户体验，通常捕捉到程序异常 Exception 后记录日志系统， 然后将其包装成系统异常 BusinessException 抛给前台。这样反馈给用户的时异常的概述

背景 日志，角色不同，出发点和认识的角度也不同 RD使用日志，首先是为了调试程序，当程序上线后，日志是为了记录err和trace。 PM可以通过日志分析，可以得出业务指标相关的统计情况。 日志的作用大致有三：异常、trace、统计。 日志使用的痛点 使用日志时大部分的场景或特点如下： 1.日志为纯文本，即可读。 2.日志分散在各个机器上，或者同步到某一台机器。 3.某某发现一个问题，让某某去查log。 这里有几个问题，或者说提高点 1.文本冗余度太大，浪费资源，如果转换为二进制，预估有5倍的收益。 2.日志分散，查找效率低，即使集中，在没有具体时间点情况下，扫描日志会很慢。 3.日志分析难度大，谁写的日志谁来查，查到和肉眼找到还差一步... 目标 所以，我们可以设计这样一个日志系统 1.支持海量数据的日志存储（TB二进制） 2.日志二进制、结构化 3.查询速度快，难度低 设计 读写日志 日志查询过程经分解和总结共性后，几乎是下边三种情况 1.K-V查询，比如基于某个消息ID，查询一条记录。 2.集合查询，比如查询某个用户的消息记录。 3.集合range查询，比如查询某个用户0点到1点消息记录。 那么，ssdb是非常适合这三个需求的。 日志系统具有写多读少的特定，再基于磁盘存储的业界主流方案，LSM是适合的， 而SSDB的存储依赖的leveldb正好属于LSM系。 日志二进制

1. 背景介绍 许多公司的平台每天会产生大量的日志（一般为流式数据，如，搜索引擎的pv，查询等），处理这些日志需要特定的日志系统，一般而言，这些系统需要具有以下特征： （1） 构建应用系统和分析系统的桥梁，并将它们之间的关联解耦； （2） 支持近实时的在线分析系统和类似于Hadoop之类的离线分析系统； （3） 具有高可扩展性。即：当数据量增加时，可以通过增加节点进行水平扩展。 本文从设计架构，负载均衡，可扩展性和容错性等方面对比了当今开源的日志系统，包括facebook的scribe，apache的chukwa，linkedin的kafka和cloudera的flume等。 2. FaceBook的Scribe Scribe是facebook开源的日志收集系统，在facebook内部已经得到大量的应用。它能够从各种日志源上收集日志，存储到一个中央存储系统 （可以是NFS，分布式文件系统等）上，以便于进行集中统计分析处理。它为日志的“分布式收集，统一处理”提供了一个可扩展的，高容错的方案。 它最重要的特点是容错性好。当后端的存储系统crash时，scribe会将数据写到本地磁盘上，当存储系统恢复正常后，scribe将日志重新加载到存储系统中。 架构 ： scribe的架构比较简单，主要包括三部分，分别为scribe agent， scribe和存储系统。 (1) scribe

最近看了google的分布式追踪系统dapper的论文： http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/zh-CN//pubs/archive/36356.pdf ，结合自己的理解描述下。 一、 引子： 用户输入关键字后只要敲个回车键就能返回搜索结果（图1a），这样一个简单的过程可能涉及到上千个服务，可能需要上千个服务器协作完成。如图1b所示，user发了RequestX请求到达A，A通过rpc（远程过程调用，如thrift）调用B以及C，而C又需要通过rpc调用D以及E等等。 对user的一次请求，他迟迟未收到响应ReplyX，或者响应时间很慢，我们需要确认性能到底消耗在哪个环节，这个时候我们该怎么办呢？自然是分析我们的日志。 我们每个服务都会有请求日志，请求日志记录着一次调用所花费的时间，比如对A来说，记录着调用B所花费的时间以及调用C所花费的时间，同理C的请求日志记录着调用D以及E所花费的时间。对于互联网应用来说，各个服务比如B，同一时刻可能有成百上千次请求记录。 这种日志有个致命 缺点---没有将这些记录与特定的请求关联一起 。对于user的一条特定的请求RequestX，我们不知道B日志中哪条记录与之对应，也不知道C日志中哪条记录与之对应。。

备份 备份软件 Amanda -客户端-服务器模型备份工具 Bacula - 另一个客户端-服务器模型备份工具 Backupninja -轻量级，可扩展的元数据备份系统 Backuppc -客户端-服务器模型备份工具和文件共享方案。 Burp -网络备份和还原程序 Duplicity -使用rsync算法加密的带宽-效率备份 Lsyncd -监控一个本地目录树的变化,然后产生一个进程去同步变化。默认使用rsync。 Rsnapshot -文件系统快照工具 SafeKeep -使用rdiff-backup，集中的，基于pull的备份 TarSnap - 具有一个开源客户端的安全备份服务 UrBackup -另一个客户端-服务器备份系统 DREBS - AWS EBS支持策略的备份脚本 克隆 克隆软件 Clonezilla -分区和磁盘镜像/克隆程序 Fog - 另一个计算机克隆解决方案 Redo Backup -简单的备份，恢复和还原 云计算 AppScale – 兼容Google App引擎的开源云计算软件. Archipel -使用Libvirt管理和监视虚拟机 CloudStack -创建，管理和部署基础云服务的云计算软件 Cobbler -Cobbler是一个Linux安装服务器，允许快速地构建网络安装环境 Eucalyptus -兼容AWS的开源私有云软件 Mesos

Region Server宕机总述 HBase一个很大的特色是扩展性极其友好，可以通过简单地加机器实现集群规模的线性扩展，而且机器的配置并不需要太好，通过大量廉价机器代替价格昂贵的高性能机器。但也正因为廉价机器，由于网络硬盘等各方面的原因，机器宕机的概率就会相对比较大。RegionServer作为HBase集群中实际的执行节点，不可避免地也会出现宕机。 宕机并不十分可怕，因为不会丢数据。HBase集群中一台RegionServer宕机（实指RegionServer进程挂掉，下文同）并不会导致已经写入的数据丢失，和MySQL等数据库一样，HBase采用WAL机制保证这点：它会先写HLog，再写缓存，缓存写满后一起落盘。即使意外宕机导致很多缓存数据没有及时落盘，也可以通过HLog日志恢复出来。 可是没有数据丢失并不意味着宕机对业务方没有任何影响。众所周知，RegionServer宕机是由zookeeper首先感知到的，而zookeeper感知到RegionServer宕机事件是需要一定时间的，这段时间默认会有3min。也就是说，在RegionServer宕机之后的3min之内系统并不知晓它实际上已经宕机了，所有的读写路由还会正常落到它上面，可想而知，这些读写必然都会失败。（当然，并不是所有RegionServer宕机都需要3min中才能被Zookeeper感知

Kafka是分布式发布-订阅消息系统。它最初由LinkedIn公司开发，之后成为Apache项目的一部分。Kafka是一个分布式的，可划分的，冗余备份的持久性的日志服务。它主要用于处理活跃的流式数据。 在大数据系统中，常常会碰到一个问题，整个大数据是由各个子系统组成，数据需要在各个子系统中高性能，低延迟的不停流转。传统的企业消息系统并不是非常适合大规模的数据处理。为了已在同时搞定在线应用（消息）和离线应用（数据文件，日志）Kafka就出现了。Kafka可以起到两个作用： 降低系统组网复杂度。 降低编程复杂度，各个子系统不在是相互协商接口，各个子系统类似插口插在插座上，Kafka承担高速数据总线的作用。 1、Kafka主要特点： 同时为发布和订阅提供高吞吐量。据了解，Kafka每秒可以生产约25万消息（50 MB），每秒处理55万消息（110 MB）。 可进行持久化操作。将消息持久化到磁盘，因此可用于批量消费，例如ETL，以及实时应用程序。通过将数据持久化到硬盘以及replication防止数据丢失。 分布式系统，易于向外扩展。所有的producer、broker和consumer都会有多个，均为分布式的。无需停机即可扩展机器。 消息被处理的状态是在consumer端维护，而不是由server端维护。当失败时能自动平衡。 支持online和offline的场景。 2、Kafka的架构

思考：一个系统的要能够被验证，能够被别的什么验证，或者系统本身支持自检，这样的系统才是一个功能可以保证准确的系统？ 一个client server模式，那么client和server都要支持能够打印日志，并能把日志串起来，用来检测调用参数是否符合预期； 一个系统，要支持静态分析和动态分析，静态分析可以看日志，动态调试很分析可以通过一些工具，比如java可用阿里的 arthas 来源： https://www.cnblogs.com/big1987/p/11994404.html

1.1 Appenders Appenders用来定义日志的输出方式，即日志要写到那种介质上去。较常用的Log4net已经实现好了，直接在配置文件中调用即可，可参见上面配置文件例子；当然也可以自己写一个，需要从log4net.Appender.AppenderSkeleton类继承。它还可以通过配置Filters和Layout来实现日志的过滤和输出格式。目前已经实现的输出方式有： AdoNetAppender 将日志记录到数据库中。可以采用SQL和存储过程两种方式。 AnsiColorTerminalAppender 将日志高亮输出到ANSI终端。 AspNetTraceAppender 能用asp.net中Trace的方式查看记录的日志。 BufferingForwardingAppender 在输出到子Appenders之前先缓存日志事件。 ConsoleAppender 将日志输出到应用程序控制台。 EventLogAppender 将日志写到Windows Event Log。 FileAppender 将日志输出到文件。 ForwardingAppender 发送日志事件到子Appenders。 LocalSyslogAppender 将日志写到local syslog service (仅用于UNIX环境下)。 MemoryAppender 将日志存到内存缓冲区。

转载自 https://www.cnblogs.com/luotianshuai/p/5206662.html Kafka初识 1、Kafka使用背景 在我们大量使用分布式数据库、分布式计算集群的时候，是否会遇到这样的一些问题： 我们想分析下用户行为（pageviews），以便我们设计出更好的广告位 我想对用户的搜索关键词进行统计，分析出当前的流行趋势 有些数据，存储数据库浪费，直接存储硬盘效率又低 这些场景都有一个共同点： 数据是由上游模块产生，上游模块，使用上游模块的数据计算、统计、分析，这个时候就可以使用消息系统，尤其是分布式消息系统！ 2、Kafka的定义 What is Kafka：它是一个分布式消息系统，由linkedin使用scala编写，用作LinkedIn的活动流（Activity Stream）和运营数据处理管道（Pipeline）的基础。具有高水平扩展和高吞吐量。 3、Kafka和其他主流分布式消息系统的对比 定义解释： 1、Java 和 scala都是运行在JVM上的语言。 2、erlang和最近比较火的和go语言一样是从代码级别就支持高并发的一种语言，所以RabbitMQ天生就有很高的并发性能，但是 有RabbitMQ严格按照AMQP进行实现，受到了很多限制。kafka的设计目标是高吞吐量，所以kafka自己设计了一套高性能但是不通用的协议