In the first article, we talked about how to log properly, and also when and where to use different types of levels. If you missed first part go check it out below link:

Image.

Log management in Go

This article is mostly about controlling your logs and finally, I wanted to show how to use logs (of level Error or higher) to take quick actions in case something bad happens.

How to log a log: approaches to control your logging

Now, your project might have only one package, yet, when it grows, the number of packages grows as well, so logging might become a little complicated. There are three basic approaches to how you might want to control your logging in a multi-package project.

The first one is to use just the default logger instance of Logrus everywhere. You can use it right out of the box referring directly to Logrus instance. Which you, therefore can control out of any package anytime.

Logrus Logging.

This produces the following results:

Logging.

Changing logging level from Foo package will, therefore, have its effect on both packages:

Changing Logging Level.
Logging.

But of course, it would not affect any of the previous run code.

With this approach, I recommend using init() function to set up Logrus logger right ahead and therefore establish settings for all packages right away (and not change them further)

Logging.

As a result, we see this:

Logging.

The second approach is you create one instance of a logger, update its log level, and then use this logger for all the packages within your project. This is not very much different from the previous example, yet, for many people, it looks more manageable and comprehensive.

Logging.
Logging.

You might want to initiate separate loggers with separate logging levels since there are cases where you would like to see more logs from one package but avoid seeing more logs from other packages. With this approach you can do just that, yet, the configuration becomes a problem then. You either use yaml or json configuration files. In case you use environmental variables, there will be a lot of them… so, think twice

Logging.

As a result, we have two packages with a different set of loggers and therefore different messages. Might be useful when we need more logs from one package and less from the other

Logging.

Logging by itself is great but not very useful. What if you want to be notified if something unexpected happens? You have "error" or "panic" logs, but not sure if you want to check log files each second to make sure nothing bad happened. This is where services like Sentry comes into play. Sentry has official SDK for Go which you can use to easily capture errors and other unexpected behavior of your code.

Logging.

Personally I prefer to use Logrus Hooks and there is a very good Logrus hook for Sentry which helps to capture errors and other unexpected behavior right with Logrus without the need to wrap them with sentry.CaptureException method.

Logging.

For more comprehensive information, please, read the following Datadog article about logging in Go which provides a lot of insides on logging in Golang with examples.

Custom backend solutions by Mad Devs.

Latest articles here

SOLID: Interface Segregation Principle in Golang.

SOLID: Interface Segregation Principle in Golang

Acronymic SOLID principles were formulated by Robert C. Martin, also known as "Uncle Bob," one of the most influential software developers in the...

GRPC Streams.

Guaranteed Delivery with gRPC Streams

Let's take a look at the minimum requirements for web developers in the 2000s. In the good old days, you could build more or less working website...

Protocol Buffers vs JSON

Protocol Buffers vs JSON

Have you ever wondered how your favorite mobile app delivers lightning-fast updates or how social media platforms handle millions of messages per...

Go to blog