Skip to main content

OCI Monitoring Should Have At Least One Alarm Configured

More Info:​

A tenancy with zero configured metric alarms indicates a complete lack of operational and security monitoring. Alarms are mandatory for maintaining situational awareness.

Risk Level​

Medium

Address​

Compliance, Security

Compliance Standards​

  • APRA CPS 234 (Australia)
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS AWS
  • CIS Critical Security Controls v8
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • Cloudanix Best Practice
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • HIPAA
  • ISO 27001
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIS2 Directive
  • NIST CSF
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • SOC2
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • UK NCSC Cyber Assessment Framework

Triage and Remediation​

Remediation​

Using Console

To remediate “OCI Monitoring should have at least one alarm configured” using the OCI Console, you need to create at least one Monitoring Alarm in each relevant compartment/region where you have monitored resources.

Below are step‑by‑step console instructions.

1. Decide What You Want to Monitor​

Typical choices:

  • Compute: CPU Utilization, Memory (custom), Network
  • Block Volume: VolumeUsage, VolumeThroughput
  • Object Storage: BucketStorageUsage
  • Databases: CPU, Storage, I/O
  • Load Balancer: Backend health, HTTP codes, Latency

You will create an alarm on a metric (e.g., CPUUtilization for compute instances) and tie it to an Alarm Destination (Notification Topic).

2. (If Needed) Create a Notification Topic & Subscription​

  1. In the OCI Console, open the hamburger menu (☰).
  2. Go to Application Integration → Notifications.
  3. Ensure you’re in the correct region (top-right region selector).
  4. Click Create Topic:
    • Name: e.g., critical-alarms-topic
    • Description: optional
    • Compartment: choose the compartment where you want to manage alerts
    • Click Create.
  5. Click the topic you just created.
  6. Under Subscriptions, click Create Subscription:
    • Protocol: e.g., Email
    • Endpoint: your email address
    • Click Create.
  7. Go to your email and confirm the subscription (click the confirmation link).

You must confirm, otherwise alarms will show as firing but you won’t receive notifications.

3. Create a Monitoring Alarm​

  1. Open the hamburger menu (☰).
  2. Go to Observability & Management → Monitoring → Alarms.
  3. Verify the region and compartment are correct (top of page).
  4. Click Create alarm.

A. Basic Details​

  1. Fill in:
    • Alarm name: e.g., cpu-utilization-high
    • Compartment: where the alarm should be defined
    • Metric compartment: where the resource metrics reside (can be same as alarm compartment)
    • Optional: Alarm description.

B. Alarm Query (Metric & Condition)​

You can either use the Query Builder or the text editor.

  1. Under Metric namespace, choose appropriate namespace, e.g.:
    • For Compute instances: oci_computeagent
  2. Under Metric name, select a metric, e.g.:
    • CpuUtilization
  3. In the resource filters, select:
    • Resource group: (if any, optional)
    • Dimension filters: e.g., choose specific instance or instancePoolId, etc.
  4. Set the statistic and interval, e.g.:
    • Statistic: mean
    • Interval: 1 minute or 5 minutes.

This will auto-generate an MQL query such as:

CpuUtilization[5m].mean() > 80
  1. Set Trigger rule:
    • Condition: e.g., > (greater than)
    • Threshold: e.g., 80
    • Duration: number of consecutive periods, e.g. “for 3 out of 3 intervals”.

C. Alarm Severity​

  1. Set Severity:
    • e.g. Critical for production/high-priority alerts.

D. Destinations (Where to Send Alerts)​

  1. Under Alarm Destinations, choose:
    • Notifications Topic you created earlier (e.g., critical-alarms-topic).
  2. Optionally enable:
    • Repeat notifications at intervals if condition persists.

E. Actions & Lifecycle​

  1. Under Notification Settings, optionally:
    • Enable “Notify when alarm is cleared” if you want recovery notifications.
  2. Under Suppress (optional):
    • Configure suppression windows if you want to silence alarms during maintenance.

F. Save the Alarm​

  1. Review all settings.
  2. Click Create alarm.

4. Verify the Alarm​

  1. In Monitoring → Alarms, confirm:
    • The alarm is listed and in OK or INSUFFICIENT_DATA state (initial state can take a few minutes).
  2. Confirm:
    • Email subscription is Confirmed in Notifications → Subscriptions.
  3. (Optional) Temporarily create a condition that will definitely trigger (for test), or increase load on the resource, then:
    • Check that the alarm state changes to FIRING.
    • Verify that you receive the email notification.

5. Ensure Policy Coverage​

If alarms or notifications are cross-compartment or cross-tenant, ensure IAM policies allow Monitoring and Notifications usage. For basic same-compartment alarms using your own user, typically no extra policy changes are required.

By having at least one active alarm configured in each required compartment/region, you remediate the misconfiguration “OCI Monitoring Should Have At Least One Alarm Configured” for OCI Alerting Monitoring.

Using CLI

Below is a minimal, CLI-focused runbook to ensure OCI Monitoring has at least one alarm configured.

1. Prerequisites​

  • OCI CLI installed and configured (oci setup config)
  • IAM permissions to:
    • Read metrics and create alarms
    • Read/create Notifications topics (ONS)

Assume:

  • Compartment OCID: ocid1.compartment.oc1..xxxx
  • Region correctly set in your CLI config.

2. (Optional) Create a Notifications Topic for Alarm Delivery​

If you don’t already have an ONS topic:

oci ons topic create \
  --name "monitoring-alarms-topic" \
  --compartment-id "ocid1.compartment.oc1..xxxx" \
  --description "Topic for monitoring alarms"

Capture the topic-id from the output (call it TOPIC_OCID).

Add at least one subscription (email example):

oci ons subscription create \
  --topic-id "$TOPIC_OCID" \
  --protocol EMAIL \
  --endpoint "your-email@example.com"

Confirm and activate via the email link you receive.

3. Decide What to Monitor (Example Metric)​

Example: Instance CPU Utilization > 80% for 5 minutes.

  • Namespace: oci_computeagent
  • Metric name: CpuUtilization
  • Resource group: usually blank for basic alarms, or you can include if needed.
  • Example query:
CpuUtilization[5m]{resourceId = "<INSTANCE_OCID>"}.mean() > 80

Or for all instances in a compartment (not best-practice for prod, but valid for “at least one alarm”):

CpuUtilization[5m].mean() > 80

4. Create the Alarm via OCI CLI​

Run:

oci monitoring alarm create \
  --compartment-id "ocid1.compartment.oc1..xxxx" \
  --display-name "High CPU Utilization Alarm" \
  --namespace "oci_computeagent" \
  --query-text 'CpuUtilization[5m].mean() > 80' \
  --severity "CRITICAL" \
  --destinations '["'"$TOPIC_OCID"'"]' \
  --is-enabled true \
  --message-format "ONS_OPTIMIZED" \
  --metric-compartment-id "ocid1.compartment.oc1..xxxx" \
  --body "CPU utilization above 80% for 5 minutes." \
  --repeat-notification-duration "PT30M"

Key flags:

  • --compartment-id: where the alarm resource lives
  • --metric-compartment-id: where the metric is emitted (often the same compartment)
  • --namespace: metric namespace (oci_computeagent, oci_blockstore, etc.)
  • --query-text: alarm expression
  • --destinations: JSON array of ONS topic OCIDs

5. Verify the Alarm Exists and Is Enabled​

oci monitoring alarm list \
  --compartment-id "ocid1.compartment.oc1..xxxx" \
  --all

Check that:

  • Alarm is listed
  • lifecycle-state is OK
  • is-enabled is true

If you need to enable it:

oci monitoring alarm update \
  --alarm-id "<ALARM_OCID>" \
  --is-enabled true

This ensures the “OCI Monitoring Should Have At Least One Alarm Configured” requirement is satisfied using OCI CLI.

Using Python

Below is a concise, step‑by‑step way to ensure “OCI Monitoring has at least one alarm configured” using Python and the OCI SDK.

Assumptions:

  • You already have:
    • An OCI tenancy, compartment, and region
    • OCI CLI/SDK config file at ~/.oci/config with a profile (e.g., DEFAULT)
    • Python oci SDK installed: pip install oci

1. Decide What to Alarm On​

Example: Create a basic alarm on an instance’s CPU utilization:

  • Namespace: oci_computeagent
  • Metric: CpuUtilization
  • Statistic: AVG
  • Threshold: 80%
  • Period: 5 minutes
  • Severity: CRITICAL

You need:

  • COMPARTMENT_OCID – where the instance and metrics live
  • DESTINATION_TOPIC_OCID – an OCI Notifications topic OCID for alarm notifications

2. Minimal Python Script to Create an Alarm​

import oci
from oci.monitoring import MonitoringClient
from oci.monitoring.models import CreateAlarmDetails

# --- CONFIGURATION ---
PROFILE_NAME = "DEFAULT"  # OCI config profile name
COMPARTMENT_OCID = "<your_compartment_ocid>"
DESTINATION_TOPIC_OCID = "<your_ons_topic_ocid>"   # OCI Notifications topic OCID
DISPLAY_NAME = "High CPU Utilization Alarm"
# ---------------------

def main():
    # Load OCI configuration
    config = oci.config.from_file("~/.oci/config", PROFILE_NAME)

    monitoring_client = MonitoringClient(config)
    # Optionally set region: monitoring_client.base_client.set_region("eu-frankfurt-1")

    # Define the alarm query - Monitoring Query Language (MQL)
    # Example: Alarm when average CPUUtilization over 5 mins > 80%
    metric_query = (
        "CpuUtilization[5m].mean() > 80"
    )

    create_alarm_details = CreateAlarmDetails(
        compartment_id=COMPARTMENT_OCID,
        display_name=DISPLAY_NAME,
        is_enabled=True,
        # MQL query
        query=metric_query,
        # Metric namespace
        namespace="oci_computeagent",
        # Frequency with which to evaluate the alarm
        resolution="5m",
        # Severity (OK, INFO, WARNING, ERROR, CRITICAL)
        severity="CRITICAL",
        # List of OCI Notifications topics (OCIDs)
        destinations=[DESTINATION_TOPIC_OCID],
        # Optional: suppress duplicate notifications
        is_notifications_per_metric_dimension_enabled=False,
        # Optional: human-friendly description
        description="Alarm when instance average CPUUtilization exceeds 80% over 5 minutes.",
        # How long the condition must be true before firing (e.g., 1 evaluation window)
        pending_duration="PT5M",  # ISO 8601, here: 5 minutes
        # Repeat notifications while in ALARM every 1 hour (optional)
        repeat_notification_interval="PT1H",
        # What to do when the alarm transitions state
        message_format="TEXT",  # or "JSON"
        # Optional: suppress notifications during maintenance
        # suppression=...
    )

    response = monitoring_client.create_alarm(create_alarm_details)
    alarm = response.data

    print("Created alarm:")
    print(f"  OCID: {alarm.id}")
    print(f"  Name: {alarm.display_name}")
    print(f"  State: {alarm.lifecycle_state}")

if __name__ == "__main__":
    main()

3. Ensure Notifications Topic Exists and Has Subscribers​

  1. In OCI Console:
    Developer Services → Application Integration → Notifications → Topics

    • Create a topic
    • Add at least one subscription (Email / PagerDuty / HTTPS, etc.)
    • Confirm the subscription (e.g., via email link)

  2. Use that topic’s OCID as DESTINATION_TOPIC_OCID in the script.

4. Validate the Alarm​

  • In Console: Observability & Management → Monitoring → Alarms
    • Confirm the alarm exists and is “Enabled”.
  • Generate load on the instance (or adjust the threshold to a very low value) and verify:
    • Alarm state changes to “FIRING”
    • Notification is sent to your subscription

5. Applying at Scale (Optional)​

You can:

  • Loop over multiple compartments or resources.
  • Use different queries per metric (e.g., memory, disk, custom metrics).
  • Use tags or resource IDs in the query to target specific resources.

If you provide your exact metric/namespace and compartment setup, I can adapt the script precisely to your environment.

Using Terraform
# Create at least one OCI Monitoring Alarm.
# Replace all UPPER_SNAKE_CASE placeholders with your actual values.

resource "oci_monitoring_alarm" "cpu_high_alarm" {
  # Required identifiers
  compartment_id = "OCID_OF_TARGET_COMPARTMENT"
  display_name   = "High CPU Utilization Alarm"

  # What to monitor: example for average CPU > 80% over 5 minutes on a specific instance
  # Honour any specific threshold/query your org requires by editing 'query' only.
  query = "CpuUtilization[5m].mean() > 80 where resourceId = \"OCID_OF_COMPUTE_INSTANCE\""

  # Alarm severity
  severity = "CRITICAL" # Allowed: INFO | WARNING | ERROR | CRITICAL

  # Alarm lifecycle
  is_enabled = true

  # Notification channel (must exist already)
  # For example, this could be an OCI Notifications topic OCID.
  destinations = [
    "OCID_OF_OCI_NOTIFICATIONS_TOPIC"
  ]

  # How often the alarm is evaluated
  resolution = "5m"

  # Whether actions should be triggered each time the condition is met
  is_notifications_per_metric_dimension_enabled = false

  # Optional: suppress clear notifications if you only care about firing notifications
  # message_format = "ONS_OPTIMIZED" # or "RAW"

  # Freeform tags (optional)
  # freeform_tags = {
  #   "Owner" = "TEAM_NAME"
  # }
}

Creating this oci_monitoring_alarm resource does not replace any existing resource; it simply adds an alarm so the tenancy is no longer without monitoring.

Verification: terraform plan should show one new resource to be created: + oci_monitoring_alarm.cpu_high_alarm.