Runtime: Logging system for kata-containers

Created on 22 Nov 2017  路  11Comments  路  Source: kata-containers/runtime

Now we have logrus and glog as candidate, both are widely used in the golang world. We all agree the logrus are more flexible and powerful. However, glog is come from Google, and used by most of the kubernetes family projects.

The question is, could we wrapped the log engine, which allows the users could select log engine if they import kata code as vendor?

Most helpful comment

@sameo @WeiZhang555 The simple answer is No.

I used to think about such ways. However, if you read more glog code, you will found --

glog has a init() method, which will insert some flags to your binary, such as -v, -logtostderr, etc. I guess you don't want to have these flags if you wan to use native
logrus, however, you have to run the init() if you import glog no matter whether
you log with it.

Then how to use glog4logrus, my assumption is ---

If you have a program use kata as a library, say hyperd here (just for illustration), and you
want use glog, because k8s use glog as well, it is reasonable to have all the binaries
output logs in the same manner. When the hyperd call kata as a lib, it could set the logrus
format and output driver with glog4logrus.

Let me summary here:

  • kata components use logrus, and provide method to setup logrus (this should not be a problem).
  • kata components don't import glog4logrus
  • If a guest code want to use glog, then they must have already imported glog, and they could import glog4logrus and configure logrus to export to glog.

All 11 comments

As discussed in the meeting, I created the issue, correct me if there is anything wrong.
@laijs @bergwolf @sboeuf @jodh-intel @sameo

A quick github search turned up this:
https://github.com/bookerzzz/glog
Not sure if that will be of use...?

or (/me goes to check)... is that the same glog. hmm...

@grahamwhaley it creates an implementation of the glog interface it seems.

Since there is no more discussion on this topic, I wrote a log adapter to allow using glog as the output of logrus: https://github.com/gnawux/glog4logrus

then we could coding with logrus and log to logrus or glog as required. Any comments?

@gnawux Thanks a lot.
So would the typical usage for exported Kata Containers component be:

  1. Import github.com/gnawux/glog4logrus
  2. When starting the component, call:
        logrus.SetLevel(glog4logrus.GlogLevel())
    logrus.SetFormatter(&glog4logrus.GlogFormatter{})
    logrus.SetOutput(&glog4logrus.GlogOuptut{})

Or should we expose an option to user and let user choose which log system to use?

For example:

--log-driver=logrus:json-file
--log-driver=glog:text

@sameo @WeiZhang555 The simple answer is No.

I used to think about such ways. However, if you read more glog code, you will found --

glog has a init() method, which will insert some flags to your binary, such as -v, -logtostderr, etc. I guess you don't want to have these flags if you wan to use native
logrus, however, you have to run the init() if you import glog no matter whether
you log with it.

Then how to use glog4logrus, my assumption is ---

If you have a program use kata as a library, say hyperd here (just for illustration), and you
want use glog, because k8s use glog as well, it is reasonable to have all the binaries
output logs in the same manner. When the hyperd call kata as a lib, it could set the logrus
format and output driver with glog4logrus.

Let me summary here:

  • kata components use logrus, and provide method to setup logrus (this should not be a problem).
  • kata components don't import glog4logrus
  • If a guest code want to use glog, then they must have already imported glog, and they could import glog4logrus and configure logrus to export to glog.

@gnawux I think this is the right approach, thanks for the clarification.

Yeah, sounds quite good :+1:

Seems we have agreement based on @gnawux's proposal. Closing this resolved issue.

Was this page helpful?
0 / 5 - 0 ratings