Perl probe kickstarter (PPK) - Part 3 - Code, debug and deploy

Document created by pmatt on Feb 14, 2017
Version 1Show Document
  • View in full screen mode

Welcome to part 3, if you need to catch up then use the links below.

 

Develop a custom Perl probe with this kickstarter - Part 1

 

Perl probe kickstarter (PPK) - Part 2 - Package and distribute

 

Firstly we are going to make life a little bit easier for ourselves. Rather than compile the code every time, we can simply launch it from a command window. The log will output to that window too so we don't have to open 'View Log' from infrastructure manager.

 

I have attached the perfmonWindow.pl file and will explain the additions below. Make sure you are working in your probe development folder, in this case perfmonWindow_dev.

 

The debug option makes the output to a command window possible. You will find this in the probe initialisation section and restart function.

 

$debug          =     $setup->{debug}        || 0;

 

You will need to add a key called 'debug' with a value of '1' under the 'Setup' section via 'Raw Configure' for your probe. Add the debug value to the log header too, if you wish.

 

Next, we will apply a small patch to the nimLog routine. As long as the debug setting is non-zero, nimLog will copy all output to the command window when you launch it manually. This appears before the doWork() definition and makes use of the 'say' feature which is specified in the use statements.

 

###########################################################
#
# nimLog patch - Will output to STDOUT when debug flag set to 1
{
    no warnings 'redefine';

    sub nimLog ($$) {
        Nimbus::API::nimLog( $_[0], $_[1] );
        say $_[1] if $debug and $setup->{loglevel} >= $_[0];
    }
}

 

Open a command window and drop into your probe development folder. Make sure that your probe is disabled in Infrastructure manager and simply use Perl to launch the perl file: -

 

 

Ctrl-C will stop the probe. You can now begin coding and simply run the file each time and watch the output.

 

When the code is ready to deploy, compile it using pp and drop the new executable file into your probe directory. Set debug back to 0, start the probe and watch the log from Infrastructure manager. If that is all working well, then you can add the executable to the package in the archive. You will need to remove the existing executable first and add the new one. Update the build and version numbers accordingly. Bear in mind that a new version will add a new row to the archive with the same name.

 

 

Finally it's time to code! We need to add a couple more configuration entries as seen below. Either edit the cfg directly or use 'Raw Configure'

 

<setup>
   loglevel = 1
   interval = 15
   logsize = 5000001
   debug = 1
   sendAlarm = 0
alarmSubsystem = CIMA_MAIL_QUEUE
</setup>
<perfCollection>
   <LogicalDisk>
      <% Free Space>
         instance = C:
         ValueHi = 100
         ValueLo = 10
      </% Free Space>
   </LogicalDisk>
</perfCollection>

 

You will notice that these values are pulled out during variable initialisation when the probe starts and also when the probe is restarted. They allow the user to configure the Windows performance counters to watch, the high and low values for the counters and the subsystem when sending alarms. Make sure sendAlarm is set to 1 when you are ready to deploy and send alarms out to the world.

 

     $perfCollection      =      $config->{perfCollection};
     $alarmSubsystem          =      $setup->{alarmSubsystem} || "PERFMONHILO";     

 

The meat and potatoes of the probe is simply pasted into the doWork() function. You can read the comments found in the file attached to hopefully understand the code. The code lines up best in notepad++ or Visual Studio Code.

 

It makes use of the nimAlarm function which is well documented here: -

 

nimAlarm - Perl SDK reference

 

Here is the probe in action, please leave a comment if you have any questions.

 

1 person found this helpful

Attachments

Outcomes