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:monitor@bigbao.com
from_addr:monitor@bigbao.com
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: big@bigbao.com
from_addr: big@bigbao.com
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: {}
Date: {}
Host: {}
Thread: {}
RequestId: {}
msg: {}
"
alert_text_args:
- type
- Date
- beat.hostname
- Thread
- RequestId
- msg
email:
- "big@bigbao.com"