主流日志监控软件技术选型分析.docx

? ? ? ? ? ? ? 主流日志监控软件技术选型分析 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  目前市场上主流日志监控软件有哪些？应该怎样选择？技术对比分析如何？ 对日志关键字的监控与告警。1.可由运维人员自定义关键字 2.能适应不规则新生成的日志文件 * “争议”栏目内容来自同行分享的一手体验和观察，仅代表个人观点 要选择开源的日志监控软件可以看下图： 要选择商业日志监控软件可以看一下日志易、启明和七牛的日志软件等。 通常传统的解决方案如下： 第一，使用 grep 等脚本工具。很大的问题是低效、易出错，更大的问题是不安全。 第二，使用 MySQL 汇聚数据。使用方便，但是能力有限。 第三，使用 NoSQL。大问题是不支持交叉查询与全文检索，使用负担相对大。 第四，使用 Hadoop / Spark / Storm。使用起来比较繁杂，不支持全文检索。 第五，使用 ELK。产品层面做的比较不足，超大数据量下稳定性存在挑战。 商业软件可以更好的解决上面这些软件的不足，使运维工作更简单一些。 厂商：国内可以参考日志易（优特捷），国外的splunk。 自研或一般厂商，目前比较多的是基于ELK做平台封装，增加kfk、权限管理、spl查询、监控设置等可维护性、可管理的功能。其他方案上一位已经回答的比较全了。 以下经验主要基于ELK平台，使用的有日志易产品，也有自研平台。 选型上，要评估自身的日志量和投入成本，低量级对厂商产品没有什么大的依赖，高量级就会涉及到es的调优能力和部署架构。 另一个会影响性能的，就是解析规则，大量的解析规则会导致性能消耗加剧，入库慢会导致监控失真。 其他可参考的，配置简易性、支持解析规则的设置能力、SPL支持能力、报表可视化、历史数据归档策略等。 1、可由运维人员自定义关键字 ——日志平台的监控，一般条件都是周期性范围内出现关键字的次数，例如5分钟内出现ERROR数10次。基本上产品都是支持的 ——为了支持更复杂的监控，一般会对一些字段做提取，比如通过正则表达式，提取出一些业务字段，可以做加减乘除、=等二次加工的条件? 2、能适应不规则新生成的日志文件 ——对于日志文件，可以对目录进行动态发现；但一般还是配置具体文件路径的比较多，例如/log/abc.YYYYMMDD，但也可以监控/log目录下的所有新日志 ——对于日志内容，至少要设置换行条件，例如起始字符或结束/n，设置起始字符，可以将exception的输出合并在一条日志里，但对日志规范有些要求 ELK 或 EFK 都是不错的技术选型，目前在国内很多厂家都落地了各种 ES 的架构方案，开源生态也稳定发展，各项配套组件都能很容易对接。 在主流的现有选型中，关系型数据库因为索引压力和对全文检索的支持薄弱，不因该作为考虑，即便是使用高性能的缓存或者消息队列没有性价比可言。NoSQL 数据库也没有先天的对日志的存储优势，虽然宽松的范式限制能够灵活地处理信息文档，现在大部分日志是 JSON 形式可以输入至 MongoDB 等，但是在日志场景的使用案例还是不够。ES 能够使用倒排索引、分片、复制等完全契合日志及文本处理需求，很容易成为选型过程中的首选。 日志的存储可以对接流计算等外部模块，能将日志的价值榨取充分。 对题主的问题进行分解，对日志关键字的监控与告警。1.可由运维人员自定义关键字2.能适应不规则新生成的日志文件。 1、自定义关键字，应该是日志中出现某个关键字进行告警，或者不出现某个关键字进行告警，其中包括String类型与Number类型 2、 适应不规则新生成的日志文件，适配所有日志文件，对日志具备初步清洗的功能 目前开源监控中较为常见的是ZABBIX或ELK（也可是EFK） zabbix完全可以实现题主的需求，主要通过匹配关键字实现告警，举个例子，新建项目， 选择类型为zabbix客户端（主动式），键值为 xx_log.log 为日志的绝对路径 ，connectException 为关键字 ，此处的关键字需根据自己需要定义，如下列配置： DIA3222E日志 log[{#DB2LOGDIR},DIA3222E,,100,skip,] 　 主机{HOST.NAME}{#DB2LOGDIR}日志产生DIA3222E信息 nodata(5m)=0 这种监控方式较为机械，不够灵活，如类型的转换，上下文关联不能够实现，收到告警后需要人工介入进行二次分析，优点是配置简单，技术掌握较为单一，且侵入性较小。 elk在监控能力方面较为全面，logstash的grok语法 可以直接使用或应用预定义的表达式名称，并支持把预定义的 grok 表达式 写入到文件中，同样满足题主的需求，相比zabbix来说，更容易实现对关键字进行抓取和搜