What you say? or: meaningless chatterboxes on their way



  •  Found this to be the contents of the log file of a very important application on one of my clients site:

    [code]13:58:29.984:·nothing·left·to·read.
    13:58:29.984:·msg·is·now·NULL.
    13:58:29.984:·Good·message·from·sd·38.··Processing·it.
    13:58:29.984:·Processing·ADMIN·message.
    13:58:29.984:·Servicing·Read·on·sd·39.
    13:58:29.984:·starting·new·message·read,·because·msg·is·0x0·and·env_left·is·0.
    13:58:29.984:·trying·to·get·last·67·of·envelope.
    13:58:29.984:·got·67·of·env.
    13:58:29.984:·[Header·so·far:<d8^00000027^0000000000000000^4AF96375&377D4AB0^00000000^4^00000002|>]
    13:58:29.984:·creating·message·of·size·3.
    13:58:29.985:·trying·to·get·last·3·of·message,·at·offset·67.
    13:58:29.985:·got·3·of·data·Data·Follows·(bytes·2):
    [/code]<font color="black" face="Helv" size="2"></font>

    Anybody understands what is happening here? Me neither. But it is important that those programmers can live in the belief that they have implemented thorough logging functionality...

     


  • Discourse touched me in a no-no place

    Looks to be debug, meaningful only to the person who required that debug.



    Unless of course the totality of the logging from this application consists of this sort of crap...



    By the way - are those 'dots' for spaces an artifact of copying that stuff to here, or are they in the output as well?



  • It's obvious, look at the first entry. The system has become sentient and has consumed the totality of all published literature, ever, and is now BORED.



  • @PJH said:

    Looks to be debug, meaningful only to the person who required that debug.

    Unless of course the totality of the logging from this application consists of this sort of crap...

    This is just an excerpt. And you really don't want to see the complete log file in all its glory...

    @PJH said:

    By the way - are those 'dots' for spaces an artifact of copying that stuff to here, or are they in the output as well?

    The dots are copy+paste remnants. Sorry for that.



  • @TheRider said:

    The dots are copy+paste remnants. Sorry for that.
     

    ^- the Real WTF (tm)



  • @TheRider said:

    <font color="black" face="Helv" size="2"></font>

    Anybody understands what is happening here? Me neither. But it is important that those programmers can live in the belief that they have implemented thorough logging functionality...

     

    I disagree. I think it's meaningful enough. There is some long-running read operation. This completed at approximately 13:58:30. Then, the same thread-of-execution began waiting for a message. Almost instantaneously, a valid "ADMIN" message arrived... etc.

    Yes, all of this is somewhat vague. But if you don't even know what sort of I/O the app's supposed to be doing, or if you don't know what an "ADMIN" message is, etc., then the log file is not really the right place to be learning such things. Nor is it the right place for troubleshooting advice. 

    The log you posted looks to me like a natural outgrowth of the development process. The programmers logged the things that were useful to them. That's very logical. One could sit down and spend a bunch of time pondering when to log, and what eloquent phrase to write out, but the log you've posted was actually proven to be useful in real work. That's a rather powerful endorsement and more than I can say about much of what gets written these days.

    I've put out log files not much better than the one you posted. In one case, my manager repeatedly said over the course of months that he was going to rework the phrasing of my messages. I told him that was fine, and I'd gladly implement his messages for him. But I also said that I didn't really think anyone could do much better. The log messages are necessarily just brief, somewhat cryptic indicators. He never did get back to me with those rephrased messages...

    I'd be very curious to see what sort of things you log. Or, what sort of process do you envision for developing log files? 



  •  This reads like some crazy old man muttering to himself. It looks like it would be useful logging for the guy who wrote the code, but if he expected anyone else to ever read it it's meaningless.



  • @bridget99 said:

    The log you posted looks to me like a natural outgrowth of the development process. The programmers logged the things that were useful to them. That's very logical. One could sit down and spend a bunch of time pondering when to log, and what eloquent phrase to write out, but the log you've posted was actually proven to be useful in real work. That's a rather powerful endorsement and more than I can say about much of what gets written these days.
    I agree in so far as these message will probably have helped a particular developer do his job and debug his or her code. But as other people have noted, These message look like utter nonsense to anybody else.

    I've put out log files not much better than the one you posted. In one case, my manager repeatedly said over the course of months that he was going to rework the phrasing of my messages. I told him that was fine, and I'd gladly implement his messages for him. But I also said that I didn't really think anyone could do much better. The log messages are necessarily just brief, somewhat cryptic indicators. He never did get back to me with those rephrased messages...

    I'd be very curious to see what sort of things you log. Or, what sort of process do you envision for developing log files? 

    I usually try to provide enough context in any log message for a reader to be able to identify the exact source, such as class and method names, or name of source file, and provide messages good enough so that searching through all source files reveals the exact location of where the message is produced.


  • @TheRider said:

    Anybody understands what is happening here? Me neither. But it is important that those programmers can live in the belief that they have implemented thorough logging functionality...

    I've found that for most applications, logging is mostly useful for finding things for which to grep through the application source.  This should not be the case, IMHO, but it's what I've found.  Usually, the older an application is, and the more widely used an application is, the less this is true.  For example, sendmail was originally written around 25 years ago, and it's been a couple of years since I saw anything in the sendmail logs that I didn't understand until I went grepping through the source for it.  Oh, wait, that's right - I transitioned from sendmail admin a couple of years ago also.  Sigh.

    (For what it's worth, the vast majority of sendmail logging is decipherable without the source code.  But I do find it sad that, after 25 years, there's still bits that require the source to really understand.  In my years of sendmail administration, I probably only needed to grep source about a dozen times to understand log files.  A dozen times too many.)

    However, one can easily contrast this with an in-house application I replaced early on in my prior job.  It had been written by one person, who intended to support it for the rest of his career.  Sadly, that was over sooner than he expected, and in the next four years, five people supported it and extended it.  As I recall, there were two log lines which it could issue that were readily meaningful: "Program started", which was issued whenever someone started the program, and "Program stopped", which would've been issued if someone sent a TERM signal to the program within about 0.1s after the time logged the first message.  After that, another signal handler stole the TERM signal for its own use, and never gave it back.  The rest of the log messages were far more useless than your sample.  I think some of them were quotes from books - 5-6 of them looked very similar to lines from "the Lord of the Flies", for example.  And then there were those that were almost useful - for example, sometimes it would log an account name.  Each line was date stamped, so one at least had that to go with it, but there were at least four places it could log an account name, and it made no distinction on that line which one did it.  And, every so often, it would abort an operation after logging the bit that identified the routine but before logging the account name.  That wouldn't have been so bad, except that one of those four places was distinguished by the fact that it didn't log a bit that identified the routine, and the aborts didn't log.  (Some did - these didn't.  Until after I fixed that, of course.)

    Thinking back to horrors like this really makes me appreciate my job, where most of the application logging I need to look at comes from one of three commercial applications which produce very nice logs (at least, relative to both of the examples I've mentioned here), which were straight-forward enough I was able to write a log summarizing routine just from looking over the logs.  Since the vendor's finally released text that describes the log format, I've even been able to validate that said parsing was mostly performed correctly.  And, for the in-house scripts and applications - well, I'm on the review board for all code changes, and I can veto bad logging.  Some has snuck through the process, but it's more like the stuff you've posted, rather than the horrors from my past.  And, over time, it gets fixed.


Log in to reply