On Mon, Apr 23, 2012 at 1:02 PM, Matt Simerson <m...@tnpi.net> wrote:

>
> On Apr 22, 2012, at 11:43 PM, Robert Spier wrote:
>
> > On Sun, Apr 22, 2012 at 2:25 PM, Matt Simerson <m...@tnpi.net> wrote:
> >
> >> Makes it much easier to figure out where that log entry came from.
> >> ---
> >> t/plugin_tests/auth/auth_flat_file |    2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/t/plugin_tests/auth/auth_flat_file
> >> b/t/plugin_tests/auth/auth_flat_file
> >> index c4218bd..6726307 100644
> >> --- a/t/plugin_tests/auth/auth_flat_file
> >> +++ b/t/plugin_tests/auth/auth_flat_file
> >> @@ -19,7 +19,7 @@ sub test_auth_flat_file {
> >>   for $u ( @u_list ) {
> >>       ( $a,$r,$p ) = @{$u_data{$u}};
> >>       ($ret, $note) = $self->auth_flat_file($tran,'CRAMMD5',$a,$p);
> >> -       defined $note or $note='No-Message';
> >> +       defined $note or $note='authflat: No-Message';
> >>
> >
> > Would it be clear to use the full name of the plugin?  What if you have
> > multiple plugins with a similar name?
>
> The shortening affects the amount of data spewed into the logs. Keeping it
> shortened is in line with how many other plugins log (see
> auth_cvm_unix_local, auth_ldap_bind, check_*).
>
> In this case, it had to grep my way around to figure out what was dumping
> that error into my logs. Prepending anything to determine the origin is an
> improvement.
>
> I do agree that using the full plugin name would be even clearer still.
>
> Best still would be consistency among all the plugins.
>
>        In some cases, plugins have log entries automatically prefixed with
> the plugin name.
>        In many cases, they are not (hence, this change)
>        Some plugins manually prefix their log entries with their plugin
> name (creating redundant log info)
>        Some plugins manually prefix their log entries with an abbreviated
> form of their plugin name
>        Some plugins have log entries with no indication of their origin
>
> I'm sure no small reason for the plugins with shortened names is to tame
> the logging a bit. It is after all, easier to drink from a garden hose than
> a fire hose.
>

One thing I've considered is moving logging over to something like a stream
of protocol buffers, and then provide another tool for formatting it to
text.  The biggest downside to that is you don't get immediate log
gratification unless you're running the conversion tool in parallel.   But
the upside is we can cleanly shove as much info into the logs as we want,
but still only pull out the stuff we want -- plus, total flexibility in
displaying it.


>
> It would be great if all plugins had their prefix automatically prepended
> before their log entries. Then all that code could be removed from the
> plugins. Perhaps it's only the auth plugins that are missing this
> prepending of plugin and hook names?


This seems likely.  The Plugin.pm logging code (see sub Log) explicitly
adds the plugin name -- there may be a difference in how auth plugins are
called that prevents that from working right.

Reply via email to