【编者的话】从2015年初入职有赞以来，一直致力于后端服务开发，主要设计开发了监控系统Hawk，但这不是本次要分享的点。一个月前，负责日志平台Track的小伙伴寻求梦想出去创业了，有幸接手了日志平台，这对本人确实是个不小的挑战，也同样是个学习成长的机会。此次就借着梳理日志平台的机会，给大家分享一下有赞统一日志平台的架构设计。 一、引言 自有赞成立以来，发展迅猛，业务增长很快，业务系统数量大，每天都会产生大量的系统日志和业务日志(据统计，平均每秒产生日志1.1万条，峰值1.5万条，每天的日志量约9亿条，占用空间2.4T左右)。 在信息化时代，日志的价值是无穷的。为了对系统进行有效的监控、维护、优化、改进，都离不开对日志的收集和分析，而这些日志散落在各个服务器上，无论对运维同学、还是业务开发同学，抑或是数据部门的同学而言，查阅或分析日志是一大痛点，实时收集分布在不同节点或机器上的日志，供离线或在线查阅及分析来提升工作效率的需求异常迫切，在此背景下，于是有赞统一日志平台就应运而生了。 在互联网高速发展的今天，有那么多优秀的日志收集系统，诸如Kafka、Flume、Scribe、Chukwa、ELK等。对于如何选型在此不做讨论，而且本人才疏学浅，也未做深入调研和性能分析对比测试，还不够资格讨论。相信前人的选择是有其理由的，接下来我们来看看秉着“短平快”的互联网精神，构建的这套适合有赞业务系统的统一日志平台。 二、总体设计废话不多说，直接上总体架构图，如图2-1所示：
有赞统一日志系统，负责收集所有系统日志和业务日志，转化为流式数据，通过flume或logstash上传到日志中心(kafka集群)，然后供Track、Storm、Spark及其它系统实时分析处理日志，并将日志持久化存储到HDFS供离线数据分析处理，或写入ElasticSearch提供数据查询，或写入Hawk发起异常报警或提供指标监控查询。 三、模块分解从上面总体架构图中，我们可以看到整个日志平台架构分为四层，从左到右依次是日志接入层、日志中心、日志处理层、日志存储层。 3.1 日志接入层日志接入层主要有两种方式，方式1基于rsyslog和logstash，方式2基于flume-ng。 3.1.1
对于一些稳定的日志，比如系统日志或框架日志(如nginx访问日志、phpfpm异常日志等)，我们添加nginx配置，通过rsyslog写到本地目录local0，然后logstash根据其配置，会将local0中的增量日志上传到日志中心对应的topic中，具体数据流图见图3-1所示： 3.1.2Flume NG是一个分布式，高可用，可靠的系统，它能将不同的海量数据收集，移动并存储到一个数据存储系统中。轻量，配置简单，适用于各种日志收集，并支持Failover和负载均衡。并且它拥有非常丰富的组件。Flume NG采用的是三层架构：Agent层，Collector层和Store层，每一层均可水平拓展。其中Agent包含Source，Channel和Sink，三者组建了一个Agent。三者的职责如下所示：
在有赞日志平台中，我们只用了Agent层。具体可以见图3-2:
日志中心的kafka是根据topic存取数据的，所以需要在日志中加入topic字段。为了统一，我们对日志格式做了约定，格式如下: |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
