Server Plugin Arrangement

Navigation:  Limits > Command Line Tools > lve-stats 2 > Creating a Plugin for LVE Stats 2 >

Server Plugin Arrangement

Previous pageReturn to chapter overviewNext page

When the server starts, it performs the search of plugins in the directory specified in /etc/sysconfig/lvestats2 configuration file. This directory is scanned only when the server starts, therefore if any plugin was added into the directory, the server has to be restarted with the following command:

 

service lvestats restart.

 

After successful restart the plugins are graded and executed  ascending by order attribute. If any plugin's order attribute is not set, it is considered as a Python language constant sys.maxint (which is usually 9223372036854775807). This in fact means that such plugins will be executed in the last.

If any plugins has similar order meanings, their execution order is unpredictable.

 

The server invokes execute method of all plugins one after another.

 

When the server invokes execute() method of any plugin, it transmits a data dictionary (lve_data argument) into plugin. The dictionary is common for all the plugins. Any plugin can read, write and change any data in this dictionary. LVE Stats 2 server doesn't control this area. That is why one must be careful while developing new plugins, in order not to change or corrupt other plugins' data which can break their functionality.

 

If an exception occurs in execute() method, its text and python stack trace is recorded into server log /var/log/lve-stats and all the changes made to lve_data dictionary before the exception happened are lost.

 

The keys of the lve_data dictionary are recommended to look like “PluginName_Key”, in order the plugins do not corrupt other data accidentally.

 

Server contains some standard plugins which define and use the following keys in the common dictionary lve_data: LVE_VERSION, stats, old_stats, procs and lve_usage. User plugins can use data from these keys, but it is recommended not to change them if there is no special need, because it can break the next plugins in the execution queue.

 

Key

Content

LVE_VERSION

LVE version. The same as console command lvectl lve-version produces.

stats

Dictionary, that contains lve id’s as keys and LVEStat class objects as values. Every LVEStat object contains values of usages and limits taken from     /proc/lve/list file for every LVE Id. Dictionary keys – integer lve id, including 0 for “default” LVE. This dictionary is updated on each iteration of lvestats-server (every 5 seconds by default).

LVEStat – is a standard server class, it can be imported with the command from lvestats.core.lvestat import LVEStat.

The class is described in the file /opt/alt/python27/lib/python2.7/site-packages/lvestats/core/lvestat.py.

Here you can find the whole list of data fields and their functions.

old_stats

stats content from the previous iteration. Before the first iteration – empty dictionary.

totalHz

When LVE_VERSION is 4, real CPU frequency in Hz multiplied by number of cores.                        

When LVE_VERSION > 4, CPU speed is in conventional units and equals to 1000000000 * cores (1 GHz per core).

procs

Quantity of CPU/cores.

lve_usages

Contains accumulated LVE statistics for each 5-seconds interval in current minute. Cleared each minute.

lve_usage

Contains aggregated LVE Statistics for “previous” minute to store to database. Overwritten each minute.

 

Each plugin’s instance lifetime is from the moment it was loaded till the server stops working. But if execute() method working time exceeds timeout, the plugin will be terminated and restarted in the next iteration. All changes to the lve_data dictionary will be lost.

 

During servers graceful shutdown (restart, server shutdown, commands service lvestats stop, service lvestats restart), each plugin receives SIGTERM signal.

This is useful to correctly unload the plugin (terminate all subsidiary processes, save data to files etc.). If a plugin doesn't need to “finalize” its execution before termination, then there's no need to implement this signal handler. Below you can see an example of such handler.

 

Note: If a plugin implements handler for SIGTERM, then this handler must end with sys.exit(0) command. Otherwise plugin process will not be terminated correctly and will become orphaned.