Application Programming Interface (API)
If your company has moved to a microservice architecture (or has always been there), once you have more than a few services up and running you have probably determined that is is beneficial to have a template to define a common HTTP interface (API) for your services. With use of this standards template there is no ambiguity in the various service intercommunications. Following JSON hypermedia standards such as HAL, Collection+JSON, and SIREN can help a great deal in this regard.
This improves the transparency, and maintainability of the overall system since all services are speaking the same language. This is all great, but don't forget the other interface a well crafted microservice should have.
that other critical interface
This is a required interface that all your microservices should support and as with the API should be imbued with consistency and standards. As described here, this interface has two primary components; Error Logging and Metrics Logging. They are both manifest via literal log statements, but they represent differing concerns of monitoring.
This includes exception conditions logged by the application. Depending on the severity, it may be a simple message string, or a full stack trace. Regardless, the development team should work to ensure consistency as to how these statements are constructed and define the minimum levels of information required for these statements. Once these standards are decided, they can be enforced via an adaption class sitting atop your base logging library thus defining the interface and all error log statements.
Where Error Logging is primarily there to assist in troubleshooting discrete exceptional application events, Metrics logging is concerned with measuring the overall health and performance of a system on an ongoing basis.
Typical metrics are system metrics such as, CPU, RAM, disk, network IO and application metrics such as response times, processing times, lifecycle events (e.g. 'password-reset-complete', 'customer-login', etc).
As with Error Logging the development team should define the standards that are most appropriate for them and then build shared libraries in order to codify those standards.
I often see this aspect of logging overlooked or not regarded as being that valuable. I would argue this type of logging is required to improve the transparency of the overall system. This is more critical with distributed microservices versus a single monolithic service, since with that latter, when there is trouble, you at least know what service to blame and where to start looking. The worst thing that can happen when moving to a microservice strategy is to go from one opaque, difficult to manage and troubleshoot service, to many small opaque, difficult to manage and troubleshoot services.
Overall Logging Concerns
There are some overall logging concerns with both Error Logging and Metrics Logging that should be called out. These include:
- Consistent log format, be it a plain text derivative (common log format, Apache flavor, etc), or a data defined format such as JSON. With a consistent log format, the processing and analysis of said logs is vastly simplified.
- A censoring policy to protect sensitive data.
- Consistent use of correlation identifiers in order to track request through and between services.
This was just a high level overview of the subject. I leave the details of implementation up to the reader since every team and environment is different so your team will be best to determine what works best for them. I would caution against rolling your own solution for much of this though. There are great existing tools out there (ELK stack, AWS logging and metrics, Loggly) which you should give serious review before writing something custom. The goal of this article is to simply call out: Don't forget to standardize your microservice monitoring interface along with its API.