Prediscovery and discovery
To understand why prediscovery and discovery exists, we must review the development of PATROL. A long time ago (first versions of PATROL), the agent was not console independent (and therefore not autonomous). If a console connected to an agent, the agent would download all required knowledge from the console. Because the agent didn't store the KM's, they had to be resent to the agent each time a connection broke and was reestablished. This caused a significant amount of overhead on the network, since in a lot of cases a downloaded KM wouldn't even run on an agent, because the application was not installed.
At that time there was only something called discovery. Discovery was the first script that was ran right after the KM was downloaded to the agent. Because in a lot of cases discovery would find out that the application was not installed, it was decided that it would be beneficial to introduce a step before discovery. Prediscovery was born.
If the prediscovery script existed, it was unconditionally downloaded to the agent. Only when prediscovery signals the agent that the active state of the application changed to 2, the KM would be downloaded.
Later (PATROL 3), the agent was fully autonomous and the real need for having prediscovery or discovery went away, but by then it had introduced a whole new way of developing KM's so the features were never removed in later versions.
Because some customers wanted to prevent KM's from being loaded altogether, based on some very simple rules, the allow on and deny to fields we added to the KM's property tab. These will be translated as pragma statements in the KM file. When an agent now loads a KM, the pregame's will be checked first, then the agent will check the agent configuration database for disabled KMs and if this succeeds then the KM will eventually be parsed.
Discovery Cycle
The Discovery Cycle is the process of going through prediscovery and discovery. This section will explain what this is all about.
Prediscovery and discovery process
Prediscovery versus discovery
After the KM has been parsed by the agent, the agent will determine the setting of the active attribute. The initial value of active is determined as follows:
- If prediscovery exists: 1
- Prediscovery doesn't exist: 2
Depending on the setting of active, the agent will start either create a prediscovery or the discovery process. These scripts will not be compiled unless they are about to be run. That means prediscovery can be used to check availability of a library (and load it) before discovery is run. Discovery can then safely require the library. It is strongly recommended never to require libraries in prediscovery.
If you safely want to check for existence of a library, use the following:
function libtest(lib)
{
local warn,alarm;
# Check if lib is installed and loadable by the agent
# This is to prevent the compiler from complaining on use before set
warn = "";
alarm = "";
# Call PSL execute. The compilation results will be stored in
# the warn and alarm variables
PslExecute("LIBTEST","requires ".lib.";",warn,alarm);
# If we had a compilation warning or alarm, return 1
return((warn jj alarm ) ? 1 : 0);
}
if ( libtest ( "mylib.lib"))
{
print("Unable to load library mylib.lib");
exit;
}
# Although you might be tempted to just load the library now, you should not.
# For more information, refer to the chapter on libraries.Discovery and prediscovery processes
The discovery process is a lightweight process in the agent (special type of process) that will be executed each after each discovery interval. After each discovery interval, the agent will check the active flag of the application to find out if the discovery or prediscovery process must be run. The process will only be started if it was not running before.
Discovery Cycle
A lightweight process can be seen as a high priority rtcell for the RUNQ scheduler and will therefore not be delayed in its execution.
All applications that use the default discovery interval (40 seconds) will be scheduled from the same lightweight process and the evaluation of active will start one after the other. The order for which KM will be checked is the same as the KM loading order.
Every KM that has its own discovery cycle will create its own lightweight discovery processes. If you don't require a 40 second execution of your discovery scripts, you must modify the discovery cycle for your application.
Coding style
Although prediscovery can be left empty, it is recommended that you not leave it empty. If you want to skip prediscovery and execute discovery directly, type the following command in your prediscovery script:
set("active",2);If you don't need prediscovery nor discovery at all, type exit in the command.
Historically, the most common check to make in prediscovery is to check that the KM is not running on an incorrect agent platform. This can be done by examining the /appType variable however, it is a lot better to use the allow on and deny to fields in the KM property window.
Some people believe that the discovery process has to be the place where application instances get created. Although this is probably true for at least one KM you write, all the instantiation can then happen from any process running on the agent. There is nothing bad in having only exit statements in both prediscovery and discovery. We will talk more about instance creation in the next section.
Full and partial discovery
PATROL doesn't know the difference between full or partial discovery. This is more or less the concept of trying to execute as few PSL instructions in discovery as possible (remember that by default the schedule is 40 seconds).
The idea behind full discovery is usually when your application was just loaded and still needs to find out all the details and perform setup of the KM. This step is supposed to be more expensive than partial discovery, where only an update to the current discovered environment needs to be made.
Although PATROL has no hardcoded states to support full or partial discovery, it provides some functions that can make it easier to check if some checking can be skipped.
If your discovery relies on the process() function, there is no need to execute the discovery script unless the PATROL internal process table was refreshed. The PSL full_discovery() command indicates that a refresh of the process cache has happened since the last time discovery was run. This function has not other purpose than notifying you the process cache was refreshed although some people seem to think there is something magical about it.
If your discovery is based on a configuration file, your initial discovery cycle will have to read this file completely. After this initial setup, it would be good to check if the file changed since the last discovery cycle. If it hasn't there is no need to set everything up again. You can use the file () function as a test to determine whether the file has changed. This function will return the last modification time of the file. You can save the time stamp in a global variable.
Checking for file updates in discovery tabsize
# Set the filename
filename = "/opt/conf/config.txt";
# get the timestamp of our config file
timestamp = file(filename);
# get the old timestamp
# if first time it will be initialized to 0
oldtimestamp = get("oldtimestamp");
# if timestamp still the same, exit
if (timestamp == oldtimestamp)
{
exit;
}
# Now do your "partial" discovery....
# save the new timestamp
set("oldtimestamp",timestamp);Unique features of discovery
The discovery script is the only script that will execute on application level and will run even if no instances have been created.
Unique features of discovery
The discovery script can be used to collect data as well (just like any PSL script). In case you have a command that will return data for all instances of your application class, then you might want to consider putting the command in the discovery script. However, make sure to remember to update the discovery interval in that situation. Change it to the same scheduling you would have used if the collection logic was in a parameter.
Discovery pitfalls
The following figure conveys a few of the pitfalls that you might with discovery.
Discovery pitfalls
Prediscovery and discovery running together
The agent will react immediately when the value of active is changed.
set("/APPL/active",0) in any PSL script immediately destroys objects. set("/APPL/active",2) immediately launches discovery (when it was not running yet), even when the agent is currently executing pre-discovery.
Since it is possible to have both discovery and prediscovery running at the same time, you should be aware that this can result is some very bizarre results.
To make sure you don't encounter this issue, it is a good practice to only have a single set("active", ...); call in either the prediscovery or discovery script. If you have multiple statements that modify the active flag then type a exit; function after these statements.
Active determines what to execute
Some people think that only discovery keeps running and prediscovery can only be executed once. This is not true. The value of active will determine what to execute and it is perfectly possible to have a KM that will only use prediscovery and never go to discovery at all.
Comments
Log in or register to comment.