Service Performance Manager

From FireScope Documentation Site
Jump to: navigation, search

Getting Started

Minimum System Requirements

The following outlines the minimum requirements required for a SaaS-based implementation of FireScope Stratis.

Port Communication Requirements

In a SaaS implementation of FireScope Stratis, a FireScope Edge virtual machine is deployed on-premise to perform discovery and data collection.  All communication between the Edge device and the FireScope cloud is initiated by the Edge device for security purposes.  The following ports will need to be open for successful communication between FireScope Stratis and each Edge device.
If using FireScope Service Insight, it will need to be able to connect to your Stratis cloud over port 9540
  • If FireScope Analytics is part of this implementation, port 40000

Edge Device System Requirements

The FireScope Edge virtual machine is responsible for executing Discovery, all data collection, and accurately forwarding all of this data to the FireScope Stratis cloud. Edge devices can be physical or virtual appliances. The number of Configuration Items it collects from, frequency of polling, and scope of data collection methodologies impact its performance.
4 vCPU
  • 8 GB RAM
  • 60 GB local storage

Note:  The storage requirement for the edge device is large to ensure sufficient storage space for caching in case of loss of connectivity with the FireScope Stratis cloud.

Web Browser

FireScope Stratis supports the following Web browsers:

Internet Explorer 8 and above*Compatibility mode not supported. HTML5 is not natively supported in versions older than 9.
FireFox 6 and above
Safari 3.2 and above
Chrome 6.0 and above
Additionally, the following requirements apply to all browsers:
JavaScript is enabled
  • Minimum resolution: 1024 x 768

On-Premise Implementations Minimum Requirements

If you are opting for a private instance of FireScope Stratis, there are additional requirements needed for the FireScope Stratis Cloud itself.  All of the previous minimum requirements are still required.
Ensure that you meet the following environment requirements to deploy FireScope Stratis successfully.

ESX Servers 3 (5 preferred)
Minimum Instances 3 x EWC2 x EAC2 x ESC1 x Edge Device
VM Environment VMware vSphere 4+ESX servers with proper configuration(Key settings are correct Time Source and Hostname)Standard VMware images, with VMDK support
Supported Storage FC SAN (preferred)Fast iSCSIDirect Attached SAS*NAS is not supported.
Network Fast Ethernet, fully switchedDistributed vSwitches for ESX
All primary Stratis components (EWC, EAC, and ESC) communicate over TCP/IP Protocol within the Stratis Cloud Environment. Each layer must have the appropriate access to the other layers in order for the application to perform optimally. As the Stratis Cloud Environment is typically housed in the same location, no special firewall rules or protocols should be required.

Defining Service Groups

FireScope defines an IT Service as each discrete point of connection between your users and your technology.  Within the solution, these services are represented by Service Groups, which act as a container for service dependencies and can also include higher-level event analysis such as Policies and SLAs, which are evaluated across multiple elements of the Service Group.  

Three Ways to Define Service Groups

  1. Use Service Insight to discover IT Service endpoints and map their dependencies automatically.
  2. Federate with Cherwell or ServiceNow CMDB.
  3. Manually create your Service Groups.

Additional advice on modeling your services in FireScope is available in this document.

For optimum service-oriented visibility of your critical services, we recommend that each of the following elements should be configured for each service group.# User Experience Checks.  At least one, and optimally four or more, User Experiences should be included with each service to incorporate the users' perspective of the health and performance of the service.  These can also be utilized in event analysis to determine if downstream events have an impact on users or if they can be de-prioritized.

  1. Service Outcome/Business Metrics.  Ultimately, every service should be producing some sort of Outcome, whether that's completed backup jobs, completed transactions, revenue generation or some other measurable metric that communicates whether the service as a whole is performing and whether that performance is within expectations.  Please see Business Impact section of the User Guide for additional instruction on finding and configuring collection of these metrics.
  2. Service Dependencies.  These are the underlying CIs that directly contribute to the service such as web servers, applications, databases, etc.  Please see the section on Service Insight for steps to discover service dependencies.
  3. Shared Services.  These are the infrastructure elements that contribute to multiple services such as the network, power and air, storage, etc.  For easier inclusion into multiple Service Groups and configuration, you may want to create discrete Logical Groups for these shared services as they facilitate associating new assets to multiple Service Groups simply by associating them with a Logical Group that is already associated with these Service Groups.
  4. Policies.  Policies allow you to define complex event logic to evaluate the health of the whole of the Service.  Multiple policies can be defined, we recommend at least including a general availability policy, a degraded performance policy and an outcome/dependency policy.  A Business Availability Policy can be used to control the Red-light/Green-light status of a given Service Group.
  5. Service Level Agreements (SLAs).  Service Level Agreements blend one or more weighted policies together to match your documented business SLAs for each service.  

Populating Configuration Items

FireScope supports a number of methods to bulk populate Configuration Items (CIs), depending on where you have existing information or your preference for configuration. The following diagram breaks down the methods, as well as a summary of the steps required.
6204.populating config.png-800x0.png

In every case, you will first need to start up a virtual Edge device and provide any authentication credentials necessary for discovery or data collection, such as SNMP community strings or API user credentials. The following describes each method and includes additional commentary as may be necessary to help you decide which method is best for you. It is also important to note that you can use multiple methods to get the best results.
# CMDB Synchronization. If you already have a populated CMDB from ServiceNow or Cherwell, FireScope includes a native web service integration that can bring over IT Services and their dependent CIs. Please see the Integrations section of the User Guide for step-by-step instructions on how to perform these integrations. For other CMDB vendors, you can either export CI data via XML for import into FireScope or make use of FireScope's configuration web service to facilitate synchronization.
  1. XML Import. FireScope can import an XML file containing CI configuration data. For specifications of the XML document format, please click here. This method is particularly useful when migrating from a private instance of FireScope Stratis to a cloud-based instance, or vice versa. Additionally, if you have an existing Asset Management tool, it may be possible to export asset data as XML, alter the document to match FireScope's required structure, and then import into FireScope Stratis.
  2. Discovery. Out of the box, FireScope includes 9 discovery engines spanning basic nmap style network discovery, service dependency discovery and API-specific discovery. In addition to being a good source of initial CI information, discovery scans are also useful as a secondary step after any of the other methods listed here, as they can often provide greater detail of CI configuration than may currently exist in existing repositories. For more information about each discovery engine, please click here.
  3. Agent Registration. If you are opting to leverage FireScope agents, and are using some manner of automated deployment mechanism, it may be possible to use the registration to populate FireScope with CIs. As Agents are deployed, they initially register with their assigned FireScope Edge device. Even if a CI is not already created for a specific server, it will still be listed on the Agent Management page in the Administration menu. From this list, you can check off any number of CIs from the list and click 'Create CIs for Selected' to quickly add these CIs into the system.
  4. Web Service Automated Config. FireScope also includes a REST-based API that can be used to perform virtually any configuration task in the solution. The REST API is fully documented here.
  5. Excel Import. While not exactly a different method, we have created a macro-enabled spreadsheet that leverages the REST API to bulk import CIs. If you already have asset information in an existing spreadsheet, all you have to do is match the format in the spreadsheet, provide credentials to Stratis and click the Bulk Import button. You can grab the spreadsheet here.

Once you have completed any of these methods, you can then augment the data collection and event definition configuration by applying Blueprints or running one of the discovery scans against the new assets.

Extending the Solution

Throughout development of FireScope Stratis, a strong emphasis has been placed on enabling users to do things beyond normal use cases.  Wherever possible, we tried to provide quick and easy default options that users can easily change to adapt to fit their unique environment or role.  Specifically, there are three key areas where we see customers routinely extending the solution:

  1. Data Collection.  In addition to the stock SNMP, TCP, API and agent data collection methods common in most monitoring platforms, FireScope Stratis includes an Enterprise Service Bus to directly query standard databases, Dynamic Data Attributes which enable either key/value pairs or JSON data to be firehosed into the solution, as well as an Agent that can pipe the output of any CLI command or script back as attribute data.  You may want to check out the Downloads section for sample scripts that leverage these capabilities.  Additionally, the User Experience Check capability can extract elements from the output of web applications as attribute data.
  2. Event Analysis.  An Advanced Event Definition builder enables you to define virtually any kind of event logic from any attribute (or combination of attributes).
  3. Blueprints.  Data collection, event analysis and visual controls for any common class of monitored asset (e.g. switches, application servers, OWA servers) is packaged as a Blueprint.  You have the control to edit any aspect of the existing Blueprints, or you can create your own.  And even better, make a change to a blueprint and the change is immediately applied to every CI that is associated with the Blueprint.

The Flow from Attributes to Events

When FireScope Stratis collects data, a number of activities are performed that may or may not ultimately lead to a notification being sent to administrators.  The following diagram outlines all of these activities.

Event process flow chart.png-620x0.png

Important Notes:* An event that does not match any of the criteria of your notification rules will not generate a notification. 

  • Notification can include sending an email, executing a command on the affected system, or generating an Incident in a integrated ServiceDesk.