最近需要配置一套elastalert來監(jiān)控日志抖格，以下情況：
- 日志用Logstash每天一個生成一個index存入es记劝。
- 日志中存儲運行期的各種信息密浑，包括物理位置褂萧，名稱，運行信息等等捷绒。
- 要在運行期信息中找到搜索特定信息，并認定為特定異常，舉例："unable to create native thread"讯壶， 我們認為是OOM了
- 現(xiàn)在要用elastalert監(jiān)控OOM并報警
很簡單的一個需求，配置的rule大概如下：
name: OOM Any Out Rule
type: any
index: applog-*
num_events: 1
timeframe:
minutes: 10
aggregation:
# "* * * * *" means: run as the "run_every" in config.yaml
schedule: "* * * * *"
# several columns of my agg summary table, the table has a default column: count
summary_table_fields:
- "service"
- "stack"
- "name"
- "@timestamp"
filter:
- query:
query_string:
query: "message: unable to create native thread"
alert:
- "email"
email:
- "my@email.com"
解釋一下：
- 因為只需要filter中的一個條件來確定OOM異常湾盗，故使用type: any
- 使用agg伏蚊，因為如果不這樣設(shè)置，那么當這樣有多個hit時格粪，es-alert是只存儲其中一條hit的躏吊。
INFO:elastalert:Ran OOM Any Out Rule from 2018-05-31 14:04 CST to 2018-05-31 14:07 CST: 3 query hits (0 already seen), 3 matches, 1 alerts sent
當你只需要agg得到的數(shù)量時，這當然ok帐萎，但是當你需要每一個hit的信息時比伏，就涼涼了。但是es-alert的文檔中說的并不清楚疆导，所以可以看到有非常多的issue在問怎么得到每一個hit赁项。 - 以上rule運行時，收到的郵件將包括一個包含"summary_table_fields"中配置的column的表格是鬼，并在表格下方遍歷所有對應(yīng)的match_body肤舞。
- 其實這樣的表格讀起來并不舒服，因為：
- 表格沒有編號列均蜜，不知道自己看到哪一條了
- 表格默認的count列沒有去掉李剖，難受
- 下方的match_body遍歷沒有任何標識，看起來復(fù)雜囤耳，占篇幅又沒意義
- 研究一下怎么解決以上問題
