January 2025 – RedThunder.Blog

Deploying OCI APM Service for Optimal EBS Application Observability

The OCI Application Performance Monitoring (APM) service allows administrators to monitor and observe the E-Business Suite web applications.

It provides deep visibility into the application performance from end-user experience down through to the application server requests.

For many customers, the E-Business Suite (EBS) Application is critical to business operations. With OCI Application Performance Monitoring (APM) service, administrators can:

Analyze all end user experience with accessing EBS web and form pages.
Trace transactions across various components and isolate problems to the impacting application or infrastructure tier.
Has ability to drill into application code and SQL calls to the database
Easily Capture End Username for user sessions without modifying application code
To search in context, you can use out of box EBS attributes auto generated from traces. These attributes include:
– EBS Function Name
– EBS Class Package Name
– EBS Forms Name
– and more ….

How To Capture Client IP in OCI Application Performance Monitoring

The Oracle Cloud Application Performance Monitoring (APM) service collects end user trace sessions for Real User Monitoring (RUM). By default the client IP is not captured for the end user session. For some customers, default Geolocation info (eg. Country, Region, City) may be sufficient for end user monitoring. However, for those who want to collect Client IP information as well, to enable this setting please see the following example.

Enable Client IP Collection for End User Session

For every End User Session, we want to capture the Client IP address location.

1. To do this, in the OCI Console, navigate to the OCI APM Service

OBSERVABILITY & MANAGEMENT > APPLICATION PERFORMANCE MONITORING > ADMINISTRATION

2. Then navigate to:
APM DOMAINS > [Select APM Domain eg. psft_app] > Span Enrichment > Global Settings

Guide to OCI Custom Metrics and Monitoring Options

OCI gives you flexibility to create custom metrics when no out of box metrics are available. There are two options on how this can be achieved. Depending on your use case let’s take a look at which choice works for you.

Requirements	OCI Monitoring Service	OCI Stack Monitoring Service
View Metrics in Monitoring Service	Yes	Yes
Create Alarms	Yes	Yes – Automatically, emitted to Monitoring Service once Metric Extension is enabled for target resource
Metric Dimensions	Yes	Yes
Frequency Collection	Control by client API execution, cron job, scheduler or agent	Yes – can be configured when creating the metric extension.
Collection can be directly executed by OS command, Script(eg. Shell, Python), SQL, JMX or HTTP (REST API)	Custom Metrics can be published using OCI CLI or REST API	Yes – Use Metrics Extensions
Centrally manage Custom Metrics for single or multiple resources – Enable, Clone, Export/Import		Yes
Define collection based on Resource Types (eg. apache_http_server, apache_tomcat, oci_oracle_db, ebs_instance, host_linux, host_windows, miscrosoft_iis, sql_server etc…)		Yes
Baseline and Anomaly detection in Metrics using ML based algorithms		Yes
Perform correlation across multiple metrics		Yes
Apply Metric Extension lifecycle phases: Test and Validate, Publish		Yes
Custom Metric Collection from OCI, on-premise and/3rd party Cloud	Yes	Yes
Alert against log data from OCI Logging Analytics	Yes – The Detection Rule needs to be created in OCI Logging Analytics
Custom Metric collection using Prometheus Exporter	Yes	Yes