Overview

Before an application can be made available in production, it must be integrated within the 3DEXPERIENCE monitoring solution. Like any piece of computing, apps can fail, and therefore will fail, for any possible reason which might come to mind: resource exhaustion (no more disk space), operating system, database or application server failure, etc. Monitoring is used in order reduce your app's downtime in the event of a failure, and it can even contribute to preventively fix issues before they happen.

Another benefit of monitoring applications is that they can be used to check whether or not the app complies with "Service Level Agreement" (SLA) terms & conditions. Your app's SLA can include guaranties in term of availability of your application, frequency of data backups, and retention duration of backups.

Deployed apps can be monitored by various teams:

• L1 (Level 1) team. People working in a L1 team are assigned monitoring alerts which cannot be automatically fixed. An L1 person must strictly follow a step-by-step checklist dedicated to the component involved in the alert. For example, for an alert on a database, a first task in the check list might be to run the restart script for the database, a second one (if the first one did not fix the issue) could be to cleanup some temporary data and then restart the database, etc. If the procedures described in the checklist have been exhausted without the issue being fixed, then the L1 operator must transfer the issue to another team called L2 team.
• L2 (Level 2) team. People working in a L2 team know your application's deployment architecture, can perform advanced analysis of the problem cause using all data collected by the monitoring solution, can run any L1 procedure and can use advanced methods to gather more data and try to fix the issue.

You can monitor 3DEXPERIENCE platform services and servers using an existing tool called the Monitoring Agent. This tool is delivered together not only along with the different 3DEXPERIENCE service installers, but also as part of a separate, dedicated product named Monitoring Agent and Probes.

The monitoring agent is a stand-alone process launched from a command line, or launched as a service. One monitoring agent must be installed on each machine where the 3DEXPERIENCE code has been installed; and some agents must be installed on machines to perform service health checks through the same load-balancers used by end-users to access these services.

After the agent is configured to monitor a 3DEXPERIENCE service or a 3DEXPERIENCE server instance, it periodically gathers monitoring information (referred to as metrics) on the service or server, maps it to standard IBM Common Base Event (CBE) monitoring format, and saves it to the local machine where it runs.

The administrator can then exploit the results using the company's own monitoring console.

The following list contains key definitions:

Metric

The smallest unit of data structure for conveying measurements in the form of numerical values at specific times.

Event

A monitoring event is a group of metrics with a common prefix comprising:

• a set of conveyed metrics values. These metrics are named <event_name>.<metric_suffix> where <event_name> is the common prefix, and <metric_suffix> is specific to the metric, for example serviceHealthCheck.status, where serviceHealthCheck.status is the event name, and status is the suffix
• an optional short text message, which can help a human operator to understand the cause of an issue. This particular metric is named <event_name>.message.

Probe

A probe is an extension of the monitoring agent whose role is to provide monitoring of service-specific features. Probes are installed either by each service, or by Monitoring Agent and Probes, as illustrated in the following user assistance section: Installation and Setup - Install - 3DEXPERIENCE Platform - Installing 3DEXPERIENCE Platform Services for the First Time - Installing Services One-by-One - Monitoring Agent Installation - Overview - Architecture.

Probe subject

Metrics with identical names may be generated for different services. The notion of subject enables you to distinguish between these different services in the generated CBE file. In the context of Monitoring Agent and Probes, subject means "what is monitored". For example, for 3DSpace, the recommended subject name is "space", etc.

Monitoring Agent

A stand-alone process which periodically requests probe subjects to generate their events, and to serialize these events so that they can be collected by a monitoring system.

JMX

Acronym for Java Management eXtensions, a Java application programming interface designed to control and manage applications.

MBeans

Management Beans.