赛克蓝德日志分析软件(SeciLog)15年总结

    需求

    随着现代化企业的发展，企业对信息化的依赖程度越来越高，企业为了保障业务正常运行，需要部署大量的设备和软件系统：包括防火墙、入侵检测、扫描器、堡垒机、监控、OA、ERP、业务系统等；根据每家企业的情况不一样，部署的产品也会不一样，有用商业软件的，也有用免费软件的，甚至是开源软件的，可谓五花八门。在部署这么多系统后，会带来很多新的问题，常见的问题有如下几条：

•  每个系统都会有自己的界面，都有自己的告警，都有自己的报表，面对这么多的系统，对运维管理带来很大的挑战。

• 每个系统都是从自己的视角来看待问题，功能上相对独立，缺少融会贯通的能力，每当遇到问题的时候，需要从一台台设备中去登录，然后查看相关日志，效率低下。

• 每个系统中的日志格式都是不一样的，各有各的表达方式，就算同一件事情，表达的内容也是不一样的，这就给人员带来很大的困惑和学习成本。

• 每个系统中每天会产生大量的告警，企业中的运维人员相对较少，这就使很多的日志没有时间去查看，给系统的运行带来很大的隐患。

• 当一件事情发生的时候，在很多的系统中都有体现，但每个系统又相对对立，导致大量的重复告警，无法进行跨产品的事故分析。

• 每个系统的磁盘都是相对固定的，每当磁盘空间不够的时候，很多运维人员想到的第一件事就是删除日志，这就导致日志的丢失，万一发生问题，对事后的追溯和取证带来很大的困难。

• 企业中有不同岗位的人员，包括开发人员，运维人员，管理人员等等，每种人员对日志的要求是不一样的，开发人员更多的时候关注开发中遇到的异常日志，运维人员关注的是系统的告警日志，管理人员更多的是关注的业务日志。面对这么多的需求，现有的这种堆积木的方式很难满足。

    设计思想

        面对企业中这多问题的时候，我们就在思考如何解决这些问题。对于软件的使用，我们提出了极简原则，就是要让产品尽量的简单，包括安装简单，配置简单，使用简单，最好都是傻瓜式的，简单配置甚至不需要配置就可以使用的，但功能还要必须强大的。于是我们提出了两个集中，四个统一的设计思想。

• 集中收集：集中收集个系统中时时产生的海量日志；

• 集中存储：集中存储在一个可管理的分布式系统中；

• 统一查询：对各种日志提供统一的查询入口和规则；

• 统一分析：对收集上来的日志进行统一的分析；

• 统一预警：对日志进行时时关联分析，统一进行预警；

• 统一展示：对所有日志提供统一的展示方式。

    架构

    为了支撑我们的设计思想，我们对技术选型做了大量的研究。

    开发语言的选择，这块没有好坏之分，只是我从事了十几年的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年会对产品的友好性，稳定性方面继续加强。同时对产品的功能继续增加，包括基线检查、配置管理、单点登录这些运维中常用的功能进行扩充。同时会增加智能分析学习的能力。这样就更加增加产品统一管理的能力。