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

Google analytics.

How We Set Up Google Analytics for Live Streaming App

In this article, I want to share my experience with video streaming for one of our Yourcast projects. You could find more about this project here:

 Top 3 best CI for your JS projects with Puppeteer tests.

Top 3 Best CI for Your JS Projects With Puppeteer Tests

For the first time, it was conceptualized and proposed by Grady Booch in 1991. It is one of the main elements of extreme programming practice.I...

How to Run Code Climate Code Analysis Locally Using VSCode + Remote-Containers.

How to Run Code Climate Code Analysis Locally Using VSCode + Remote-Containers

Everyone who writes code knows that the best code is code that is not written! But as they say, everyone is not perfect and we have to write code....

Go to blog