Tchater maintenant avec le support
Tchattez avec un ingénieur du support

Foglight for Application Operations 5.9.8.5 - User Guide

Introducing Foglight APM Monitoring Transactions Examining Response Times Examining Error Breakdowns Viewing Real User Activity from a Geographical Perspective Using the SOC Transactions Tab Using the SOC for APM triage Creating Custom Drag-and-Drop Dashboards APM Tile and View Reference Appendix: Enabling End User Transactions from FxM and FxV

Topology object name reference table

The following table provides the domain and topology object names you need to use to ensure the tiles appear correctly for a manually built service.

 
Table 31. Topology object name reference
Domain
Topology Object

.NET

.NETApplicationInstance

Apache

ApacheSvrAgent

AppMonitor

AppMonitorAgent

APM Appliance (hits)

EUHitInteraction

APM Appliance (sequences)

EUSequenceInteraction

Custom Application Transactions (Java™ EE and .NET®)

CustomApplicationTransaction

DB2

DB2_Instance

FTR

FTRResult

FxM

FxMApplicationResult

Host1

Host

Java EE Technologies

JavaEEAppServer

JMX

JMXServer

Log Filter

LogFilterAgent

MQ Series

MQQueueManager

Oracle

DBO_Instance

SQL Server

DBSS_Instance

Sybase

Sybase_MDAAgent

WebMonitor

WebMonitorAgent

1

For hosts, always select the host object, regardless of whether or not the host is virtual (for example, Hyper-V® or VMware®). Foglight looks for the appropriate host extensions and displays the associated host dashboard (physical or virtual).


 
* 
NOTE: The list of available topology objects is current as of this release. Additional cartridges may add additional relevant objects in future releases.

 

Appendix: Enabling End User Transactions from FxM and FxV

This section describes the configuration required to use FxM and FxV as data sources for Foglight for Application Operations. Read through all sections that apply to the functionality you want to enable before attempting to configure the integration and use the dashboards.

For building services:

•
Understanding recommended service structures
•
Service Level Agreements in Foglight APM
•
Defining how the SLA is calculated for services

For the Service Operations Console (SOC):

•
Prerequisites for monitoring end user transactions in the SOC
•
Configuring trace analysis for the SOC

For Geographical Perspectives:

•
Prerequisites for using the Geographical Perspective dashboard
•
Creating a map agent for FxM appliance data
•
Editing Map Agent properties

For Response Time Breakdowns:

•
Prerequisites for using the Response Time Explorer dashboard
•
Associating FxV hitfFilter mappings for response time breakdowns
•
Assigning proxy objects
or
•
Install the Foglight Management Server and ensure it is running. For more information, see the Foglight Installation and Setup Guide set.
•
Install and configure the cartridges required to monitor application components (for example, operating system, application servers, databases). For more information, see the documentation included with the cartridges you are using.
•
Configure End User transactions in Foglight Experience Monitor (FxM), Foglight Transaction Recorder (FTR), and Foglight Experience Viewer (FxV). For more information, see the documentation for these components.
•
Build services, either through Dependency Mapping or manually, and add the services to the Service Operations Console. For more information, see the topic “Creating and maintaining services” in the Managing Dependency Mapping User Guide.

Understanding recommended service structures

In Foglight, a service is any component or group of components that you want to monitor. If you have the Advanced Operator role, you can create services in the Service Builder dashboard to reflect the components in your monitored environment that are meaningful or interesting to your organization. For more information, see the topic “Monitoring your services” in the Foglight User Guide.

APM users typically organize their application services into three types: a Top Level Service, Tier Services, and one or more User Services. Each logical tier in the application should have its own service, which includes the application components (for example, databases, application servers, web servers) and the hosts that support those components.

•
A Top Level Service contains all elements in the application. It includes all child services and is added to the Service Operations Console (SOC) for application support.
•
A Tier Service is a logical representation of a service component. Foglight organizes data into default tiers, including User, Web, Application, Database, Host, and Agent. Over time, the Tier Service can track operational level agreements.
•
A User Service contains all End User artifacts, and organizes the transactions that support the application. For most users, a single End User service is sufficient.

For example, a typical small web application might have the following service structure.

Figure 98. Small service structure

This is a high-level, or tier view of the service structure. This service includes four tiers: User, Web, Application, and Database.

This service can also be represented as follows.

Figure 99. Four-tier service structure

This is the application infrastructure view. Here you can see the hosts contained in each tier: an Apache server (web tier), two instances of WebLogic® each hosted on a separate application server (App tier), and an Oracle® database instance (DB tier).

For more information, see the following topics:

•
Using the SOC Transactions Tab
•
Service Level Agreements in Foglight APM
•
Defining how the SLA is calculated for services

Service Level Agreements in Foglight APM

Foglight automatically examines each service and establishes its availability and service level compliance. By default, a service is available and compliant with its Service Level Agreement (SLA) if it does not have any fatal alarms.

The following general guidelines are recommended for Foglight APM:

•
Implement a top-level SLA based on end user transactional data to allow the Application Support team to become familiar with SLA functions and the data available. For more information, see Defining how the SLA is calculated for services.
•
Defer the implementation of tier-based SLAs until your organization is ready to implement official operational level agreements for the infrastructure and component level teams.
Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation