Logs are often the foundation of metrics and observability infrastructure because they contain business-level statistics that help you and your team make decisions. Without them, it’s impossible to know how often users are hitting errors or how the latencies in your services are varying over time.
If you’re responsible for keeping web servers running, you already know easy access to log messages is critical when troubleshooting issues. Apache provides comprehensive support for logging, and its highly customizable configuration allows you to tailor its logging to your exact needs. You can gain visibility into your web servers by logging everything from the initial request through to the URL mapping process and connection termination. And if this wasn’t enough, third-party modules provide additional logging capabilities such as support for application runtimes including PHP, Java, and CGI programs.
The JSON format is ubiquitous and used everywhere from logging in web apps to message passing for microcontrollers. Thanks to its compact nature and it being easily readable by humans, JSON has become the de facto standard for sharing structured data.
Modern apps and services generate a constant stream of log data capturing the inner workings of the code and how users interact with it externally. Buried inside those logs are golden nuggets of information critical for troubleshooting problems in development and in production.
Managing log files on a single server is a cakewalk, and familiar tools such as grep, tail, and sed can expose the data you need. But it’s a completely different story once you’re working at scale and need to analyze logs across tens, hundreds, or even thousands of machines. In this case, the best solution is to aggregate your logs in the cloud and use a log viewer to analyze your logs holistically. Fortunately, that’s exactly what SolarWinds® Papertrail™ does.
When setting up logging for your apps and services for the first time, it’s natural to want to focus on the content of the messages; you want to make sure you have all the information you need when you use your logs to troubleshoot issues. But picking your log format is just as important.
Imagine the software you’ve just pushed to production is causing latency spikes for users visiting your web app. Your code passed all the tests but something about running with real-life users has uncovered a bug not previously caught by your automated testing. Now you need to figure out what went wrong and how to fix it.
Modern garbage collectors use sophisticated algorithms to manage unused memory, so you don’t have to. But when things aren’t working right, you need a way to peek under the hood and troubleshoot issues. Analyzing garbage collection (GC) logs can provide key insights into the behavior and performance of programming languages using automatic memory management, such as Java. If you suspect you’ve got a memory problem with your Java app, the GC log is the first place to look.
Wouldn’t it be great if web apps and websites just worked the way they did in testing and staging? Unfortunately, it seems as soon as you release them into the wild, things start going wrong. When you’re getting calls from users or seeing availability alerts, getting your hands on the right data from your IIS logs can make a big difference in how quickly you respond.
Syslog has been around for four decades, and it’s a well-used tool in every DevOps and admin tool kit. The syslog format began as part of the Sendmail project, and it has since become a ubiquitous logging protocol used by hundreds of applications and supported out of the box by most major operating systems. This battle-tested logging format provides all the pieces you need to create actionable log messages and diagnose problems with your apps and services.