Advanced functions for developing a Knowledge Module

This section covers information about building advanced functions in the PATROL Knowledge Module (KM). 

Working with PATROL Autonomous Agents

PATROL architecture is based on autonomous agents. Autonomous means that the agents should be able to run at all times, without any consoles or other clients connected. The agent's execution engine allows for automation of some problems, thus giving operators more time to work on specific problems that need their attention. To utilize automation capabilities, you must program "intelligence" into the agent.

When you install and run an agent out-of-the-box, it waits for you to tell it or configure it to do something. To provide the PATROL Agent with intelligence, you will write knowledge modules (KMs). Then, when the PATROL administrator loads the KM, the agent starts executing the code written in the KM.

This section provides developers with information about what they can do with an agent, and the agent tasks performed by an operator or administrator. Also information about how to install, start, or configure the agent, how to load KMs, or how the PATROL user interface works is presented to help you get started.

Working with PSL

The PATROL Script Language (PSL) is a powerful tool with vast capabilities. Although you will use PSL for KM development, there are areas of the agent that you must not modify.

All the agent tuning parameters are stored in the PATROL configuration database, pconfig, which developers have access to. However, it is important that your KM does not modify variables that influence the agents operation. For example, a KM must never automatically modify the /AgentSetup/preloadedKMs value to enforce persistency or modify the agent's tuning variable. Changing these values must be handled by the PATROL administrator. These configuration settings influence more than just the operation of your KM and can change the agent's impact on the system. For more information, see Understanding PATROL Script Language (PSL) and its design.

Thinking Beyond Your Own Environment

Sometimes developers write code as if their development system, in their development environment, is representative of all systems that will run their code. This assumption can potentially lead to problems concerning scalability, performance, and usability. Although your development system might look "average" to you, it is likely that the code you develop will be run on systems larger or smaller than your own.

If you write a KM to monitor a specific application (for example, a Web server), are you aware that some users might actually run 100 instances of this application? In addition, these users might not want all the detailed information that you make available for this single Web server. Maybe they want the ability to toggle between overview monitoring and detailed monitoring modes.

It is important to think beyond your own environment because a customer considers their own system to be an average system. Also, consider what you offer concerning optimization. A KM that can potentially be installed on a large amount of systems must be tuned as much as possible. For example, if you can reduce 1 percent of CPU from overall CPU consumption of your KM, this makes a considerable difference to someone running the KM on 1000 systems.

More is not always better

One of the powers of PSL is the ease to extend current functionality. You must determine the level of detail you want to present before actually writing it. Most developers don't have a problem not writing something, but hate the idea of removing something they already wrote.When a developer starts writing a KM, usually the application is researched for metrics that could be exposed. After a list of metrics is compiled, the developer verifies if these metrics make sense. The proper way to do this is by asking someone close to the application which parameters one could be interested in. This becomes the basic functionality for the KM. Often the developer presents the list of parameters and ask which ones are really not needed. This approach is the same as walking with a kid in a candy store and then asking the child for the items the kid wouldn't like to have. You will probably end up buying a lot more than if you would have asked the question what candy you must bring when you go to the candy store.

It even gets worse if the developer hasn't properly researched the application and just starts writing code from the user or API documentation. The amount of data presented in the KM will be huge, but the value or information probably minimal. It is the task of the developer to be as creative as possible to turn this data into information without over using code cycles, CPU cycles or memory.

Nesting or over nesting

PATROL allows for nesting of instances. Although this GUI feature can make the representation of information more structured, it can also make it a big effort for an operator to find the information he is looking for. One of the warning sign of too deep nesting is probably if you are nesting more than 6 levels deep, if your design nests this deep, you might want to consider restructuring your information, because it might be hard for an operator to find the needed information. It might make more sense to just remove some of the KM that are nested so deeply and replace the information with menu commands that will be generated when the user needs it.

Look for the exception

Before you consider yourself ready to start coding, imagine the situation where everything on every server goes into alarm. Do you create additional instances when something is in alarm (for example an instance for every log entry)? Would it still make sense to show all that info?

Will your KM spawn a response functions to warn someone in a certain case (let's say application is switched to maintenance mode)? How would you feel if you see behind a terminal and suddenly all your 1000 computers go into alarm because your application was in that mode? While you are going through all the potential failure situations, also check for the all-OK case. Do you have any instances that no one will ever look at or need reporting data for while everything is going well?

Maybe you shouldn't create the instance unconditionally.

Use all your knowledge

One of the most effective ways to prevent the Christmas tree effect (all instances turning red) in your KM would simply be to define no alarms at all on any of the parameters and leave it all up to the customer. But why do you think the customer will ever buy KMs? Usually because it shows intelligent, specific knowledge about the application and because they feel quite con dent that they will be notified of problems. So if you never implemented alarms or intelligence in your KM, you are not delivering to the customer what they expect and you will not sell many KMs (you might even never pass the part of the sales cycle). Again research will be important. When you decide to implement a certain metric as a parameter, always ask yourself if the value of this parameter is always good (usually parameters for reporting) or if there are any exceptions you should take into account.

For example, you are writing a KM to monitor hardware and one of the values indicates the "internal temperature". When you write your KM, you set the value of the parameter to 70 C. The next thing you must do is look in the manual for "operating temperatures" and set the maximum and possibly minimum values. If you cannot find this in the manual, then you must call support for that application to find out what the nominal values are. Remember, if you do not do it, the customer will eventually have to do it and they will probably not value the KM very high.

After you define these alarm ranges, you must check if there are recovery actions you can take. Most people will require a toggle on any recovery actions you provide (default=off, for demos you want all bells and whistles enabled). An example recovery action would be to turn the speed of the hardware momentarily down, so it can cool a bit. You must never forget that you have to be able to recover from a recovery action and return to normal operation after the temperature has dropped.

Thinking Like a Customer

Before you start coding, spend some time thinking as a customer. Draw your design on a piece of paper and imagine the code already written. This will help you prevent usability errors that could seriously impact the KM and it's design. For every instance you create, think what the user would expect to find underneath. Check if it makes sense to create all the parameters and see if the location of the menu commands make sense.

A customer is usually not interested in if you can do it; but is more interested in how well you can do it.

This section contains the following topics about building advanced functions: