Basic log files aren’t cutting it anymore. In this competitive world of app development(mobile app development), users expect more than ever. They need your app to work perfectly not just the first time, but every time. If there are errors (and there will be!) they need to be discovered and handled quickly.
App logging is the best way to discover why something in your app isn’t working right. You want to work smarter not harder, and your logs should be working for you to make it easier to solve even the biggest of problems. So how do you actually get more out of your log data? This guide will tell you how.
1. Prevent Memory Errors
The last thing you want is an out of memory error. When your app lacks resources, it crashes. That’s a no-go for your users who won’t take well to spontaneous crashing. Because you need to know when these memory problems occur, you’ll need to create tags to get notified when such an event is happening.
One of the leading reasons you’ll experience out of memory issues is because of your garbage collection behavior. If you track this behavior, you’ll get notified when your free heap space is over a certain threshold that you set. It could point towards a memory leak before it happens.
2. Increase Your Response Times
Slow response times are a serious performance problem. Your response time will help you understand just how long a request is taking to be returned, and it shows you whether your application is performing well. If it’s more than a 0.1 second response time, the user stops feeling that the system is reacting instantly. More than a second or two and you’ll likely lose that user entirely.
By setting your own response_time threshold, you can be notified if there are any user experience problems. This is key when keeping up with your application performance.
3. Avoid High Resource Usage
The load on your system might be increasing quickly without enough resources to keep up. If you track your resource usage, you can see if you need to increase your capacity or if you need more service instances. Using patterns like cpu>X or disk>X as well as when the disk is at or near capacity, you can avoid any high resource usage problems.
4. Slow Queries and Database Problems
Understanding when a query failed is a useful part of logging. You can identify when a request didn’t return with the right data, thus users don’t get the data they need. Even if the user does return the right information, it might not return quickly. Once again, your response time is important even if you aren’t experiencing any app errors.
Tracking these slow queries will help you understand how well your database is performing. You do this by setting acceptable thresholds for your query time. Some example patterns are the long query, slow query, or SqlException.
5. Don’t Log Alone
One of the biggest mistakes new app developers make is to use printf or to write log entries by themselves to file. Don’t handle log rotation by yourself. This is when you need a standard library or system API. By using one of these two methods, you know for sure the application will work well with any other system components.
More importantly, you’ll log to the right network services. A lot of developers will argue that using a library will up your CPU consumption, but this isn’t really true. Unless you’re not putting your log statements into tight inner loops, you won’t see any difference.
6. Be Meaningful with Your Logs
How meaningful are your logs? It’s tempting to write cryptic, vague log entries with the idea that most people who review them will have a deep understanding of your system. That’s usually not the case. Even if it is the case, it’s smarter to count on the potential log reviewers knowing less than knowing more.
When you write your log entry messages, pretend the only thing you are commenting on is the log file that shows what happened. Your log message is in the context of the code where your log directive is inserted. If the context isn’t included, it might not be possible to even understand the log message. If possible, add remediation information to the log message or the purpose of the operation, as well as what happened after the log message.
Don’t count on previous messages to always appear, because you don’t know that will actually happen. If those messages are logged on a different category, they might not even show up in the same place. More is always better when writing log entries.
7. Log in Machine Parseable Format
Finally, you want to ensure machines can read your logs as well. It’s easy to assume only humans are going to need these messages, but that doesn’t mean you won’t need any automated processing for alerts or audits.
In Jodan Sissel’s ruby-cabin library, you’ll see the context of machine parseable logs. This is a great idea since not only are your log parsers easier to write but it is an easier process.
As you can see, there’s a lot you can accomplish with logging. To learn more about logging particularly on Windows, review this blog post by Loggly on Windows logging basics. It’s important to keep up with your logging efforts in order to avoid any performance problems. Your users expect the best performance every time, so use your logs to make sure that happens.
Producing more useful logs is a big part of being an app developer. Your logs need to be constantly improving to ensure you’re covering your tracks wisely. Knowing how and what to log isn’t always easy. When you’re writing code, you don’t always know what information you’ll need during the troubleshooting process. However, the more you practice, the stronger you’ll get at utilizing your logging to take your application further.