Testing And Verification

LogZilla documentation for Testing And Verification

Testing and verification

Testing ensures transformation logic behaves as expected before and after rollout. The following practices apply to rewrite rules, Lua rules, and Apps that include transformation logic.

Prepare representative inputs

  • Use device-specific sources when available to generate realistic traffic.
  • For custom pipelines or ad hoc tests, send events via the HTTP Event Receiver.
    • Structured JSON enables explicit control over host, program, and fields.
    • Unstructured JSON under /incoming/raw is suitable for quick experiments that rely on rules to extract values.

Manage rules during tests

  • Keep test changes in a distinct rule set or app build.
  • Validate syntax and structure prior to enabling.
  • Reload rules after updates and monitor for errors.
bash
# Validate a rule file before enabling
logzilla rules validate /path/to/rule.yaml

# Test a rule against sample data (where applicable)
logzilla rules test --path /path/to/rule.yaml

# Enable or disable rules and reload after changes
logzilla rules enable --name "Test Rule"
logzilla rules disable --name "Test Rule"
logzilla rules reload

# Inspect recent runtime errors for rules
logzilla rules errors

Observe parser health and field outcomes

  • Confirm that the parser processes events without errors or stalls.
  • Inspect field values and tag distributions to verify normalization and enrichment.
bash
# Parser performance and health overview
logzilla events parser-stats

# Review values seen for fields and tags
logzilla events values --scope fields --limit 50
logzilla events values --scope tags --limit 50

# Review field and tag cardinality (optional)
logzilla events cardinality --scope all

Verify in the UI

  • Run focused searches to confirm expected tags and normalized fields are present.
  • Check pre-built or custom dashboards for visual confirmation and KPI impact.
  • Confirm triggers that depend on newly enriched fields behave as intended.

Use traffic capture and replay as needed

  • Capture short windows of traffic to reproduce an issue or verify a fix consistently.
bash
# Start a short capture and store decoded events
logzilla sniffer start --filename sniff-{t}.out --time 60 --live

# Stop capture or check status
logzilla sniffer status
logzilla sniffer stop

# Replay captured traffic for regression testing
logzilla sniffer replay sniff-2025-01-01.out

Rollout and fallback

  • Stage changes in a lower environment when possible.
  • Monitor parser metrics and rule errors immediately after enabling.
  • Maintain the ability to disable a problematic rule quickly if an unexpected outcome is observed.

Common pitfalls to avoid

  • Overly broad matches that unintentionally rewrite many events.
  • High-cardinality tags created by free-form data (for example, unique identifiers or full message fragments).
  • Inconsistent field names that reduce dashboard and alert reuse.
  • Silent failures due to unvalidated configuration changes.

Related reading

Testing And Verification | LogZilla Documentation