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 |
RedThunder.Blog 