Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jdavidb (1361)

jdavidb
  (email not shown publicly)
http://voiceofjohn.blogspot.com/
J. David Blackstone has a Bachelor of Science in Computer Science and Engineering and nine years of experience at a wireless telecommunications company, where he learned Perl and never looked back. J. David has an advantage in that he works really hard, he has a passion for writing good software, and he knows many of the world's best Perl programmers.

Journal of jdavidb (1361)

Wednesday April 19, 2006
12:43 PM

Instrumenting your code

[ #29375 ]

How do you instrument your code? Almost all of my code runs automatically as scheduled jobs, and I code with the principle that I don't want to see any output at all unless an error or unexpected condition has occurred. If I need to dig into the inner workings of a program, I add debugging statements and then receive the result in my email (from a cron job) or to the terminal (when I run it from the command line).

Meanwhile, the other folks throw all kinds of junk into a log file in /tmp. Very, very hard to wade through.

Cary Millsap's Optimizing Oracle Performance remarks that through the years Oracle has provided more and more instrumentation to allow you to figure out what is going on inside. They do a lot of great performance work by parsing Oracle log files and sticking the results into database tables for manipulation.

Meanwhile, from the same folks, I noticed this seminar with an Oracle expert has a one hour session entitled "Instrumentation 101." Sounds like something I'd love, but my interest for some of the rest of the seminar contents is low at this time.

But I really would like to get into instrumenting my programs in a better way. I don't want to spew junk to a log file, and I want to know what happened prior to an error when I receive one in email. It probably all needs to be in the database somewhere. We're already seeing some mandates to start collecting some basic statistics. What do you do?


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Instrumenting your code 4 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I would hazard a guess that you could do something like this log4perl. You'd need to configure some appender to record the last (say) 100 log lines at debug, in memory, in a circular buffer. When the crash hits, mail them off.

    -Dom

  • NASA finally open-sourced an older version of the CGI stuff I worked on for them. I seem to remember a Perlier logging class in there somewhere that I should clean up and re-release.
  • I think the main problem with logging is that initially you don't really know what information will be useful so it's best to log much more than you think you will need. For me this also applies to the format of the logs -- I just don't know what will be the best format to delog when a problem does occur. For some apps it seems that certain types of logs (e.g. text) are just hard sift through, when for others those same types work great.

    If you use something like log4perl or Log::Dispatch, as suggested ear

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.