cardinality rule not send any alerts

[waeshalaby]

I use sample cardinality rule to send alert while number of hosts is lower than 15 to test the rule as the unique count for hosts is always 7. but still no alerts received during debug this rule

rule.yml:

index: tibco-* name: Example cardinality rule use_local_time: true type: cardinality cardinality_field: "hostname.keyword" min_cardinality: 15 timeframe: hours: 4 filter:

• query: query_string: query: "app_id: PREPAID" alert:
• "debug"

here is the config.yml:

rules_folder: example_rules run_every: minutes: 1

buffer_time: minutes: 15

es_host: 10.230.84.134

es_port: 9200

writeback_index: elastalert_status writeback_alias: elastalert_alerts

alert_time_limit: days: 2

here is the log for this rule:

WARNING:apscheduler.scheduler:Execution of job "ElastAlerter.handle_rule_execution (trigger: interval[0:01:00], next run at:26 14:41:43 EET)" skipped: maximum number of running instances reached (1) INFO:elastalert:Skipping writing to ES: {'hits': 68268, 'matches': 0, '@timestamp': '2019-06-26T12:41:43.761790Z', 'rule_nample cardinality rule', 'starttime': '2019-06-26T12:25:57.884307Z', 'endtime': '2019-06-26T12:40:45.741374Z', 'time_taken': 58739624} INFO:elastalert:Ran Example cardinality rule from 2019-06-26 14:25 EET to 2019-06-26 14:40 EET: 68268 query hits (62085 alre, 0 matches, 0 alerts sent INFO:elastalert:Background configuration change check run at 2019-06-26 14:41 EET INFO:elastalert:Background alerts thread 0 pending alerts sent at 2019-06-26 14:41 EET INFO:elastalert:Sleeping for 59.999975 seconds

[liyue201]

i met the same problem

[CatCanCreate]

+1

[levanvunam]

+1

[csrenato]

+1 Getting this error log:

06:03:13.254Z ERROR elastalert-server: ProcessController: WARNING:apscheduler.scheduler:Execution of job "ElastAlerter.handle_rule_execution (trigger: interval[0:00:05], next run at: 2019-09-25 06:03:13 UTC)" skipped: maximum number of running instances reached (1)

Since this is a python thing, can you provide a timing mechanism to complete the process within the scheduled time?

[kamner]

+1

[olddanmer]

+1

[yinhejianke]

WARNING:apscheduler.scheduler:Execution of job "ElastAlerter.handle_rule_execution (trigger: interval[0:01:00], next run at: 2020-09-02 07:52:53 UTC)" skipped: maximum number of running instances reached (1)

need help ！！！

[madianas]

Encountered the same problem. Recreating container helps, temporarily.

WARNING:apscheduler.scheduler:Execution of job "ElastAlerter.handle_rule_execution (trigger: interval[0:01:00], next run at: 2020-10-06 03:50:29 UTC)" skipped: maximum number of running instances reached

[madianas]

+1 same error WARNING:apscheduler.scheduler:Execution of job "ElastAlerter.handle_rule_execution (trigger: interval[0:01:00], next run at: 2020-10-08 16:31:49 UTC)" skipped: maximum number of running instances reached

[zardnet]

+1

[aaronsdevera]

I have the same, deployed directly on ec2

WARNING:apscheduler.scheduler:Execution of job "ElastAlerter.handle_rule_execution (trigger: interval[0:00:10], next run at: 2020-12-22 23:07:58 UTC)" skipped: maximum number of running instances reached (1)

[DanielCarmel]

+1

[dream91]

Use Metric aggregation rule with metric_agg_type: cardinality instead of a Cardinality rule. Metric agg makes different query so it is lighter for elastalert. Cardinality rule should be used for processing a small amount of events. Metric aggregation can process huge amount of events in small amount of a time.

When you see maximum number of running instances reached (1) then it tells you - I haven't finished processing this alert, so I am skipping next run.

You can try run Cardinality rule with lower buffer_time and use_term_query also.