[vayarajesh]

If you are micro-services based architecture, then it is very important to track and log a request through the multi-service calls and relate the logs.

Syslog with a common UUID set at the entry point (typically at proxy or load balancer level e.g. nginx) of the request and then logger will log the UUID as the part of UUID parameter of Syslog.

Syslog then can be parsed and also form JSON objects for the poeple in Ops and send it to a service. Basically you could have one more internal micro-service to handle logs from Syslog and then parse it and send it wherever Ops would need.

[Xylakant]

I would avoid syslog. The protocol does not handle multiline messages (stack traces) etc. gracefully since it's purely line-based. It's also very hard to encode application specific fields into syslog. However, it's a good idea to pick (or design) something based on which fields traditional log daemons use - either based on syslog, or based on systemds journal. (which, btw. does not suffer from any multiline issues)

[bruth]

Along those lines (and possibly what the OP was looking for as well), what are the conventions around key names including namespacing? Or what are the common environment variables you capture for a given service, i.e. the boilerplate stuff.

[vayarajesh]

Syslog has very detail key name sand namespacing (http://www.iana.org/assignments/syslog-parameters/syslog-par...) which can be filled in with application related data and this can be then parsed by any PaaS logging platform / OSS logging tool

I think syslog is a widely accepted log format and most of the tools which revolve around log metrics do support syslog and more so with parsing tools

[Too]

+1, Request tracking across micro services is a must. You will be crying floods at the worst imaginable time if you do not have this. Think of it like a stack-trace for each request.

[paulddraper]

For richer view of the call tree, consider full distributed tracing, like Zipkin.