Question for "summary_table_fields" and "aggregation "

[dsj27zhangfuxin]

Due to certain reasons, I can only develop on the internal network, so when testing, I used the local svc, which provides services through the Java-written post2 webapp alert receiving channel. However, when this rule is actually used, it will adopt the workwechat bot method. So my current dilemma is that the test cases I wrote are for post2, but post2 cannot support aggregated tables and unified sending of aggregated summaries. In the source code of the post2 alert system, I saw a comment stating that each match in matches will be sent individually via post. However, the post2 source code does not call the create_alert_body method, making it impossible to obtain the aggregated table from the payload (I am not sure if my understanding is correct; if not, I hope you can correct me). Therefore, the testing phase is like blind men touching an elephant, and I have written a version of the workwechat alert. If there are any errors, I hope you can point them out.

---

The display method I want to achieve now is: to show the summary table at the top of the alert information, and then separate it with "------", listing the detailed information of each alert.
However, since I have many log matching fields, I only want to display the queryHash, time, and durationMillis fields in each detail. I'm not sure if the "alert_text" I wrote can achieve this purpose.
Yeastday,I have read the code of workwechat.py and found that it aggregates the table and each specific piece of data in the create_alert_body() method to form a "body".
So I would like to ask if my way of writing alert_text can achieve the expected effect?

---

myRule

---

name: "mongo"
type: any
index: filebeat*

realert:
minutes: 5

aggregation:
minutes: 5

filter:
- query:
bool:
must:
- match_phrase:
message: "Slow query"
- term:
kubernetes.container.name: "mongod"

alert:
- "workwechat"
work_wechat_msgtype: "markdown"
work_wechat_bot_id: "******"

alert_text_type: alert_text_jinja

alert_text: |
mongodb_slow_query_alert!
queryHash: {{queryHash}}
time: {{'@timestamp'}}
durationMillis: {{durationMillis}}

summary_prefix: |
MongoDB-Slow-Query-summaryTable
summary-time: {{ aggregation.minutes }} min
alert-time: {{ '@timestamp' }}
num-events: {{ num_matches }}

summary_table_fields:
- kubernetes.container.name
- queryHash
- num_matches
- keysExamined
- docsExamined
- nMatched
- nModified
- keysDeleted
- ndeleted
- nreturned
- durationMillis

summary_table_max_rows: 30
summary_table_type: "markdown"

---

sorry for some "Space" display in the rule.yaml.

[jertel]

The recommended process for developers to perform testing like this is to have a separate WorkWeChat account dedicated to dev/test/staging. Trying to swap out the alerter type prior to production is inefficient and prone to failure.

I don't think the summary_prefix supports embedding field variables like you have done. It's supposed to be static text.

For future posts please use backticks to enclose code like I have done in this response. See #11 for more information on forum guideliness.

[dsj27zhangfuxin]

Thank you for answering my questions promptly.
Yes, I also think it’s an inefficient method.
Unfortunately, Work WeChat can’t be deployed on the intranet. It is a popular messaging app in our country, similar to Facebook.
All the content we submit to the online environment should be fully tested on the intranet. I need to ensure that the rules are usable when they are uploaded to the online system.
hh, this is what’s been bothering me.
I plan to use my own internet-connected computer to deploy Elasticsearch (ES), Filebeat, and ESAlert this weekend to test the Work WeChat alarm.
Thank you for the suggestions you’ve offered.