The landscape for developing applications has continued to evolve, as technology matures into providing dedicated segments focused on handling aspects of a system’s required processing. The notion of an all-encompassing monolith continues to become less of a reality as a result of this progression.
With the popularity of microservices, a dedicated application program interface (API) is built to handle the heavy-lifting needs of a focused set of functionalities. These APIs often utilize integrations which can include an enterprise service bus (ESB), file-system based resources, cloud solutions, or even legacy systems.
The concept of “* as code” allows a majority of these underlying services to rely on a git-based repository and a build mechanism to transform the source code into functional systems.
This is the reality of a modern application design. When properly architected, these elements can work together quite well to present a fully-functional application. However, when an unexpected issue occurs somewhere amidst these components, the ability to find the root cause can be difficult.
Each of these aspects has the ability to log events as they participate in some form of application service delivery. However, the format and structure of these logs vary from one system to the next. This is where the concept of centralized log management can provide a great deal of assistance.
In the diagram below, a centralized log management solution can ingest the log events from all components of an application in order to provide a single-source to review and analyze.
When the logs are combined and organized properly, the production support engineer assigned to the situation can easily walk through the event without having to toggle between log files contained within disparate and proprietary systems.