Sessions · obserae

A session is a readable network conversation built from one or more NetFlow/IPFIX records.

Raw flow records are useful when you need packet-counter detail, but analysts usually ask a simpler question: who talked to whom, on which service, and did that traffic match what we expected? The Sessions page is built for that.

Example:

client 10.0.0.42:53124  ->  server 10.0.10.12:443  TCP
duration 38s, 182 KB client->server, 4.1 MB server->client
matched rule: web-to-api

What A Session Represents

One TCP connection or UDP exchange can generate many flow records on an exporter. obserae groups those records into one session so you can investigate the conversation instead of every export fragment.

Each session has:

Field	What it helps with
Endpoints	The two IPs and ports involved.
Protocol	TCP, UDP, ICMP or another IP protocol.
Directional counters	Bytes and packets in each direction.
State	Whether the conversation is still open, half-open or closed.
Server side	Which endpoint looked like the service/listener.
Matched rules	Which Flow Matrix rules accounted for the traffic.
Exporter	Which observed device reported the flow.

The server side is inferred from the strongest available evidence: TCP behavior when available, declared services in Cartography, known ports and traffic shape. The row includes the method/confidence so you can judge how much to trust the inference.

Session States

State	Meaning
active	Traffic is still being observed or has not timed out yet.
half_open	A TCP opening attempt was seen, but no reply was observed yet. Useful for scans and drops.
closed	The session is complete. Counters, server inference and rule matches are stable.

Most investigation and detection work should focus on closed sessions. Active sessions are useful for “what is happening right now”; closed sessions are best for rules, alerts and post-event review.

Long-running conversations become visible before they end, so a persistent SSH, database or backup connection does not disappear from the UI for hours.

Using The Sessions Page

Open Sessions from the Analysis group. Start with a time window, then narrow with filters:

source or destination entity;
IP, host, network, group or cartography reference;
port/protocol;
state;
exporter;
Unmatched only.

Click a row to open the drawer. The drawer shows counters, timing, inferred server side, matching rules and raw flow records behind the session.

Unmatched Only

The Unmatched only filter is one of the highest-value views in obserae. It shows closed sessions that no Flow Matrix rule accounted for.

Use it after importing or editing the Flow Matrix:

Look at unmatched sessions over the last hour or day.
Decide whether each pattern is expected or suspicious.
Add legitimate traffic to the Flow Matrix.
Investigate or alert on what remains.

This turns the Flow Matrix into a living baseline instead of a static diagram.

Common Queries

Recent sessions touching a known host or group:

FROM sessions
| LAST 3600
| WHERE ip == "databases"
| KEEP ip_a, ip_b, server_ip, server_port, ab_bytes, ba_bytes, opened_at
| SORT opened_at DESC

Internal hosts talking to the public internet:

FROM sessions
| LAST 3600
| WHERE ip == "internal4" AND server_ip == "internet4"
| KEEP ip_a, ip_b, server_ip, server_port, ab_bytes
| SORT ab_bytes DESC

Likely TCP scans or blocked attempts:

FROM sessions
| LAST 3600
| WHERE state == "closed" AND close_reason == "no_reply" AND protocol == TCP
| KEEP ip_a, ip_b, server_ip, server_port, opened_at
| SORT opened_at DESC

Sessions not covered by the Flow Matrix:

FROM session_matches | LAST 3600
> FROM sessions
  | LAST 3600
  | WHERE state == "closed"
  | PIVOT NOT session_id == session_id
  | KEEP ip_a, ip_b, server_ip, server_port, role_method

For more examples, see the NFQL Cookbook.

Multiple Exporters Seeing The Same Conversation

If both a switch and a firewall export the same conversation, obserae keeps the per-exporter sessions separate so byte and packet counts are not accidentally double-counted.

When you want a sampler-independent view, query sessions_consolidated. It groups matching per-exporter sessions into one conversation and exposes client/server-oriented columns:

FROM sessions_consolidated
| LAST 3600
| WHERE sampler_count > 1
| KEEP client_ip, server_ip, server_port, sampler_count, coherence_pct

Use consolidated sessions for overview and correlation. Use regular sessions when you need to know which exporter saw what.

Tuning

The defaults are intended to work for most installs. Tune sessions only when you have a visible reason:

Setting	Raise it when…	Lower it when…
`sessions.hard_timeout`	Long connections appear too early and clutter “current” views.	Long connections stay hidden for too long.
`sessions.grace`	Exporters deliver records late or out of order.	You need lower visibility delay and exporters are well behaved.
`sessions.max_open_ksessions`	Open sessions hit the cap during normal traffic.	The host is small and normal concurrency is low.
`sessions.idle.*`	Normal sessions are closing too early.	Scan or no-reply detection should surface faster.

If the Cockpit or top bar shows session pressure, check whether it is a real traffic spike/scan before simply raising the cap.

sessions:
  hard_timeout: 15m
  grace: 30s
  max_open_ksessions: 500
  idle:
    tcp_established: 60s
    tcp_half_open: 5s
    udp: 30s
    icmp: 10s
    other: 60s

After A Restart

Closed sessions already written to history remain available. Sessions that were still open at the exact restart moment are rebuilt from new incoming flow records. For a 24/7 service this short transition is expected.