Translations of this page:

Instance Management

We can create new instances or edit and modify the existing ones through the instance management. We are going to see how these tasks are accomplished as well as the screens associated with the process. It is really simple.

Creating Instances

An Instance is created whenever a new element is to be monitored. In order to do this task we should go to the main screen of the Instance manager (click on the management tab). As the picture shows, there is a button with the ‘+’ symbol. Click on this button to create a new instance in Osmius.

osm_gestion_func_botonaltainstancia.jpg

We will see now the creating instances screen, where all the data related to the new instance is requested. Now with Osmius we can add one or more instances of the same type from this screen, and we can assign Master agents, services, for all the instances easily. The necessary data to add new instances is detailed below.

osm_gestion_func_pantallaaltainstanc1.jpg

  • Type: enter here the instance type for the new instance. This is a very important step, as on it depends the way Osmius will connect to the instance and request the events to be recognized by the instance. More info available in: Type of Instance
  • (Download Template): With Osmius you can add a lot of instances of the same type via .csv file. Clicking here you can download a template (.odt) file that help you to assign a lo to instances.
  • CSV: The .csv file with all the instances, you can upload it to the application an automatically the list below will be loaded.
  • Delete button: This button is used to deleted old the mark elements (instance configuration data) from the list below.
  • Check: This check is used to delete elements in the list.
  • Identifier: this is an alphanumeric string up to 8 characters long that we should provide for the identification of the new instance.
  • Description: we can add a text to provide further information about the instance.
  • Connection information: this is the necessary information to reach the instance. Whenever this information is required, we will have a help text explaining the way we should provide the details. The picture shows that the upper line displays a prototype of the connection information expected, whereas the text box right below is for the specific connection information for the new instance.
  • Node Name: this information will be used to define the source of the data, and it will help the operator or the event supervisor to identify the source of the information and the potential problems. In case this information is not provided, it will use the hostname running the agent in charge of questioning the instance.
  • SNMP Community: in instances that could be monitored via SNMP, this field indicates the community.
  • SNMP Port: in instances that could be monitored via SNMP, this field indicates the port.
  • Add button: adds a new row in the list to insert data for a new instance.
  • Groups: here we can associate a group to the instance so that afterwards we can perform actions over the entire group, like applying authorizations to the whole group (affecting all the instances that are part of the group) or creating views exclusively over the events of certain group. Is mandatory to assign at least one group. You can create, delete and manage groups in the Security tab. In order to add the instance to one group all you have to do is select this one in the drop list that is shown by clicking over Groups button.

osm_gestion_func_groups.jpg

Configuring Instances

Now that we have supplied the minimum necessary information for the new instance/s, we can provide (or not) another information relevant to the instance/s.

  • First we can assign one or more Master Agents to monitor the instance/s.

osm_gestion_func_pantallaaltainstanc3.jpg

  • Second we can assign one or more Services to the instance/s.

osm_gestion_func_pantallaaltainstanc_services.jpg

Again it works similarly to the group assignment section.

On some type of instances, we can also assign a trap agent to monitor traps.

 Trap Agents

  • Third we can modify the events parameters of the instance. By default, a template is loaded automatically when we choose the type of instance.

osm_gestion_func_pantallaaltainstanc2.jpg

  • OIDs Seeker: when we want to monitor an event via SNMP we need the OID identifier. Clicking on this button opens a new window when we can navigate through different MIBs in an easy way.
  • Template Id.: we can create templates for each type of instance. This will help us to configure the instance faster and more efficiently. By default Osmius provides a predefined template called Default template for each type of instance. Clicking on the Load template button will display the types of event for that type of instance with a standard configuration.

We have several options depending on what we want to do:

  • In case we agree on the proposed configuration, just click on the Apply button..
  • In case we want to make changes to the events configuration, but only a specific change for a given instance, we can enter the changes and click on the Apply button.
  • In case we want to change the default template or create a new template we will proceed to change the events configuration and once we are finished, click on the Save template as, therefore saving the changes in a new template that we can use for other instances of the same type.
  • In case we have erroneously changed the configuration and we want to restore the configuration of the original template then click on the Reload button.
  • This is also for events traps who once set Event Traps can be enabled or disabled in this screen. Should be noted that we have to set “Node Name” (Creating Instances) to the trap host sender if we want to receive these events .

osm_gestion_func_pantallaaltainstanc4.jpg

Once we have clicked on the Apply button for the previous section, we get to the last step of the creation and configuration of a new instance.

Editing Instances

You can modify the configuration if the instances from the following locations:

Tree of Services

From the tree of services, located in the Events View screen, we can manage the configuration of any instance through the context menu of the instance and then choosing Edit instance.

osm_gestion_func_arbolserviciosedit.jpg

Tree of Instances

The tree of instances, also located in the Events View screen, allows us to change the configuration of the instance at will. In order to do it, access the context menu of the instance and then choose Edit Instance. osm_gestion_func_arbolinstanciasedit.jpg

Tree of Groups

Access the main Instance Management screen through the Management tab, and then on the left hand side of the screen there is a tree displaying the groups of instances. We can edit any instance unfolding the groups and clicking on the selected instance. osm_gestion_func_arbolgruposedit.jpg

List of Instances

This list is located in the main Instance Management screen, accessed through the Management tab. By selecting the Instance id we can have an easy access to its information. This screen shows further details about the selected instance such as id, type, description, date of creation and which master agents are monitoring the instance. osm_gestion_func_listadoinstanciasedit.jpg

Dependencies

When editing an instance, we can manage an additional task that is not present when we create an instance. This task is assign dependencies.

osm_gestion_func_pantallaaltainstanc_dependences.jpg

Dependencies means that an instance can be parent of other instances or be a child of other instances. Lets view an example: we can have an instance of type Linux and other instances like an Apache, a MySQL, a Tomcat server,… These instances are all executing in the Linux OS previously mentioned, so the Linux instance can be consider parent of the other instances.

At this moment, an instance can be only or 'parent' or 'children' and there is only one level of dependency.

Manage dependencies is similar to manage Groups assignment previously mentioned.

If an instance is child of other instance, we couldn't assign dependencies.

Configuration Management

The configuration templates are not used to define a monitoring model over an instance. We could establish the interval for the events examination frequency, if the events are active by default or not, as well as many other parameters.

Applying Templates to Instances

By means of this functionality, which we can find as the option Configuration Management under the Management tab, we are allowed to assign a template previously created to a group of instances. Of course this template can only be applied to the compatible instances, for example, a Tomcat monitoring template cannot be applied to instances of type different than Tomcat.

osm_gestion_func_plantillas.jpg

You can appreciate the simplicity of the process in the picture:

  1. Select the Instance type which we want to access.
  2. Depending on the previous selection it will show the templates associated with that instance type. We have to select the template through the Template id. It shows the template configuration but we cannot edit these details, in case we want to do so, go to Instance Management.
  3. From the bottom list of the instances select those to be associated with the template, and in case this list is too long you can benefit from the Instance Filter functionality, which only shows those instances matching the pattern entered in the near text box. Once you have selected the instances you can use the controls called Assign Template.
  4. The last step is to save and apply the changes using the upper toolbar button with the floppy disk 1) image.
  5. In the case we modified the parameters of the template, we can save them in the same template or in a new one. To do this we can to click over the Save button. A new popup will be open. All we have to do is insert a new Identifier and a new Description in the case we want to create a new template or click over Apply button to modify the template we were working with.

SLA Management

We are going to learn how to manage and configure the SLA. Click on the SLA option in the Management tab to access the main SLA Management screen.

osm_gestion_func_gestionans.jpg

As can be seeing in the image, this screen helps us to discern all the existing SLA in a quick and easy way.

Each SLA can be defined by:

  • Color and Identifier: a name to identify it and an associated color to distinguish it easily at a glance.
  • Description: a text extending the information about the SLA.
  • % Availability: percentage of time with regard to the total time (when the service was created) in which the service must be available.
  • % OK: percentage of time with regard to the total time in which the service must work perfectly, without errors or degradations.

Creating SLA

Click on the SLA option in the Management tab to access the main SLA Management screen. In order to create the new SLA you just have to click on the ‘+’ 2) button located in the upper section of the screen. Once this is done, it shows the SLA Configuration screen.

Configuring SLA

The SLA Configuration screen can be reached in two ways:

  • Clicking on the id. of the SLA in the main SLA Management screen.
  • Clicking on the Create New SLA button.

The first option displays the information of the selected SLA, while the second option shows the fields empty ready to be filled. In both cases the process is very similar

osm_gestion_func_configuracionans.jpg

In order to configure the SLA we have to provide (or modify) the following information:

  • Identifier: a name to identify the SLA in a unique manner.
  • Description: a text extending the information about the SLA.
  • % Availability: percentage of time with regard to the total time (when the service was created) in which the service must be available. It accepts 4 decimal places.
  • % OK: percentage of time with regard to the total time in which the service must work perfectly, without errors or degradations. It accepts 4 decimal places.
  • Color: Select the color to associate with the SLA from the Color Pallet.

Once this process is over, click on the button with the floppy disk image 3) to save and apply the changes. In case you wish to leave the screen without saving the modifications just click on the button with the arrow image 4) located in the upper part of the screen.

Deleting SLA

We can delete SLA in a very simple way from the Management SLA main screen. You are able to delete one or several ALS simultaneously by means of ticking the checkbox for the selected SLA followed by clicking on the Delete SLA button. This button is represented by the ‘-‘symbol5) and it is located in the upper part of the Management SLA screen.

IMPORTANT: you can only delete the SLA not associated with any service. In case you want to delete an SLA associated to one or several services, first you have to unlink the SLA with the associated services. A warning message will be displayed when this situation occurs.

Service Management

Click on the option Services in the Management tab to access the main screen of this functionality.

osm_gestion_func_gestionservicios.jpg

There are two well defined areas in this screen:

  • Tree of Services: it shows the existing SLA in system and you can unfold each SLA node through the ‘+’ button to see all the services associated to that particular SLA. At the same time, if you click on the ‘+’ button of the service a list of the instances contained in that service will be displayed. You can access the Management Service screen by clicking on the Service name, all the same if you click on the Instance name to access the Management Instance screen.
  • List of Services: it shows the services previously configured in the system, with at least one (OsmiusSV) that comes pre-configured with the installation. Every service in the list shows its id., description and associated SLA.

Creating Services

Click on the Services option in the Management tab to access the Management Services main screen. In order to create a new service you just have to click on the ‘+’6) button located in the upper part of the screen. Once this is done, you will access to the Service configuration screen.

Configuring Services

A service consists of the following elements:

  • Identifier: unique key to designate the service.
  • Description: a text extending the information about the service.
  • SLA: name of the SLA with which we want to link the service.
  • Schedule: a schedule in which the service will be active. Any incidence out of the schedule time will not be evaluated to calculate the percentages of the SLA.
  • Instances belonging to the service: a service is, basically, a group of instances.
  • Propagation Rules: rules to propagate or NOT to propagate the state of availability of the service instances.

We can access the Management Services screen through the following ways:

  1. Clicking on the ‘+’ button to create a new service.
  2. Clicking on any service id. to configure or edit the service..

The first stage requests the following information:

osm_gestion_func_configuracionservicios0.jpg

  1. Identifier: this is an alphanumeric string up to 8 characters long that we should provide for the identification of the new service and it must be unique.
  2. Description: a text extending the information about the service.
  3. Aggrupation: Collection of services to which this service belongs.
  4. Responsible: Responsible user for this service.
  5. Schedule: A pull-down list with all the available Schedules. Select one Schedule to be linked with the service.
  6. SLA: A pull-down list with all the available SLA. Select one SLA to be linked with the service.

Once this information is filled you should click on the Apply button to save this configuration and carry on with the process of defining the service.
In the second stage of the configuration process we have to select the instances to be part of the service.

osm_gestion_func_configuracionservicios02.jpg


The last task is to define different Propapation Rules of availability (not mandatory). There are 2 types of rules:

osm_gestion_func_configuracionservicios_rules.jpg

  1. NO Propagation Rules: Instances in this rules don't propagate their availability to the service.
  2. Group Propagation Rules: To propagate the availability to the service, all the instances of this rule must been unavailable. An example could be a Tomcat Cluster. The service Tomcat is unavailable if all the instances of the cluster are down.

La forma de operar para dar de alta reglas es similar a la de asignar instancias a un servicio con la salvedad de que tendremos que previamente seleccionar el Tipo de Regla y una vez seleccionadas las instancias pinchar sobre el botón Añadir para añadir dicha regla. Pinchando sobre el botón Borrar borraremos las reglas que tengamos seleccionadas en la lista.

Remember to click on the Apply button to save and apply the changes.

Deleting Services

We can delete services in a simple way through the Management Services main acreen. You are able to delete one or several services simultaneously by means of ticking the checkbox for the selected services followed by clicking on the delete service button, represented by the ‘-‘ symbol7) located in the upper part of the management services screen. IMPORTANT: When a service is deleted, the instances linked to that service are not deleted, nor the associated SLA, but all the information related to the Service-SLA-Instance association will be lost. An explanatory warning message will be shown in case this situation arises.

Data Mining Management

Osmius is able to manage in an automatic way, after a small configuration carried out by the user, all the data extracted from the monitoring process.

Historic Management

A recurrent problem with the data collector systems is the associated maintenance. Usually, the size occupied by the data grows continuously, and in certain moment it becomes a problem: all the available space runs out, backup copies are mandatory, we need to free some space…

Osmius solves this problem taking charge of the management of the historic, based in the concept of the Round Robin Databases. We lose control over the details and granularity with this functionality, but it saves lots of space and maintenance time.

osm_gestion_func_configuracionmineria.jpg

In order to activate the automatic historic management system and thus forget about the database management we have to activate the verification of the Round Robin Database checkbox and provide the following details:

  • # Days to aggregate per hour: this is the number of days for which it will calculate the average of data in 1 hour blocks for each type of event of each instance and deleting the rest. It would correspond to the H parameter in the graphic located a few lines below.

e.g.: It is enough for me to know the hourly average CPU time in the Oracle server for a given day 3 months ago, I do not really need a granularity by the minute.

  • # Days to aggregate per day: this is the number of days from which it will calculate the average of data in 1 day blocks for each type of event of each instance and deleting the rest. It would correspond to the D parameter in the graphic located a few lines below.

e.g.: I do not need to know the amount of MB used by Tomcat on an exact date like February 9th 2008 08:09:15. It would be enough to know the average of the day.

  • # Days to delete: the data will be eliminated after this number of days. It would correspond to the E parameter in the graphic located a few lines below.
  • History Backup: We have the option of a backup copy of the historic events that will be deleted once the days established in the previous parameter have expired. In case this option is activated we will find the original records in the table called OSM_DWH_HISTEVENTS. Usually this option is not activated unless we have a deep knowledge about the events we are handling or/and we would like to maintain the historic for detailed Data Mining processes, pattern identification and other statistical methods.
  • # Days to delete the other historic: this parameter affects the other historic backups maintained by Osmius. Usually, you would like to delete this after a long enough number of days. The data affected by this parameter are: Processed Tasks Historic (OSM_HISTTASKS) – Notifications Historic (OSM_N_HIST*) – User Session Historic; every time the user enters the system it leaves a record in the system tables, and the parameter indicates the antiquity of the records to be deleted.

Gestión de datos históricos en Osmius

Once this process is finished click on the floppy disk image 8) button to save and apply the changes.

ITIL Indicators

ITIL Indicators

The operation of this screen is very simple. With the Type of Instances combo with can choose the type of instance to apply the events of Availability, Capacity and Information.

Choosing an element in that combo will load a table with the following fields:

  • Event: Event code
  • Description : Descriptive text of the event
  • Availability : Checkbox to select an event to be of Availability type.
  • Capacity : Checkbox to select an event to be of Capacity type.
  • Information : Checkbox to select an event to be of Information type.

To save all the changes we have to click over the icon Salvar.

Los eventos de Disponibilidad, Capacidad e Información que seleccionemos serán para todas las instacias de ese Tipo, ya que es una opción global y no por cada una de las instancias.

User Defined Events

A new Osmius feature is the ability to monitor events that the Osmius infrastructure does not offer through its monitorization agents.

To do this, Osmius offers several options:

  • Scripts : monitoring an event through a script
  • SNMP: monitoring an event of an instance through an OID of a MIB.
  • Derived Events: logical rule-based monitoring of previously defined events.
  • Statistics: Statistical calculations based on previously defined events.
  • Web Probe: monitoring an event through IDE Selenium web probe (Test Case). Selenium IDE.

User Defined Events List

User Defined Events List

The User Defined Events List show the information groupped by tabs. Selecting the corresponding tab show us the list of this specific tab.

With this screen we can add new events clicling over , or delete selected events clicking over . To delete User Defined Events it will be mandatory that these events will not be activated on the associated instances.

The information available on this list is grouped by type of instance and interface. The columns are: event, descrption and number of active evens in the associated instances.

We can filter by type of instance, interface of event identifier.

The events of process interface has an extra management via parameters field. If we click over the View script icon, a pop-up with the content of the script will be displayed. Clicking over the Upload icon icon will allow us to upload a new version of the script.

Creation of User Defined Events

Creating User Defined Events is predetermined by their type. User Script and SNMP events type share the same screen, with the only diffenrece of the parameters needed for each type, while Derived and Statistical events have their own screen, due to its characteristics.

User Defined Events via Script

 User Defined Events via Script

The events defined by the user via script provides the user the ability to monitor instances / events not offered by default in Osmius infrastructure. Monitoring this events is as simple as upload a script file.

As we can see on the screen, the first step is to select the type of instance/s to which we want associate the event and the script file. The returned value of the event is the exitcode of the script, but if the script write in the output KEYVALUE[value] this value is the returned value of the event. The event text is the text written by the script in the output.

In a second step, we'll click withe the mouse over the Scripts field and window will be opened where you could select the file you want to associate with the event.

Finally, we give a name to the event (6 characters), a description that will quickly help us to determine the goal of the event, and alarm and severity values and associated with the event.

These are the required parameters. Alternatively, we can indicate whether an event has to behave silent or not.

Clicking on the icon Save will save the event.

User Defined Events via SNMP

 User Defined Events via Script

The User Defined Events via SNMP provide monitoring SNMP instances through standard SNMP interface. Osmius supports SNMP version 1 and 2.

The process is analogous to the creation of User Defined Events via Script. The main difference is that in this scree we must select an OID, which we can either write directly or by double clicking on the parameter value field.

There are a number of optional parameters such as the community, the SNMP port, … that we provide in case it be different from the default.

User Defined Events - Derived

 User Defined Events via Script

Derived events allow the user to apply logical rules to predefined events.

The comparison operators are>, <, =,> = and ⇐ while conditional operators are AND and OR.

Examples of rules that can be built through such events are:

  • (OSM_Host.OSPRCCPU> 90)
  • (OSM_Host.OSPRCCPU> 90) OR (OSM_Host.OSPRCMEM> 90)

As you can see in the iamge, the first step is to assign the name of the event (6 characters), description and sampling time interval.

Then select an instance and its corresponding event and the comparison operator you want (>, <, =,> =, ⇐). Automatically a select with two options will be loaded: compare that event with another event or with a constant.

This was the first comparison of our rule. If you want to add more comparisons, you must select the bottom combo and choose between AND and OR values to automatically load a new list of instances and events and repeat the above process.

Clicking on the icon Save will save our event.

User Defined Events - Statistics

 User Defined Events via Script

Statistical events provide the user the ability to do statistics operations (average, accumulated ,…) on pre-defined Osmius events.

The process is very simple.

First we must assign the name of the event (6 characters), description and sampling time interval.

Then select which type of instance and corresponding event we want ot make the statistical calculation.

You mus provide the warning and severity values of the event (as well as the type of comparison).

There are 5 types of operations implemented:

  • No operation
  • Average
  • Accumulated
  • Differences

After the operation, you can calculate:

  • Absolute value of the result.
  • Application constant: adding, subtracting, multiplying, dividing or calculating the percentage of the constant over the result.

No operation: You can calculate absolute value or aplly constant (addition, subtraction, multiplication, division, percentages) over the event selected before.

The accumulated and average operations apply to the type of event we've previously selected, while differences referes to a difference with another event or a constant. This difference can be calculated in the real value or a percentage. If the operation we selected was Average or Accumulated it will be necessary to select the range on which we carry out this operation.

The sum operation can add several events of the same type of instance of the event selected before.

Finally and optionally, we can assign instances which have enabled this event by default, using the list 'Apply in these instances”.

Clicking on the icon Save will save our event.

User Defined Events via Web Probe

 User Defined Events via Web Probe

The events defined by the user via Web Probe provides the user the ability to monitor instances / events not offered by default in Osmius infrastructure. Monitoring this events is as simple as upload a html test case files recorded with selenium IDE

The “Test Case” of Selenium IDE must be recorded with a browser Firefox using a profile identical to that located in the $OSM_ROOT/user/scripst/webtrans/profiles/selenfirefox of the Osmius distribution (ask to administrator). To create and use firefox's profiles see Firefox Profiles. If you change some of the profile (eg language, which by default is English) administrator user have to replace the original profile of the distribution for the new one.

Administrator have to check the procedure Master Agent configuration to execute Selenium Web Probes.

As we can see on the screen, the first step is to select the type of instance/s to which we want associate the event and the script file.

In a second step, we'll click withe the mouse over the Scripts field and window will be opened where you could select the html test case file recorded with selenium IDE you want to associate with the event. The event execute the selenium Test Case and returns the number of seconds to run the web transaction of the Test.

We can modify the The Base URL field for allowing test cases to be run across different domains http://seleniumhq.org/docs/02_selenium_ide.html#using-base-url-to-run-test-cases-in-different-domains.

Finally, we give a name to the event (6 characters), a description that will quickly help us to determine the goal of the event, and alarm and severity values and associated with the event.

These are the required parameters. Alternatively, we can indicate whether an event has to behave silent or not.

Clicking on the icon Save will save the event.

Trap Events

Osmius has the capability of receive traps through Osmius Agent for Traps and translate them in Osmius instance events. This is done in two steps.

Trap Events List

Listado de Eventos Trap

With this screen we can add new events clicling over , or delete selected events clicking over . To delete Trap Events it will be mandatory that these events will not be activated on the associated instances.

The information available on this list is grouped by it's Enterprise OID, and we can see it's identifier and description.

We can filter by the Enterprise OID and by event identifier.

Creating Trap Events

The screen to add new Trap Events is showed following

Trap Event create

On the top of this screen we set the event identifier, description and enterprise OID.

On the right, we check the types of instances we want to assign to this new event.

After we create the new trap event we can activate it in instances of these types. Configuring Instances

After entering the enterprise OID the screen will automatically load all the traps defined in its MIB, which can be configured one by one to translate them in this event with the severity indicated. We can delete any of the traps and/or add new traps of different MIBs.

Descriptions of the traps and their bind variables are those that Osmius will show in the text of the event when it occurs. It is recommended therefore that they are short of and meaningful.

Traps of the Event

There are events like LINKSTTE in the picture that depend of one of its bind variables, ifIndex in this case. The number of the interface of the router that falls (linkDown) or recovers (linkUp) come in the ifIndex bind variable. Osmius server translate two traps with different ifIndex in two events differents,

For that, we have to set ifIndex like “key” in all traps of the event.

Varbind Key

Most traps define the criticality of the event to which they belong, but there are traps that define the event severity depending to the values of any of its bind variables. In these cases (the variables must be scalar) we have to set the severity of the trap as “VARS” and set bind variable values.

Most traps define the severity of the event to which they belong, but there are traps that define the event severity depending to the values of any of its bind variables. In these cases (the variables must be scalar) we have to set the severity of the trap as “VARS” and set bind variable values.

Varbind Severity

To save the event we must click over the icon Save

Saving the event will add this event to the instances of the selected type of instances. By default, the event will not be activated on these instances.

Discovered Trap Events

Traps catched by Osmius Agent Traps that have not been translated to any Osmius Event are showed in this screen:

 Discovered Traps

This may be due to:

0: NO Events or No Instances associated to this trap.
1: NO Active events associated to this trap

Fields:

  • OID: Trap oid.
  • Text: Trap oid text, if its MIB has been loaded.
  • IP: IP of the device that has sent this trap.
  • Host: Hostname of the device that has sent this trap.
  • Master: Master Agent of the Osmius Agent Trap.
  • Discovered: Date.
  • Message: Explanation.
  • Enterprise OID: Enterprise OID of the device.
  • Enterprise: Trap oid text, if its MIB has been loaded.

Plugins

From version 10.04, the ability to load Plugins has been incorporated into Osmius console to the users with role ROOT.

An Osmius Plugin is a tool that allows the addition of new capabilities to the console. One example could be add more new agents.

An Osmius Plugin is a zip file which is composed of other files, usually a plugin.xml file that describes elements of the plugin, as its idenficador, its creation date, etc, a .jar file which executes the code responsible of the proper loading of the plugin in the console and other files necessary that depends of the type of plugin that we are loading.

Prior to describe the plugin screens in more detail, we want point out that the development of Osmius Plugins is very easy. Osmius Development team has selected 'Groovy' to be the Osmius Plugin development language thanks to its greatly facilitates to the development. In addition, a miniSDK has been developed to facilitate the development of the Plugins.

The administration via the web console is very easy. You can manage Osmius Plugins with only one screen.

 Plugin List

From this screen you can upload / update plugins by clicking on the + icon.

In addition to the controls for paging, you can filter the existing plugins both for its identifier, such as by description or by version.

If we click the mouse on an identifier or a description, the application automatically loads a popup showing further details of the selected plugin.

 Plugin Detail

The process of loading / updating Plugis is very easy. The only thing we have to do is click the mouse over + icon and a window to select the file to load will be automatically displayed. We select our .zip file. and the console will guide us through the steps to install the plugin.

 Plugin Load

Depending on the type of plugin (or if we are upgrading a plugin), the console will guide us via relevant questions so we can decide whether to continue with the plugin installation process or cancel it.

One example is a plugin update.

 Plugin Update

If you decide to install it.

 Plugin installed

Actions Management

Osmius has the functionality to execute actions by running scripts on the Master Agent machine that contains the agents that monitor the instances.

To do this, Osmius defines 2 types of actions:

  • Generic : actions can be executed in any instance.
  • Specific : actions can only be executed for a particular type of instance..

 Actions

On Actions List, clicking over the icon Add actions we can add new actions. A new window will open as follows::

 Upload script

Clicking with the mouse on File, we will upload the script you want to use.

We can assign a description to the action, and mark the action as generic by checking the corresponding check or choose the type of instance that we want to assign the action.

We must also indicate the platform/s on which this script can be executed.

Finally, we can add parameters to our script with the 'Command' option if necessary.

By default the application will always attach 3 parameters that can be used within the script:

  • Type of instance
  • Type of event
  • The Instance identifier

 View script

The new actions are listed on the 'Actions' list.

 Actions list

Actions can be deleted selecting the corresponding check and clicking on the icon Delete actions.

You can re-upload a script file that requires modification clicking on the icon Upload script of the corresponding action. A new window will be open as described above and all you have to do is upload the file.

You can also view the content of our script by clicking on the icon View script.

 Script

In addition, this screen has a list of exectued actions.

 Executed Actions list

These actions have been executed on the event screen. The list allows filtering, paging and sorting the actions. We can view the detail of the execution of an action clicking over the icon View Log.

 Log

1) , 3) , 8) osm_gestion_func_botonguardardisq.jpg
2) , 6) osm_gestion_func_botonagregarplus.jpg
5) , 7) osm_gestion_func_botoneliminarminus.jpg
 
en/usuario/gestion/funcionalidad.txt · Last modified: 2011/07/20 11:36 by joseluis.marina
 
Recent changes RSS feed Creative Commons License Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki