New package: golang/glog

[Rob Pike]

New package for Gophers who log.

go get github.com/golang/glog

After the jump is a copy of the README.

-rob

glog

====

Leveled execution logs for Go.

This is an efficient pure Go implementation of leveled logs in the

manner of the open source C++ package

http://code.google.com/p/google-glog

By binding methods to booleans it is possible to use the log package

without paying the expense of evaluating the arguments to the log.

Through the -vmodule flag, the package also provides fine-grained

control over logging at the file level.

The comment from glog.go introduces the ideas:

Package glog implements logging analogous to the Google-internal

C++ INFO/ERROR/V setup.  It provides functions Info, Warning,

Error, Fatal, plus formatting variants such as Infof. It

also provides V-style logging controlled by the -v and

-vmodule=file=2 flags.

Basic examples:

glog.Info("Prepare to repel boarders")

glog.Fatalf("Initialization failed: %s", err)

See the documentation for the V function for an explanation

of these examples:

if glog.V(2) {

glog.Info("Starting transaction...")

}

glog.V(2).Infoln("Processed", nItems, "elements")

The repository contains an open source version of the log package

used inside Google. The master copy of the source lives inside

Google, not here. The code in this repo is for export only and is not itself

under development. Feature requests will be ignored.

Send bug reports to golan...@googlegroups.com.

[Volker Dobler]

Thanks!

V.

[Henrik Johansson]

Thanks! Works really nice!

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ibrahim M. Ghazal]

This doesn't seem right:
https://github.com/golang/glog/blob/master/glog_file.go#L73

if dir[0] != '/' {
dir = "/" + dir
}

Shouldn't this be a relative directory instead of just prepending / ?

[Henrik Johansson]

I do however have some problems. Running like this:

./myprog -v=2 

logs nothing with either glog.V(2).Info("message")

or glog.Info("message")

Although glog.V(2) is true and should (?) log.

Also perhaps I am missunderstanding how logging to the system log works but should that not also consider the levels? It seems to always log with -alsologtostderr=true regardless of level.

I can not find any log files either and no message about problems creating them. I tried to generate lots of logs in case there was a buffer that only gets flushed on occasion to no apparent avail.

My understanding is that either -v or -vmodule="files and levels" are the only flags you should need right?

What am I doing wrong?

[David Symonds]

On 16 July 2013 18:20, Henrik Johansson <dahan...@gmail.com> wrote:

> I do however have some problems. Running like this:
>
> ./myprog -v=2
>
> logs nothing with either glog.V(2).Info("message")
> or glog.Info("message")

Pass -logtostderr to the program too. Or -log_dir=/some/path.

> Also perhaps I am missunderstanding how logging to the system log works but
> should that not also consider the levels? It seems to always log with
> -alsologtostderr=true regardless of level.

If it's going to alsologtostderr, all levels are logged there. The
character at the start of the line tells you what level it is.

[Henrik Johansson]

Really?

./myprog -v=2 -log_dir=/some/path

Generates the symlinked INFO,ERROR, etc files but all that goes in there is the initial metadata

Log file created at: 2013/07/16 10:58:13

Running on machine: antiva

Binary: Built with gc go1.1.1 for linux/amd64

Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg

For a log statment like

glog.V(2).Infoln("message")

that just does not show up.

Maybe I am being dense....

-logtostderr works better it seems although there is a difference between

glog.V(2).Infoln("msg")

and

glog.Infoln("msg")

I thought perhaps naively that the latter is an alias of the former?

Sorry for bugging you but I have sorely missed a nice way of handling logging on different levels of verbosity.

[Rob Pike]

glog.V(2) will log, using Info, only if verbosity is set to 2 or
greater, via the -v flag or the -vmodule flag, whereas glog.Infoln
will always log to the to the Info log file.

Another way to see this is that glog.V(2).Infoln("msg") is the same as
if glog.V(2) {
glog.Infoln("msg")
}

This example is in the announcement mail.

-rob

[Henrik Johansson]

Yes thanks!

I am slowly grokking it, it is slightly different from what I am used to.

[Rob Pike]

I admit it's odd. The way it works was constrained by compatibility
with the C++ package Google uses internally.

The internal design is at least a little bit interesting and the use
of booleans with methods addresses the problem of unnecessary
evaluation.

Of course, having numbered levels (V 1 2 3) as well as named levels
(Debug Info etc.) is pretty silly, and having them not quite
orthogonal is peculiar, but see paragraph 1.

-rob

[Rob Pike]

If it's a valid name in the root, it will work; if not, it won't. This
is no doubt related to some detail of how logs work inside the Google
world, but that said, this code will never trigger in normal use.

-rob

[Andrew Lytvynov]

That's some fancy type magic. Package looks great, thanks!

[Henrik Johansson]

I like it more and more now that I have gotten used to it.

Migrating like crazy which is really good, it seems I had no really thought into the logs before...

[Michael Hofmann]

The licensing bits seem to have gotten mixed up in the release process: According to the source files it's 3-clause BSD, while LICENSE contains a copy of the Apache 2.0 license.

[David Symonds]

That's an error. It is supposed to be Apache 2.0. We will fix it.

[Peter Caven]

test panic on Windows (x64):

C:\Projects\GoCode>go test github.com/golang/glog

E0716 11:26:45.790000 07484 glog_test.go:135] test

I0716 11:26:45.791000 07484 glog_test.go:272] x

log: exiting because of error: log: cannot create log: open /tmp/C:\Users\Peter\AppData\Local\Temp\go-build204452727\github.com\golang\glog\_test\glog

.test.exe.SERVER2.Server2\Peter.log.INFO.20130716-112645.7484: The filename, directory name, or volume label syntax is incorrect.

--- FAIL: TestRollover (0.00 seconds)

panic: runtime error: invalid memory address or nil pointer dereference [recovered]

        panic: runtime error: invalid memory address or nil pointer dereference

[signal 0xc0000005 code=0x0 addr=0x30 pc=0x43569c]

[David Symonds]

On 17 July 2013 01:32, Peter Caven <pca...@gmail.com> wrote:

> log: exiting because of error: log: cannot create log: open
> /tmp/C:\Users\Peter\AppData\Local\Temp\go-build204452727\github.com\golang\glog\_test\glog
> .test.exe.SERVER2.Server2\Peter.log.INFO.20130716-112645.7484: The filename,
> directory name, or volume label syntax is incorrect.

The problem is that that bit of code should be using path/filepath
instead of checking for a leading slash. I'll push a fix soon.

[David Symonds]

Pull down the latest update and try again?

[Rob Pike]

The Windows problem and the licensing issue are both resolved. For those playing along at home, go get -u github.com/golang/glog with added gopher flakes.

-rob

[Peter Caven]

I'm still getting the same result:

C:\Projects\GoCode>go get -u github.com/golang/glog

C:\Projects\GoCode>go build github.com/golang/glog

C:\Projects\GoCode>go test github.com/golang/glog

E0717 11:47:27.689000 05840 glog_test.go:120] test

I0717 11:47:27.689000 05840 glog_test.go:257] x

log: exiting because of error: log: cannot create log: open /tmp/C:\Users\Peter\AppData\Local\Temp\go-build239402991\github.com\golang\glog\_test\glog

.test.exe.SERVER2.Server2\Peter.log.INFO.20130717-114727.5840: The filename, directory name, or volume label syntax is incorrect.

--- FAIL: TestRollover (0.00 seconds)

panic: runtime error: invalid memory address or nil pointer dereference [recovered]

        panic: runtime error: invalid memory address or nil pointer dereference

[signal 0xc0000005 code=0x0 addr=0x30 pc=0x43569c]

goroutine 14 [running]:

testing.func·004()

        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist417694871/go/src/pkg/testing/testing.go:348 +0xd0

github.com/golang/glog.(*loggingT).output(0x5fdc60, 0xc000000000, 0xc0800500c0)

        C:/Projects/gocode/src/github.com/golang/glog/glog.go:635 +0x49c

github.com/golang/glog.(*loggingT).print(0x5fdc60, 0x0, 0x33be98, 0x1, 0x1, ...)

        C:/Projects/gocode/src/github.com/golang/glog/glog.go:590 +0x115

github.com/golang/glog.Info(0x33be98, 0x1, 0x1)

        C:/Projects/gocode/src/github.com/golang/glog/glog.go:928 +0x51

github.com/golang/glog.TestRollover(0xc08007b510)

        C:/Projects/gocode/src/github.com/golang/glog/glog_test.go:257 +0x170

testing.tRunner(0xc08007b510, 0x5f9d78)

        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist417694871/go/src/pkg/testing/testing.go:353 +0x8d

created by testing.RunTests

        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist417694871/go/src/pkg/testing/testing.go:433 +0x86e

goroutine 1 [chan receive]:

testing.RunTests(0x568940, 0x5f9ca0, 0xb, 0xb, 0x1, ...)

        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist417694871/go/src/pkg/testing/testing.go:434 +0x891

testing.Main(0x568940, 0x5f9ca0, 0xb, 0xb, 0x5f5a40, ...)

        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist417694871/go/src/pkg/testing/testing.go:365 +0x8d

main.main()

        C:/Users/Peter/AppData/Local/Temp/go-build239402991/github.com/golang/glog/_test/_testmain.go:65 +0x9d

goroutine 3 [chan receive]:

github.com/golang/glog.(*loggingT).flushDaemon(0x5fdc60)

        C:/Projects/gocode/src/github.com/golang/glog/glog.go:803 +0x51

created by github.com/golang/glog.init·1

        C:/Projects/gocode/src/github.com/golang/glog/glog.go:370 +0x277

FAIL    github.com/golang/glog  4.572s

[Martin Schmidt]

Hi,

what its meant by:

On Tuesday, July 16, 2013 7:44:10 AM UTC+2, Rob Pike wrote:

By binding methods to booleans it is possible to use the log package

without paying the expense of evaluating the arguments to the log.

because seems to not mean that evaluate() in
glog.V(2).Infoln("logged: ", evaluate())
wont be called in case verbosity is less than 2.

regards,
Martin

[edmc...@hotmail.com]

On Wednesday, July 17, 2013 1:39:53 PM UTC-4, Martin Schmidt wrote:

Hi,

what its meant by:

On Tuesday, July 16, 2013 7:44:10 AM UTC+2, Rob Pike wrote:

By binding methods to booleans it is possible to use the log package

without paying the expense of evaluating the arguments to the log.

 According to the glog documentation, you have to use the form

if glog.V(2) { glog.Info("This is not evaluated if verbosity < 2") }

if you don't want the arguments to be evaluated. I was also confused by the connection between "binding to boolean" and "not evaluating arguments", when it looks like the only thing that prevents evaluation is an if statement, which seems like it would work just as well with any type that defined boolean methods for testing the log level.

--Ed

[Henrik Johansson]

You can call Info() directly on the returned level which is said boolean referred to earlier like so:
V(2).Info()

--

[edmc...@hotmail.com]

On Wednesday, July 17, 2013 6:32:05 PM UTC-4, Henrik Johansson wrote:

You can call Info() directly on the returned level which is said boolean referred to earlier like so:
V(2).Info()

Yes, but that form will always evaluate its arguments, I think.

[Henrik Johansson]

No i think that is the point of Robs comment about binding functions to a boolean. Check the source it actually contains an if that does it for you.

[Rob Pike]

Edmccard is right: You need the explicit "if" or the arguments are evaluated. It's being able to write the "if" in the first place that motivates the boolean design. Making it just *be* a boolean (and hence very cheap) is just gravy.

-rob

[Henrik Johansson]

Hmm ill have to take another look i could have sworn i saw something along those lines. Would be nice to be able to do away with the explicit checks tho.

[Henrik Johansson]

http://play.golang.org/p/q0E1btmyHs

Are you sure? It seems to return a false level in case the wanted level is greater and it is guarded by itself in the Info call.

Am I missing something fundamental?

[David Symonds]

Are you able to debug what's going wrong with the function near the
top of glog_file.go? It seems like you have $TMPDIR or $TMP set, but
to what? Can you sprinkle some print statements in createLogDirs to
see what's going on?

[Dominik Honnef]

Henrik Johansson <dahan...@gmail.com> writes:

> http://play.golang.org/p/q0E1btmyHs
>
> Are you sure? It seems to return a false level in case the wanted level is
> greater and it is guarded by itself in the Info call.
> Am I missing something fundamental?

http://play.golang.org/p/UfdUx-p3im

Without tne explicit "if", the arguments get evaluated and passed to the
method. This might be a cost you want to avoid.

[edmc...@hotmail.com]

On Wednesday, July 17, 2013 6:59:38 PM UTC-4, Henrik Johansson wrote:

http://play.golang.org/p/q0E1btmyHs

Are you sure? It seems to return a false level in case the wanted level is greater and it is guarded by itself in the Info call.

Am I missing something fundamental?

A function or method call causes its arguments to be evaluated before the body of the function or method is run. So in the case of the Info method, the "if v { ... }" can prevent "logging.print" from being called, but it has no effect on the evaluation of "args", which has already happened. The only way to prevent that is to not call the method, for example by putting the method call inside an "if glog.V(2)" block.

[Henrik Johansson]

You are right of course. In my haste to explain that the logging and the formatting which can of course be costly I sort of disregarded the function call itself... 

Some cases are not so bad of course as the example you gave with the evaluated function but I stand corrected.

Thanks! I blame my sloppy use of SL4J in Java which technically suffers from the same thing. 

Btw, can it not be inlined? What happens in that case?

--

[Peter Caven]

Yes, you're right. I didn't notice that before. 

I have the following user environment variables set:

USERPROFILE = C:\Users\Peter

TEMP  = %USERPROFILE%\AppData\Local\Temp

TMP   = %USERPROFILE%\AppData\Local\Temp

This actually seems to be a good reference: http://en.wikipedia.org/wiki/Environment_variables

-- Peter

[Peter Caven]

And after putting in a couple of prints in createLogDirs, 

after initializing 'candidates' and after looping through them:

C:\Projects\GoCode>go test github.com/golang/glog

E0718 00:44:24.107000 07480 glog_test.go:120] test

createLogDirs.candidates:  [  C:\Users\Peter\AppData\Local\Temp /tmp]

logDirs:  [C:\Users\Peter\AppData\Local\Temp //tmp]

I0718 00:44:24.107000 07480 glog_test.go:257] x

log: exiting because of error: log: cannot create log: open /tmp/C:\Users\Peter\AppData\Local\Temp\go-build318908843\github.com\golang\glog\_test\glog

.test.exe.CUBEFUSION2.CubeFusion2\Peter.log.INFO.20130718-004424.7480: The filename, directory name, or volume label syntax is incorrect.

[brainman]

http://golang.org/pkg/os/#TempDir is how to discover temp directory on any os, not by using TMPDIR environment variable.

[David Symonds]

Yeah, the code there is historical rather than useful. Please try out
what I've just pushed.

[Peter Caven]

I modified the createLogDirs to initialize 'candidates' as:

candidates := []string{

*log_dir,

os.TempDir(),

}

and now I get:

C:\Projects\GoCode>go test github.com/golang/glog

E0718 01:24:21.546000 05880 glog_test.go:120] test

createLogDirs.candidates:  [ C:\Users\Peter\AppData\Local\Temp]

logDirs:  [C:\Users\Peter\AppData\Local\Temp]

I0718 01:24:21.546000 05880 glog_test.go:257] x

log: exiting because of error: log: cannot create log: open C:\Users\Peter\AppData\Local\Temp/C:\Users\Peter\AppData\Local\Temp\go-build230942359\github.com\golang\glog\_test\glog.test.exe.CUBEFUSION2.CubeFusion2\Peter.log.INFO.20130718-012421.5880: The filename, directory name, or volume label syntax is incorrect.

[Peter Caven]

After your latest changes there seems to still be something happening with the path:

C:\Projects\GoCode>go test github.com/golang/glog

E0718 01:35:46.986000 08028 glog_test.go:120] test

I0718 01:35:46.986000 08028 glog_test.go:257] x

log: exiting because of error: log: cannot create log: open C:\Users\Peter\AppData\Local\Temp/C:\Users\Peter\AppData\Local\Temp\go-build355884803\github.com\golang\glog\_test\glog.test.exe.CUBEFUSION2.CubeFusion2\Peter.log.INFO.20130718-013546.8028: The filename, directory name, or volume label syntax is incorrect.

[David Symonds]

Aah, found that one too. Update and try again?

[Peter Caven]

Some progress, I think we're getting there:

C:\Projects\GoCode>go test github.com/golang/glog

E0718 02:01:02.841000 07508 glog_test.go:121] test

I0718 02:01:02.841000 07508 glog_test.go:258] x

log: exiting because of error: log: cannot create log: open C:\Users\Peter\AppData\Local\Temp\glog.test.exe.CUBEFUSION2.CubeFusion2\Peter.log.INFO.20130718-020102.7508: The system cannot find the path specified.

[David Symonds]

Oh, is your hostname "CUBEFUSION2.CubeFusion2\Peter"?

[David Symonds]

Or is your username "CubeFusion2\Peter"?

[Peter Caven]

Yes,

USERDOMAIN=CubeFusion2

USERNAME=Peter

But I think the main problem is that the path being used to create the log file has an embedded directory path separator, in this case "\".

I think that's why the call to os.Create is failing.

Here's the temporary directory: C:\Users\Peter\AppData\Local\Temp

Here's the filename that's being created:  glog.test.exe.CUBEFUSION2.CubeFusion2\Peter.log.INFO.20130718-020102.7508

-- Peter

[David Symonds]

Yes, we need to sanitize the username. Pull and try again.

[Peter Caven]

OK!

C:\Projects\GoCode>go test github.com/golang/glog

ok      github.com/golang/glog  5.554s

-- Peter

[Dmitry Vyukov]

On Tue, Jul 16, 2013 at 1:35 PM, Rob Pike <r...@golang.org> wrote:
> glog.V(2) will log, using Info, only if verbosity is set to 2 or
> greater, via the -v flag or the -vmodule flag, whereas glog.Infoln
> will always log to the to the Info log file.
>
> Another way to see this is that glog.V(2).Infoln("msg") is the same as
> if glog.V(2) {
> glog.Infoln("msg")
> }
>
> This example is in the announcement mail.


FWIW

_ = log.V(2) && log.Log("bla-bla-bla", ...)

http://play.golang.org/p/uQvT-dckEB

The prefix is larger (and trickier), but single-line.

[RickyS]

Some glog mysteries solved.  Some not.  I redid the 'go get' just now.

Ubuntu Linux 13.04 x86_64.  go version go1.1.1 linux/amd64

1. You have to:  import "flag" as well as ".../glog"
2. call flag.Parse() in main().
3. call glog.Flush() at the end.  Or periodically.  Or the output does not appear.
4. I cannot give you an example on the playground.  No glog there.
5. I was surprised to see so many different files and symlinks output.  Still thinking about this.

But:

1. This compiles and runs:
   glog.V(glog.Level(i)).Infof(" Infof: Hell.  Oh.   Urled. %d\n", i)
   
2. Whereas this gets a syntax error:
   glog.V(glog.Level(i)).Errorf("Errorf: Hell.  Oh.   Urled. %d\n", i)
   
   glog.V(glog.Level(i)).Errorf undefined (type glog.Verbose has no field or method Errorf)
   
3. This seems very inconsistent.  Is there a rationale?   Is broke or am I missing something?
4. When you use a ./log directory, the symlinks are still broken, as reported by somebody else, first.

———————————————————————————

Here is the complete program:

I run it with: go run noodleGlog.go -v=2 -log_dir=log

package main

import (

"flag"

"github.com/golang/glog"

)

func main() {

flag.Parse() // required.
glog.Info("Do you see this message?\n") // Yes.
for i := 0; i < 5; i++ {
glog.V(glog.Level(i)).Infof(" Infof: Hell.  Oh.   Urled. %d\n", i)

//glog.V(glog.Level(i)).Errorf("Errorf: Hell.  Oh.   Urled. %d\n", i)  

                // Mysterious Syntax Error .

// But this works:
glog.Errorf("Errorf: Hell.  Oh.   Urled. %d\n", i)
}
glog.Flush() // required.

}

 Please forgive "hell oh urled".  It's "hello world" in the web dialect.

———————————————————————————
On Tuesday, July 16, 2013 8:44:10 AM UTC+3, Rob Pike wrote:

New package for Gophers who log.

go get github.com/golang/glog
...

[Kyle Lemons]

On Sun, Jul 21, 2013 at 12:44 PM, RickyS <rickys...@gmail.com> wrote:

Some glog mysteries solved.  Some not.  I redid the 'go get' just now.

Ubuntu Linux 13.04 x86_64.  go version go1.1.1 linux/amd64

1. You have to:  import "flag" as well as ".../glog"

Only if you, you know, want to be able to use the flags it provides. 

1. call flag.Parse() in main().
2. call glog.Flush() at the end.  Or periodically.  Or the output does not appear.

I prefer

flag.Parse()

defer glog.Flush()

This makes the most difference for short-lived programs.  Most of the fatal logging functions will automatically flush. 

1. I cannot give you an example on the playground.  No glog there.
2. I was surprised to see so many different files and symlinks output.  Still thinking about this.

Others will no doubt disagree with me on this, but I will primarily be using this package when I'm open sourcing something from within Google that already uses it.  The number of files and line format of glog are compatible with the other logging packages within Google.  I generally just use the standard "log" package.

 

But:

1. This compiles and runs:
   glog.V(glog.Level(i)).Infof(" Infof: Hell.  Oh.   Urled. %d\n", i)
   
2. Whereas this gets a syntax error:
   glog.V(glog.Level(i)).Errorf("Errorf: Hell.  Oh.   Urled. %d\n", i)
   
   glog.V(glog.Level(i)).Errorf undefined (type glog.Verbose has no field or method Errorf)
   
3. This seems very inconsistent.  Is there a rationale?   Is broke or am I missing something?

You can think of it like this: Error and Warning are their own log levels and have their own files.  Info and the various verbosities are sliding scales of the same log level and allow the control of the amount of data dumped into the info log.

1. When you use a ./log directory, the symlinks are still broken, as reported by somebody else, first.

———————————————————————————

Here is the complete program:

I run it with: go run noodleGlog.go -v=2 -log_dir=log

package main

import (

"flag"

"github.com/golang/glog"

)

func main() {

flag.Parse() // required.
glog.Info("Do you see this message?\n") // Yes.
for i := 0; i < 5; i++ {
glog.V(glog.Level(i)).Infof(" Infof: Hell.  Oh.   Urled. %d\n", i)

//glog.V(glog.Level(i)).Errorf("Errorf: Hell.  Oh.   Urled. %d\n", i)  

                // Mysterious Syntax Error .

// But this works:
glog.Errorf("Errorf: Hell.  Oh.   Urled. %d\n", i)
}
glog.Flush() // required.

}

 Please forgive "hell oh urled".  It's "hello world" in the web dialect.

That's a strange web dialect I've never run into.

 

———————————————————————————

On Tuesday, July 16, 2013 8:44:10 AM UTC+3, Rob Pike wrote:

New package for Gophers who log.

go get github.com/golang/glog

...

--

[Dan Kortschak]

Bringing idiomatic perl to Go...

[Hochhaus, Andrew]

On Sun, Jul 21, 2013 at 2:44 PM, RickyS <rickys...@gmail.com> wrote:
> call glog.Flush() at the end.  Or periodically.  Or the output does not appear.

In case more context is helpful, the c++ glog implementation has two flags which help control buffering/flushing behavior.

GLOG_DEFINE_int32(logbuflevel, 0,
                  "Buffer log messages logged at this level or lower"
                  " (-1 means don't buffer; 0 means buffer INFO only;"
                  " ...)");
GLOG_DEFINE_int32(logbufsecs, 30,
                  "Buffer log messages for at most this many seconds");

https://code.google.com/p/google-glog/source/browse/trunk/src/logging.cc#136

However, these do not appear to be in the go implementation at this time.

-Andy

[Zippoxer]

I want to see INFO logs in the console, especially while in development of a program. Do I always have to execute with -logtostderr?

On Tuesday, July 16, 2013 11:24:40 AM UTC+3, David Symonds wrote:

On 16 July 2013 18:20, Henrik Johansson <dahan...@gmail.com> wrote:

> I do however have some problems. Running like this:
>
> ./myprog -v=2
>
> logs nothing with either glog.V(2).Info("message")
> or glog.Info("message")

Pass -logtostderr to the program too. Or -log_dir=/some/path.

> Also perhaps I am missunderstanding how logging to the system log works but
> should that not also consider the levels? It seems to always log with
> -alsologtostderr=true regardless of level.

If it's going to alsologtostderr, all levels are logged there. The
character at the start of the line tells you what level it is.

[Rob Pike]

Short answer: Yes. Or you could run tail on the log file.

I am hoping someone (other than me) will take the guts of this package (which are carefully designed, efficient, well-tested, and thread-safe, not to mention having great features like -vmodule) and put them inside a shiny box that doesn't display Google's peculiar way of thinking about server logging.

-rob