Foglight Evolve 7.3.0 - Web Component Guide

Using the Web Component Tutorial

With Foglight®, application and IT managers can understand end-user service levels for their critical business applications, notify stakeholders when those service levels are violated, and assign problem resolution tasks to the appropriate domain expert.

In addition to Foglight's core performance management capabilities, Foglight offers specialized monitoring for all application tiers including: End-User Response, Application, Web Servers, Application Servers, Databases, and Operating Systems.

That is a lot of capability, and the volume of data being collected can be overwhelming. The views in the browser interface attempt to organize the data into meaningful summaries, with drilldowns to increasingly specific information about a chosen component, such as a single host or a particular database instance.

It is likely that you organize the top-level screens around the concept of services, and choose them to show a view that should be useful to a broad range of users—those with typical environments. In all likelihood your environment is not quite typical, and as you gain familiarity with the browser interface, you will imagine ways that they could be improved.

NOTE: You must have a Foglight Dashboard Designer role to develop new dashboards.

Browser Interface Views

Web Component designers anticipated your need to customize the browser interface, so they included the means to allow you to access the product’s component framework and create your own custom views. You can populate these views with other display components, such as charts and tables, and connect them to data sources. This is the same data that the Foglight® agents are configured to collect, but now it is organized in a way that best fits your business model and its information needs.

The end result is a monitoring system that organizes data in a way that mirrors your business model. Real-time monitoring data is presented the way you want to see it, and you better control your application’s availability. This also helps you with service level management: because your custom views show services in a cleaner way, you can inform application and IT managers about end-user service levels, notify stakeholders when those service levels are violated, and assign problem resolution tasks to the appropriate domain experts. Custom views that focus on known trouble spots can help establish processes for quick recovery from system failure.

Why Configure the Default Views?

Suppose your company’s rapid expansion leads to the addition of many different application systems and groups, with each support team comfortable with their own legacy systems. In total, your IT department is responsible for managing an ERP system consisting of many servers and Oracle® databases distributed across a number of major locations.

Before the acquisition of Foglight®, homegrown scripts and applications were used to monitor these distributed systems, which made it difficult for the support organization to manage the information and care for the entire distributed environment.

Now you have Foglight, a standardized monitoring system that provides centralized management and allows people to attack problems from the same perspective, pro-actively monitor a large heterogeneous environment, and offers access to this distributed monitoring system via a Web browser. You and your team can see the big picture and correlate events between systems for the entire application. With Foglight, the situation can be improved even further.

Foglight uses a configurable Web-based interface. By making your own custom configurations, you can apply your detailed knowledge of your system to augment or replace the views Foglight shows by default.

This helps Foglight to notify you directly when something is broken, rather than relying on a user notifying a help desk, getting a trouble ticket, and only then having the support group notified. If a custom configuration presents a clearer view or better correlation of events between all systems, and leads to pinpointing a problem that might otherwise take longer to notice and to diagnose, then the time spent in crafting the custom view is well spent.

The aim of this tutorial is to make the learning curve less steep. In it, you’ll see how to create additional views, populate them with GUI components, and connect these components to data sources.

What is the Web Component Framework?

The Web Component Framework is a super-set of the View Component collection that contains other control components, such as renderers. It is used to build thin client interfaces for products that are primarily (but not necessarily) in the systems management domain. This is the framework you will use in this tutorial.

The Web Component Framework is written in JavaTM and is capable of running in a Web container such as Apache Tomcat. It can be used on contemporary Web browsers without requiring the use of a plug-in. It is portal-like, but is not a JSR-168 standard portal.

The top level of the Web Component Framework is comprised of panels.The items in the left and right panels can provide access to several different display types: