This page is deprecated in favour of documentation provided at http://xdaq.web.cern.ch

Introduction

The XMAS (XDAQ Monitoring and Alarming Suite) provide the tools to observe XDAQ application activities. XMAS is essential if you need to stay connected with your XDAQ applications so you can monitor them continuously. It consists of an architecture that allows aggregation and dissemintation of metrics from XDAQ applications. XMAS can work on a single computer just as well as it can work across a network. The goal of XMAS is to provide a dynamic and extandable framework for gathering and reporting metrics about XDAQ services and applications runinng within defined groups. The types of metrics maintained for a service will be defined per service implementation and an XML representation of each type of metric (Flashlist). The XMAS includes tools for gathering metrics acros the distributed systems.

XMAS Architecture

A xmas::sensor::application plug-in is available for every local XDAQ context in a group, that provide a WEB API for obtaining either runtime metric totals for one or more XDAQ applications (pull mode) or for registering listeners that will detect periodic updates of metric data (push-mode). Each sensor shall be configured by defining the data elements that should be monitored and how they should be sampled. The sensor configuration is given as an XML file. The sensor configuration refers to flashlist definitions in order to define the data element that need to be monitored. Two type of sampling are available. The instant sampling which report the most up to dat value of a given data element and the history sampling that allow the periodic collection of a number of data elements within a windo of time. Instant or history metrics both collected via pull or push mode are reported by to a WS-eventing service according configuration. The WS-eventing service is implemented by the XDAQ application xmas::service::Eventing. All metrics are available as binary data tables. All service metrics are serialized in appropriate format for trasmission over the network.

Several method are provide by the XMAS infrastructure to retrieve metrics collected by the sensors.

• direct retrieval from xmas::sensor::Application

This method is not supported yet.

• The WS-Eventing Service notification

Metrics can be obtained directly from the ws-eventing service by simple subcription to the service itself. Different level of ws-eventing service can be configured for scalability and defined levels of data aggregation. Since metric clients (local or remote) may not be interested in all metrics for a given group, any request for metrics can be accompanied by a filter that specify which service metrics are desired (XPath). Additionaly service specific filters may be provided to limit the amount of metrics that are reported. These filters, besides reducing the amount of processing on a metric source, will reduce the amount of network bandwidth in reporting metrics since unnecessary data will not be included. This method required knowldge of the ws-eventing standard SOAP interface. The ws-eventing give a lower level of access to the data and report of data are for single data sources. It is responsibility of the client to perform required collection from several sources.

• LAS , Live Access Services

Metric can be obtained via a simple SOAP as binary attachments, HTML or CSV formats. The LAS service provide a simpler method to access collected metrics. It also perform simple aggregation of metrics from several sources in the distributed environment. The LAS relies receive monitoring data through the WS-Eventing services.

• Web dashboards

The dashboard services provides mechanism to browse metrics through a WEB interface

Monitorable Services

XDAQ applications can be instrumented to be monitorable by using qualified infospace as container of monitoring data. The extension to the application is such that application can run independently of the use of the XMAS infrastructure. The qualified infospaces are visible to the XMAS infrastucture and can be monitored by properly instructing the xmas::sensor::Application plugin. It is a good practice but not mandatory to provide a XMAS sensor configuration ( a XML file ) per each application class that provide a service, which is loaded into the running XDAQ process. The XMAS sensor configuration can be empty, therefore indicating the that service does not provide monitoring data.

NB All XMAS services rely on the discovery services. Therefore the XPlore applicatino must be configured for the system.