EVE JSON and flow correlation

Read event types first

EVE writes structured records such as alert, flow, HTTP, DNS, TLS and stats when those loggers are enabled. They answer different questions. An alert records a detection; a flow summarizes traffic; protocol events describe decoded transactions. Do not count every line in eve.json as a security incident.

Select the needed loggers

outputs:
  - eve-log:
      enabled: yes
      filetype: regular
      filename: eve.json
      community-id: true
      types:
        - alert
        - http
        - flow
        - stats

Merge this example into the existing outputs list of the complete YAML. Do not replace unrelated required outputs accidentally. Community ID can aid cross-tool correlation when compatible tools use the same settings; flow_id remains an engine-specific correlation value. Handle HTTP metadata as sensitive operational data.

Select one detection

jq -c 'select(.event_type=="alert") | {timestamp,flow_id,src_ip,dest_ip,sid:.alert.signature_id}' lab-out/eve.json
{"timestamp":"2026-10-18T10:00:00.000000+0000","flow_id":42,"src_ip":"10.10.10.20","dest_ip":"192.0.2.80","sid":1000001}

This constructed record identifies when, where and which signature matched. Preserve sensor identity and time context; the number 42 is not a universally unique incident ID.

Follow the conversation

jq -c 'select(.flow_id==42) | {event_type,flow_id,http,flow}' lab-out/eve.json
{"event_type":"http","flow_id":42,"http":{"url":"/routecraft-check","http_method":"GET"},"flow":null}
{"event_type":"flow","flow_id":42,"http":null,"flow":{"pkts_toserver":5,"pkts_toclient":4}}

Multiple records can share one flow. HTTP transaction IDs distinguish requests within a reused connection when present. A flow summary may arrive later than the alert; do not assume chronological file proximity is a complete join.

Keep detection and final action separate

The alert action describes that detection. The engine verdict, when enabled, can show a final drop even if another individual alert has action allowed. Correlate drop events, counters and endpoint evidence for prevention. A flow can generate multiple alerts; aggregate carefully so repeated records do not become fictitious separate attacks.

For investigation, retain the original events, sensor name, rule revision, clock synchronization and relevant capture references. Query only required fields for routine dashboards, apply retention controls, and avoid treating missing optional fields as zero or as proof that nothing happened.