Osmius Information Portal (OSIP) is a Business Intelligence web portal deployed as an external tool to Osmius Enterprise Edition. OSIP gives you a simple way to access the data stored in any number of Osmius's installations with customizable dashboards that can be integrated with external data sources as well in very easy way.

OSIP is specially useful in multi-site monitoring environments such as big corporations and monitoring providers.

As a web portal, OSIP can manage user communities, roles and permissions and it can be integrated with other web applications. Thus, you can manage users and compose screens from where they can visualize not only data from services monitored by Osmius but also keep track of emails, calendars, data from the Cloud…

This is a perfect schema for a monitoring provider to manage clients or a traditional IT department to provide dashboards to the final users. OSIP allows them to abstract from the monitoring process using a business-driven application that focuses on the data collected by the monitoring system, making easier to visualize and understand what is happening in their services and enrich this experience with external data.

• Installation: as a monitoring provider you will manage one or more Osmius installations. This is the top hierarchical entity in Osmius and it represents a data repository from where OSIP can read data.

• Provider: this organization is unique and it represents the company that supplies monitoring services.

• Client: each company for whom you provide monitoring services is a client. A client is an organization that must be related to one and only one installation.

• Users: They are Osmius installation entities and can be very different depending on their role and permissions. For example, a root user has access to the whole portal and manages everything, a client admin can manage its own company's screens and users, a viewer user can only access to certain dashboards, etc… Permissions are fully configurable to adapt to each organization and you can integrate the user management with LDAP and Active Directory.

• Service, Instance, Event: a service is a logical aggregation of monitored elements related to a schedule and a Service Layer Agreement (SLA). Each of these elements is an instance (a network device, a server, a KPI repository, etc…) and each of the measures that we monitor is an event (bandwidth, CPU load, sales by day, etc…). A client may have any number of services and instances. These entities are stored in Osmius installations from where OSIP reads the data to compose visualizations.

OSIP is based in Liferay (http://www.liferay.com). Liferay Portal is the world's leading open source enterprise portal solution using the latest in Java and Web 2.0 technologies. Liferay Portal is one of the most widely deployed portal technologies on the market, with an estimated 250,000 deployments worldwide.

More than a portal, Liferay is a platform for creating effective business applications and solutions. It offers a robust feature set, impressive scalability, time-saving development tools, support for over 30 languages, and a flexible, scalable architecture that is open source developed and enterprise refined. Notable differentiators include:

• Compatible with all major databases, operating systems, and app servers
• Hierarchical system of communities and organizations
• Granular, delegable permissioning system
• Highly scalable, supporting more than 5,000 concurrent transactions (33,000 simultaneous users) per server
• Real-world performance of millions of page views and 1.3 million users
• Supports 22 languages, out-of-the-box
• Award-winning user interface

Liferay is constructed of functional units called portlets. Portlets are pluggable user interface software components that are managed and displayed in a web portal. Liferay supports the JSR-268 Java Portlet Specification that allows interoperability of portlets between different web portals.

OSIP is distributed as a Liferay Portal where we have deployed portlets that perform several functions related to Osmius like displaying data about client's services or manage installations.

The following diagram represents a typical OSIP installation where we have a provider that sells monitoring services to several clients. The data collected by the Osmius monitoring is integrated with other data sources, these external repositories could be ERPs, CMDBs, CRMs, ticketing systems…

In resume, as a provider, the OSIP's schema allows you to:

• Monitor any number of clients from one or more Osmius installations (you may monitor more than one client from one Osmius installation).

• Integrate Osmius data with other sources of interest.

• Display this data graphically using portlets designed to be easy to manage and use by users not familiarized with monitoring processes without losing any detail of what is happening in their systems, applications and services.

• Flexibility: extend OSIP just adding standard Java portlets that performs new desired functions without interfering with existing portlets.

• Manage your clients and their users giving permissions to view, edit, modify or delete their own pages and portlets.

OSIP is distributed as a compressed file. Unpack this file in the directory where you want to install OSIP.

Once done, you will find a Liferay distribution inside your directory with and web application server (usually Apache Tomcat) and several OSIP portlets. Please, note that removing any of these portlets will cause OSIP does not work properly.

Within this zip you will also find a SQL file osip_data.sql. We are going to use this file to populate OSIP's database later.

For this document we will work with an OSIP distribution running over Liferay 6.0.5 and Tomcat 6.0.26. Version numbers may vary but the configuration process is the same for all distributions.

Before starting the server we will configure a XML file to tell to OSIP where to find our Osmius data sources. In this tutorial we will suppose that we have two Osmius installations using MySQL running on two servers located in the hosts 192.168.3.240 and 192.168.3.241. Both of them using “osmius” as database user and login (replace these values with yours). This process is nothing new if you are familiarized with application servers configuration.

Go to mydir/liferay-portal-6.0.5/tomcat-6.0.26/conf and edit the file server.xml.

You will find a section delimited by the tags <GlobalNamingResources> and </GlobalNamingResources>, paste the following code between those tags:

<Resource auth="Container" driverClassName="com.mysql.jdbc.Driver" factory="org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory" maxActive="50" maxIdle="10" maxWait="10000" name="jdbc/osmius" removeAbandoned="true" removeAbandonedTimeout="240" type="javax.sql.DataSource" url="jdbc:mysql://192.168.3.240/osmius" username="osmius" password="osmius" validationQuery="SELECT 1"/>

<Resource auth="Container" driverClassName="com.mysql.jdbc.Driver" factory="org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory" maxActive="50" maxIdle="10" maxWait="10000" name="jdbc/osmius2" removeAbandoned="true" removeAbandonedTimeout="240" type="javax.sql.DataSource" url="jdbc:mysql://192.168.3.241/osmius" username="osmius" password="osmius" validationQuery="SELECT 1"/>

As you can see, we must define a resource for each Osmius database that we want to read with OSIP. Feel free to change any configuration parameter to adapt to your own setup.

Now we must declare this resources as global to be accesible from our portlets. In order to do this, edit the file context.xml and copy this XML text inside the <Context></Context> tag:

<ResourceLink global="jdbc/osmius" name="jdbc/osmius" type="javax.sql.DataSource"/>
<ResourceLink global="jdbc/osmius2" name="jdbc/osmius2" type="javax.sql.DataSource"/>

This is, one ResourceLink per Osmius database with the same name that we wrote in server.xml

The next step is to configure OSIP's database. You may use any of the databases compatible with Liferay (SQL Server, PostgresSQL, DB2, MySQL, etc…), please refer to Liferay documentation for more detail on this topic. We will use MySQL as default database.

Go to mydir/liferay-portal-6.0.5/tomcat-6.0.26/webapps/ROOT/WEB-INF/classes and open portal-ext.properties

There you will find the following lines:

jdbc.default.driverClassName=com.mysql.jdbc.Driver
jdbc.default.url=jdbc:mysql://localhost/osip?useUnicode=true&characterEncoding=UTF-8&useFastDateParsing=false
jdbc.default.username=osip
jdbc.default.password=osip

These are the default values for OSIP's database connection (database: osip, login: osip, password: osip), change them to your desired values after creating your database.

Once done, create the database and use the file osip_data.sql to populate it.

Now we can start the application server executing mydir/liferay-portal-6.0.5/tomcat-6.0.26/bin/startup.sh

If you need any extra Tomcat configuration (ports, security connections, etc…) feel free to change any parameters. By default OSIP's Tomcat runs on port 8080.

To start defining Installations go to Control Panel - Portal - Installations

There you will find a form where you can create references to Osmius installations formed by four attributes: name, description, Osmius Datasource and Osmius Login. Osmius Datasource must be one of the repositories that we declared as global resource in previous steps. Osmius Login must be a user inside that Osmius Installation with ROOT role granted.

For this example we have defined two references to two Osmius installations, one located in Madrid and one located in Barcelona. Each one related to its own database (jdbc/osmius and jdbc/osmius2 respectively).

You can manage these installations using the list below.

To insert new clients into OSIP go to Control Panel - Portal - Clients.

This process will create two entities in Liferay: a organization that represents the client itself and an administrator for this organization. As you can see, a client is related to one Osmius installation and you must assign a login of that installation to this client. That is, a client in OSIP has a one-to-one relation with a login in Osmius that determines what information is suitable of being watched by that client. In our example we have created a client named Client A, whose monitoring is being performed in the Osmius installation in Madrid.

But a client will probably contain more than one user. So, how do we manage security if we have only one login? In OSIP, each client's administrator has the possibility to define which data can be visualized by each user of his or her organization using Liferay security.

This schema is flexible and can be modified to adapt to different scenarios. For example, a common requirement could be the delegation of the permissions management from the client administrator to the monitoring services provider.

Once the client is saved you can manage its users and organization from Control Panel - Portal - Users and Control Panel - Portal - Organizations.

Composing customized views for your users with Liferay is easy. The first step is to create a new Page clicking in the Add - Page menu at the top of the screen:

Then you can go to Manage - Page:

There you can edit the Look and Feel, permissions, child pages, etc… Please refer to Liferay Documentation for more information about Administration.

Once you have created and configured your page you can start to add portlets. Liferay provides some useful portlets by default and you can mix these (or any other portlet installed in your portal) with the ones provided by Osmius in the same Page.

Osmius portlets are distributed in two different groups: Provider and Clients. the former contains portlets designed to be used by the provider's users while the later contains portlets designed to be used by clients users. Though both are similar, the first ones allow you to select the client from wich you want to retrieve data that will be visualized in that portlet while client portlets are designed to be used by clients and to only retrieve data from that certain client.

When you add an Osmius portlet you will be asked for parameters such as the client/service/instance/events that you want to view. To change these parameters later go to Tools - Preferences (top-right corner of the portlet).

If you are interested in the development of your own plugins please refer to Liferay Documentation for more information about Development.

Installation Portlet allows a provider's user supervise what is happening in the whole system.

The list above shows each one's name and description followed by this data:

• Services: number of services in this installation and how many of them have problems (in red and between brackets).
• Instances: number of elements being monitored by this installation and how many of them have problems (in red and between brackets).
• Events: number of active events that are currently happening in this installation and the number of warnings (yellow) or critical (red) between brackets.
• Users: number of Osmius users in this installation.
• Clients: number of OSIP clients monitored y this installation and the number of them that have one or more services not available (in red between brackets).

If you click in an installation's name some charts containing statistics will be displayed:

• Top 10 Non Available Services: displays the ten services that have less availability and their last month's percentage of non availability.
• Top 10 Non Available Instances: displays the ten instances that have less availability and their last month's percentage of non availability.
• Top 10 Most Active Events: displays the ten most frequent events with their severity distribution.
• Top 10 Most Problematic Events: displays the ten most frequent critical events with their severity distribution.

The Control Panel is a business-oriented control that can be used to get a complete view of the clients status. This view starts with a low granularity vision that can be browsed deeper and deeper to get, at the maximum detail level, the alarms of all of the monitored elements of each client.

The first list contains a resume about the clients:

• Client: logo, click here for client detail.
• Services: number of services in this installation and how many of them have problems (in red and between brackets).
• Instances: number of elements being monitored by this installation and how many of them have problems (in red and between brackets).
• Installation: the installation from where this client is being monitored.
• Last 24 hours: a red or green led that indicates if the client has had a problem during the last 24 hours with any service.

In the example, we have two clients: A and B. Client A has four services and fifteen instances and it's being monitored from an Osmius installation in Madrid. As you can see, this client has problems with one unavailable service and one of its instances is not working properly. Finally, the red led indicates that this problems are recent (last 24 hours). Let's see what happens when we click on its icon.

The controls above the list Last 24 hours and Last 30 days shows a resume divided in time slices that indicates if there have been problems in that moment for this client. In the example we can see that we had problems in the last 24 hours between 08:00 AM and 09:00 AM and between 09:00 AM and 10:00 AM, and in the last two days.

If you click in any red cell, a pop-up with details of those problems will be displayed:

The fields in this screen are:

• Availability: indicates that this service was unavailable at that moment.
• Date: the date when the service started to be unavailable.
• Service: service description.
• Now: indicates if the service is available or not at this moment.

Let's return to the previous figure to see what data is displayed:

• Availability: indicates if the service is available or not at this moment.
• Service: service description. Click here to see a detailed view of the service.
• SLA: name of the SLA defined in Osmius that this service must meet.
• SLA Meeting: this indicates if the service is meeting its SLA or not, the left value is the meeting percentage while the value between brackets is the SLA meeting goal.
• Instances: number of monitored elements in this service and how many of them have problems (in red and between brackets).
• Last 24 Hours: a red or green led that indicates if the service has had a problem during the last 24 hours.

Following our top-to-down browsing, now we click in the service Databases to get more detail.

The left-sided square shows who is the responsible of this service and his/her email (Database Manager) and the schedule assigned to the service (24×7). Last 24 hours and Last 30 days work similar to the previous ones except that this time they will display information about instances. The Availability chart tells us that this services is not available since yesterday at 11:47:39 AM (we already know this because we saw it in the dialog before). The grid contains information about the instances that compose this service:

• Availability: indicates if the instance is available or not at this moment.
• Instance: instance description. Click here to see a detailed view of the instance.
• Type: type of the instance (SQL Server and MySQL in the example)
• Time since last change: this tell us how much time as passed since the last change of availability for this element. In the example, we can see that SQL Server has been not available more than 24 hours.
• Last 24 hours: a red or green led that indicates if the instance has had a problem during the last 24 hours.

Now we will click in SQL Server to find what is happening with this instance.

Now, if you click any of the red cells you will get all the alarms (red events) received in this time slice.

Finally, the table shows the current active alarms of this instance. In the example we can see that we have an alarm because the number of rows in a certain table of the database exceeds the limits of the given threshold and this causes an error (probably because this measure has been set as an ITIL indicator).

With this portlet we have made a complete top-to-down exploration of our infrastructure:

1. We started with the detection of a problem in one of our clients (low-granularity, business view).
2. Then we saw that the Databases service was unavailable since yesterday.
3. We realized that the database that had troubles was SQL Server.
4. Finally we detected that the number of rows in a critical table was too high (high-granularity, technical view).

This is a simple way to browse through our monitoring data collected by Osmius. Though, we wouldn't always want to provide such a complete view to all the users because of security issues or any other reason. That's why we have the Client, Service and Instance portlets.

These portlets work in the same way that the Control Panel but they skip granularity levels. For example, a Client portlet displays information for a certain client but not for others, a service portlet shows information for one service but not for others, etc… This schema allows you to create fully-configurable dashboards that can segmentate the visualized data according to each user role and permissions.

The Server Status Porlet is a specific portlet for server instances. It works in the same way that the generic Instance Portlet but provides a detailed view with different measures like CPU and Memory load, network traffic…

In order to configure these portlets click in Tools - Preferences

This will display different parameters. Usually you will need to select a Client, Service or Instance depending on each portlet.

For instance, if you add the Service Portlet to your Page and then you edit your Preferences you will see something like this:

In this example we are selecting the “Databases” from “Client A” as the service to be displayed in this portlet.

Chart portlets allows you to visualize data collected by Osmius. These charts show data in different ways, though the configuration is similar for all of them:

This is the common configuration page for Chart Portlets.

• Date: period of time to collect data from Osmius. This parameter is global for all events.
• Instance - Event - Alias: for each measure that you want to display in this chart you must select its instance, event and alias. Alias is the name that OSIP will display in the charts, it takes the same value that the event by default, but you can use it to make it shorter and to homogenize data from different sources. For instance, if you take an event called “Windows CPU Load” from a Windows server and an event called “Linux CPU Load” from a Linux Server you can set their alias to “CPU Load” and they will be displayed as the same measure (CPU load) from different elements.

This portlet displays a timeline chart with a data serie for each event. With this chart you can follow individual measures over time periods.

In this chart each line represents an instance and each vertex is the average of that event in the selected time slice. This display allows you to represent one or more instances in terms of their most important measures.

This chart displays a bar for each event that represents the average value of that event in the selected time slice.

This is the most interactive chart. Each instance is represented by a bubble in a five dimensional space: time, x-axis, y-axis, size and color. You can select any event for the last four.

With this chart you can follow the evolution of one or more instances over the time in terms of their most important measures.

1. Liferay Administration.
2. Liferay Development.