amf 9.2

8/16/2019 AMF 9.2

http://slidepdf.com/reader/full/amf-92 1/23

AMDOCS MONITORING FRAMEWORK

RELEASE 9.2

Amdocs Monitoring Framework 9.2

Functional Overview

8/16/2019 AMF 9.2


Copyright © 2014 Amdocs. All Rights Reserved. Reproduction or distribution other than for intended

purposes is prohibited, without the prior written consent of Amdocs. The trademarks and service marks of

Amdocs, including the Amdocs mark and logo, Intentional Customer Experience, CES, Clarify, Ensemble,

Enabler, Return on Relationship, Intelecable, Collabrent, XACCT, DST Innovis, Stibo Graphic Software, Qpass,

Cramer, SigValue, JacobsRimell, ChangingWorlds, jNetX, OpenMarket Inc., MX Telecom Inc., MX Telecom Ltd,

Streamezzo, and Bridgewater Systems are the exclusive property of Amdocs, and may not be used without

permission. All other marks are the property of their respective owners.

Document Information

Release: 9.2

Publication Date: November 2014

Catalog Number: 2287162

Information Security: Level 1 - Confidential

8/16/2019 AMF 9.2


Information Security Level 1 - Confidential iiiProprietary and Confidential Information of Amdocs

Table of Contents

1 Introduction ....................................................................................................................... 1

Scope of This Document ...................................................................................................................... 2

Target Audience ................................................................................................................................... 2

Related Documents ............................................................................................................................. 2

2 Product Overview ............................................................................................................. 3

Amdocs Monitoring Framework Overview ........................................................................................... 4

3 Product Components........................................................................................................ 7

Amdocs Monitoring Toolkit ................................................................................................................... 8

Main Features ............................................................................................................................ 8

Amdocs Monitoring Agent .................................................................................................................... 9

Main Features ............................................................................................................................ 9

Process Flow ........................................................................................................................... 10

Interaction with Other Applications and Systems .................................................................... 10

Amdocs Monitoring Gateway ............................................................................................................. 11

Main Features .......................................................................................................................... 11

Main Components ................................................................................................................... 12

Graphite ............................................................................................................................................. 17

Elasticsearch ...................................................................................................................................... 17

Amdocs Monitoring Framework Dashboard ...................................................................................... 17

4 Common Scenarios ........................................................................................................ 18

Ongoing Metric Collection Scenario................................................................................................... 19

Ad-Hoc Notification Scenario ............................................................................................................. 19

Application Status Indicator Change Scenario .................................................................................. 20

Rule-Based Status Indicator Change Scenario ................................................................................. 20

8/16/2019 AMF 9.2


Information Security Level 1 - Confidential 1Proprietary and Confidential Information of Amdocs

1 Introduction

Amdocs Monitoring Framework is a full suite monitoring platform, which provides real-time health monitoring metrics that enable smooth and easy integration to mostmonitoring systems. The data collected gives system operators the ability to monitorsystem health, and get notifications in case of system malfunction.

Amdocs Monitoring Framework consists of a monitoring server and a client-kit. The

client kit is adopted by Amdocs applications thus enabling the exposure of application-related health metrics.

This document presents the main functional features of Amdocs Monitoring Framework.

8/16/2019 AMF 9.2


8/16/2019 AMF 9.2



2 Product Overview

The following topics give a high-level description of Amdocs Monitoring Framework:

Amdocs Monitoring Framework Overview

8/16/2019 AMF 9.2


Amdocs Monitoring Framework 9.2 Functional OverviewChapter 2. Product Overview


Amdocs Monitoring Framework Overview Amdocs Monitoring Framework is a full suite monitoring platform, which provides real-

time health monitoring metrics that enable smooth and easy integration to most

monitoring systems. The data collected gives system operators the ability to monitorsystem health, and get notifications in case of system malfunction.

Amdocs Monitoring Framework consists of a monitoring server and a client-kit. Theclient kit is adopted by Amdocs applications thus enabling the exposure of application-

related health metrics.

Amdocs Monitoring Framework distinguishes between the following types of data:

Metric – A general term used for all types of metrics. A metric is a single piece ofdata pertaining to the health state and other parameters of various system

components. Metrics contain information regarding performance (latencies and backlogs), various errors that might occur in system components, system resources

(disk spaces), and more. Event – Represents an alert or a notification. Events are exposed by the Status

Indicator metric type that reports the current status of an application entity (such as

running, error, warning, and unknown) and by the ad-hoc notifications. They can also be generated as a result of rule execution (Rule and Metric Engine).

8/16/2019 AMF 9.2




The following figure shows the Amdocs Monitoring Framework functional architecture.It is followed by an explanation of each component.

Figure 2.1 Amdocs Monitoring Framework Functional Architecture

Amdocs Monitoring Framework comprises the following components:

Amdocs Monitoring Toolkit – Provides a common API with which Amdocsapplications are able to report application-specific metrics, such as the number of

invocations and response times. The Amdocs Monitoring Toolkit library is a general purpose library that can be adopted by any Amdocs application, including Amdocsfoundations, core products, and customization layers. Adoption of Amdocs

Monitoring Toolkit includes the adoption of its JAR files (during build), and theembedding of Amdocs Monitoring Toolkit calls into component code.

Amdocs Monitoring Agent – Enables Amdocs applications to register themselves toAmdocs Monitoring Gateway, letting the gateway be aware of their MBean server

host and port, and to query their MBeans and MBeans’ attributes.

Amdocs Monitoring Gateway – Enables monitoring systems to collect metricinformation from a single point of access, eliminating the need to discover and

connect to individual processes. Amdocs Monitoring Gateway enables the creation ofaggregate views over the collected data, allowing simple exposure of system widemetrics.

Amdocs Monitoring Gateway includes the Rule and Metric Engine component,which enables running complex rules that evaluate and correlate the values of

Amdocs Monitoring Framework

Amdocs Monitoring Gateway

Amdocs Application

Amdocs Monitoring Toolkit

Amdocs Monitoring Agent

Amdocs Application



Rule and Metric Engine

Graphite

Metrics

Elasticsearch

Events

Amdocs Monitoring Framework DashboardExternal

Management

System

1783164

Metrics (MBeans)

Rest

Rest

JMX-R

SNMP

8/16/2019 AMF 9.2




multiple metrics and generate alerts. Rule and Metric Engine also enables thecreation of metrics from existing metrics and from external sources such as Graphite.

Graphite – An open software tool that stores time-series data and renders graphs ofthis data on demand. Amdocs Monitoring Gateway sends metric information to

Graphite. The information is then available to Amdocs Monitoring FrameworkDashboard.

Elasticsearch – An open software search server based on Lucence. It provides adistributed, multitenant-capable full-text search engine with a RESTful Web interfaceand schema-free JSON documents.

Amdocs Monitoring Gateway sends events to Elasticsearch. Event history ismaintained in Elasticsearch. The events can then be available to Amdocs MonitoringFramework Dashboard.

Amdocs Monitoring Framework Dashboard – A dashboard that enables users tomonitor Amdocs applications. Amdocs Monitoring Framework Dashboard queries

Elasticsearch, Graphite, and Amdocs Monitoring Gateway, to present metrics, events,

and trend graphs.

External Management System – Represents an external monitoring and management

system (northbound management system), such as HP OpenView or IBM TivoliMonitoring.

8/16/2019 AMF 9.2



3 Product Components

This chapter provides information regarding the following Amdocs MonitoringFramework components:



Amdocs Monitoring Gateway

Graphite

Elasticsearch

Amdocs Monitoring Framework Dashboard

8/16/2019 AMF 9.2


Amdocs Monitoring Framework 9.2 Functional OverviewChapter 3. Product Components


Amdocs Monitoring Toolkit Amdocs Monitoring Toolkit enables Java applications to collect and expose health-state

metrics to a monitoring tool. Using a set of public APIs, applications are able to report

application-specific metrics, such as the number of invocations and response times.

All metrics are collected by each application’s code. The Amdocs Monitoring ToolkitAPIs report the collected metrics to monitoring tools using JMX MBean attributes andJMX notifications.

Amdocs Monitoring Toolkit does not feature a core/customization model, so that anymetrics reported at core level are automatically available in customization layers.

Adoption of Amdocs Monitoring Toolkit includes the adoption of its JAR files (during build), and the embedding of Amdocs Monitoring Toolkit calls into the application code.

No configuration activities are required.

Amdocs Monitoring Toolkit supports a preconfigured set of metrics, serving as a wrapper

for several third-party libraries that provide the ability to collect metrics and report them.It has a fixed footprint, meaning that computation time remains constant regardless of

polling intervals or update rates.

All metrics used by the adopting application at runtime must be registered duringapplication initialization before the run.

Amdocs Monitoring Toolkit is based on a lock-free data structure, so that metrics

collection and reporting does not block normal application flows.

Main Features

Amdocs Monitoring Toolkit provides the following main features:

Provides Amdocs Java applications with a unified API for collecting and exposingapplication metrics, including:

Counter – Increment/decrement counters (for example, the number of errors)

Timers – Time-related attributes (for example, operation response time)

Meter – Event rate (for example, the mean number of requests per second)

Gauge – Values maintained at application level (for example, queue size)

Status indicator – Running, error, warning, and unknown statuses

Ad-hoc notification – A unified API for sending JMX notifications to AmdocsMonitoring Gateway

Exposes application metrics and events in a standard way, using JMX MBean

attributes and JMX notifications

Maintains a fixed number of measured metrics (no auto-increment counters or

random values in metric names can be used), to ensure a stable, unvarying footprint

Can be implemented in multithreaded environments

8/16/2019 AMF 9.2




Compatible with JEE server environments (IBM WebSphere® and Oracle® WebLogic)

Amdocs Monitoring Agent Amdocs Monitoring Agent enables developers to connect an Amdocs application to the

gateway server, while registering itself to the gateway cluster (and its embeddedZooKeeper servers). Amdocs Monitoring Agent may serve both JEE and JSE Amdocsapplications.

Amdocs Monitoring Agent is based on the Curator framework. The Apache ZooKeeperagent handles the connections and the retry policies with the built-in Curator code.

Amdocs Monitoring Agent is embedded in each application JVM (EAR, WAR, JAR) andregisters local MBeanServer host:port on the Apache Zookeeper at startup. Amdocs

Monitoring Gateway receives notifications upon agent registration and connects to theregistered MBeanServers as needed.

Main Features

Amdocs Monitoring Agent provides the following main features:

Manages the connection against the gateway server, allowing a configured retry policy in case the connection to the server is lost.

The agent application configuration is based on predefined JVM arguments, bydefault. It exposes the agent application to the host gateway server and the relevant

connections retry policy to use.

Amdocs application deployed on a J2EE container gets an enterprise applicationarchive (.EAR) .This .EAR contains a Web application module (.WAR). The Web

application contains a servlet allowing all applications deployed on the same JVM toregister themselves to Amdocs Monitoring Gateway.

The agent is exposed as a J2EE application and as an API to be used within a JSEapplication in the same process. The agent code is packed into a .WAR file packedinto .EAR file and then provided as a library for JSE applications. The JSE

application should unpack the .WAR file in order to have the entire required agentJARs to be added to the classpath.

Bulk MBean pre-fetch. It is used to fetch a bulk of MBean data that is cached inAmdocs Monitoring Gateway thus enhancing performance.

8/16/2019 AMF 9.2




Process Flow

Amdocs Monitoring Agent manages the connection against the gateway server, allowing

a configured retry policy in case the connection to the server is lost.

The general registration flow for an agent application is as follows:

1. Exposing Bulk MBean. This is done at the beginning of the flow so it is available as

soon as possible.

2. Instantiating an Apache ZooKeeper agent based on the Curator framework code. Thefollowing is provided:

A separated connection string including one or more host name and ports, inwhich the Apache ZooKeeper gateway server is deployed.

A configurable sleep time between retries that is used by the retry policy of theconnection.

Note: By default, Amdocs Monitoring Agent allows configuring only the retrysleep time and not the retry count. Consider carefully when and if to use a policy, which is not the Amdocs Monitoring Agent default one, as at thisstage, no connection state callback is registered by the agent client. Sinceconnection state callback is not supported, there is no need to expose theretry-time configuration, as there is no way for an agent client to handlecases where the retry count has reached the upper limit.

Note: The generic configuration interface exposed by the gateway allows passing in any Curator available retry policy for JSE applications. For suchapplications it is highly recommended to use the default Amdocs MonitoringFramework abstract implementationcom.amdocs.amf.agent.config.AbstractCuratorAgentConfiguration

3. Registering the host application on the Apache ZooKeeper cluster, providing the

local MBean server host and port, as well as the JMX service URL to the gatewayserver.

Interaction with Other Applications and Systems

Amdocs Monitoring Agent is based on the Curator framework, which is built on ApacheZooKeeper (Apache licensed). The Apache Zookeeper eases agents’ communication. TheApache ZooKeeper agent initializes and handles the connections and the retry policieswith the built-in Curator code.

The Curator framework is completely thread safe, and allows an application to share oneCurator framework instance for the calling application. A caller can maintain theframework instance to the same Apache ZooKeeper cluster, and use it in a safe manner.

8/16/2019 AMF 9.2




Amdocs Monitoring Gateway Amdocs Monitoring Gateway enables an upstream monitoring system to collect metricinformation from a single point of access, eliminating the need to discover and connect toindividual processes. Amdocs Monitoring Gateway enables the creation of aggregate

views over the collected data, allowing simple exposure of system wide metrics.

Main Features

Amdocs Monitoring Gateway provides the following main features:

Provides a single access point to all Amdocs applicative metrics.

Provides a single access point to all Amdocs applicative JMX notifications.

Automatically discovers application processes (assuming Amdocs Monitoring Agent

is installed in the monitored application), without requiring manual configuration ofhosts and ports of individual instances.

Handles connection failures to underlying processes. In case a process is not running,the gateway responds to the northbound management system with an error.

Exposes its information to northbound management systems through REST, JMX,and SNMP interfaces.

Stores history information in Graphite and Elasticsearch.

Provides aggregate views over data exposed by individual processes.

Metrics can be grouped by:

Host name

Process instance

Individual attributes can be aggregated using configurable aggregation functions:

Sum, Average, Min, Max

Sample – An attribute value is retrieved from an arbitrary processes within agroup

Enables flexible deployment of a hierarchy of gateways and agents – starting from ahost level agent collecting data from multiple processes running on that host, up to a

central gateway exposing information from multiple agents. From technical perspective, all types of gateways share the same infrastructure, utilizing different

configuration settings to determine their specific role.

Supports the cache mechanism to enhance performance. Amdocs Monitoring

Gateway pre-fetches a bulk of MBean data, using Bulk MBean. Bulk MBean is aJMX MBean registered in the MBean server on the Amdocs Monitoring Agent side.Amdocs Monitoring Gateway caches the data locally, allowing higher throughput to

queries from northbound clients and reducing loads from the agent applications.

Note: This pre-fetch mechanism must be configured correctly, via AmdocsSystem Configurator, so the gateway only pre-fetches metrics of interest to thenorthbound management system.

8/16/2019 AMF 9.2




Supports standard JMX security features (user name/password authentication andSSL transport)

Main Components

This section describes the Amdocs Monitoring Gateway components.

Connection Manager

Connection Manager is responsible for:

Auto-discovery of processes monitored by Amdocs Monitoring Gateway

Keeping reliable connections from Amdocs Monitoring Gateway to monitored processes

Connection Manager starts ZooKeeper, a third-party application, which keeps reliable

connections with monitored applications and notifies Amdocs Monitoring Gateway aboutany topology changes.

The monitored processes must register in the ZooKeeper server, providing their address – host and port. This way, Amdocs Monitoring Gateway gets access to all registeredmonitored processes and gets notifications from ZooKeeper server on any new orremoved connection.

Connection Manager encapsulates all interactions of Amdocs Monitoring Gateway with

the ZooKeeper server. Configuring the ZooKeeper server is done through AmdocsSystem Configurator. Depending on configuration, an Amdocs Monitoring Gatewayinstance can:

Start an embedded (in-proc) instance of Connection Manager

Connect to an external Connection Manager instance

Connect to a cluster of Connection Managers

Connection Manager Client

Connection Manager Client registers itself in the ZooKeeper server that is started byConnection Manager.

Connection Manager Client gets notifications from Connection Manager when a new

monitored application is registered or when an existing application is removed.Connection Manager Client delegates these notifications to the connection event listenersassociated with Connection Manager Client.

Connection Manager Client uses a third-party library, Netflix Curator, for connecting tothe ZooKeeper server. Specifically, it uses Curator Discovery, a sub-module of the

Curator Framework. Curator Discovery provides high-level abstraction over ZooKeeper,allowing nodes to register and receiving events on topology changes.

Connection Manager Client encapsulates all interactions with the Curator Framework.

ZooKeeper manages the clients’ data in a tree-like structure, where each node in the treecan keep real data.

Connection Manager Client registers its data in ZooKeeper under a base node path. Foreach agent, a new node with a unique ID is created. Under this node, agent publishes its

8/16/2019 AMF 9.2




MBean server URL. This way, Amdocs Monitoring Gateway knows where to findMBeans of the monitored application.

MBean Data Collector

MBean Data Collector collects all MBeans from the monitored applications according toa set of filters pre-defined in Amdocs System Configurator. MBean Data Collector provides the Amdocs Monitoring Gateway modules with a list of relevant MBeans andMBeans’ data (attributes). It also notifies the modules about changes in the list of activeMBeans.

The MBean Data Collector configuration includes a list of MBean name filters. Thefilters follow MBean Object Names semantics and utilize wildcard-based filteringcapabilities provided by JMX. The filters enable controlling set of the MBeans that areexposed in Amdocs Monitoring Gateway.

MBean data Collector implements logic of synchronization with MBeans registered inmonitored applications (for initial synchronization and for new MBean registration).

MBean data Collector receives notifications from Connection Manager about added andremoved connections with monitored processes.

MBean Poller

Because new MBeans can be created in the monitored application, Amdocs MonitoringGateway must be updated accordingly.

MBean Poller periodically calls a dedicated method in the MBeanDataCollectorinstance. This method synchronizes its MBeans with the MBeans registered in

MBeanServers of the monitored applications.

Mirroring

Mirroring enables access to MBeans located in multiple MBean Servers from a singlelocation. Both attributes and notifications within the underlying MBeans are mirrored.The mirrored MBeans are implemented as dynamic MBeans.

The Mirroring module exposes all MBeans that are provided by the MBean DataCollector module. These MBeans are filtered according to the filters pre-defined inAmdocs System Configurator.

Mirroring contributes a set of JMX MBeans that are registered in the Gateway’s MBeanServer. The Mirroring module implements the following lifecycle methods:

Init – reads the module configuration and registers any needed listeners

Start – starts operation (exposing any required MBeans)

Stop – shuts down the module

Notification

Notification centralizes JMX notifications emitted by multiple MBean servers to a singlenotification access point, which is implemented as a dynamic MBean.

8/16/2019 AMF 9.2




MBean Cache

MBean Cache enhances the gateway performance by reducing RMI calls to the agent

applications. The RMI calls get MBean data from the agents and are invoked bynorthbound management systems through the gateway. MBean Cache stores a bulk of

MBean data that is pre-fetched by the gateway periodically, based on a configurable polling interval time (rather than on demand). The polling interval time and the filters based on which metrics are fetched are set in Amdocs System Configurator.

Aggregation

Aggregation enables the creation of aggregate views, consolidating data collected frommetrics that share the same metric name and are located in multiple monitored processes.The aggregation types based on the collected metrics are:

Counter aggregations

Timer aggregations

Meter aggregations

Gauge aggregations

Aggregate views are defined by:

Selecting the set of source metrics participating in the view, by specifying a filter to be applied over the metric names.

Selecting the MBean attributes to be aggregated. An aggregation function is specified

per field. The following functions are supported:

Sum

Average

Min Max

Sample – Using this function, monitored attribute values are retrieved from anarbitrary metric within a group of metrics collected from different monitored

processes (rather than applying calculation on all the collected attribute values).The arbitrary metric is selected randomly by Amdocs Monitoring Gateway.

Example:

To calculate max response time of an operation deployed in multiple applicationprocesses, the following configuration is required:

Defining a filter that includes the operation response time metric name

Applying Max aggregation function to the ‘Max’ attribute of the timers

REST Adapter

Rest Adapter provides RESTful interface to the northbound monitoring tool (Jolokia).

Jolokia is an agent-based approach to access MBeans. It uses HTTP for its transport

business where the data payload is serialized in JSON (http://www.json.org). UsingHTTP instead of java-centric RMI, Jolokia allows non-Java clients to access MBeans.

8/16/2019 AMF 9.2




Jolokia provides new features for accessing JMX remotely, which are not available inJSR-160 connectors:

Bulk requests allow for multiple JMX operations with a single remote serverroundtrip

A fine grained security mechanism can restrict the JMX access on specific JMXoperations

Other features such as the JSR-160 proxy mode or history tracking

Jolokia is deployed as a Web application on the Tomcat server on which AmdocsMonitoring Gateway is running. The MBeans registered in the Gateway MBean servercan be accessed via Jolokia using REST requests to the Jolokia Web application.

SNMP Agent

Simple Network Management Protocol (SNMP) is an internet-standard protocol for

managing devices on IP networks. It is used mostly in network management systems tomonitor network-attached devices for conditions that warrant administrative attention.

For further information on SNMP, see www.ietf.org.

Amdocs Monitoring Gateway exposes metric information to external northboundmanagement systems through the SNMP interface.

SNMP Agent is the Amdocs Monitoring Gateway module responsible for the SNMPcommunication. It translates the metric information (JMX MBeans) to SNMP entities,

and vice versa. SNMP Agent supports SNMP v2c and v3 protocols.

The mapping between Amdocs JMX MBeans and SNMP entities is set in Amdocs

System Configurator.

SNMP Agent can be configured as one of the following types:

Native – SNMP Agent listens and handles SNMP requests without passing themfurther.

AgentX – SNMP Agent serves as a subagent, and communicates with a master agentvia the AgentX protocol. Using this protocol, a master agent receives requests and

passes them to subagents.

At runtime, SNMP Agent does the following:

Responds to SNMP get requests, and thus exposes Amdocs collected metrics

Sends SNMP traps

Note: Currently, Amdocs Monitoring Gateway sends SNMP traps using the

SNMP v2c protocol only.

http://www.ietf.org/




8/16/2019 AMF 9.2


8/16/2019 AMF 9.2




Rule and Metric Engine

Rule and Metric Engine enables running complex rules that evaluate the values of metrics

with the purpose of finding potential problems in the system. For example, a rule may beused for comparing the size of a queue to a predefined threshold. If the size exceeds the

threshold, an alert is issued.A rule is linked to either a metric of the Status Indicator type or to an ad-hoc notification.A metric of the Status Indicator type is updated every time the rule is executed toRunning, Error, Warning or Unknown.

Rule and Metric Engine also enables the creation of metrics from values of other existing

metrics and from external sources such as Graphite. This type of metrics is known as RME metrics. The RME metric value is calculated by running an expression using theexisting metrics values, parameters, and constants.

The configuration of the rules and RME metrics is done through Amdocs SystemConfigurator. As a result, a configuration file is created containing the required

definitions. For more information, see Amdocs Monitoring Gateway Configurator Guide.

Graphite Graphite is an open software tool for monitoring and graphing the performance ofsystems. Graphite collects, stores, and displays time series data in real time. It containsthree main subcomponents:

Carbon – A Twisted daemon that listens for time-series data.

Whisper – A simple database library for storing time-series data.

Graphite Web application – A front-end Web application that renders graphs and provides a basic user interface.

Amdocs Monitoring Gateway fetches metrics from all the registered agents and sends the

information to Graphite. The information is saved in the history Graphite database, and isavailable to Amdocs Monitoring Framework Dashboard.

Elasticsearch Elasticsearch is an open software search server based on Lucence. It provides a

distributed, multitenant-capable full-text search engine with a RESTful Web interfaceand schema-free JSON documents. Amdocs Monitoring Gateway sends events toElasticsearch. The events are then available to Amdocs Monitoring Framework

Dashboard.

Amdocs Monitoring Framework Dashboard Amdocs Monitoring Framework Dashboard enables users to monitor Amdocsapplications. Amdocs Monitoring Framework Dashboard queries Elasticsearch, Graphite,and Amdocs Monitoring Gateway, to present metrics, events, and trend graphs.

8/16/2019 AMF 9.2



4 Common Scenarios

This chapter describes common scenarios handled by Amdocs Monitoring Framework.

For detailed information, see the following topics:

Ongoing Metric Collection Scenario

Ad-Hoc Notification Scenario

Application Status Indicator Change Scenario

Rule-Based Status Indicator Change Scenario

8/16/2019 AMF 9.2


Amdocs Monitoring Framework 9.2 Functional OverviewChapter 4. Common Scenarios


Ongoing Metric Collection Scenario The following scenario describes the flow of metrics from Amdocs applications, through

Amdocs Monitoring Gateway, up to Amdocs Monitoring Framework Dashboard:

1. An Amdocs application uses Amdocs Monitoring Toolkit to maintain metrics in its

MBean server.

2. Amdocs Monitoring Gateway periodically polls the application for its BulkMBean,which returns a bulk of all monitoring metrics to the gateway.

3. Amdocs Monitoring Gateway refreshes ehCache with fresh application metrics.

4. Amdocs Monitoring Gateway periodically queries all Amdocs Mbeans from ehCache

and sends the data to Graphite (Carbon).

5. Graphite provides with refreshed metric data points in Graphite’s cache and Whisperdatabase.

6. Amdocs Monitoring Framework Dashboard periodically refreshes views such asgraphs or SLAs by calling the Graphite render API to get data points.

7. Amdocs Monitoring Framework Dashboard updates bound views to render freshdata.

Ad-Hoc Notification Scenario The following scenario describes the creation of ad-hoc notifications:

1. An Amdocs application catches exception and uses Amdocs Monitoring Toolkit to

initiate an ad-hoc notification.

2. The Notification component of Amdocs Monitoring Gateway parses the notificationand invokes an Elasticsearch java API to index the notification as a document.

3. Amdocs Monitoring Framework Dashboard periodically refreshes alert views by

querying the Event Storage API to get filtered events.

4. The following steps occur concurrently:

Amdocs Monitoring Framework Dashboard updates bound views to render fresh

data

Rule and Metric Engine periodically polls the Event Storage API to get

incremental events

5. Rule and Metric Engine applies rules against severity and event tags to determine the

distribution list to which the event is sent (if at all), and initiates an email with theSMTP server.

8/16/2019 AMF 9.2


Amdocs Monitoring Framework 9.2 Functional OverviewChapter 4. Common Scenarios

Information Security Level 1 - Confidential 20

Application Status Indicator Change Scenario The following scenario describes a change in a Status Indicator metric:

1. An Amdocs application uses Amdocs Monitoring Toolkit to maintain Status

Indicator metrics in its MBean server. Status indicator is set to Running, Error, Warning or Unknown

An alert message is set

2. Amdocs Monitoring Toolkit emits a notification.

3. The notification event is received in Amdocs Monitoring Gateway and is stored as adocument in Event Storage.

Amdocs Monitoring Framework Dashboard polls the event document to renderevent views

The Rule and Metric Engine polls the event document to send an alert email

4. Amdocs Monitoring Gateway polls the metric and refreshes its value it the gatewayand in Graphite.

Rule-Based Status Indicator Change Scenario This following scenario describes the creation of a metric of the Status Indicator type,

based on Graphite trends:

1. According to predefined rules, Rule and Metric Engine periodically queries theGraphite render API for calculated metric data points.

2. Rules are applied to retrieved data points against configured thresholds; a metric ofthe Status Indicator type is set to Running, Warning, Error, or Unknown.

3. Rule and Metric Engine uses Amdocs Monitoring Toolkit to set rule-based statusvalues accordingly.

4. Amdocs Monitoring Toolkit emits notifications to Amdocs Monitoring Gateway,which initiates the “Application Status Indicator Change Scenario.”

5. Amdocs Monitoring Gateway periodically refreshes Status Indicator values from the

Rule and Metric Engine.

6. Amdocs Monitoring Framework Dashboard periodically refreshes Status widgets by

polling the Amdocs Monitoring Gateway Jolokia API to get preconfigured statusindicators.

7. Amdocs Monitoring Framework Dashboard updates bound views to render fresh data