1 # other rules to consider:
2 # filesystem, network, ntp rules:
3 # https://github.com/cloudalchemy/ansible-prometheus defaults/main.yml
4 # on my system, the interpolated values are in /a/opt/ansible-prometheus/rules.yml
12 # ## uncomment for testing an alert firing
13 # - alert: test-alert4
19 # description: "always-firing alert VALUE = {{ $value }}"
23 ###### BEGIN MISC NOTES ######
26 # other interesting exporters
27 # https://github.com/prometheus-community/node-exporter-textfile-collector-scripts
30 # interesting post: https://www.metricfire.com/blog/top-5-prometheus-alertmanager-gotchas/
32 # interesting promql query that could be useful later.
33 # changes(ALERTS_FOR_STATE[24h])
37 # alert flap strategy.
38 # https://roidelapluie.be/blog/2019/02/21/prometheus-last/
40 # Another idea generally is to make an alert that fires for 24 hours and
41 # inhibits another alert for the same thing, which we want at most
42 # 1 alert per 24 hours.
44 ###### END MISC NOTES ######
47 # various queries only look at increases, so invert the up metric so we
48 # can better query on down.
52 # convenience metric to use in multiple alert expressions
53 - record: mailtest_lag_inhibit
54 expr: present_over_time(ALERTS{alertname=~"kd_eth0_down|target_down|cmc_wan_down"}[17m]) or on() count_over_time(up{job="prometheus"}[19m]) <= 18
57 # the node_network_info here goes away when it is down,
58 # https://www.robustperception.io/absent-alerting-for-scraped-metrics
60 # What this says is: return metric if up == 1 if there isnt also
61 # the right hand metric (with the same instance+job).
64 # ! exists(operstate=up) && up
67 up{instance="10.2.0.1:9100"} == 1 unless on(instance,job) node_network_info{instance="10.2.0.1:9100",device="wan",operstate="up"}
73 node_network_up{instance="kdwg:9101",device="eth0"} != 1
78 # alerting on missing metrics:
79 # https://www.robustperception.io/absent-alerting-for-scraped-metrics
80 # that doesnt work if we want to alert across multiple hosts, eg
81 # up{job="node"} == 1 unless node_systemd_unit_state{name="systemstatus.service",state="active",job="node"}
82 # however, google lead me to a solution here
83 # https://www.linkedin.com/pulse/prometheus-alert-missing-metrics-labels-nirav-shah
84 # there is also the absent() function, but i didnt see a way to make that work
85 - alert: mysers_units_missing
87 count(up{job="node"} == 1) by (instance) * 3 unless
88 count(node_systemd_unit_state{name=~"(systemstatus|btrfsmaintstop|dynamicipupdate).service",state="active"}) by (instance)
93 - alert: epanicclean_not_active
95 node_systemd_unit_state{name="epanicclean.service",state="active"} != 1
100 - alert: epanicclean_missing
102 count(up{job=~"node|tlsnode"} == 1) by (instance) unless
103 count(node_systemd_unit_state{job=~"node|tlsnode",name="epanicclean.service",state="active"}) by (instance)
108 - alert: mysers_not_active
110 node_systemd_unit_state{name=~"(systemstatus|btrfsmaintstop|dynamicipupdate).service",state="active"} != 1
115 # todo: at some point, look into making mailtest-check either be resilient to the internet going down,
116 # or inhibit or group this alert with it going down.
117 - alert: sysd_result_fail
118 # not sure 30m is really needed, it prevents the alert from flapping
121 rate(node_systemd_unit_result_fail_count[30m]) > 0
125 - alert: exim_paniclog
131 - alert: check_crypttab
137 # 17 minutes: We try to send every 5 minutes. if we reboot causing 1
138 # send to fail, thats 10 minutes between 2 sends. we test this every 5
139 # minutes, so thats 15 minutes of time we can expect for 1 failed email,
140 # and 1 failed email is expected due to reboots or other tiny issues we
143 # cmc_wan_down etc, inhibits other alerts, but mailtest_check needs
144 # additional time to recover after an outage. We can only inhibit while
145 # an alert is actually firing, it doesnt affect the "for:"
146 # condition. So, we have those alerts that need to be delayed be
147 # conditioned on a query for that alert having not been firing in the
148 # last X minutes. However, there is a special case when prometheus
149 # itself was down, and so there was no alert. So, I test for missing
150 # of metric that gets generated for prometheus itself. If for some
151 # reason that has a problem, I could make it more conservative by
152 # checking that we booted recently instead, eg:
153 # time() - node_boot_time_seconds{instance="kdwg:9101"} <= 60 * 17
154 - alert: mailtest_check_vps
156 time() - mailtest_check_last_usec{job="tlsnode"} >= 60 * 17 unless on() mailtest_lag_inhibit
160 summary: '17 minutes down'
162 - alert: mailtest_check_mailhost
164 time() - max by (folder,from) (mailtest_check_last_usec{job="node"}) >= 60 * 17 unless on() mailtest_lag_inhibit
168 summary: '17 minutes down'
170 # 20 minutes. just allow for more due to prod alert.
171 - alert: mailtest_check_gnu_mailhost
173 time() - max by (folder,from) (mailtest_check_last_usec{folder="/m/md/l/testignore", from="iank@gnu.org"}) >= 60 * 20 unless on() mailtest_lag_inhibit
177 summary: '20 minutes down'
179 - alert: mailtest_check_unexpected_spamd_vps
181 mailtest_check_unexpected_spamd_results >= 1
185 summary: 'jr -u mailtest-check -e -n 10000'
187 - alert: mailtest_check_missing_dnswl
189 mailtest_check_missing_dnswl >= 1
194 summary: 'jr -u mailtest-check -e -n 10000'
196 # We expect to be getting metrics, if we come up and notice we have
197 # any missing in the past, and it wasn't from a reboot, and we haven't
198 # fired any other alerts, make an alert. In testing, the the count is
199 # 19 for 19 minutes, but I make it 18 just to give a bit of slack.
200 - alert: historical_missing_metric
202 count_over_time(up{job="prometheus"}[19m]) <= 18 unless on() present_over_time(ALERTS[19m]) unless on() time() - node_boot_time_seconds{instance="kd"} <= 60 * 17
206 # 10 am friday. but, do it 1 minute early so it is closer to actually
208 - alert: dead_man_test
210 ( hour() == 13 and minute() >= 59 or hour() == 14 and minute() < 3 ) and day_of_week() == 5
215 summary: Prometheus weekly test alert
218 #### Inhibit notes ####
219 ## Example of expressions to detect if the target_down alert
220 # fired in the last 24 hours. Initially, I thought his could
221 # be an alert which inhibits up_resets, but eventually I figured
222 # that doesn't make much sense, and the idea of using an alert
223 # that is not an indication of something wrong, only inhibits another
224 # alert, I think works better to integrate directly into the
225 # alert it would inhibit, this may mean a recording rule. That avoids
226 # an alert we have to ignore or filter out.
228 # Alternate expression, to calculate if the alert would have fired is:
229 # min_over_time(sum_over_time(up[30m])[1d:]) == 0
230 # where 30m matches the for: time in target_down
232 # Note: for graphing, surround in the expression in sum_over_time()
233 # ALERTS{alertname="target_down",alertstate="firing"}[1d]
234 #### end Inhibit notes ####
237 # For targets where we alert only on long downtimes, we
238 # still want to know if it is going down many times for short times over
239 # a long period of time. But ignore reboots.
241 ## Another way would be to detect an overall downtime:
242 # avg_over_time(node_systemd_unit_state{name="dynamicipupdate.service",state="active"}[1d]) < .95
244 # However, this seems to just find too many false positives for now, so
249 # resets(up[1d]) - changes(node_boot_time_seconds[1d]) > 12
253 # summary: "Target has gone down {{ $value }} times in 1 day, > 12"
257 # https://awesome-prometheus-alerts.grep.to/rules
259 # todo, we should probably group the prometheus alerts that indicate a
260 # host-local problem.
261 # eg, set a label alert-group: local-prom, then make a receiver that
262 # groups by it when the alert-group is local-prom.
264 - name: awesome prometheus alerts
267 - alert: PrometheusJobMissing
268 expr: absent(up{job="prometheus"})
273 summary: Prometheus job missing (instance {{ $labels.instance }})
274 description: "A Prometheus job has disappeared\n VALUE = {{ $value }}"
276 - alert: lowpri_target_down
277 expr: up{instance!~"kdwg:9101|bkex.b8.nz:9101|liex.b8.nz:9101|10.2.0.1:9100|kwwg:9101"} == 0
282 summary: Target down for 30m
284 # note PrometheusAllTargetsMissing is intentionally omitted because it
285 # is redundant to the above.
288 expr: up{instance=~"kdwg:9101|bkex.b8.nz:9101|liex.b8.nz:9101|10.2.0.1:9100"} == 0
293 summary: High priority target down for 5m
296 expr: absent(present_over_time(mailtest_check_last_usec{folder="/m/md/l/testignore",from="ian@iankelling.org"}[5m]))
301 summary: MAIL_HOST likely down for 5m
303 - alert: PrometheusConfigurationReloadFailure
304 expr: prometheus_config_last_reload_successful != 1
309 description: "Prometheus configuration reload error\n VALUE = {{ $value }}"
311 - alert: PrometheusTooManyRestarts
312 expr: changes(process_start_time_seconds{job=~"prometheus|pushgateway|alertmanager"}[30m]) > 10
317 description: "Prometheus has restarted more than ten times in the last 30 minutes. It might be crashlooping.\n VALUE = {{ $value }}"
319 - alert: PrometheusAlertmanagerJobMissing
320 expr: absent(up{job="alertmanager"})
325 description: "A Prometheus AlertManager job has disappeared\n VALUE = {{ $value }}"
327 - alert: PrometheusAlertmanagerConfigurationReloadFailure
328 expr: alertmanager_config_last_reload_successful != 1
333 description: "AlertManager configuration reload error\n VALUE = {{ $value }}"
335 - alert: PrometheusNotConnectedToAlertmanager
336 expr: prometheus_notifications_alertmanagers_discovered < 1
341 description: "Prometheus cannot connect the alertmanager\n VALUE = {{ $value }}"
343 - alert: PrometheusRuleEvaluationFailures
344 expr: increase(prometheus_rule_evaluation_failures_total[3m]) > 0
349 description: "Prometheus encountered {{ $value }} rule evaluation failures, leading to potentially ignored alerts.\n VALUE = {{ $value }}"
351 - alert: PrometheusTemplateTextExpansionFailures
352 expr: increase(prometheus_template_text_expansion_failures_total[3m]) > 0
357 description: "Prometheus encountered {{ $value }} template text expansion failures\n VALUE = {{ $value }}"
359 - alert: PrometheusRuleEvaluationSlow
360 expr: prometheus_rule_group_last_duration_seconds > prometheus_rule_group_interval_seconds
365 description: "Prometheus rule evaluation took more time than the scheduled interval. It indicates a slower storage backend access or too complex query.\n VALUE = {{ $value }}"
367 - alert: PrometheusNotificationsBacklog
368 expr: min_over_time(prometheus_notifications_queue_length[30m]) > 0
373 description: "The Prometheus notification queue has not been empty for 10 minutes\n VALUE = {{ $value }}"
375 - alert: PrometheusAlertmanagerNotificationFailing
376 expr: rate(alertmanager_notifications_failed_total[1m]) > 0
381 description: "Alertmanager is failing sending notifications\n VALUE = {{ $value }}"
383 # file_sd doesnt count as service discovery, so 0 is expected.
384 # - alert: PrometheusTargetEmpty
385 # expr: prometheus_sd_discovered_targets == 0
390 # description: "Prometheus has no target in service discovery\n VALUE = {{ $value }}"
392 - alert: PrometheusTargetScrapingSlow
393 expr: prometheus_target_interval_length_seconds{quantile="0.9"} > 90
398 description: "Prometheus is scraping exporters slowly\n VALUE = {{ $value }}"
400 - alert: PrometheusLargeScrape
401 expr: increase(prometheus_target_scrapes_exceeded_sample_limit_total[10m]) > 10
406 description: "Prometheus has many scrapes that exceed the sample limit\n VALUE = {{ $value }}"
408 - alert: PrometheusTargetScrapeDuplicate
409 expr: increase(prometheus_target_scrapes_sample_duplicate_timestamp_total[5m]) > 0
414 description: "Prometheus has many samples rejected due to duplicate timestamps but different values\n VALUE = {{ $value }}"
416 - alert: PrometheusTsdbCheckpointCreationFailures
417 expr: increase(prometheus_tsdb_checkpoint_creations_failed_total[1m]) > 0
422 description: "Prometheus encountered {{ $value }} checkpoint creation failures\n VALUE = {{ $value }}"
424 - alert: PrometheusTsdbCheckpointDeletionFailures
425 expr: increase(prometheus_tsdb_checkpoint_deletions_failed_total[1m]) > 0
430 description: "Prometheus encountered {{ $value }} checkpoint deletion failures\n VALUE = {{ $value }}"
432 - alert: PrometheusTsdbCompactionsFailed
433 expr: increase(prometheus_tsdb_compactions_failed_total[1m]) > 0
438 description: "Prometheus encountered {{ $value }} TSDB compactions failures\n VALUE = {{ $value }}"
440 - alert: PrometheusTsdbHeadTruncationsFailed
441 expr: increase(prometheus_tsdb_head_truncations_failed_total[1m]) > 0
446 description: "Prometheus encountered {{ $value }} TSDB head truncation failures\n VALUE = {{ $value }}"
448 - alert: PrometheusTsdbReloadFailures
449 expr: increase(prometheus_tsdb_reloads_failures_total[1m]) > 0
454 description: "Prometheus encountered {{ $value }} TSDB reload failures\n VALUE = {{ $value }}"
456 - alert: PrometheusTsdbWalCorruptions
457 expr: increase(prometheus_tsdb_wal_corruptions_total[1m]) > 0
462 description: "Prometheus encountered {{ $value }} TSDB WAL corruptions\n VALUE = {{ $value }}"
464 - alert: PrometheusTsdbWalTruncationsFailed
465 expr: increase(prometheus_tsdb_wal_truncations_failed_total[1m]) > 0
470 description: "Prometheus encountered {{ $value }} TSDB WAL truncation failures\n VALUE = {{ $value }}"