• Antelope Release 5.5 Linux 2.6.32-220.el6.x86_64 2015-04-21

 

NAME

q330logs2db - monitor q330 log files for particular phrases and add to a db table

SYNOPSIS

q330logs2db  [-p pf] [-v] [-l match_logname] [-s {OLDEST|start_time} | -S statefile ] orb db

SUPPORT


Contributed code: NO BRTT support.
THIS PIECE OF SOFTWARE WAS CONTRIBUTED BY THE ANTELOPE USER COMMUNITY. BRTT DISCLAIMS ALL OWNERSHIP, LIABILITY, AND SUPPORT FOR THIS PIECE OF SOFTWARE.

FOR HELP WITH THIS PIECE OF SOFTWARE, PLEASE CONTACT THE CONTRIBUTING AUTHOR.

DESCRIPTION

q330logs2db monitors log packets produced by q3302orb(1) to find rows which match a regular expression. The simple match (and reject) expressions are kept in a parameter file, q330logs2db.pf. The matching lines are placed as a dlcomment into a dlevent table and tagged with a dlevtype. See also the programs logs2dlevent(1) and dlreport(1) which review the logs written out by orb2logs(1). dlreport can be run to summarize the events. The parameter files for q330logs2db and logs2dlevent are identical.

The intent for this script is that it will be run on an operational real-time system to help summarize various interactions with the datalogger (currently only tested on a Q330). It assumes that interactions via Willard are noted with a UMSG or via output from dlcmd. Hopefully, you can convince those who interact with the datalogger via a UMSG to use standard phrases... otherwise this script might be of little use except for capturing commands send by the data center. If the output from dlcmd changes, this script will likely be less effective. There have been multiple changes in the message format for q3302orb over the years, so results may vary depending on your log vintage.

OPTIONS

PARAMETER FILE

This is an example parameter file:


#
# q330logs2db.pf
#

match &Tbl{
UMSG
recenter
massrecenter
masslock
massunlock
getconfig
getannc
getstatus
reboot
}

reject &Tbl{
#Processing
sbpwr
Baler
dopen
QMASERV
C1_UMSG
Error
Sending
Issuing
}

dlevents &Arr{
#	dlevtype	log_phrase
	service		UMSG
	massrecenter	recenter
	massrecenter	massrecenter
	sensor_lock	masslock
	sensor_unlock	massunlock
	sensor_cal   	calibration
	request_config	getconfig
	request_annc	getannc
	request_status	getstatus
	baler		Baler
	reboot		reboot
}

convert_umsg &Arr{
# UMSG_comment_phrase	dlevtype
        massrecenter    massrecenter
        recenter        massrecenter
        center          massrecenter
        MRC             massrecenter
        mrc             massrecenter
        unlock          sensor_unlock
        lock            sensor_lock
        Cal             sensor_cal
}

Which log strings are kept are controlled by:

How the strings are mapped to dlevtypes is controlled by:

EXAMPLE

Run as part of an operational real-time system. Put the following task in the Run Array.

q330logs2db	q330logs2db -p pf/q330logs2db -S state/q330logs2db $STATUSORB $DB

Capture all information available in the status ORB starting with the oldest packet.

q330logs2db -s OLDEST $STATUSORB $DB

Capture all information available in the status ORB starting with data from 11/1/2008

q330logs2db -s "11/1/2008 00:00:00" $STATUSORB $DB

SEE ALSO

dlreport(1)
dlcmd(1)
logs2dlevent(1)
q3302orb(1)

BUGS AND CAVEATS

This has only been tested on output log packets from q3302orb(1).

This program has not been tested for memory leaks.

The field size for the dlcomment is only 120 characters. I do not know what the limit on a UMSG size is so you may overflow the field.

It may take some adjustment of the parameter file to get (or reject) various events that you might find interesting.

Greps of strings from log packets which change format over time are obviously prone to errors. You may not get all of the information you want in the dlcomment field.

AUTHOR

Jennifer Eakins
ANF-IGPP-SIO-UCSD

Antelope User Group Contributed Software
Printer icon