> ## Documentation Index
> Fetch the complete documentation index at: https://cloudanix.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# 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

<Tabs>
  <Tab title="Remediation">
    ### Remediation

    <AccordionGroup>
      <Accordion title="Using Console" defaultOpen="true">
        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

        5. 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.

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

        This will auto-generate an MQL query such as:

        ```text theme={null}
        CpuUtilization[5m].mean() > 80
        ```

        10. 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

        11. Set **Severity**:
            * e.g. `Critical` for production/high-priority alerts.

        #### D. Destinations (Where to Send Alerts)

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

        #### E. Actions & Lifecycle

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

        #### F. Save the Alarm

        16. Review all settings.
        17. 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.
      </Accordion>

      <Accordion title="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:

        ```bash theme={null}
        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):

        ```bash theme={null}
        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:

        ```text theme={null}
        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”):

        ```text theme={null}
        CpuUtilization[5m].mean() > 80
        ```

        ***

        ### 4. Create the Alarm via OCI CLI

        Run:

        ```bash theme={null}
        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

        ```bash theme={null}
        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:

        ```bash theme={null}
        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.
      </Accordion>

      <Accordion title="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

        ```python theme={null}
        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.
      </Accordion>

      <Accordion title="Using Terraform">
        ```hcl theme={null}
        # 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`.
      </Accordion>
    </AccordionGroup>
  </Tab>
</Tabs>