MessageLogging policy: Using multiple MessageLogging for Cloud Logging in an API proxy

[katharineyau]

We came across this Apigee docs:

https://cloud.google.com/apigee/docs/api-platform/antipatterns/messagelogging-multiple-times

which make us wonder if our current implementation of Logging framework which uses multiple MessageLogging policies in

1. Proxy Request (PreFlow)
2. Target Request (PostFlow)
3. Target Response (PreFlow)
4. Proxy Response (PostClientFlow)

to capture request/response data at different stage of the proxy flow for sending log to Cloud Logging would be an antipattern it described.

However, we want to clarify:

1) if this antipattern applies to both syslog and CloudLogging as the page only mentioned syslog but not CloudLogging.

2) does the MessageLogging policy use the same mechanism i.e. make connection to log server using TLS over TCP? and have the same implication to resources usage and performance?

[dchiesa1]

Yes.

I guess we should update the documentation to also mention Cloud Logging.

---

EDIT: We updated the documentation for this anti-pattern to also mention Cloud logging.

[NikhilAnand_whp]

@dchiesa1 - Apologies to bury a question on a old thread, but this seemed the exact problem i have.

For instance, in an earlier implementation on APIGEE X, the old team habitually employed this anti-pattern and logged messages from everywhere. Due diligence, have been done to make sure it works and does intended job in every case. 

As a new member of team, I want to get rid of this anti pattern and log only as post-client flow, but I am struggling to quantify exactly what we lose with this anti-pattern.

Development effort isn't an issue, given that a template proxy with requisite policies is readily available for replication.

Consumers for the proxy are OK, with the couple of seconds being added to proxy execution time, with the added logging.

Kindly assist in getting rid of this anti-pattern (How much and what do we lose with this anti pattern ?). 

[dchiesa1]

---

@NikhilAnand_whp wrote:

Apologies to bury a question on a old thread,

---

Ha, so you've read my responses before about this sort of thing!

No problem. you're so nice about it, I'll answer here.

---

@NikhilAnand_whp wrote:

I am struggling to quantify exactly what we lose with this anti-pattern.

---

i will give you the excerpt from the anti-pattern documentation. 

I've seen customers dismayed at how slow their proxies are - they show me the debugsession files, proving that a single API request is taking over 180ms just within Apigee. That's waaaaay too much. When  I looked at their proxy definition, I saw logging messages scattered all over the proxy.  Each one took 20-30ms, and all of them were happening while the caller was waiting for the response. 

When they consolidated to a single log policy , in postclient flow, the time consumed in Apigee was reduced to under 15ms.  That made for better scalability, better efficiency, and better responsiveness. 

I understand it's expedient to log from anywhere. If you don't actually care about scale and response time ("don't care"  means, if it's ok for your proxy to "cost" 100ms, 150ms or more, on top of whatever latency is added by the target system, which itself could be another 100ms or more), then no problem,....  log from anywhere and everywhere. If you want efficiency, you should consolidate your log messages. 

Good luck.