Test Environments
[posted 2007/01/08]
[Notes (edited slightly) issued with the release of PIKT 1.19.0pre1, which: introduced several new alarm status settings, among them 'testing'; implemented a new built-in define, pikttest; and reformulated the '-T' command-line option to activate the new pikttest define, and in general to set up special test environments.]
Most of the recent PIKT development has been devoted to deepening and easing the administration of test environments. What follows is rather advanced material. PIKT beginners should probably ignore many of these new features and only make use of them later when they are experienced and have greater understanding of the PIKT system as a whole.
Before, there were just two alarm status settings: active & inactive. Now there are three more: suspended, debugging & testing.
Suspended status is like inactive status. Alarm scripts don't run in either case. Here is the difference: Suspended status is always logged, while inactive status is only logged if verbose_log (in PIKT.conf) is set to true. (You might then schedule a log scanning script to remind you of suspended alarms on a regular basis.)
In debugging status, it's as if the 'pikt -G' debuG option were set but only for the scope of that alarm. In debuG mode, additional debugging information is output to stdout or logged.
In testing status, alarm 'exec' and 'exec wait' statements become effectively 'output' (or 'output mail'), and command strings are reported and/or logged rather than executed.
A new built-in PIKT define has been implemented, pikttest. It operates much like a regular test define, but with the following difference: You would set an optional and user-specified test define in defines.cfg using 'test TRUE' and elsewhere using '#setdef test = TRUE'. You might also specify 'test FALSE' in defines.cfg, and undefine test elsewhere using '#setdef test = FALSE'. With pikttest, however, the piktc command-line option '-T' globally sets pikttest to TRUE, and once set, it remains set, i.e., cannot be changed in defines.cfg or anywhere else using #setdef.
The 'piktc -T' and pikttest tandem is therefore just a quicker and more convenient way to activate test mode globally. Presumably you would have
#ifdef piktttest
...
#endifdef
positioned at various places around your PIKT configuration to activate (or not) special testing environments. 'piktc -T', together with the pikttest define, allows you to conveniently enter test mode site-wide.
Before, the '-T' command-line option was used during the PIKT 'make check' to test PIKT operations after the binary build but before the binary installation. Now, '-z' performs that function, and '-T' has been reformulated to set general test environments for any PIKT binary operation.
So, for example, 'piktc -T' sets the global, built-in pikttest define (invariably) to TRUE; sets the new =pikttest built-in macro to "test" (or some other string you set in PIKT.conf using the pikttest_substitution parameter; otherwise, the =pikttest macro defaults to the null string); and appends '-T' to any pikt command string that piktc writes to piktd.conf.
'piktd -T' logs pikt commands at the specified times in piktd.conf but doesn't actually exec them.
'pikt -T +A Foo' effectively forces a 'status testing' across all alarms in the Foo alert group (and therefore command strings are reported and/or logged rather than executed).
('piktc_svc -T' has no special effect at this time.)
You may now specify alarm status and severity levels on a per-alert basis in alerts.cfg. For example, in your Urgent alerts specification (in alerts.cfg), you might have
Urgent
...
#ifndef pikttest
status active
#elsedef
status testing
#endifdef
level urgent
...
Then, for any alarms you specify (in alarms.cfg), you might have
ScanSyslog
init
status =piktstatus
level =piktlevel
...
When the ScanSyslog alarms is installed on the PIKT slave system, this would actually be written as
ScanSyslog
init
status testing
level urgent
...
if 'piktc -T' were used and therefore 'pikttest = TRUE' were in effect.
The combination of specifying status and level in alerts.cfg and referencing =piktstatus and =piktlevel is thus a handy means of enforcing status and level consistency across all alarms in the alert group. Note that you are not required to use =piktstatus and/or =piktlevel in your alarm definitions. Override with specific status and level settings on a per-alarm basis if you wish.
With the new =pikttest macro, in alerts.cfg you might do something like the following:
SysAdminsUrgent=pikttest
#ifndef pikttest
timing
35 */2 * * * 5
#elsedef
timing =testtiming(40)
#endifdef
mailcmd "=mailx -s 'PIKT Alert on =pikthostname: Urgent' =sysadmins-urgent"
lpcmd "=lp =piktprinter"
#ifndef pikttest
status active
#elsedef
status testing
#endifdef
level urgent
alarms
#ifndef pikttest
ProcessSystemDead
LoadAverage
ProcZombieCounts
DmesgRedFlagsScan
#elsedef
CPUUsage
#endifdef
Using 'piktc -iv +A SysAdminsUrgent +H all', you would install a SysAdminsUrgent alert on all systems with the alarms ProcessSystemDead, LoadAverage, ProcZombieCounts, and DmesgRedFlagsScan, with all alarms in active status, and to run at the timings indicated.
Using 'piktc -ivT +A SysAdminsUrgentTest +H all', you would install a special test-mode SysAdminsUrgentTest alert on all systems with just the CPUUsage alarm, in testing status, and to run at the special =testtiming(40) interval (where =testtiming is a PIKT macro defined (in macros.cfg) as, say,
testtiming(M) (M) 0-6/2 * * * 1
Presumably, you would also specify (in macros.cfg) the =sysadmins-urgent mail-recipient macro to send SysAdminsUrgent alert messages to all the usual people, but for SysAdminsUrgentTest, send test alert messages only to the =piktadmin (just one or maybe two persons, also specified in macros.cfg). These are advanced topics, and beyond these hints we will have nothing more to say about them here.
For more examples, see Developer's Notes.
