graylog-deploy/alerts/alert7_accelppp_repeated_error_warn.json
byrsapty 609ac74574 Fix two bugs found live: pipeline/rule update gap, and alert7's over-broad query
- step_pipeline_rules() and step_pipelines() only ever created new
  rules/pipelines by title, never updated existing ones whose content
  changed under the same title. Confirmed live this session: 5 new rules
  were added to rules/*.json and created fine in Graylog, but "Servers
  Parsing"'s stage list was never updated to actually call them, since
  the pipeline already existed. Both functions now compare by 'source'
  content and PUT-update if it differs, matching the pattern already used
  elsewhere (e.g. step_inputs()'s timezone self-heal).
- alert7's query (vendor:accel-ppp) was too broad: it also matches
  routine traffic tagged only by the generic accelppp_interface_tag
  fallback rule, which sets vendor but never event_type - producing false
  "(Empty Value)" group_by matches on ordinary volume. Confirmed live.
  Fixed to vendor:accel-ppp AND event_type:* - severity_tag was
  considered instead but rejected, since accelppp_router_address_error
  (the rule that inspired this alert) never set it either.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-23 16:28:50 +03:00

21 lines
1.7 KiB
JSON

{
"title": "WARNING: repeated accel-ppp error/warning from one server",
"description": "The same category of accel-ppp error/warning is repeating from one server - a single occurrence can be transient (a RADIUS retry, a one-off MAC change), but sustained repetition usually means a stuck session or an ongoing condition. Confirmed live on 2026-07-23 against a real 1GB accel-ppp log: 'can't determine router address' repeated 2,746 times over ~4 hours for two specific subscriber interfaces before self-resolving, with no alert firing at the time since this alert didn't exist yet. Threshold (>5 in 5 minutes) is set low enough to have caught that incident within its first cycle, while still tolerating an occasional single warning. Query requires event_type to exist (not just vendor:accel-ppp) - confirmed live that vendor alone also matches routine traffic tagged only by the generic accelppp_interface_tag fallback (which never sets event_type), producing false '(Empty Value)' group_by matches otherwise.",
"priority": 2,
"alert": true,
"config": {
"type": "aggregation-v1",
"query": "vendor:accel-ppp AND event_type:*",
"streams": ["__SERVERS_STREAM_ID__"],
"group_by": ["gl2_remote_ip", "event_type"],
"series": [{"type": "count", "id": "count-", "field": null}],
"conditions": {"expression": {"expr": ">", "left": {"expr": "number-ref", "ref": "count-"}, "right": {"expr": "number", "value": 5.0}}},
"search_within_ms": 300000,
"execute_every_ms": 300000,
"event_limit": 50
},
"field_spec": {},
"key_spec": [],
"notification_settings": {"grace_period_ms": 900000, "backlog_size": 5},
"notifications": [{"notification_id": "__DISCORD_NOTIFICATION_ID__"}]
}