vlambda博客
学习文章列表

来自twt社区同行交流，欢迎更多同行参与交流

@聂奎甲 长春长信华天 项目经理：

要选择开源的日志监控软件可以看下图：

要选择商业日志监控软件可以看一下日志易、启明和七牛的日志软件等。

通常传统的解决方案如下：

第一，使用 grep 等脚本工具。很大的问题是低效、易出错，更大的问题是不安全。

第二，使用 MySQL 汇聚数据。使用方便，但是能力有限。

第三，使用 NoSQL。大问题是不支持交叉查询与全文检索，使用负担相对大。

第四，使用 Hadoop / Spark / Storm。使用起来比较繁杂，不支持全文检索。

第五，使用 ELK。产品层面做的比较不足，超大数据量下稳定性存在挑战。

商业软件可以更好的解决上面这些软件的不足，使运维工作更简单一些。

@nansingnansing AiB 系统架构师：

厂商：国内可以参考日志易（优特捷），国外的splunk。

自研或一般厂商，目前比较多的是基于ELK做平台封装，增加kfk、权限管理、spl查询、监控设置等可维护性、可管理的功能。其他方案上一位已经回答的比较全了。

以下经验主要基于ELK平台，使用的有日志易产品，也有自研平台。

选型上，要评估自身的日志量和投入成本，低量级对厂商产品没有什么大的依赖，高量级就会涉及到es的调优能力和部署架构。

另一个会影响性能的，就是解析规则，大量的解析规则会导致性能消耗加剧，入库慢会导致监控失真。

其他可参考的，配置简易性、支持解析规则的设置能力、SPL支持能力、报表可视化、历史数据归档策略等。

1、可由运维人员自定义关键字

——日志平台的监控，一般条件都是周期性范围内出现关键字的次数，例如5分钟内出现ERROR数10次。基本上产品都是支持的

——为了支持更复杂的监控，一般会对一些字段做提取，比如通过正则表达式，提取出一些业务字段，可以做加减乘除、<>=等二次加工的条件 

2、能适应不规则新生成的日志文件

——对于日志文件，可以对目录进行动态发现；但一般还是配置具体文件路径的比较多，例如/log/abc.YYYYMMDD，但也可以监控/log目录下的所有新日志

——对于日志内容，至少要设置换行条件，例如起始字符或结束/n，设置起始字符，可以将exception的输出合并在一条日志里，但对日志规范有些要求

@anonym 某银行 运维工程师：

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来说，更容易实现对关键字进行抓取和搜索，并可以对关键字的类型进行转化和计算。

二者都可以 适配所有日志文件，不同的是，elk可以对日志进行预清洗，而zabbix不可以。

还有一种思路可以提供参考，可以通过 logstash-output-zabbix插件，让logstash来对日志进行初步的清洗来达到日志的标准化，同样可以对关键字在某种特殊场景下的类型转换和二次计算来让监控指标更加合理， 通过这个插件将Logstash与zabbix进行整合，也就是将Logstash收集到的数据进行过滤，将有错误标识的日志输出到zabbix中，最后通过zabbix的告警机制进行触发、告警，这种方式将zabbix和logstash的优点进行整合，在技术栈在可控范围内进行收窄的同时，更灵活的进行关键字的配置和告警，同时zabbix还可以实现告警后的处理，如重启应用、执行脚本来达到初步的自愈功能。

@Zabbix大叔_乐维  研发工程师：

前面已经有人分析的很好了，日志易经过深度优化形成了自己的搜索引擎，其他两家基于elk为底层做的上层应用，sp是集大成者，基于日志在运维和安全都做的很好，缺点就是外企大厂的通病，易用性差。在日志运维这块国内日志易做的比较好，其次是七牛，乐维也有日志监控。安全这块，传统的安全厂商日志产品都是基于满足审计需求的盒子，真正做了一点场景的是瀚思，但是被360收了。

针对ES日志监控，ES本身在X-pack中有集成的工具包，但是收费的。故开源免费的ElastAlert是比较好的替代品。

Elastalert的定义：

ElastAlert是一个用Python编写的框架，用于实时监控ES中数据中的异常，极值或其他感兴趣的模式。它结合了两种类型的组件：规则类型和警报。

ElastAlert定时轮询ES，并将查询数据传递到规则类型。规则类型定义了匹配的时间和触发告警的条件。此过程由一组规则配置，其中每个规则限定了一个查询，一个规则类型和一组警报。

官网介绍了一些Elastalert的特性：

--可靠性：ElastAlert依靠ES将自身状态的信息回写到约定的索引上。这样可以事后回顾和调试ElastAlert的操作，并避免在ElastAlert重新启动或崩溃时丢失数据。一旦崩溃，ElastAlert也能靠持久化下来的信息，恢复到先前处理的位置。

--高度模块化：ElastAlert的主要组件是规则类型和警报。它们可以作为模块导入或定制。

--易于配置：只需设置全局配置文件和一组规则，即可轻松设置和配置ElastAlert。

值得一提的是，如果采用docker部署ElastAlert，可以通过K8S来弥补ElastAlert目前不能做到高可用HA的缺点，同时，Github上也能下载插件，与kibana进行集成，实现页面对规则的管理。

欢迎点击文末阅读原文到社区阅读和讨论交流

觉得本文有用，请转发、点赞或点击在看，让更多同行看到