Centralized Logging
Most if not all modern systems have some way to track or log things that occur in the system from things as simple as a login to all the things that lead up to a kernel panic or application failure. The challenge with log analysis is the number of systems that organizations now depend upon to run their business. With the adoption of containers, hybrid cloud implementations, 3rd party APIs dependencies, and whatever other complexity each organization may have, log analysis has become a daunting task.
What is a log?
A log is simply a timestamp, most likely a severity, and a message stored in a file on a system. This may be over simplifying things as some systems may add more fields to add context. For instance, an application may add an ID so that the log can be referenced from an application trace; for security proposes the originating IP Address where an authentication request came from might be logged. But in the end a log usually looks something like this:
xx/xx/xxxx 00:00:00 – sev 3
The Challenge
Each hardware and software vendor logs in different ways (and sometimes there are difference between their own products) and puts there logs in different areas of a file system. This can add a lot of manual effort before any log analysis can be accomplished. This causes the analysis to take much longer than an organization may want or need. If a system or application is no longer running or usable this could cause a great risk to a business not only because they cannot provide service their clients but there is also the chance for reputational impact to occur.
Compounding the challenge of finding and then analyzing a log is the number of afore mentioned systems an organization must use to run their business. This causes the difficulty of resolving an issue to increase. An issue that could be solved in an hour or less may cause an outage of eight hours or more because technicians must take time to figure out which haystack they need to search to resolve the issue.
The Resolution – Centralized Logging
Syslog has been around for a while and is a way for most infrastructure devices to create a common format within their systems. A Syslog Server was a way to centralize the logs from infrastructure devices to avoid the effort of logging into to each device, searching for a log file, and then analyze the logs. But as technology is more than just infrastructure (i.e. servers, storage, database and network) there is a need to get any logs from all technologies into a central repository in a format that can be queried easily. There are many vendors who have focused on this challenge. Each do things in different ways to address their client’s requirements.
Regardless of vendor, each solution is trying to accomplish the following tasks:
- Exporting logs (from systems and/or applications)
- Parsing logs into a common and/or expected format
- Ingesting logs (either on premise or in the cloud)
- Storing logs
- Ensuring security of logs
These tasks do not necessarily need to be done in order and some vendors tout their approach to either be more cost effective or to ensure all logs are stored or both. In the end the goal is to set up all the systems to export the logs to something so that they can be queried easily by either people or machines. For example, Artificial Intelligence may help look for the fault or trends to help an organization become more proactive. The holy grail in this situation is to use technology to automatically sense indicators before a fault and to automatically remediate the issue so that revenue risk is mitigated.
Evolving Solutions helps clients understand these challenges and plan a path forward to integrate centralized logging into a greater observability strategy. As more organizations leverage technology to drive their business and innovation, understanding what is happening in all the systems involved is critical for informed business decisions. Through Evolving Solutions’ Enterprise Monitoring & Analytics approach, we give structure that enables modernization journeys.
