- Blog
#Azure #Technology
Securing Azure Virtual Machines: Using Azure Bastion and Just-In-Time (JIT) Access
- 18/11/2024
Reading time 5 minutes
Welcome to an introductory post on understanding your application and system through logging. We will look at some important logging details and measures.
By logging usually is meant created records through a piece of software at your operating system level, a web application, a mobile app, a load balancer, a database, a mail server and so on. Logs are created by many different types of sources.
Their importance comes from their ability to allow you to understand what is happening in your system or application. They should show you that everything is alright and if things are not, you should be able to determine where the problem is and how to fix it.
From the start of the application to the end of it, you should be able to see the entire history of the application and be able to analyze what has happened.
The general categories of logging can be summed up in the following points:
There are more categories to consider but the main points are above. Also depending on your organization or company your requirements for logging might be loose or strict. A government agency will require more specific and stricter logging than what a medium-sized private company would require.
Also depending on the severity of your application and what it does logging requirement can be stricter. For example, dealing with payments and user data is something that usually requires you to be very aware of what is happening in your application and what to log and what not to.
Let’s start with what to log, I would consider the following but analyze your application and determine if all are relevant to you or if something is missing:
Now this is not a complete list of what you should log but it is a good start, these suggestions are the minimum you should consider.
Now as much it is important to log and have a good view on what is happening in your system or application, it is also a fine art to understand when not to log things.
Having too much log will make it hard to find out the relevant critical information you need. Having too little logging you risk not being able to understand your problem properly.
So, there is a fine balance between logging too much or too little.
A possible solution to this issue is to have more verbose logging during development and when deploying to production your application will only log what is determined important by the developers so that someone will be able to troubleshoot a problem in production without having too much or too little logging. This is also a process that needs refactoring during the lifetime of the application.
This leads us to a requirement of logs: logs should be structured and easily indexed, filtered and searched.
These are the things that you should want to AVOID. Having these things in a production release will be a security risk at the very least:
Now, there is a situation where you might need to log sensitive information. In this case, I would recommend “masking” or removing parts of the sensitive data to give you an idea of what the log entry is related to but without giving away the sensitive information wholly. For example:
Still, be very careful with this information, especially with user-related data.
When you are logging, I recommend considering who are you logging for?
You need to ask yourself: Why add logging to an application?
One day, someone will read that log-entry, and it should make sense to them and be helpful. So, when you log things, think of your audience and ask yourself the following things:
All of these can be quite different depending on who is looking at your logs. As a developer, you can easily understand quite complex logs but as a non-developer you most likely would not be able to make much sense of complex log entries. So, adapt your language to the intended target audience, you can even dedicate separate categories for this.
Also, think if the log entries can be visualized. For example, metrics logs should have categories, dates and, numbers which can be translated into charts that show how long things last or succeed.
When writing log entries avoid writing them in a way that you need to have in-depth knowledge of the application internals or code logic, even if the log reader is expected to be a developer.
There are a few reasons to write log messages that are not depended on knowing the application code or the technicalities behind your application:
Logging is about the four W:
By context, I mean that your log message should usually tell what is going on by giving away all the needed details to understand what is happening.
So, this is not OK:
“An order was placed”
If you were to read that one, you would ask: “What order? Who placed the order? When did this happen?”
A much more detailed and helpful log message would be:
“Order 234123-A175 was placed by user 9849 at 29.3.2019 13:39”
This message will allow someone to get that order from a system, look at what was ordered and by whom and at what time.
When you create a log entry your log entry should have an associated level of severity and importance. The common levels that are used are the following:
This is it for the theory side of things. In my next blog post, I will discuss a bit more technical things regarding logging. We will look into what kind of data is actually needed and what kind of tools you might need.
Our newsletters contain stuff our crew is interested in: the articles we read, Azure news, Zure job opportunities, and so forth.
Please let us know what kind of content you are most interested about. Thank you!