FireScope Quick Start

Select Product

FireScope Unify Quick Start Guide

Getting the Virtual Appliance Up and Running

Download your copy of the virtual machine

Extract the virtual machine from its zip file into a location with space for growth.

Start the virtual appliance using your virtual machine player or server.

Launch your web browser and type the IP Address of your FireScope Appliance, shown in green on the VM console, into the address bar.

Upload the license file sent to your email address into the form as requested.

Now, you're ready to model your services and begin real-time management of the business impact of IT Operations.

Once you have the FireScope virtual machine up and running, the next steps are to configure your service model, service levels and data collection. This document will guide you through these steps. Each section has a related links section for step-by-step instructions for sub tasks and other sources of additional information.

1) Defining Services

Service Groups are logical groups of networked assets that contribute to client-facing services such as email, CRM or financial applications. When defining services, it is recommended that you start with what your users consider to be the most critical services provided by IT, and then identify which servers, network equipment, storage devices or other networked assets contribute to this service. Defining services are easy, at this point all that is necessary is naming the Service Groups, such as CRM Service, Public Website, Email or any other services that IT provides to end users.

For hardware that contributes to multiple business services, such as routers and switches, consider creating Logical Groups for easier configuration.

2) Configure Dependencies

The next step is to setup the Configuration Items, such as application servers, database servers, switches, storage solutions and other networked devices that contribute to each of the services you defined in step #1. You have two options to choose from, manual configuration or auto discovery, depending on your internal policies or preferences. The fastest method is auto discovery; all you have to do is define your discovery rules and let FireScope do the work.

3) Setup Event and Performance Metric Data Collection

Now that you’ve identified which Configuration Items contribute to your Service Groups, the next step is to collect event and performance data to manage the performance and business impact of your services. Metrics can run the gamut from processor utilization, page file statistics or even application metrics; this in addition to polling logs for specific event information. To make the process of configuring these metrics easier, FireScope uses a template engine to apply settings to multiple Configuration Items. In addition to the templates that come out of the box, you can create your own templates to meet your unique needs. Multiple templates can be applied to individual CI’s; for example a Redhat server could use a basic snmp template, a Redhat template for operating system specific metrics, as well as a MySQL, Apache, FTP and JMX template for application specific metrics.

In addition to deciding which metrics to measure, you also have flexibility over how FireScope collects these metrics. Use the related links for details on selecting the best data collection methods.

4) Set Service-Level Thresholds

Once you’ve begun collecting metrics and events, the next step is to define service levels. Start with Event Triggers for each Configuration Item to define thresholds for key metrics or to identify critical events. For example, an Event Trigger could be created to flag when Apache has reached 90% of processor utilization, or when 5 or more invalid login attempts have occurred. You can also flag one of these Event Triggers to be the Availability Trigger for the CI it is associated with. Unlike other solutions that define a server as being down when it is unreachable, FireScope lets you define when a CI is no longer contributing to the Services it is linked to. You can also configure Actions to enable FireScope to respond to these events, either through notification or by automatically executing commands to begin remediation.

Trigger Groups expand on Event Triggers to give visibility into infrastructure wide events, even across disparate technologies, by linking multiple Event Triggers together in either an AND (all component events must be true to trigger the Trigger Group) or an OR (an occurrence of any of the component events will cause the Trigger Group to fire). An example would be all file servers experiencing above average network utilization as indicative of a possible virus outbreak.

For Service-Level Agreements (SLA’s), Service-Level Objects (SLO’s) or corporate policy enforcement, you can link one or more Event Triggers to build complex event tracking. For example, your SLA for a CRM system may be 99.99% service availability, an average time to create a new record should not exceed 3 minutes and for security there should not be more than 30 failed login attempts per day. All of these aspects of the SLA can be created by linking multiple Event Triggers or Trigger Groups to build these complex service levels.

One last step remains. When configuring SLA’s or SLO’s, you can generate a financial impact of that event, directly in the form where the policy is defined. This is critical to achieving effective Business Service Management as it helps define IT’s value in a way that members outside of IT can easily understand. Rather than discussing IT in terms of uptime or kilobytes, this enables IT leaders to discuss events in the terms of how much it cost the business. The exact formula used to measure financial impact is yours to decide, a couple of example formulas are included in the related links for this section.