Logging - advise if CPU load same regardless of log export method HTTP(s) Syslog and Netflow logging

cancel
Showing results for 
Search instead for 
Did you mean: 

Logging - advise if CPU load same regardless of log export method HTTP(s) Syslog and Netflow logging

L2 Linker

Hello Experts,

 

I tried to find any information to assist with understanding if some log export protocols taxing CPU (Management and DP) more then others. Perhaps ones DP pass log events to MP it is for Management to package and ship the logs, therefore, as long as some rules has logging enabled, the DP load will be the same regardless of the protocol used.

1. Is there any information to help with estimates on additional CPU load for Syslog log destinations? What about HTTP log destinations?

2. Can I save some CPU using TCP vs UDP syslog? Any other fiddling? Obviously logging on session end only will generate 2x less log amount.

 

The platforms in question are 8xx and 30xx.

Regards Serg.

 

Some notes:

  • List of logging protocols from documentation - Use External Services for Monitoring
  • Point in time stats via "show running logging"
  • KB listing "platform limits" here - Panorama Sizing and Design Guide It is also referencing CLI tool - "To check the log rate of a single firewall, download the attached file named "Device.zip", unpack the zip file and reference the README.txt file for instructions. This package will query a single firewall over a specified period of time (you can choose how many samples) and give an average number of logs per second for that period. At minimum this script should be run for 24 consecutive hours on a business day."
1 ACCEPTED SOLUTION

Accepted Solutions

L7 Applicator

only logging at session end has a greater multiplier than 2, as 'session start' will log each step a session takes, which could be 3-4 steps as sessions go from app-id to app-id, especially with ssl decryption involved, so don't use 'log at session start' unless you're temporarily troubleshooting or _really_ need all the logs

 

all logging generated on the firewall is sent to the management plane log disk, only there additional log forwarding is performed by the varlogrcvr, so log forwarding, regardles of protocol, causes load on the MP, not on the DP

 

some logging will be optimized compared to other, panorama logging will have the best performance as there is queueing and some mechanisms in place to trickle logs when needed, on other protocols your mileage may vary depending on the overhead ( udp > tcp > http )

 

 

Tom Piens
Like my answer? check out my book! https://bit.ly/MasteringPAN

View solution in original post

2 REPLIES 2

L7 Applicator

only logging at session end has a greater multiplier than 2, as 'session start' will log each step a session takes, which could be 3-4 steps as sessions go from app-id to app-id, especially with ssl decryption involved, so don't use 'log at session start' unless you're temporarily troubleshooting or _really_ need all the logs

 

all logging generated on the firewall is sent to the management plane log disk, only there additional log forwarding is performed by the varlogrcvr, so log forwarding, regardles of protocol, causes load on the MP, not on the DP

 

some logging will be optimized compared to other, panorama logging will have the best performance as there is queueing and some mechanisms in place to trickle logs when needed, on other protocols your mileage may vary depending on the overhead ( udp > tcp > http )

 

 

Tom Piens
Like my answer? check out my book! https://bit.ly/MasteringPAN

View solution in original post

Sorry, with regards to "mileage may vary depending on the overhead ( udp > tcp > http )" - do you mean UDP takes most or less CPU cycles from MP?

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!