bug: processed SNMP traps persist subject name instead of trap message #3130

New issue

Closed

opened 2026-04-06 06:08:35 +00:00 by mfreeman451 · 0 comments

mfreeman451 commented

2026-04-06 06:08:35 +00:00

Owner

Summary

SNMP trap log records in Observability are persisting the subject name logs.snmp.processed as the message body instead of the trap text extracted from the trap varbinds.

Evidence

Observed behavior

SNMP trap records show a generic subject fallback instead of the actual trap message.
The log detail view therefore surfaces the placeholder value rather than the first meaningful varbind text.

Expected behavior

Processed SNMP traps should persist a normalized body that contains the trap message text derived from the trap payload.
If the incoming trap payload omits body, the normalization path should still derive one from the first meaningful varbind instead of falling back to the NATS subject.

Likely root cause

rust/trapd publishes SNMP traps without a top-level body field.
The seeded snmp_severity Zen template only rewrites body when body == 'logs.snmp.processed' or body == ''.
When body is missing/null during Zen evaluation, the expression leaves it unset.
The DB event-writer then falls back to the subject string logs.snmp.processed.

Suggested scope

Update SNMP trap normalization so missing/null body is treated the same as the existing empty/sentinel fallback path.
Add regression coverage for the missing-body case in the SNMP rule/template tests and downstream log parsing path.

## Summary SNMP trap log records in Observability are persisting the subject name `logs.snmp.processed` as the message body instead of the trap text extracted from the trap varbinds. ## Evidence - Demo query: https://demo.serviceradar.cloud/observability?q=in%3Alogs+time%3Alast_7d+sort%3Atimestamp%3Adesc+limit%3A20+source%3Asnmp&limit=20&tab=logs - Example log detail: https://demo.serviceradar.cloud/logs/e82773c6-7938-422e-b344-59a688dba2f8 ## Observed behavior - SNMP trap records show a generic subject fallback instead of the actual trap message. - The log detail view therefore surfaces the placeholder value rather than the first meaningful varbind text. ## Expected behavior - Processed SNMP traps should persist a normalized `body` that contains the trap message text derived from the trap payload. - If the incoming trap payload omits `body`, the normalization path should still derive one from the first meaningful varbind instead of falling back to the NATS subject. ## Likely root cause - `rust/trapd` publishes SNMP traps without a top-level `body` field. - The seeded `snmp_severity` Zen template only rewrites `body` when `body == 'logs.snmp.processed'` or `body == ''`. - When `body` is missing/null during Zen evaluation, the expression leaves it unset. - The DB event-writer then falls back to the subject string `logs.snmp.processed`. ## Suggested scope - Update SNMP trap normalization so missing/null `body` is treated the same as the existing empty/sentinel fallback path. - Add regression coverage for the missing-body case in the SNMP rule/template tests and downstream log parsing path.