Last updated at Mon, 30 Oct 2017 17:58:16 GMT
The complexity of companies’ software solutions are increasing, with developers having less and less insight into all the corners of an application.
Years ago, when I was initially developing (now I’m talking 20 years ago here), I remember how a lot of business-facing or customer-facing applications were built on a rather simple stack. Often, applications were built on an application server (such as Tomcat, ColdFusion or Microsoft’s ASP server) with a SQL database behind this and utilized web browsers as the clients. This meant that, when there was an issue within an application, it was usually quite easy to identify the issue.
Things have changed a lot…even simple applications these days utilize a raft of tools, open-source libraries and frameworks that aid in rapid building. The disadvantage of this high velocity development, though, is the loss of visibility into what is actually happening behind the scenes. How many times (assuming you’re a developer) have you come across a problem that you do not believe to be directly within your code, but believe to be based in the code of one of the tools that you are using? How can you be sure?
I came across an article recently from another log management software provider where they said, “find the issue before they reach your customers’ clients.” This, to me, seems ludicrous as problems can appear anywhere in your stack and providing a solution that only focuses on the back-end systems shows a shortsightedness that will impact customers. You need to be able to track and catch errors anywhere in your stack.
In order to be confident in the ongoing quality of an application that you deliver you need to be sure that you can do two simple things:
• Catch errors where and when they happen
• Identify what caused those errors to happen
Simple to say…harder to achieve.
Often an error will appear in one part of your stack (more often than not in one of the clients), but can be caused from another part of the application. Being able to associate the error with the cause is a true skill, but using Logentries makes it a hell of a lot easier.
So how do you track an error down identified in one part of your application with what’s happening in another part of your application I hear you ask?
At it’s simplest, you put handlers within your application that will pass an identifier through the stack with any calls and log any important action, making sure to log this identifier. The identifier should be associated with a single client (be it human or machine) and be a unique identifier for their session or lifetime. It is then easily possible to use this unique identifier as a filter within the Logentries system to isolate the specific log events. By combining this with our Aggregated View, where you can merge specific logs into a singe view based on time, you can quickly track an event through the entire stack.
In part 2, I will:
- describe a simple use case and show an example of how this works in an multi-tier stack
- Show some best practices for logging across your application to help facilitate event tracking
- Tell how Logentries makes identifying the issue much easier
