9 helpful tips for effective app logging

Imagine lacing up your running shoes, ready to hit the pavement and meet your daily fitness goals with the assistance of a trusty running app.

But when you start running, the app keeps freezing, preventing you from tracking your pace and distance.

Not exactly a pleasant experience, is it?

To prevent this from happening, behind every app, there should be a robust logging strategy that allows developers and other IT experts to quickly access log files and identify what went wrong.

That’s why in this article, we’ll explore nine tips that will enable you to harness the potential of app logging and tackle issues with ease.

Know who your target audience is

Before you dive into logging, it’s paramount to take some preparatory actions in order for the process to run more efficiently.

Without a doubt, one of these preliminary steps involves pinning down the target audience for the log entries.

This is important because it’ll dictate how the message content, level, context, and other important variables will be recorded.

In general, the target audience can be divided into three categories:

• End users who intend to troubleshoot issues themselves
• System administrators who will troubleshoot issues in a production environment
• Developers who will perform debugging during the development phase or fix bugs in production

The nature of your log entries will vary depending on which of these categories they primarily cater to.

For instance, when creating log messages for developers, you can expect them to possess extensive technical knowledge.

Therefore, these messages can be more intricate compared to those intended for end users.

However, it’s important to note that log entries primarily serve system administrators and other IT professionals.

As Robin Hiller, Head of Engineering at The Hut Group, aptly states in his article Logging For Production:

Although logging can be useful during development, developers are not the primary audience for log messages. Software Operators, or System Administrators, are the primary users of log messages and potentially, they’ll be using them in high-pressure situations.

So, in most scenarios, your log messages will be designed to assist system administrators in their troubleshooting endeavors.

Nevertheless, it’s still advisable to ascertain your intended audience before commencing the logging process.

Doing so will help the individuals carrying it out to be more successful in their troubleshooting or debugging efforts.

Log for more than troubleshooting

Just like log files can be intended for different audiences, they can also be used for different purposes.

Although their conventional use revolves mostly around troubleshooting and debugging, as we mentioned earlier, they can also be highly valuable in areas such as:

• Auditing
• Profiling
• Statistics

First up, we have auditing, which can be significant for business analytics.

The idea is to capture statements that depict user activities, system interactions, and app events.

This way, you can identify user behavior and usage patterns, which can drive your future business decisions toward more strategic choices.

If you look at the image of a log file below, you can see that it can give you a multitude of useful information on user login behavior.

From timestamp and username to login and logout events, login types (e.g., local or remote), and IP address, these details furnish valuable perspectives on how users interact with your app.

By inspecting this data, you can draw important conclusions from a business standpoint.

Moving on, profiling is another area where your logging process can shine.

Since it involves collecting information on performance metrics, it’ll allow you to assess how your code is executed, track resource usage, and gather data that helps optimize performance.

For example, if you aspire to make your application faster, logging can help you understand precisely which operations are causing delays so that you can improve those areas.

Lastly, log files can also be used for gathering statistical data.

You can, for instance, log every time an error or exception occurs and get insights based on that statistical data, such as uncovering hidden patterns or detecting anomalies.

All things considered, don’t limit your logging only to troubleshooting purposes because it can, as you can see, give you a host of other invaluable data.

Write your log messages in English

Now, when you first read that heading, you might have raised an eyebrow and wondered why such advice even needs to be stated.

After all, it’s only natural to jot down log entries in English.

Isn’t that the golden standard—to have log entries displayed in English, just like in the image below?

You would be surprised to learn that this isn’t always the case.

Many still choose to inscribe their log messages in their mother tongues, particularly if those tongues happen to be major languages such as German, French, or Spanish.

Let’s, therefore, delve into why it’s beneficial to embrace the English language, the lingua franca of the IT industry, for all your log messages.

First of all, when you record log messages, you want them to be captured with ASCII characters.

If your messages use a special character set or even UTF-8, some tools and consoles may be unable to read them.

Thus, log entries may become corrupted, lost in translation, and look messy like this:

Although this alone is a good reason to use English, a quote from Emil Stenqvist, a developer at Unomaly, gives us another perspective on the topic as it articulates the significance of mutual understanding in our interconnected IT world.

You never know who, in some distant country, will one day have to look at your logs, and curse at you for using your, surely wonderful, but to many, unintelligible mother tongue. The Internet is (or at least should be) borderless — let’s make it as inclusive as possible.

Local languages can create a language barrier among team members spanning the four corners of the earth and make it difficult to decipher log messages.

So if you want your log messages to be readable by different tools and professionals worldwide, use the English language, even if it’s not your native tongue.

Add context to your log messages

When it comes to logging, adding context to log messages can make a world of difference.

Without proper context, it would be challenging, if not impossible, to uncover the main cause of an issue.

Imagine, for example, the scenario in which users tried to register on your app but failed, and you receive a ticket stating that they had trouble completing the signup process.

If your log message resembles the unhelpful example below, you will have little meaningful information to start investigating the issue.

However, if you incorporate contextual information into the equation, such as the specific use case, impacted fields, reasons for the failure, and the value of the field causing the registration failure, you’d be far better equipped to tackle the issue.

Let’s see how this particular log entry can be improved:

By inspecting the latter example, we can pinpoint the exact spots where the errors occurred and efficiently resolve the ticket.

Every log message should, therefore, include the following contextual data points:

• User or request ID
• Timestamp
• Component where the log event originated
• Log levels that denote the severity
• Description of the log event
• Exception and error details

By including this contextual information, you’ll have no trouble locating the problematic areas later in the process and knowing just how to address them.

However, while context is essential, try to avoid excessive verbosity by including too much information.

Developers and system administrators often need to quickly skim through log files in search of information, and an excess of data makes it harder to read and comprehend them.

Avoid logging sensitive information

When it comes to logging, going the extra mile is absolutely crucial if you want to protect your logging system against security and privacy breaches.

Log files are like magnets for data intruders, which is why it’s essential to keep your users’ confidential information far away from those logs.

But before we proceed, let’s clarify precisely what we mean by sensitive information.

In a nutshell, it encompasses the following categories:

• Personally identifiable information (PII)—users’ full names, usernames, billing addresses, email addresses, gender, birthdays, phone numbers, social security numbers, and driver’s license numbers
• Business names and contact information
• Financial data—bank accounts, credit card details, and transaction amounts
• Passwords, security keys, and IP addresses

If you refer to any privacy laws, such as the GDPR, you’ll quickly realize that most of this data should never appear in your logs.

To ensure that it remains that way, data encryption is a commonly employed technique (shown below).

Essentially, encryption ensures that even if someone tries to steal your log file, they’ll be unable to decode and use the data without the encryption key.

This protective measure is accomplished by applying the encrypt attribute to fields that contain sensitive data, thereby rendering them inaccessible to unauthorized attacks.

Here’s an example of how the end result might appear in your log file:

Remember, protecting the sensitive information of your users requires going to extraordinary lengths.

Complying with regulations and requirements isn’t just another box to check off.

Any breach of security not only puts the company’s reputation at stake but also threatens its bottom line.

Don’t log too much or too little

Logging can be a slippery slope—too much of it can clog the system and cause performance issues, while insufficient logging makes troubleshooting difficult.

To illustrate this point, let’s explore the story that Jeff Atwood, the co-founder of Stack Overflow, shared on his blog, Coding Horror.

The story revolves around building Stack Overflow, where they were logging everything, led by the idea that too much logging can’t hurt.

Of course, their strategy backfired quickly, resulting in frequent deadlocks that affected the site several times a day.

To make things worse, they tried to deal with it by logging even more.

However, after a memory dump and a thorough examination, they had to confront the truth: their logging strategy was the primary culprit.

So, what did they learn from this situation?

The author states it eloquently:

Like any other tool in your toolkit, when used properly and appropriately, it can help you create better programs. The problem with logging isn’t the logging per se — it’s the seductive OCD ‘just one more bit of data in the log’ trap that programmers fall into when implementing logging.

With that in mind, how should we approach logging?

Brice Figureau, the creator of Masterzen’s Blog, suggests that during app development, you should let yourself log as much as possible.

However, once you enter the production phase, analyze those log messages and refactor the logging statements accordingly.

Since this requires extensive collaboration between system administrators and developers in their already busy schedules, perhaps a more practical solution proposed by Jeff Atwood from Coding Horror might be worth considering.

After their unfortunate experience with too much logging, they shifted their focus exclusively to exception logging.

This way, they still retain important log messages while ensuring that an excessive number of log entries doesn’t clutter their memory.

Regardless of your logging practices, always bear in mind the importance of striking a balance when it comes to logging.

Log in a machine-parsable format

Although sifting through log files can certainly get the troubleshooting and debugging job done, there is a smarter way to handle the task.

It’s called automation.

When you’re faced with the need to search or filter your log files, or when you’re confronted with a hefty stack of log messages that require auditing, relying solely on your own eyes will undoubtedly be a painstakingly slow process.

That’s why it’s recommended to implement structured logging into the process.

For this purpose, you can utilize a machine-parsable format such as JSON, shown in the image below.

JSON happens to be an exceedingly popular and widely used option for constructing log statements.

It allows the data to be organized in a manner that machines can automatically inspect and decipher, yet it still maintains an intuitive syntax that is understandable to us humans.

This enables you to quickly search through a large volume of data with greater efficiency.

Abhishek Dubey, a DevOps consultant and junior partner at OpsTree, explains it this way:

The biggest benefit of logging in JSON is that it provides a structured format. This allows for analyzing application logs just like Big Data. It’s not only readable but also a database that can be queried for each and every field.

Another noteworthy advantage of JSON is its lightweight nature.

This means it won’t gobble up excessive memory, which is always a welcome relief.

Moreover, JSON serves as a language-agnostic format, meaning it’s compatible with all computer languages, either natively or through libraries.

That being said, a machine-parsable format like JSON has already become an industry standard, and it’s something you should implement in your own processes.

Take advantage of the right tools

Considering the large volume of data generated during logging, attempting to handle everything manually can be a futile endeavor.

That’s why the use of tools is a standard practice that paves the way for successful capturing, storing, monitoring, and managing log data.

This is precisely where the significance of tools such as Better Stack (shown below), Sumo Logic, Datadog, Cloudlytics, and others stands out.

They enable quick searches, seamless filtering, and detailed analysis of log files, thus facilitating the more successful resolution of issues.

The use of in-app tools has also proven to be effective, as they provide the ability to generate log messages without leaving the tool.

Let’s take our tool, Shake, as an example.

Shake is an SDK that integrates into any iOS or Android application with just a few lines of code.

When users or testers come across a bug in the app, Shake generates detailed log files that show exactly what was happening in the app when the bug occurred or the app crashed.

This is possible because Shake, similar to an airplane, has black box capabilities that allow recording of everything that happens 60 seconds before the ticket is submitted.

This enables developers and system administrators to inspect the logs and glean invaluable insights, such as which OS was used, battery levels, CPU percentages, network statuses, usernames, and more.

Additionally, Shake allows you to sort these logs using five distinct levels (depicted in the image below) and filter them based on their severity.

By doing so, you won’t only resolve tickets faster but also uncover a wealth of knowledge concerning user patterns, system behavior, and potential areas for improvement.

All in all, with the help of tools, you will achieve at least four things: better log management, easier troubleshooting, effective monitoring, and insightful analysis.

And that is something worth considering.

Avoid getting locked to a vendor

Picture the annoyance of meticulously setting up your logging standards and practices, only to encounter a sudden roadblock when an external logging framework or library you rely on shuts you out.

This unexpected hurdle can be a significant setback because it forces you to rely on vendor support to regain control over your logging process.

Thankfully, there are ways to reduce your reliance on vendors, and one effective approach is to opt for open-source logging libraries like Log4j.

Log4j stands tall as one of the most widely adopted Java logging tools, trusted and used by teams across the globe.

It’s not tied to any specific vendor or platform, and it’s compatible with a wide range of applications and environments.

It’s important, however, to note that Log4j has its own set of vulnerabilities, so you’ll have to be aware of how to sidestep or avoid them.

Another approach worth trying is to choose logging solutions that are aligned with open standards, such as structured logging formats like JSON, as illustrated in the image below.

Because these standards ensure compatibility and portability of log data across different frameworks and libraries, you can easily switch between different logging solutions without major code changes.

Both approaches will increase the flexibility, and independence of your logging solutions and make you less dependent on third-party tools.

Conclusion

Logging is an important part of the troubleshooting and debugging process as it enables inspecting the log files and detecting the root cause of the issue.

It can also be used for monitoring, auditing, security protection, and many other purposes.

In this article, we provided nine tips that we thought could help you in your logging activities.

We hope that they provided you with valuable information that will facilitate your future logging processes.