That's true re: LogError and LogMessage, but the point isn't what they do today, the point is that we can (and will, eventually, see #105) change the behavior in the future w/o having to separately visit hundreds of different places where `log.Print` is in use.

And yes, we want to be able to get the data out even when message delivery isn't working. But when message delivery is working, which is most of the time, messages are a very useful mechanism. That's why the Heka internal report supports both... it will send a message, typically, but SIGUSR1 will always cause the reporting output to be sent directly to stdout.

So my original opinion still holds; I think we should package this diagnostic info up in a data structure, and then pass that to a method. That method could use `log.Print` to send the output directly to stdout, and/or it could make sure the data shows up on Heka's internal report, which is always available to the user w/ SIGUSR1, regardless of whether or not messages are flowing.