What is the best approach to log faults to syslog? We want to log some of the faults that occur when using some of the OAuth and other built-in policies and I cant seem to find a easy way to do this with the Message Logging policy. We are using Loggly and I am pretty sure I can create a JS policy to do a HTTP POST to Loggly but it seems likes there should an easier way to log a fault to syslog and have the proxy handle this rest.
Any help is appreciated.
The documentation for the Message Logging Policy (http://apigee.com/docs/api-services/reference/message-logging-policy) shows an example of how to log a message to syslog/Loggly. Is there any additional information needed in order to do the same for your implementation?
Hi!
I need also help!!! how do you continue to logg if fault raise activity have been raised? Im using message logging policy as soon as i hit a raise fault to true the logging stops there! Anyone out there who knows a solution to this???
I have tried to add a Messaging Log policy to the fault rules of flow step and when I add this fault step I get the wonderful non-descript error message:
Error while Uploading file for API EdCloud. Gateway error message not available
I am not sure why this wouldn’t work.
I have a support ticket out to Apigee that was submitted on Oct 8 and still have not heard back from them on this topic. Also pinged them on about the ticket on Oct 13 as well and still no answer. (Poor service for a paying enterprise account customer). If I ever hear back I will post their response.
im not sure this will help much, but if any fault is raised for a policy which has the “continueOnError=false” property, then message exits the normal flow and either enters your defined fault flow or it exits completely and returns an error to the end-user/client. to continue message logging you could do a few things depending on your situation:
set continueOnError=true for the policy which is throwing the fault (make sure to implement adequate error-handling afterwards though, otherwise you could let bad things happen
put a message logging policy in a fault flow such that when the fault is raised, the message logging policy is actuated
if your message logging policy is the policy that is raising the fault, then that sounds like an error is occurring within the message logging itself. you /could/ try to set continueOnError=true, but you might want to use the trace tool and see what is happening to that policy
