Skip to main content

Oci Monitoring Cloud Guard Critical Problems Remediation

Triage and Remediation​

Remediation​

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​

  1. In OCI Console, open Navigation Menu → Identity & Security → Cloud Guard.
  2. Go to Problems.
  3. Filter by:
    • Status: Open
    • Risk Level: High and Critical
    • Detector Type: look for Monitoring / related (e.g., misconfigured alarms, disabled alarms, missing notifications).
  4. 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​

  1. Go to Navigation Menu → Observability & Management → Monitoring → Alarms.
  2. 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)​

  1. Click Create alarm.
  2. 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).
  3. Under Notifications:
    • Choose/assign an OCI Notifications topic (create one if needed).
  4. Click Create alarm.

B. If alarm exists but is disabled/incorrect​

  1. From the Alarms list, locate the alarm named in the problem.

  2. 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​

  1. After fixing the alarm(s), wait a few minutes for Cloud Guard re-evaluation.
  2. Go back to Cloud Guard → Problems.
  3. Refresh:
    • If Cloud Guard recognizes the fix, the problem status should move to Resolved / Closed automatically.
  4. 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:

  1. Go to Cloud Guard → Detector Recipes.
  2. Open the Monitoring-related Detector Recipe assigned to your target.
  3. For the specific detector rule:
    • Adjust Risk Level, conditions, or Targets if needed (e.g., exclude non-prod compartments).
  4. 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​

  1. Install SDK:

    pip install oci

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

  3. 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​

  1. Use Cloud Guard to list all CRITICAL and HIGH problems.
  2. Filter problems that relate to Monitoring / Alarms.
  3. 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).
  4. Call appropriate Monitoring APIs to fix the configuration.
  5. 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:

  1. List problems (critical/high).
  2. Filter monitoring‑related.
  3. 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.