1. 环境准备与基础配置在开始之前我们需要确保已经搭建好EFKElasticsearch Fluentd Kibana日志系统。如果你还没有完成这一步可以参考我之前写的《Docker-compose部署分布式日志方案EFK》进行搭建。这里假设你已经有了正常运行的环境IP为192.168.10.109的Elasticsearch服务正在监听9200端口。ElastAlert2的安装方式有很多种我个人最推荐使用Docker方式部署因为可以避免各种Python环境依赖问题。新建一个项目目录比如叫做elastalert-dingtalk在里面创建两个子目录elastalert2用于存放主配置文件rules用于存放告警规则。配置文件elastalert.yaml需要放在elastalert2目录下这是整个系统的核心配置。我建议新手直接复制下面这个模板再根据自己环境修改关键参数rules_folder: /opt/elastalert/rules run_every: seconds: 10 buffer_time: minutes: 15 es_host: 192.168.10.109 es_port: 9200 es_username: elastic es_password: your_password_here writeback_index: elastalert_status alert_time_limit: days: 2这里有几个参数需要特别注意run_every决定了ElastAlert2检查新事件的频率生产环境建议设置在30秒以上buffer_time要大于run_every确保不会漏检日志writeback_index是ElastAlert2用来存储状态的索引首次运行时会自动创建2. 钉钉机器人配置实战要让告警消息推送到钉钉群首先需要在钉钉群里添加自定义机器人。我以Mac版钉钉为例具体操作路径是群设置 - 智能群助手 - 添加机器人 - 自定义机器人。安全设置建议选择加签记下生成的access_token和secret这两个参数后面会用到。在rules目录下创建dingtalk.yaml文件这是我们的第一个告警规则。下面是我在实际项目中验证过的配置模板name: error-log-alert type: frequency index: your-log-index-* is_enabled: true num_events: 1 timeframe: minutes: 5 realert: minutes: 10 timestamp_field: timestamp alert_text: | 【异常日志告警】 时间: {0} 服务: {1} 错误内容: {2} 完整日志: {3} alert_text_args: - timestamp - service.name - message - log filter: - query: query_string: query: level:ERROR OR level:error alert: - dingtalk dingtalk_access_token: 你的access_token dingtalk_secret: 你的加签secret dingtalk_msgtype: markdown这个配置实现了以下功能监控所有ERROR级别的日志5分钟内出现1次错误就触发告警10分钟内相同的错误不会重复告警使用Markdown格式发送更美观的通知3. 规则文件深度解析ElastAlert2的规则文件看似简单但实际使用时有很多细节需要注意。让我们拆解几个关键配置项type字段决定了告警的触发机制常用的有frequency固定时间段内达到指定次数触发spike短时间内日志量激增或骤降flatline日志突然停止产生blacklist/whitelist匹配特定黑名单/白名单filter部分使用的是标准的Elasticsearch查询语法。这里有个实用技巧可以先在Kibana的Dev Tools里调试好查询语句再复制到配置文件中。比如我们要监控404状态码的API请求可以这样写filter: - query: query_string: query: status:404 AND path:/api/*alert_text支持动态变量插值通过alert_text_args指定字段。我建议至少包含以下信息发生时间服务/主机标识错误摘要相关TraceID如果有对于复杂的告警内容可以使用dingtalk_msgtype: markdown然后通过Markdown语法组织内容alert_text: | ### 【{0}】服务异常 **时间**: {1} **节点**: {2} java {3}查看详情## 4. 调试与优化技巧 第一次启动时建议使用前台模式运行方便查看日志 bash docker-compose up常见的启动问题包括ES连接失败检查es_host、es_port和认证信息索引不存在确保index模式能匹配到实际索引权限不足Elasticsearch用户需要有读写权限调试时可以临时增加以下配置debug: true verbose: true在Kibana中查看ElastAlert2的状态索引也很重要。我通常会创建以下可视化告警触发趋势图最近24小时告警类型分布规则匹配次数排名对于生产环境还需要考虑添加realert防止告警风暴设置aggregation将相似告警合并配置priority区分告警级别5. 高级应用场景除了基本的错误日志监控ElastAlert2还能实现很多高级功能。比如监控API响应时间百分位name: slow-api-alert type: metric_aggregation index: web-logs-* buffer_time: minutes: 5 metric_agg_key: response_time_ms metric_agg_type: percentile percentile_range: 95 max_threshold: 500 filter: - query: query_string: query: type:api或者实现跨索引关联告警。比如当订单服务报错的同时支付服务也出现异常name: order-payment-correlation type: cardinality index: microservice-* timeframe: minutes: 3 max_cardinality: 1 query_key: trace_id filter: - query: query_string: query: (service:order AND level:ERROR) OR (service:payment AND level:ERROR)对于需要人工介入的严重告警可以结合钉钉的所有人功能dingtalk_at_mobiles: - 13800138000 dingtalk_is_at_all: true6. 性能调优经验分享随着规则数量增加ElastAlert2的性能可能会下降。根据我的实战经验可以通过以下方式优化索引策略优化index: service-logs-2023.08.* # 明确时间范围 use_strftime_index: true # 自动解析时间格式查询优化filter: - range: timestamp: from: now-15m to: now - query: query_string: query: level:ERROR default_field: message资源分配 在docker-compose.yml中增加资源限制elastalert2: mem_limit: 2g cpu_count: 2批量处理aggregation: minutes: 5 summary_table_fields: - host.name - error.code状态管理 定期清理旧的告警状态curl -X DELETE http://es-host:9200/elastalert_status*?pretty在实际项目中我建议从简单规则开始逐步增加复杂度。每新增一个规则都要评估其对系统的影响可以通过Elasticsearch的_nodes/stats接口监控查询负载。