OCI Monitoring Cloud Guard Should Not Have Critical/High Problems

Using Console

Below is how to handle “OCI Monitoring Cloud Guard Should Not Have Critical/High Problems” using the OCI Console, focusing on Monitoring/Alerting.

1. Find the Exact Cloud Guard Problem

In OCI Console, open Navigation Menu → Identity & Security → Cloud Guard.
Go to Problems.
Filter by:
- Status: Open
- Risk Level: High and Critical
- Detector Type: look for Monitoring / related (e.g., misconfigured alarms, disabled alarms, missing notifications).
Click a specific problem to open the details pane:
- Note the Resource Type (Alarm, Compartment, Metric, etc.).
- Note the Recommendation text – Cloud Guard usually tells you what is missing/misconfigured.

2. Identify What’s Wrong With the Monitoring/Alerting

Common Monitoring/Alerting-related Cloud Guard problems:

No alarms configured for key resources/metrics.
Alarm is in Disabled / Suppressed state.
Alarm missing notification (no topic, no subscription).
Alarm severity or condition not aligned with policy (e.g., wrong thresholds, wrong evaluation period).
Alarm not attached to correct compartment/region.

From the problem details, confirm which of these applies.

3. Fix Alarms in Monitoring

Go to Navigation Menu → Observability & Management → Monitoring → Alarms.
Make sure you are in the same region and compartment as the resource shown in the Cloud Guard problem.

A. If no alarm exists (resource unmonitored)

Click Create alarm.
Fill fields:
- Name: meaningful (e.g., cpu-high-app-prod).
- Compartment: same as the resource.
- Metric namespace: select correct service (e.g., oci_computeagent, oci_vcn, etc.).
- Metric name & dimension: pick the metric Cloud Guard expects (from the problem recommendation).
- Alarm severity: set appropriately (e.g., Critical or High).
- Trigger rule: define threshold/rule as suggested (e.g., CPUUtilization > 80 for 5 minutes).
Under Notifications:
- Choose/assign an OCI Notifications topic (create one if needed).
Click Create alarm.

B. If alarm exists but is disabled/incorrect

From the Alarms list, locate the alarm named in the problem.
For each issue:
- Disabled alarm:
  - Open it; click More Actions → Enable (or toggle to Enabled).
- No notification:
  - Edit the alarm.
  - Under Notifications, select a Topic.
  - Click Save changes.
  - If no topic exists:
    - Open new tab: Navigation Menu → Application Integration → Notifications → Topics → Create Topic.
    - Then add Subscriptions (email, PagerDuty, Slack via HTTPS, etc.) and confirm them.
    - Return to the alarm and attach this topic.
- Wrong condition / severity / resource scope:
  - Edit the alarm:
    - Correct metric, dimensions, and compartment.
    - Adjust threshold, operator, evaluation period to match security / SRE requirements or Cloud Guard recommendation.
    - Set Severity to match the risk level (e.g., Critical for production outages).
  - Save.

4. Validate and Close the Cloud Guard Problem

After fixing the alarm(s), wait a few minutes for Cloud Guard re-evaluation.
Go back to Cloud Guard → Problems.
Refresh:
- If Cloud Guard recognizes the fix, the problem status should move to Resolved / Closed automatically.
If it remains Open:
- Re-open the problem, verify:
  - The resource/compartment/region aligns with the alarm’s configuration.
  - The alarm is Enabled and in the correct compartment.
- Make corrections and wait again.

5. Optionally Tune Detection (Detector/Responder Recipes)

If you’re getting false positives or want automatic remediation:

Go to Cloud Guard → Detector Recipes.
Open the Monitoring-related Detector Recipe assigned to your target.
For the specific detector rule:
- Adjust Risk Level, conditions, or Targets if needed (e.g., exclude non-prod compartments).
For auto-fix:
- Go to Cloud Guard → Responder Recipes.
- Enable/attach a responder that can create/enable alarms automatically (if available for that rule).
- Associate that responder recipe with the same Target as the detector.

If you paste one actual problem’s text (detector name + recommendation), I can give you exact field values for the alarm and any Monitoring settings to change.

Using CLI

Below is a pragmatic way to handle “OCI Monitoring – Cloud Guard Should Not Have Critical/High Problems” using the OCI CLI, focusing on Monitoring / Alerting–related problems.

1. Identify the relevant Cloud Guard problems

First, list Cloud Guard problems with HIGH/CRITICAL severity for the Monitoring service.

TENANCY_OCID="<your_tenancy_ocid>"
COMPARTMENT_OCID="<target_compartment_ocid>"   # use tenancy OCID for root

oci cloud-guard problem list \
  --compartment-id "$COMPARTMENT_OCID" \
  --compartment-id-in-subtree true \
  --severity-filter "HIGH,CRITICAL" \
  --all > problems.json

Filter only Monitoring-related problems:

jq '.data[] | select(.resourceType | test("alarm|monitoring"; "i"))' problems.json > monitoring_problems.json

You can inspect one problem:

PROBLEM_ID="<problem_ocid_from_monitoring_problems.json>"

oci cloud-guard problem get \
  --problem-id "$PROBLEM_ID" \
  --query 'data'

Look at:

resourceType
resourceId (often the alarm OCID)
detectorRuleId
riskLevel / severity
recommendation

2. Inspect and fix the underlying Monitoring resources

Most Monitoring-related Cloud Guard problems are about:

disabled alarms
missing notification destinations
bad alarm query / incorrect conditions
alarm in INSUFFICIENT_DATA due to misconfigured metric query
alarms not covering critical metrics

2.1 Get details of the alarm mentioned in the problem

From the problem details note resourceId (e.g., alarm OCID) and its compartment.

ALARM_OCID="<alarm_ocid_from_problem>"
ALARM_COMPARTMENT_OCID="<compartment_of_alarm>"

oci monitoring alarm get \
  --alarm-id "$ALARM_OCID" \
  --query 'data'

Fields to check:

isEnabled
destinations
metricCompartmentId
query
severity
pendingDuration
suppression
resolution
lifecycleState

2.2 Enable disabled alarms

If isEnabled: false, enable it:

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

2.3 Add a notification destination (if missing)

If destinations is empty, set an OCI Notifications topic OCID:

TOPIC_OCID="<notifications_topic_ocid>"

oci monitoring alarm update \
  --alarm-id "$ALARM_OCID" \
  --destinations '["'"$TOPIC_OCID"'"]'

2.4 Fix the alarm query or configuration

If Cloud Guard indicates misconfiguration (e.g., wrong metric namespace or dimensions), you may need to update:

namespace
metric-name
dimensions in the query
pendingDuration / thresholds
severity

Example changing the query and severity:

NEW_QUERY="CpuUtilization[5m].mean() > 80"

oci monitoring alarm update \
  --alarm-id "$ALARM_OCID" \
  --query "$NEW_QUERY" \
  --severity "CRITICAL"

If Cloud Guard complains about INSUFFICIENT_DATA, ensure:

correct namespace/metric
correct metricCompartmentId
resource is actually generating that metric

For example, change metric compartment:

NEW_METRIC_COMPARTMENT_OCID="<metric_compartment_ocid>"

oci monitoring alarm update \
  --alarm-id "$ALARM_OCID" \
  --metric-compartment-id "$NEW_METRIC_COMPARTMENT_OCID" \
  --metric-compartment-id-in-subtree true

2.5 (Optional) Create new alarms for missing coverage

Sometimes the problem is “no alarm on critical metric”. Create an alarm via CLI:

COMPARTMENT_OCID="<compartment_for_alarm>"
DISPLAY_NAME="High CPU Alarm"
NAMESPACE="oci_computeagent"
QUERY="CpuUtilization[5m].mean() > 80"
TOPIC_OCID="<notifications_topic_ocid>"

oci monitoring alarm create \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name "$DISPLAY_NAME" \
  --is-enabled true \
  --namespace "$NAMESPACE" \
  --query "$QUERY" \
  --severity "CRITICAL" \
  --destinations '["'"$TOPIC_OCID"'"]' \
  --metric-compartment-id "$COMPARTMENT_OCID" \
  --metric-compartment-id-in-subtree true \
  --body '{"resolution": "1m"}'

3. Mark the Cloud Guard problem as resolved/dismissed

Once the underlying issue is fixed and verified (alarm is enabled, properly configured, and functional), change the problem’s lifecycle state so it is no longer an active HIGH/CRITICAL problem.To mark as RESOLVED:

PROBLEM_ID="<problem_ocid>"

oci cloud-guard problem update \
  --problem-id "$PROBLEM_ID" \
  --lifecycle-state "RESOLVED"

If it is a false positive and you want to dismiss it:

oci cloud-guard problem update \
  --problem-id "$PROBLEM_ID" \
  --lifecycle-state "DISMISSED" \
  --comment "Known exception; accepted risk."

4. (Optional) Automate via Cloud Guard responders

Instead of manually resolving:

Enable or customize responder recipes in Cloud Guard to auto-fix some Monitoring issues (e.g., enabling alarms).
Use CLI to update the Cloud Guard target’s detector/responder recipes.

Example (very high-level):

TARGET_ID="<cloud_guard_target_ocid>"

oci cloud-guard target update-target-detector-recipe \
  --target-id "$TARGET_ID" \
  --target-detector-recipe-id "<target_detector_recipe_ocid>" \
  --detector-rules file://detector_rules_update.json

(Where detector_rules_update.json enables the appropriate rules and responders.)

If you paste one sample Monitoring-related problem JSON (from oci cloud-guard problem get), I can give exact CLI commands tailored to that specific problem type.

Using Python

Below is a practical way to handle this with Python: detect and remediate (or at least mark/track) critical/high Cloud Guard problems related to Monitoring/Alarms, using the OCI Python SDK.

1. Prerequisites

Install SDK:
pip install oci

Configure OCI CLI/SDK auth (~/.oci/config):

[DEFAULT]
user=ocid1.user.oc1..xxxxx
fingerprint=xx:xx:xx:xx
key_file=/path/to/oci_api_key.pem
tenancy=ocid1.tenancy.oc1..xxxxx
region=us-ashburn-1

IAM permissions needed for the principal running this script:

allow group <group-name> to read cloud-guard-family in tenancy
allow group <group-name> to manage monitoring-family in tenancy

2. High-level remediation flow

Use Cloud Guard to list all CRITICAL and HIGH problems.
Filter problems that relate to Monitoring / Alarms.
For each problem, inspect its detector_rule_id / risk_level / resource_type / problem_description to determine what needs fixing (e.g., missing alarm, disabled alarm, missing metric stream).
Call appropriate Monitoring APIs to fix the configuration.
Optionally, update the Cloud Guard problem state to RESOLVED (only if you are sure you fixed it).

Because Cloud Guard problems are rule‑specific, the exact remediation depends on the rule. Below is a generic automation pattern that you can customize per rule.

3. Python: list & filter critical/high Cloud Guard problems

import oci

config = oci.config.from_file()  # or from_file(profile_name="DEFAULT")
cloud_guard_client = oci.cloud_guard.CloudGuardClient(config)

COMPARTMENT_OCID = "<your_root_or_target_compartment_ocid>"

def list_high_critical_problems(compartment_id):
    problems = []
    # Use pagination
    list_resp = cloud_guard_client.list_problems(
        compartment_id=compartment_id,
        compartment_id_in_subtree=True,
        risk_level_filter=["CRITICAL", "HIGH"],
        # optionally: status="OPEN"
    )

    problems.extend(list_resp.data.items)
    while list_resp.has_next_page:
        list_resp = cloud_guard_client.list_problems(
            compartment_id=compartment_id,
            compartment_id_in_subtree=True,
            risk_level_filter=["CRITICAL", "HIGH"],
            page=list_resp.next_page
        )
        problems.extend(list_resp.data.items)

    return problems

problems = list_high_critical_problems(COMPARTMENT_OCID)
print(f"Found {len(problems)} critical/high problems")

Look at resource_type, detector_rule_id, problem_description etc. Monitoring issues usually have resource_type like alarm, monitoringresource, or refer to monitoring in the description.

monitoring_related = []

for p in problems:
    if (
        "monitor" in (p.resource_type or "").lower()
        or "alarm" in (p.resource_type or "").lower()
        or "monitor" in (p.problem_description or "").lower()
    ):
        monitoring_related.append(p)

print(f"Monitoring-related problems: {len(monitoring_related)}")
for p in monitoring_related:
    print(p.id, p.resource_type, p.problem_description)

From this output, note which detector rules you want to automatically fix (e.g., “Alarm not configured for X metric”, “Alarm disabled”, etc.).

5. Example remediation patterns for Monitoring

Below are generic remediation functions. You must map each Cloud Guard detector rule or description to one of these.

5.1. Create a missing alarm

Suppose Cloud Guard says “No alarm configured for <resource> metric X”.

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

monitoring_client = MonitoringClient(config)

def create_alarm_for_metric(compartment_id, display_name, namespace, query,
                            severity="CRITICAL", destinations=None):
    """
    destinations: list of OCIDs of Notifications topics
    """
    details = CreateAlarmDetails(
        compartment_id=compartment_id,
        display_name=display_name,
        metric_compartment_id=compartment_id,
        namespace=namespace,
        query=query,
        severity=severity,
        is_enabled=True,
        body="Automated alarm created from Cloud Guard remediation.",
        destinations=destinations or [],
        pending_duration="PT5M",  # 5 minutes
        resolution="PT5M"
    )

    resp = monitoring_client.create_alarm(details)
    return resp.data

# Example usage:
# query example for CPU > 80% avg 5m:
# "CpuUtilization[5m]{resourceId = 'ocid1.instance.oc1..aaaa'}.mean() > 80"
new_alarm = create_alarm_for_metric(
    compartment_id="<target_compartment>",
    display_name="Auto-created CPU alarm",
    namespace="oci_computeagent",
    query="CpuUtilization[5m]{resourceId = 'ocid1.instance.oc1..aaaa'}.mean() > 80",
    destinations=["ocid1.onstopic.oc1..xxxxx"]
)
print("Created alarm:", new_alarm.id)

You would build the query and display_name from data embedded in the Cloud Guard problem (e.g., p.resource_id, p.resource_name, or freeform tags).

5.2. Enable a disabled alarm

If the problem says an alarm is disabled:

from oci.monitoring.models import UpdateAlarmDetails

def enable_alarm(alarm_id):
    update = UpdateAlarmDetails(is_enabled=True)
    resp = monitoring_client.update_alarm(alarm_id=alarm_id, update_alarm_details=update)
    return resp.data

# Example using resource_id from problem
for p in monitoring_related:
    if "disabled" in (p.problem_description or "").lower():
        alarm_id = p.resource_id
        enabled_alarm = enable_alarm(alarm_id)
        print("Enabled alarm:", enabled_alarm.id)

6. Mark Cloud Guard problem as resolved (optional)

Once you’ve programmatically remediated, you can mark the problem as RESOLVED (if your process requires that):

from oci.cloud_guard.models import UpdateProblemStatusDetails

def resolve_problem(problem_id, comment="Remediated via automation"):
    details = UpdateProblemStatusDetails(
        status="RESOLVED",
        comment=comment
    )
    resp = cloud_guard_client.update_problem_status(
        problem_id=problem_id,
        update_problem_status_details=details
    )
    return resp.data

for p in monitoring_related:
    # Only resolve if you’re sure the remediation succeeded
    resolved = resolve_problem(p.id)
    print("Resolved problem:", resolved.id)

7. Putting it together (skeleton)

You can orchestrate this into a single script:

List problems (critical/high).
Filter monitoring‑related.
For each:
- Branch based on detector_rule_id / description.
- Call the appropriate remediation function (create alarm, enable alarm, etc.).
- Optionally resolve the problem.

Skeleton:

def remediate_monitoring_problem(problem):
    desc = (problem.problem_description or "").lower()

    if "alarm" in desc and "not configured" in desc:
        # Build an alarm for the affected resource
        # You must parse the resource info from `problem`:
        query = build_query_from_problem(problem)  # your function
        create_alarm_for_metric(
            compartment_id=problem.compartment_id,
            display_name=f"Auto-alarm for {problem.resource_name}",
            namespace="oci_computeagent",
            query=query,
            destinations=["ocid1.onstopic.oc1..xxxxx"]
        )
    elif "alarm" in desc and "disabled" in desc:
        enable_alarm(problem.resource_id)

    # After remediation:
    resolve_problem(problem.id, comment="Remediated by Python script")

for p in monitoring_related:
    remediate_monitoring_problem(p)

If you can paste an example Cloud Guard problem JSON for “OCI Monitoring” from your environment, I can provide a more precise mapping from each problem type to exact Python remediation code.

Using Terraform

OCI Monitoring and Cloud Guard configuration in Terraform cannot “clear” or resolve existing Critical/High problems; this is an operational action on findings, not a configuration property of oci_monitoring_* or Cloud Guard resources.Use the Console or CLI to investigate and resolve each problem (Cloud Guard → Problems → filter by Critical/High → remediate or mark resolved), and optionally tighten your alarms/policies going forward via Terraform (e.g., adjusting Monitoring alarm queries), but there is no Terraform argument on oci-monitoring-cloudguard-configuration (or related resources) that can make existing Critical/High problems disappear.Since there is no Terraform-exposed setting to remediate this finding, terraform plan will correctly show no changes related to Cloud Guard problems themselves.

OCI Misconfigurations

OCI Monitoring Cloud Guard Should Not Have Critical/High Problems

More Info:

Risk Level

Address

Compliance Standards

Triage and Remediation

Remediation

1. Find the Exact Cloud Guard Problem

2. Identify What’s Wrong With the Monitoring/Alerting

3. Fix Alarms in Monitoring

A. If no alarm exists (resource unmonitored)

B. If alarm exists but is disabled/incorrect

4. Validate and Close the Cloud Guard Problem

5. Optionally Tune Detection (Detector/Responder Recipes)

1. Identify the relevant Cloud Guard problems

2. Inspect and fix the underlying Monitoring resources

2.1 Get details of the alarm mentioned in the problem

2.2 Enable disabled alarms

2.3 Add a notification destination (if missing)

2.4 Fix the alarm query or configuration

2.5 (Optional) Create new alarms for missing coverage

3. Mark the Cloud Guard problem as resolved/dismissed

4. (Optional) Automate via Cloud Guard responders

1. Prerequisites

2. High-level remediation flow

3. Python: list & filter critical/high Cloud Guard problems

5. Example remediation patterns for Monitoring

5.1. Create a missing alarm

5.2. Enable a disabled alarm

6. Mark Cloud Guard problem as resolved (optional)

7. Putting it together (skeleton)

​More Info:

​Risk Level

​Address

​Compliance Standards

​Triage and Remediation

​Remediation

​1. Find the Exact Cloud Guard Problem

​2. Identify What’s Wrong With the Monitoring/Alerting

​3. Fix Alarms in Monitoring

​A. If no alarm exists (resource unmonitored)

​B. If alarm exists but is disabled/incorrect

​4. Validate and Close the Cloud Guard Problem

​5. Optionally Tune Detection (Detector/Responder Recipes)

​1. Identify the relevant Cloud Guard problems

​2. Inspect and fix the underlying Monitoring resources

​2.1 Get details of the alarm mentioned in the problem

​2.2 Enable disabled alarms

​2.3 Add a notification destination (if missing)

​2.4 Fix the alarm query or configuration

​2.5 (Optional) Create new alarms for missing coverage

​3. Mark the Cloud Guard problem as resolved/dismissed

​4. (Optional) Automate via Cloud Guard responders

​1. Prerequisites

​2. High-level remediation flow

​3. Python: list & filter critical/high Cloud Guard problems

​4. Identify Monitoring-related problems

​5. Example remediation patterns for Monitoring

​5.1. Create a missing alarm

​5.2. Enable a disabled alarm

​6. Mark Cloud Guard problem as resolved (optional)

​7. Putting it together (skeleton)

More Info:

Risk Level

Address

Compliance Standards

Triage and Remediation

Remediation

1. Find the Exact Cloud Guard Problem

2. Identify What’s Wrong With the Monitoring/Alerting

3. Fix Alarms in Monitoring

A. If no alarm exists (resource unmonitored)

B. If alarm exists but is disabled/incorrect

4. Validate and Close the Cloud Guard Problem

5. Optionally Tune Detection (Detector/Responder Recipes)

1. Identify the relevant Cloud Guard problems

2. Inspect and fix the underlying Monitoring resources

2.1 Get details of the alarm mentioned in the problem

2.2 Enable disabled alarms

2.3 Add a notification destination (if missing)

2.4 Fix the alarm query or configuration

2.5 (Optional) Create new alarms for missing coverage

3. Mark the Cloud Guard problem as resolved/dismissed

4. (Optional) Automate via Cloud Guard responders

1. Prerequisites

2. High-level remediation flow

3. Python: list & filter critical/high Cloud Guard problems

4. Identify Monitoring-related problems

5. Example remediation patterns for Monitoring

5.1. Create a missing alarm

5.2. Enable a disabled alarm

6. Mark Cloud Guard problem as resolved (optional)

7. Putting it together (skeleton)