Syslog Priority Translation

In the ever-growing world of the internet, management and consolidation become increasingly important. Whether it’s content management, resource management, traffic management or some other form of managing resources for ease of use and efficiency, they all become paramount as applications scale up and spread across more servers, datacenters and continents. Consolidation of Syslog resources is one of the more widely used practices in this genre.

Syslog and Syslog-ng make it easy to dictate where your Syslog information should be sent. Let’s face it, no one wants to log into 400 web servers to see what got sent to Syslog. So it’s a common practice to forward this information back to a set of central Syslog systems for processing and monitoring. Well that’s great, assuming that all of your devices send things with the facility and severity you’re expecting. But what if the resultant priority isn’t something you’re configured to handle on the back-end, or merely isn’t descriptive enough for your tastes? How do you change the priority of the Syslog message being sent from a router or even your LTM so that your back-end Syslog setup can interpret it properly?

With iRules, of course.

Below is an example iRule that allows you to define a class of priority numbers. The first number in each pair is the priority that the device(s) in question are sending. The second number is what you want that priority to be changed to. For instance, in the first line of the class below, any Syslog messages with a priorty of 124 would be changed to a priority of 200. Note that these numbers are purely for demonstration purposes.

Class

 
class DATA_GROUP { 
  "124 200" 
  "132 240" 
  "208 120" 
} 

iRule

 
when CLIENT_DATA { 
# First, find the priority portion of the request 
  set pri [regexp -inline {<\d+>} [UDP::payload] ] 
# Next, check the first Data Group to see if this priority needs to be altered 
  if { [matchclass $::DATA_GROUP starts_with $pri] } { 
# If it does need to be altered, find what it needs to be altered to 
    set replace [findclass $pri $::DATA_GROUP " "] 
# Perform the substitution and save the result in the newPayload variable 
    regsub $pri [UDP::payload] $replace newPayload 
# Replace the original payload with the newly modified payload 
    UDP::payload replace 0 [UDP::payload length] $newPayload 
  } 
} 

All that’s left is to configure whatever devices are sending Syslog messages with errant priorities to a Virtual Server configured on an LTM device with the iRule applied, then define the proper values for the desired before and after priority numbers in the class on the same LTM.