随着现代化企业的发展,企业对信息化的依赖程度愈来愈高,企业为了保障业务正常运行,须要部署大量的设备和软件系统:包括防火墙、入侵检测、扫描器、堡垒机、监控、OA、ERP、业务系统等;根据每家企业的状况不同,部署的产品也会不同,有用商业软件的,也有用免费软件的,甚至是开源软件的,可谓五花八门。在部署这么多系统后,会带来不少新的问题,常见的问题有以下几条:java
每一个系统都会有本身的界面,都有本身的告警,都有本身的报表,面对这么多的系统,对运维管理带来很大的挑战。web
每一个系统都是从本身的视角来看待问题,功能上相对独立,缺乏融会贯通的能力,每当遇到问题的时候,须要从一台台设备中去登陆,而后查看相关日志,效率低下。sql
每一个系统中的日志格式都是不同的,各有各的表达方式,就算同一件事情,表达的内容也是不同的,这就给人员带来很大的困惑和学习成本。api
每一个系统中天天会产生大量的告警,企业中的运维人员相对较少,这就使不少的日志没有时间去查看,给系统的运行带来很大的隐患。安全
当一件事情发生的时候,在不少的系统中都有体现,但每一个系统又相对对立,致使大量的重复告警,没法进行跨产品的事故分析。架构
每一个系统的磁盘都是相对固定的,每当磁盘空间不够的时候,不少运维人员想到的第一件事就是删除日志,这就致使日志的丢失,万一发生问题,对过后的追溯和取证带来很大的困难。框架
企业中有不一样岗位的人员,包括开发人员,运维人员,管理人员等等,每种人员对日志的要求是不同的,开发人员更多的时候关注开发中遇到的异常日志,运维人员关注的是系统的告警日志,管理人员更多的是关注的业务日志。面对这么多的需求,现有的这种堆积木的方式很难知足。运维
面对企业中这多问题的时候,咱们就在思考如何解决这些问题。对于软件的使用,咱们提出了极简原则,就是要让产品尽可能的简单,包括安装简单,配置简单,使用简单,最好都是傻瓜式的,简单配置甚至不须要配置就可使用的,但功能还要必须强大的。因而咱们提出了两个集中,四个统一的设计思想。elasticsearch
集中收集:集中收集个系统中时时产生的海量日志;分布式
集中存储:集中存储在一个可管理的分布式系统中;
统一查询:对各类日志提供统一的查询入口和规则;
统一分析:对收集上来的日志进行统一的分析;
统一预警:对日志进行时时关联分析,统一进行预警;
统一展现:对全部日志提供统一的展现方式。
为了支撑咱们的设计思想,咱们对技术选型作了大量的研究。
开发语言的选择,这块没有好坏之分,只是我从事了十几年的java开发,比较熟悉,因此选择java做为开发的语言。其次是技术的框架的选择,如今的产品开发不少时候不须要从头开发,要站在巨人的肩膀上作事情。
框架的选择:java语言可选择的框架比较多,目前在日志领域最经常使用的流派有两组,一个是elasticsearch +logstash +kibana简称elk,一个是flume+kafka+storm。这两个选择都有大量的用户使用,也有各自的有点,在此不作过多的评价。但我我的认为这两种组合都有一个共同的缺点就是复杂,首先都是有几个组件,每一个组件相对对立,经过不一样的配置进行整合,须要通过屡次下载、配置、整合、测试、使用,根据我的能力不一样,少则一两天多多则一两周才能把环境搭建好,但这仅仅是第一步,后面的学习、使用、维护、开发都须要花费大量的时间和精力。根据咱们自身的积累咱们最终只选择了elasticsearch做为咱们存储和搜索的核心组件。对日志采集分析和展现部分,咱们本身进行了开发。
最终的架构是咱们本身的collect+elasticsearch+web,做为咱们本身的主要技术架构组合,从最终的产品使用效果来看,咱们的产品对大多数有必定经验的运维人员半个小时能够把环境搭建好,并可使用。
日志处理过程,系统先通过不一样的协议收集,而后都日志进行格式化处理,接着是入库,最后是对日志进行关联分析,产生告警。
日志采集:系统可以支持多种协议进行日志采集,系统内置Syslog server、SNMP Trap server、FTP server、SSH client、Sftp client、ftp client、Oracle client、Mysql client、web upload。这些全部的能力来源于java丰富的库。
日志的格式化:这一部分是产品的核心功能,既要简单又要好用,因此抽象出了不少的维度,目前咱们抽象出来的维度高达五十多个维度。 对经常使用日志格式的咱们作的大量的适配工做,目前支持经常使用的标准日志,包括Linux、Windows、Ftp/Sftp、Nginx等中间件的标准日志、IIS的日志;咱们还经过插件支持性能采集、Sniffer Mysql、Sniffer Http协议,Inotify文件修改的审计。对这些日志咱们都作了很好的匹配,作到了开箱即食的效果,因此你不用关注这些是怎么实现的,极大的简化了产品的使用。
日志的分析:咱们对预警的模型做了不少的抽象,咱们能够分析单条事件的行为,多条事件的行为,前后事件的行为;咱们还即将支持基于统计的日志分析和基于智能学习的日志分析。经过这些大量的模型,咱们能够很好的支持业务、运维和安全的关联分析。再次咱们举个例子来讲明咱们关联分析的效果。在作运维的都知道,cpu利用率是个很经常使用的指标,但这个指标比较敏感又和业务有必定的关系。那我如何来判断cpu利用率太高呢,咱们但愿的告警规则以下:在早上七点到九点之间,在连续的5分钟内cpu利用率超过80%5次以上,在其余时间,在连续的5分钟内cpu利用率超过60%5次以上进行告警。这是一个很实用的告警规则,但据我所知,能完成这种告警的产品很少,主要集中在几个大的siem品牌中,但他们的产品价格很高。
日志存储:咱们基于比较新版本的elasticsearch进行开发,在使用到的api中咱们基本上使用了最新的接口,这些接口在elasticsearch最新的2.1版本中继续支持,杜绝了产品废弃的接口,这些接口在官方的手册中明确提出在2.X版本后将废弃。这样咱们的产品就很容易的升级到最新的版本中。
日志搜索:因为采用了elasticsearch,咱们对日志搜索支持全文搜索,这些就像搜索引擎搜索同样方便。同时只是不一样维度的精准搜索,都经常使用搜索能够保存起来进行下次的快速搜索。支持在搜索中直接查看IP的地区。对不一样的维度能够自定义在列表中是否显示,极大的方便个性化的查看。
内置报表:系统内置经常使用的不少报表,包括WEB报表,防火墙报表,会话审计、登陆报表等,对这些报表都支持二级甚至三级钻取功能,系统同时还支持自定义报表,基本知足大多数的需求。
日志分析产品咱们从15年4月份第一个版本上线到16年一月中旬,系统共升级了22个版本。极大的丰富了产品的内容,但因为时间比较短,不少地方作的不够精致,因此16年会对产品的友好性,稳定性方面继续增强。同时对产品的功能继续增长,包括基线检查、配置管理、单点登陆这些运维中经常使用的功能进行扩充。同时会增长智能分析学习的能力。这样就更加增长产品统一管理的能力。