Modern applications typically weave together an impressive underlying architecture of microservices with serverless and container technologies to make sure your service works seamlessly for customers. Unfortunately, when problems arise with your application when you’re on call at 3AM, this microservice tapestry looks less like a beautiful picture created by teams working in harmony and more like a confusing, tangled knot.
To get to the root of application performance problems quickly (and ensure you get the most rest at night), you’ll need to rely on observability practices to direct your attention to where problems originate. In the context of microservices, you’ll need to consider whether it makes more sense to use log monitoring or instrumentation for your projects. Both can trace back to problems in a current system and provide insight for future projects. But which is more practical? Both require your time and resources that could otherwise be spent doing other work.
Why use log monitoring?
Log monitoring, or logging, is a method of tracking and storing data to ensure application availability, and to assess the impact of transformations on performance. This sounds great, and logging is widely used. More than 73% of DevOps teams use log management and analysis to monitor their systems. However, there are some serious drawbacks to using only logging as a solution.
Manual logging is time-consuming and imbalanced
Developing logs is a tedious process that can be error-prone. You might spend hours adding data, only to find that it’s less than helpful in production when you need exact information to find out what has gone wrong in your application.
Adding new information about debugging processes into log files takes up precious time and you have to identify every potential piece of data that may be needed beforehand. (Hopefully, you have a crystal ball available in advance of any conceivable problem!)
You need to create the perfect balance of logs when debugging code, adding only enough to debug any problems within a program quickly. If you don’t provide enough logs, you won’t have enough information to debug, but if you add too many, this can become resource-intensive because there will be so many logs to analyze. (Again, better get good at gazing into that crystal ball.)
Logging is difficult to track across multiple services
If your application is like most out there, it is using multiple services, containers, and processes. Therefore, solving problems in application performance might require you to understand all the relationships between different logs. If you’ve woven the entirety of the app yourself maybe you can connect all the threads. Yet even in this case, you’ll still have to read through the raw text of the logs to remember how everything connects.
If you need to explain these connections to someone else, the fastest way might be visually, showing the depth of a problem within the nest of microservices. But because logs only report text, you’ll have to spend more time either making a chart or talking it through with your colleagues.
What is instrumentation?
Instrumentation is the process of adding code to your application so you can understand its inner state. Instrumented applications measure what code is doing when it responds to active requests by collecting data such as metrics, events, logs, and traces (MELT). In contrast to an application that isn’t instrumented and only uses point-in-time logs, an instrumented application tracks as much information as possible about the service’s operations and behavior. It provides more detail about what is happening, so you can see relationships between requests.
Why instrumentation is key to modern applications
Despite being incredibly useful, instrumentation is an often-overlooked aspect of software development. Many people have the perception that it can be hard to get started and may not provide the same return on investment as simply relying on logs. However, instrumentation is key to ensuring your application is performing up to its best. It provides immediate visibility into your application, often using charts and graphs to illustrate what is going on “under the hood.”
With the analyzed data that instrumentation provides, you can solve immediate on-call problems quickly because there is so much data available for debugging. But, you can also use instrumentation to see larger patterns over time that you would miss if you just rely on point-in-time log data. This can help you make improvements to your application as a whole, rather than just patching holes. It is important to consider instrumentation is an iterative process that can bring hidden insight to the surface rather than an immediate solution for individual problems.
To try instrumentation solutions for your application, sign up for a free New Relic One account. Your free account includes 100 GB/month of free data ingest, one free full-access user, and unlimited free basic users.
The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. Any solutions offered by the author are environment-specific and not part of the commercial solutions or support offered by New Relic. Please join us exclusively at the Explorers Hub (discuss.newrelic.com) for questions and support related to this blog post. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.