search

RITlug / teleirc

Go implementation of a Telegram <=> IRC bridge for use with any IRC channel and Telegram group
https://docs.teleirc.com/
GNU General Public License v3.0
140 stars 45 forks source link

Implement Go logging #213

Closed Tjzabel closed 4 years ago

Tjzabel commented 5 years ago

Summary

Implement a standard way to log system and chat messages in TeleIRC

Background

Instead of writing fmt.Println statements when we want to redirect output to stdout, we should implement Go's log package. This will give us much more fine tuned functionality for logging, and will also allow the user to specify whether or not they wish to see more verbose output.

Details

All logs will go to stdout since we expect to run TeleIRC in a container.

Outcome

Log messages appear in stdout

jwflory commented 4 years ago

Discussed in 2020-02-15 developer meeting.

@10eMyrT and @kennedy are leading research on this issue. The deliverable is a comment on this GitHub issue that addresses the key areas explained in the Details section of the original comment. Once the research is shared on this issue, we can close it and refer back to it as needed when writing the rest of the handlers.

kennedy commented 4 years ago

I found a great article in creating a custom logger with the standard log package and *log.logger type: https://www.ardanlabs.com/blog/2013/11/using-log-package-in-go.html

The article suggest creating a *log.logger object for each log situation (info, debug, error, etc).

Subject I am unsure of how to handle logging through multiple goroutines/services.

The other option is use a third party logging framework which extends the standard log gives us the same abilities from the article. Here are a list of logging libraries ranked by popularity (github stars) and dev activity. https://go.libhunt.com/categories/504-logging

The most popular and most active are:

  1. https://github.com/Sirupsen/logrus
  2. https://github.com/kpango/glg

I am honestly leaning towards third-party because it does all the hard work illustrated from the article, and has a singleton mechanic.

Let me know what you guys think

Tjzabel commented 4 years ago

@kennedy generally, I think it makes sense to have a logger instance within each of the Client structs.

jwflory commented 4 years ago

The most popular and most active are:

1. https://github.com/Sirupsen/logrus

2. https://github.com/kpango/glg

I am honestly leaning towards third-party because it does all the hard work illustrated from the article, and has a singleton mechanic.

If using a third-party logging framework, I suggest logrus. It looks like it has a more diverse community and more activity than glg. Plus, another popular Go project, Podman, uses it for its logs. I've used Podman for debugging and loved the way they do debug logging, but didn't realize it was logrus:

https://github.com/containers/libpod/blob/f2bcc9cc7dc8b1937f39db503db96651d84c3e3e/go.mod#L63

Tjzabel commented 4 years ago

@jwflory I agree logrus is nice, and it seems to have a much larger community.

However, for the sake of TeleIRC and our goal of relying on as few 3rd party libraries as possible, I would prefer to just use the standard log library. I think the real question is: Does it have all the features we need?

What are all your thoughts?

kennedy commented 4 years ago

Perfect, that’s what I was leaning towards as well.

On Feb 19, 2020, at 5:02 PM, Tim Zabel notifications@github.com wrote:

 @jwflory I agree logrus is nice, and it seems to have a much larger community.

However, for the sake of TeleIRC and our goal of relying on as few 3rd party libraries as possible, I would prefer to just use the standard log library. I think the real question is: Does it have all the features we need?

What are all your thoughts?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

jwflory commented 4 years ago

@Tjzabel I haven't done a thorough analysis, but my last comment could have been shiny-object syndrome :slightly_smiling_face: I also prefer to keep things simple, especially knowing that our biggest contributor group will likely be undergrad students, so long as the project is managed by RITlug. So, I'm in favor of simplicity over complexity.

That said, I really haven't done my homework here. I'll try to do a deeper dive soon… I've been focused on other things.

jwflory commented 4 years ago

Discussed in 2020-02-22 developer meeting.

In the call, we briefly discussed how we wanted to do logging. To keep things simple, and since our use case is simple, we will use the standard library in Go for logging. A new issue is coming soon to migrate our existing print statements over to the logging library.

Closing! :ocean:

jwflory commented 4 years ago

Also thanks @kennedy for leading the research on this one! I still learned something from this discussion :slightly_smiling_face: