Error & Info Logging

(NOTE:  Some of the techniques shown or described on this page--marked in purple--require new features in the latest official PIKT 1.19.0 release (pikt-current.tar.gz) that are unavailable in any previous version.)

When run in debug (-G) mode, PIKT binaries do error and info logging to stderr.  Otherwise, they write to various program-specific log files.

Every time piktc sends a service request to a client system, this is logged in its =piktdir/var/log/piktc.log file.  With piktc, sometimes additional, technical information is logged to piktc.log, but most errors are reported to stderr.  In particular, 'piktc -G' will report file preprocessing information as it happens, also complete authentication information, as in

# piktc -ivG +A =alerts +H copenhagen

Apr 17 01:54:41 copenhagen piktc[32016]: [ID 0 DEBUG] (../../../src/piktc/piktc.c,
line 1089, preprocess()) preprocessing file /pikt/lib/configs/systems.cfg
Apr 17 01:54:41 copenhagen piktc[32016]: [ID 0 DEBUG]
(../../../src/piktc/include.c, line 53, instrmopen()) preprocessing file
/pikt/lib/configs/systems/down_systems.cfg

...

Apr 17 01:54:47 copenhagen piktc[32016]: [ID 0 DEBUG]
(../../../src/piktc/include.c, line 53, instrmopen()) preprocessing file
/pikt/lib/configs/alarms/test_alarms.cfg
Apr 17 01:54:47 copenhagen piktc[32016]: [ID 0 DEBUG] (../../../src/piktc/piktc.c,
line 1089, preprocess()) preprocessing file /pikt/lib/configs/alerts.cfg

processing copenhagen...
Apr 17 01:54:47 copenhagen piktc[32016]: [ID 1 INFO] probing rpcinfo on copenhagen
Apr 17 01:54:47 copenhagen piktc[32016]: [ID 1 INFO] program 392205847 version 1
ready and waiting
installing file(s)...
Apr 17 01:54:50 copenhagen piktc[32016]: [ID 1 INFO] install_file request to host
copenhagen
Apr 17 01:54:50 copenhagen piktc[32016]: [ID 0 DEBUG]
(../../../src/piktc/rpcclnt.c, line 2510, get_key()) key (keysan) is
59b8a3f4cd6a15422c8e6d4b8465af2f, keysum
is 1dcd8112e16df70c8e4ddb433f02a461, keyenc (keyencsan) is
v....[..u..3A}..2..L\.......N+.?, keyenclen is 32

...

So, using 'piktc -G', you can monitor the progress of piktc as it goes about its file preprocessing.  Equally important, if piktc were to hang on some #include'd process, you can use 'piktc -G' to determine the point of the hang.

In general, PIKT logs daemon (piktc_svc and piktd) starts and stops and daemon failures to the appropriate log file (piktc_svc.log and piktd.log, both in =piktdir/var/log).

piktc_svc logs, to =piktdir/var/log/piktc_svc.log, every service request it receives.  If piktc_svc receives a request from an unauthorized account or system, it flags this as an "ERROR".  You can use other log file monitoring Pikt scripts to alert you to this possible security violation.  You can also have scripts to analyze and compare the piktc.log and various piktc_svc.log files to verify the validity of service requests.

Every time piktd launches a Pikt script, it logs the invoking command in =piktdir/var/log/piktd.log.

As for pikt, each alert is assigned its own log file.  For example, the Urgent alert's log file is Urgent.log (also found in =piktdir/var/log).  In alert log files, the following things are logged:

• alert run startups and normal/abnormal terminations
• errors (marked by "ERROR"), whenever a serious error is detected (e.g., attempted divide by zero, or the appearance of a negative array index); depending on the seriousness of the error, the pikt run may or may not abort prematurely
• warnings (marked by "WARNING"), whenever a possible error condition is detected (e.g., whenever interpreting a number as a string, or when a file is not found); warnings never lead to premature aborts
• external command invocations (e.g., for every "exec" statement, or whenever #system() or $command() are invoked); the idea here is to log each time PIKT reaches out to impact on the external environment, useful for later debugging
• anything that an exec'ed statement, $command() call or #system() call outputs to stderr; this is useful for determining why a script mysteriously fails; such log entries are not date/time-stamped--you can use this fact within log monitoring scripts to identify such entries and thus report stderr dumps

Every log entry is stamped with the current date and time, the system name, the PIKT program generating the log entry, its process id, a numerical error id, and an error level.  For some log entries, the source file, the line number in that source file, and the function where the logging occurred might also be shown.  Here is a typical log entry:

Oct 14 09:37:25 vienna pikt[24009]: [ID 7501 WARNING] in
  SysBakSubnetDownEmergency, resolving number 30.000000 as string 30

Alert logs can grow quickly in size, if a script is run often enough, if it analyzes lots of data, and if it produces many warnings (through, e.g., repeated number-to-string conversions).  You should seriously consider putting in place PIKT alarms to monitor your alert (and other) logs, truncating and/or compressing-and-archiving them when they reach a certain size.  (See the examples.)  You should also set 'verbose_log' to 'no' in PIKT.conf, except when debugging.

If auto_syslog is set to 'yes' in PIKT.conf, in addition to the logging described above, all program outputs (for example, from Pikt 'output', 'output mail', etc.) are sent to syslog at facility local0.  You can, using the syslog_facility parameter, set this to any of local0 through local7 instead.

This automatic routing of all program outputs to syslog is especially useful if you have configured syslog (via the appropriate syslog.conf settings) to send along all messages to a central loghost.  You might do this to archive all PIKT messages, or to process them all at one point for purposes of graphical display.  You might also find it useful to send all EMERG-level messages to all root logins, for example.

prev page

1st page

next page