1、logstash 做监控的优劣
适合match-then-alert 的方式
logstash-filter-metric
logstash-input-http_poller
无状态、进程间数据无法交流
无复杂表达能力 logstash 做监控没有复杂的语法,同时越复杂的功能越消耗资源,本身logstash 就非常的消耗资源
利用logstash mail 插件有点low 2、spark 做监控的优劣
streaming 方式做准实时监控,需要预定义模式和编程能力,checkpoint 会降低性能
sql 方式做定期统计监控,运行缓慢
es-hadoop 方式读取es数据,可以利用sql来读取es数据,spark可以并发线程直连每个es的shard,
但是:意味着query出来的数据需要转存一份到spark里,利用sparkSQL做聚合统计后,数据再删除,
重复使用一次IO
非常吃内存 3、Elastalert
elastalert 是Yelp公司开源的用python 2.6 写的报警框架
属于后来elastic.co公司出品的Watcher的同类产品
文档地址是:
http://elastalert.readthedocs.io/en/latest/elastalert.html#
我们创建的规则都要写道es里,所以elastalert要创建index到es 3.1、elastaliert 的配置语法:
query(watcher 的 trigger) 查询
rule(watcher 的 input,comdition) 规则
enhancements(watcher 的 transform)
alert(watcher 的 action) 报警 3.2、query 配置:
除了有关es服务器的配置以外,主要包括:
1、‘run_every’配置,用来设置定时向ES发请求,默认五分钟
2、‘buffer_time’配置,用来设置请求的时间字段的范围,默认45分钟,查多长时间段内的数据
3、‘ruler_folder’配置,用来加载下一阶段的rule设置,默认是example_rulers
4、’timestamp_field‘配置,设置'buffer_time‘时 针对哪个字段,默认是@timestamp
5、'timestamp_type'配置,设置'timestamp_field'的事件类型,elastalert 内部也需要转换时间对象,默认是"ISO8601",也可以是'UNIX'
run_every:我们到 es 里去查询数据,定时的轮询去查询数据,满足一定规则的,这个我们可以全局的指定,也可以每个配置文件单独指定的,默认是全局的,建议每一个配置文件单独指定、 3.3 rule 配置
rule 设置各自独立以独立的文件方式存储在'rules_folder'设置的目录里,其中你可以定义下面这些参数,其中可以
定义下面这些参数:
name配置:每个rule需要有自己独立的name,一旦重复,进程将无法启动
type配置:选择某一种数据验证方式
index配置:从某类索引里读取数据,支持时间配置
filter配置:设置向es请求的过滤条件
timeframe配置:累计触发报警的时长(连续多长时间有异常才发报警)
alert配置:设置触发报警时执行那些报警手段 内置的rule介绍:
any:只要有匹配就报警;
blacklist: compare_key字段的内容匹配上 blacklist数组里任意内容;
whitelist: compare_key字段的内容一个都没能匹配上 whitelist数组里内容
change:在相同 query_key条件下, compare_key字段的内容,在 timeframe范围内发送变化;
frequency:在相同 query_key条件下, timeframe范围内有 num_events个被过滤出来的异常
spike:在相同 query_key条件下,前后两个 timeframe范围内数据量相差比例超过spike height。其中可以通过 spike_type设置具体涨跌方向是up,down,both。还可以通过 threshold_ref设置要求上一个周期数据量的下限, threshold_cur设置要求当前周期数据量的下限,如果数据量不到下限,也不触发
flatline: timeframe范围内,数据量小于 threshold 阈值
new_term: fields字段新出现之前 terms_window_sizer默认30天)范围内最多的terms_size(默认50)个结果以外的数据
cardinality: 在相同 query_key条件下, timeframe范围内 Cardinality_field的值超过max_cardinality或者低于 min_cardinality 3.4 enhancements 方式
match_enhancements 配置,设置一个数组,在报警内容发送到alert之前修改具体数据elastalsert 默认
不提供具体的enhancements实现,需要自己去扩展
不过,作为通用的方式,elastalert 提供几个便捷选项,把kibana 地址加入报警
1、generate_kibana_link: 自动生成一个kibana3 的临时仪表板在报警内容上
2、use_kibana_dashboard:采用现成的kibana3 仪表盘附属在报警内容上
3、use_kibana4_dashboard:采用现成的kibana4 仪表盘附属在报警内容上 我们现在使用的是kibana 5,这个是没有关系的,我们配置上URL,他是不会识别我们的kibana的版本号的。所以这个没有关系的,我们直接
把我们的kibana URL配置上就行 3.5 alert 配置
alert配置是一个数组,目前elastalert 支持的报警方式有:
Command
Email
JIRA
OpsGenie
SNS
HipChat
Slack
Telegram
Debug
Stomp 我们在使用的时候要预防报警风暴(在实际使用中我们遇到过可能一分钟成百上千的错误,要是都是发出来,就有问题了)。我们利用下面的一些措施来控制报警风暴:
1、aggregation:设置一个时长,则该时长内,所有的报警(同一个配置文件内的报警)最终合并在一起发送一次:
2、realert:设置一个时长,在该时间内,相同 query_key 的报警只发一个
3、exponential_realert: 设置一个时长,必须大于realert 设置,则在realert到exponential_realert之间,每次报警之后,realert 自动翻倍 3.5.1 alert command 方式
1、command 最灵活也最简单,默认采用 '%{fieldname}s' 格式
command:["/bin/send_alert的脚本","--username","%{username}s","--time","%(key_as_string)s"]
2、如果要用的比较多,可以开启'pipe_match_json'参数,会把整个过滤到的内容,以一整个JSON字符串的方式管道输入指定脚本 3.5.2 alert email 方式:
1、email方式采用SMTP协议,所以有一系列‘smtp_*’的配置,然后加上'email'参数提供收件人地址数组
2、特殊的是email 和 jira两种方式,elastalert 提供了一些内容格式化模板
3、比如可以这样控制邮件标题
alert_subject:"issue:{0} occurred at {1}"
alert_subject_args:
- issue.name
- "@timestamp"
4、而默认的邮件内容模板是:
body = rule_name
{alert_text}
ruletype_text
{top_counts}
{field_values}
5、这些内容同样可以通过'alert_text' (及对应alert_text_args)等来修改 配置案例:
alert:
- "email"
alert_text:"test"
smtp_host:smtp.exmail.qq.com
smtp_auth_file:smtp_auth_file.yaml
email_reply_to:[email protected]
from_addr:[email protected] 4、针对业务系统的监控系统:
业务系统与基础设施的关注点差异
基于日志 VS 基于探针
Rsyslog + ES
模板:
name: test1-front-rule
type: any
index: test1-front-*
realert:
minutes: 0
num_events: 1
filter:
- query_string:
query: "Level:ERROR" smtp_host: smtp.bigbao.com
smtp_port: 25
smtp_auth_file: /data/package/elastalert/smtp_auth_file.yaml
email_reply_to: [email protected]
from_addr: [email protected]
alert:
- "email"
alert_subject: "[front] service ERROR !!!"
#include: ["Date","Thread","RequestId","msg"]
#exclude: ["@timestamp","Class","Level","_id","_index","_type","beat","kafka"]
#alert_text_type: alert_text_only
alert_text: "
Service_Name: {} \n
Date: {} \n
Host: {} \n
Thread: {} \n
RequestId: {} \n
msg: {} \n
"
alert_text_args:
- type
- Date
- beat.hostname
- Thread
- RequestId
- msg email:
- "[email protected]"
05-02 05:05