Session Logging Considerations
Understanding when sessions appear in traffic logs and when to enable session start logging helps you configure effective logging policies and troubleshoot issues.
| Where Can I Use This? | What Do I Need? |
|---|
- NGFW (Managed by Strata Cloud Manager)
- NGFW (Managed by PAN-OS or Panorama)
- Prisma Access (Managed by Panorama or Strata Cloud Manager)
|
|
When Sessions May Not Appear in Traffic Logs
Even with Log At Session End enabled, sessions may not appear in traffic logs in the
following situations:
- Very short-lived sessions - Sessions that complete too quickly may not
generate logs due to buffer flushing or logging thresholds. Enable Log At
Session Start to capture these sessions.
- Log forwarding issues - If you misconfigure the Log Forwarding Profile,
reach logging rate limits, or lose connectivity to the destination (Panorama,
syslog server), logs are silently dropped.
- Incomplete TCP sessions - TCP SYN packets that do not complete the
three-way handshake, or sessions that never transmit application data may not
reach the logging stage.
- Silent threat prevention drops - Threat prevention profiles that drop
traffic mid-session without logging enabled will not generate traffic logs (check
threat logs instead).
- Log storage issues - When the log disk fills or logging processes fail,
session logging may not occur even though sessions are established.
Differences Between Session Start and Session End Logging
Log At Session Start generates logs when the first application data packet is
transmitted (not when the TCP handshake completes). As App-ID identifies
applications during the session, multiple logs may be created for a single connection
as the application classification evolves (for example: ssl → facebook-base →
facebook-messaging). This creates additional log entries and increases management
plane CPU load.
Log At Session End generates a single log entry when the session completes,
showing the final application App-ID identified and the ultimate policy rule that
applied after App-ID completed. This consumes fewer resources and provides more
accurate application identification.
When to Enable Log At Session Start
Enable Log At Session Start in the following situations:
- Troubleshooting policy behavior - To see both the initial policy match
(before App-ID) and the final policy match
- Capturing very short-lived sessions - Sessions that may not generate end
logs due to their brief duration
- Monitoring long-lived sessions - GRE tunnels and OT/ICS connections that
you want to see immediately in the ACC rather than waiting for the session to
end
- Debugging application identification - To see how the application
classification evolves over time
For production environments, Log At Session End remains the recommended setting due to
lower resource consumption and more accurate application identification.
