ElasticSearch日志告警
我们看到很多人使用夜莺做可视化告警规则管理，同时接入了多个 Prometheus 集群，已经可以很好的解决指标告警的问题，不过对于日志告警，还是没有很好的统一化方案，希望能够在夜莺里也完成日志告警规则的管理。本文就来讲讲，如何基于夜莺构建日志监控能力。
典型的日志告警的需求比如：
- 统计日志中的 ERROR 关键字出现次数，超过阈值则发出告警；
- 从网关日志中提取服务接口的 QPS，出现较大波动则发出告警；
- 从网关日志中提取服务接口的延迟，延迟太高则发出告警；
我们可以基于夜莺的的整体流程，快速构建一个日志告警平台来满足上述的需求，本文从产品设计，架构设计，代码实现三个方面，来介绍如何基于夜莺来构建日志告警平台。为了满足大家的好奇心，我们来先看一张效果图，下图是告警历史详情页的截图。
产品设计
通过前文的介绍，我们的需求已经比较明确了，将应用的日志收集起来，在平台上配置告警规则，根据配置的规则触发告警通知，收到通知之后，我们在页面上可以看到和告警数据相关的日志原文，便于快速定位问题。
夜莺监控已经支持了告警规则配置页面和告警详情查看页面，所以我们可以直接复用这两个页面。当收到告警通知，点击到告警详情页时，夜莺目前的告警详情页只有查看时序数据的能力，没有查看日志原文的能力，所以还需要增加在详情页查看日志原文的能力。所以为了支持日志告警能力，在产品层面我们需要对夜莺的两个页面（告警规则页面、告警历史详情页面）进行改造。
告警规则配置页面：
历史告警页面：
架构设计
产品设计确定之后，我们来进行架构设计，首先看一下夜莺已有的能力
- n9e-webapi 提供各种配置管理、即时数据查询、告警历史详情查看的能力
- n9e-server 提供同步规则、查询数据、产生异常点、生成告警事件、告警屏蔽、告警订阅、告警通知的能力。
如果要增加日志告警能力，我们可以发现在产生异常点之后，n9e-server 后续的一系列能力是可以复用的，所以我们可以得到下面的架构图
从上图我们可以发现，日志告警模块只要实现下面4个功能即可
- 同步告警规则
- 从日志中提取 metric 数据和原文
- 根据规则判断数据是否异常
- 异常点发送给 n9e-server
搞清楚要做什么事情之后，下面我们要开始动手写代码了
代码实现
本小节主要是介绍日志告警模块代码实现的思路，我们可以开发一个独立的模块，主要是实现下面四个功能。
同步告警规则
我们可以通过定期查询 n9e-webapi 提供的 api 来同步告警规则，同步逻辑可以参考 n9e-server 模块 https://github.com/ccfos/nightingale/blob/main/src/server/memsto/alert_rule_cache.go 的逻辑，将从数据库查询，改成从 api 获取即可
日志中查询 metric 数据和原文
Elasticsearch 提供了 bucket aggregations 和 metric aggregations 的 api，通过这两个 api ，我们可以根据查询条件查到对应的 metric 数据。通过 es 的 search api，我们可以根据查询条件查到日志原文。
根据规则判断数据是否异常
这个功能可以参考 n9e-server 的告警规则判断逻辑，代码在 https://github.com/ccfos/nightingale/blob/main/src/server/engine/worker.go loopFilterRules() 定期获取规则，然后生成异常点检测任务，Work() 实现了产生异常点的功能。
异常点发送给 n9e-server
n9e-server 提供了接收异常点然后产生告警事件的接口，产生异常点之后，我们把异常点 push 给 n9e-server 的 api 即可，之后的告警事件处理流程，全部由 n9e-server 来负责。
最终效果
通过夜莺日志告警插件，我们可以在夜莺平台，实现日志场景下的监控告警体系建设。
