Is there any way of specifying the severity of message logged through the message logging policy to a syslog provider? This will allow us to identify information messages from errors and critical events.

[anilsr]

Dear @Sunin Shah , Great Question, Welcome to Apigee Community 🙂

[anilsr]

@Sunin Shah , Are you using any third party log service providers with message logging policy?

[sunin_shah]

@Anil Sagar Thanks for the warm welcome. Yes I am using loggly for now. Eventually the plan is to use syslog with a setup that will help us deal with critical events in a better manner.

[anilsr]

@Sunin Shah

Loggly only accepts syslog events with a RFC5424 compliant header. You can able to pass severity levels using Priority value contained in angle brackets.

For Example, <34>1 2003-10-11T22:14:15.003Z server1.com sudo - - [8bf8cc10-4140-4c3e-a2b4-e6f5324f1aea@41058]

In Above syslog header, 34 is the priority value. It's calculated using table mentioned here.

 Numerical         Severity
             Code

              0       Emergency: system is unusable
              1       Alert: action must be taken immediately
              2       Critical: critical conditions
              3       Error: error conditions
              4       Warning: warning conditions
              5       Notice: normal but significant condition
              6       Informational: informational messages
              7       Debug: debug-level messages

Earlier, We have seen issues with message logging policy & loggly. For Example, Check post here.

Instead of message log policy, you can use service callout policy and make an API call to loggly. Find example with CURL.

curl -H "content-type:text/plain" -d "<34>1 2015-16-08T10:14:15.003Z - - - - [xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx@xxxxx] Hello World!" http://logs-01.loggly.com/inputs/xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx/tag/http/ 

Hope it helps..

[sunin_shah]

Thanks @Anil Sagar. I think the issue here is in the message logging policy making an assumption that all the logging is for informational purpose only. Ideally, we should not have to drop out into a service callout policy to make use of a standard feature. At the moment though it looks like there isn't a clean way of doing this except by dropping out into custom code - so on that basis your answer is accepted.

[sunin_shah]

A side effect of dropping out into service callout policy is that you lose the asynchronous nature of the message logging policy and this will have an impact on performance where the usage of your API is high. What is the best way to overcome this?

[sunin_shah]

Another reason why I don't want to use a service callout policy is because I will not be able to do this in postclient flow. I believe this is something that needs to be fixed in the message logging policy implementation.