Service Performance Manager
Minimum System Requirements
Port Communication Requirements
- If FireScope Analytics is part of this implementation, port 40000
Edge Device System Requirements
- 8 GB RAM
- 60 GB local storage
|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|
- Minimum resolution: 1024 x 768
On-Premise Implementations Minimum Requirements
|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|
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
- Use Service Insight to discover IT Service endpoints and map their dependencies automatically.
- Federate with Cherwell or ServiceNow CMDB.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
- 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.
- 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.
- 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.
- 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.
- 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.
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:
- 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.
- Event Analysis. An Advanced Event Definition builder enables you to define virtually any kind of event logic from any attribute (or combination of attributes).
- 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.
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.