whats the best way to log a "trace level" info in prod in apigee

[naggc]

Hi

I am struggling with a requirement to understand why transactions failed at Apigee level for a given proxy. The trace tool is awesome to help understand where and why things are error-ing, but its only in real time. I have had developers come by with issues where things weren't working and I had to sit and trace rather than just review logs and see what might have gone wrong.

Similarly, now in prod, if bunch of transactions fail, its good to know what error code, but its not helpful not knowing which rule it failed on. '

Any solutions to trace errors post realtime?

PS- we look at the log message policy but it will just build XML and then will need to be read in a log tool behind firewall, and isnt the prefered solution.

[DChiesa]

Yes - the Edge Trace facility is useful for interactive usage. When you want to see something, enable a trace session, run some transactions, view the results.

This is obviously not useful for a retroactive or ad-hoc examination of traffic. For that you need a running log. Something that is always collecting log records, for every transaction, because you never know when you want to view the records.

The MessageLogging policy within Edge is useful for that purpose. It can send log data to a filesystem file, if you are managing the Apigee Edge infrastructure. Or, it can send log data to a syslog endpoint, like a syslogd, or a loggly or splunk endpoint. In this case, all the log records for all transactions flow to that endpoint. These options would allow you to see records for every request.

I don't know what you mean by "it will just build XML". The MessageLogging policy does not require that log records are spooled in XML format. Maybe I misunderstood.

Also, I don't know what you mean by "will need to be read in a log tool". There will need to be a log tool of course. The volume of log records will be very high, in general, so you will need some kind of tool to be able to filter, sort and search the records.

You can also use API-accessible log services, like Google's Stackdriver or Sumologic, via a ServiceCallout policy that uses the REST API for the service. Set the policy to be asynchronous, of course.

[naggc]

Hi Dino

Thanks for response. You are correct about the MessageLogging Policy and the fact that we need a log reader. I was under impression it will be in XML that's what I mentioned. For us 3rd party tools that you mentioned may not be feasible and might have to resort to on prim solutions hence firewall issues.

Surely I can connect it to Splunk or some other tool, my concern (and i haven't tried it yet), is that the log reader can not put a pretty picture like a trace to see which step and what metadata is being passed and where the problem is.

I am looking for an ability like "trace" to read ad-hock traffic or errors. Like we have used another Gateway product which can show you last X hrs of traffic and you can find out the errors and drill down to why it happened and which policy failed. We don't have to write separate logs in each policy/proxy...its part of the system.

Not sure if there is some dashboard we can get access to or something we can connect to other than having to write that to our splunk or something.