AIOps-based Anomaly Detection Automation: ML Alerting and Kubernetes Event Correlation Guide

• Introduction: the Limits of Threshold Alerting
• AIOps Concepts and the Maturity Model
• Comparing ML-Based Anomaly Detection Algorithms
  • Algorithm Comparison
  • Isolation Forest: Multi-Dimensional Metric Anomaly Detection
  • Prophet: Time Series Anomaly Detection
  • DBSCAN: Log Pattern Clustering
• Implementing Anomaly Detection on Prometheus Metrics
  • Combining Prometheus Alerting Rules with ML
• Kubernetes Event Correlation
  • A kubectl-Based Event Correlation Script
  • Automated Correlation with Robusta
• Alert Noise Reduction Strategies
  • Alert Grouping
  • Deduplication
  • Adaptive Thresholds
• Comparing Open Source AIOps Tools
• Failure Cases and Recovery Procedures
  • Failure Case 1: Excessive False Positives from Insufficient Training Data
  • Failure Case 2: The Curse of Dimensionality in Isolation Forest
  • Failure Case 3: Undetected Model Drift
  • Failure Case 4: A Wrong Automated Response from a Misread Correlation
• Operational Checklist
• Conclusion
• References

Introduction: the Limits of Threshold Alerting

It is 4 AM and alerts are pouring into Slack. 50 warnings that CPU utilization passed 80%, 30 memory utilization warnings, 20 disk I/O warnings. Yet only one service has actually failed. The other 99 were transient spikes right after a deploy, or a normal resource increase caused by a nightly batch job. This is the reality of alerting based on static thresholds.

Traditional monitoring systems depend on fixed thresholds such as "alert if CPU > 80%" or "warn if response time > 500ms". The approach is simple and easy to understand, but in a modern, complex distributed system it exposes fatal limits.

It cannot reflect seasonality. Traffic on an e-commerce service surges at lunchtime and after work hours and collapses overnight. Payment traffic explodes at month end, and during a promotion more than 10 times the usual number of requests arrives. A fixed threshold reports these natural pattern shifts as anomalies (false positives).

It misses slow burn failures. A problem that progresses gradually, like a memory leak, goes undetected until it reaches the threshold. Memory utilization growing 0.1% per day takes months to reach an 80% threshold, but the actual failure has to be prevented long before that.

It cannot see correlation. If a Pod restart, node memory pressure and rising network latency all happen at once, there is no way to tell whether the three come from one root cause or are three independent problems. As a result the on-call engineer has to check dozens of alerts one at a time to trace the root cause.

AIOps (Artificial Intelligence for IT Operations) uses machine learning to address these limits structurally. It learns the normal pattern of time series data, automatically detects anomalies that depart from that pattern, and correlates multiple events to infer a root cause.

AIOps Concepts and the Maturity Model

AIOps is a concept Gartner first defined in 2017: applying artificial intelligence and machine learning to IT operations to carry out monitoring, event correlation and automated response. As of 2026, AIOps has moved beyond simple alert automation and is evolving toward autonomous operations.

AIOps maturity is divided into the following five levels.

Most organizations are stuck at Level 1, and the move to Level 2 delivers the highest ROI. This article concentrates on implementing Level 2~3 ML-based anomaly detection and event correlation.

Comparing ML-Based Anomaly Detection Algorithms

The main ML algorithms used for anomaly detection each have clear strengths and limits. Pick the algorithm that fits the data characteristics of your operating environment.

Algorithm Comparison

Isolation Forest: Multi-Dimensional Metric Anomaly Detection

Isolation Forest rests on the intuition that anomalous data is easier to "isolate" than normal data. When random trees are built, anomalous points are separated at a depth close to the root, while normal points are separated much deeper.

import numpy as np
import pandas as pd
from sklearn.ensemble import IsolationForest
from prometheus_api_client import PrometheusConnect

# Collect metrics from Prometheus
prom = PrometheusConnect(url="http://prometheus:9090", disable_ssl=True)

# Collect CPU, memory and network metrics for the last 24 hours
metrics = {}
for metric_name in ['node_cpu_seconds_total', 'node_memory_MemAvailable_bytes', 'node_network_receive_bytes_total']:
    result = prom.custom_query_range(
        query=f'rate({metric_name}[5m])',
        start_time=pd.Timestamp.now() - pd.Timedelta(hours=24),
        end_time=pd.Timestamp.now(),
        step='60s'
    )
    metrics[metric_name] = [float(v[1]) for v in result[0]['values']]

# Build the multi-dimensional feature matrix
df = pd.DataFrame(metrics)
df = df.dropna()

# Train the Isolation Forest and predict
model = IsolationForest(
    n_estimators=200,         # number of trees (default 100, raised to 200 for precision)
    contamination=0.01,       # expected proportion of outliers (1%)
    max_samples='auto',
    random_state=42
)
model.fit(df)

# Prediction: -1 means anomalous, 1 means normal
predictions = model.predict(df)
anomaly_scores = model.decision_function(df)

# Print the anomaly detection result
anomalies = df[predictions == -1]
print(f"Detected {len(anomalies)} anomalies out of {len(df)} samples")
print(f"Anomaly score range: {anomaly_scores.min():.4f} ~ {anomaly_scores.max():.4f}")

# Send the anomaly detection result to the Prometheus Pushgateway
from prometheus_client import CollectorRegistry, Gauge, push_to_gateway

registry = CollectorRegistry()
anomaly_gauge = Gauge('aiops_anomaly_score', 'Anomaly score from Isolation Forest',
                      ['metric_group'], registry=registry)
anomaly_gauge.labels(metric_group='node_resources').set(anomaly_scores[-1])
push_to_gateway('pushgateway:9091', job='aiops_anomaly_detection', registry=registry)

In this code the contamination parameter specifies the proportion of outliers in the whole dataset. In a production environment it is generally set between 0.5% and 2%. Too high and false positives increase; too low and real anomalies can be missed. Early in operation it is better to start at 0.01 (1%) and adjust gradually while watching alert quality.

Prophet: Time Series Anomaly Detection

Prophet, developed by Facebook (now Meta), automatically decomposes trend, seasonality and holiday effects in time series data to build a forecasting model. When an observed value falls outside the prediction interval, it is judged anomalous.

from prophet import Prophet
import pandas as pd
from prometheus_api_client import PrometheusConnect

# Collect the HTTP request count for the last 14 days from Prometheus
prom = PrometheusConnect(url="http://prometheus:9090", disable_ssl=True)
result = prom.custom_query_range(
    query='sum(rate(http_requests_total[5m]))',
    start_time=pd.Timestamp.now() - pd.Timedelta(days=14),
    end_time=pd.Timestamp.now(),
    step='300s'
)

# Convert to the Prophet input format (the ds and y columns are required)
df = pd.DataFrame({
    'ds': [pd.Timestamp(v[0], unit='s') for v in result[0]['values']],
    'y': [float(v[1]) for v in result[0]['values']]
})

# Train the Prophet model
model = Prophet(
    changepoint_prior_scale=0.05,    # trend change sensitivity (lower is more conservative)
    seasonality_prior_scale=10.0,    # seasonality strength
    interval_width=0.99,             # prediction interval width (99% confidence interval)
    daily_seasonality=True,
    weekly_seasonality=True,
)

# Add Korean public holidays (reflects traffic pattern changes)
model.add_country_holidays(country_name='KR')
model.fit(df)

# Forecast over the same period
forecast = model.predict(df)

# Anomaly detection: an observed value outside (yhat_lower, yhat_upper) is anomalous
df_merged = df.merge(forecast[['ds', 'yhat', 'yhat_lower', 'yhat_upper']], on='ds')
df_merged['is_anomaly'] = (
    (df_merged['y'] < df_merged['yhat_lower']) |
    (df_merged['y'] > df_merged['yhat_upper'])
)

anomalies = df_merged[df_merged['is_anomaly']]
print(f"Prophet anomaly detection result: {len(anomalies)} anomalies detected")

# Print the details when an anomaly occurs
for _, row in anomalies.iterrows():
    deviation = abs(row['y'] - row['yhat']) / row['yhat'] * 100
    direction = "spike" if row['y'] > row['yhat_upper'] else "drop"
    print(f"  [{row['ds']}] traffic {direction}: "
          f"observed={row['y']:.1f}, predicted={row['yhat']:.1f}, "
          f"deviation={deviation:.1f}%")

The Prophet interval_width parameter directly determines the sensitivity of anomaly detection. Setting it to 0.95 (a 95% confidence interval) detects more anomalies but also increases false positives, while 0.99 (99%) detects only clear anomalies. In production it is recommended to start at 0.99 and lower it as needed.

DBSCAN: Log Pattern Clustering

DBSCAN (Density-Based Spatial Clustering of Applications with Noise) is a density-based clustering algorithm. It recognizes regions where data points are dense as clusters and classifies points that belong to no cluster as noise, that is, anomalies. It is effective for identifying anomalous groups among log patterns or metric combinations.

Implementing Anomaly Detection on Prometheus Metrics

This section looks at how to build an anomaly detection pipeline on metrics collected in Prometheus. The key is to gather data through the Prometheus API, analyze it with an ML model, then push the result back into the Prometheus ecosystem and wire it to Alertmanager.

Combining Prometheus Alerting Rules with ML

Running traditional Prometheus alerting rules alongside ML-based anomaly detection builds a two-layer alerting scheme: the existing rules handle simple threshold breaches while the ML model takes on complex pattern anomalies.

# prometheus-rules.yaml
# Run traditional threshold alerts and ML anomaly alerts side by side
groups:
  - name: traditional_threshold_alerts
    rules:
      # Level 1: fixed threshold alert (needs an immediate response)
      - alert: HighCPUUsageCritical
        expr: |
          100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 95
        for: 5m
        labels:
          severity: critical
          alert_type: threshold
        annotations:
          summary: 'CPU utilization above 95% ({{ $labels.instance }})'
          description: 'CPU utilization on {{ $labels.instance }} is {{ $value | printf "%.1f" }}%.'

      # Level 1: memory threshold alert
      - alert: HighMemoryUsageCritical
        expr: |
          (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 > 90
        for: 10m
        labels:
          severity: critical
          alert_type: threshold
        annotations:
          summary: 'Memory utilization above 90% ({{ $labels.instance }})'

  - name: aiops_ml_anomaly_alerts
    rules:
      # Level 2: ML-based anomaly alert (collected from the Pushgateway)
      - alert: MLAnomalyDetected
        expr: |
          aiops_anomaly_score < -0.5
        for: 3m
        labels:
          severity: warning
          alert_type: ml_anomaly
        annotations:
          summary: 'ML anomaly detection: abnormal pattern found in {{ $labels.metric_group }}'
          description: |
            Isolation Forest anomaly score: {{ $value | printf "%.4f" }}
            A score below -0.5 is a statistically significant anomaly.
            Dashboard: http://grafana:3000/d/aiops-anomaly

      # Level 2: Prophet-based traffic anomaly detection
      - alert: TrafficAnomalyDetected
        expr: |
          aiops_prophet_anomaly_flag == 1
        for: 5m
        labels:
          severity: warning
          alert_type: prophet_anomaly
        annotations:
          summary: 'Prophet forecast breached: anomalous traffic pattern detected'
          description: |
            The observed value fell outside the 99% prediction interval.
            Deviation: {{ $labels.deviation_pct }}%

What matters in this configuration is the setting of the for clause. The for: 3m on the ML anomaly alert fires only when the anomaly score persists for at least 3 minutes, which cuts false positives caused by transient spikes.

Kubernetes Event Correlation

In a Kubernetes environment many events happen at once: Pod restarts, OOMKills, node pressure, deployment rollouts. Looking at individual events makes the cause hard to see, but sorting them on a time axis and correlating them finds the root cause quickly.

A kubectl-Based Event Correlation Script

The script below collects Kubernetes events within a given time range and correlates them by namespace and event type to extract root cause candidates.

#!/bin/bash
# k8s-event-correlation.sh
# Kubernetes event correlation script
# Usage: ./k8s-event-correlation.sh [namespace] [minutes]

NAMESPACE=${1:-"default"}
MINUTES=${2:-30}
SINCE=$(date -u -d "${MINUTES} minutes ago" +"%Y-%m-%dT%H:%M:%SZ" 2>/dev/null || \
        date -u -v-${MINUTES}M +"%Y-%m-%dT%H:%M:%SZ")

echo "========================================"
echo " K8s event correlation report"
echo " Namespace: ${NAMESPACE}"
echo " Analysis window: last ${MINUTES} minutes"
echo " Start time: ${SINCE}"
echo "========================================"

# Step 1: collect Warning events and analyze their frequency
echo ""
echo "[1/4] Warning event frequency analysis"
echo "----------------------------------------"
kubectl get events -n "${NAMESPACE}" \
  --field-selector type=Warning \
  --sort-by='.lastTimestamp' \
  -o custom-columns='TIME:.lastTimestamp,TYPE:.type,REASON:.reason,OBJECT:.involvedObject.name,MESSAGE:.message' \
  | tail -50

# Step 2: detect OOMKilled Pods
echo ""
echo "[2/4] OOMKilled Pod detection"
echo "----------------------------------------"
kubectl get pods -n "${NAMESPACE}" -o json | \
  jq -r '.items[] |
    select(.status.containerStatuses[]?.lastState.terminated.reason == "OOMKilled") |
    "\(.metadata.name) | restarts: \(.status.containerStatuses[0].restartCount) | last OOM: \(.status.containerStatuses[0].lastState.terminated.finishedAt)"'

# Step 3: node state analysis (memory/disk pressure)
echo ""
echo "[3/4] Node Condition analysis"
echo "----------------------------------------"
kubectl get nodes -o json | \
  jq -r '.items[] |
    .metadata.name as $node |
    .status.conditions[] |
    select(.type != "Ready" and .status == "True") |
    "\($node) | \(.type): \(.message)"'

# Step 4: recent deployment change history
echo ""
echo "[4/4] Recent deployment rollout history"
echo "----------------------------------------"
for deploy in $(kubectl get deployments -n "${NAMESPACE}" -o name); do
  echo "--- ${deploy} ---"
  kubectl rollout history "${deploy}" -n "${NAMESPACE}" | tail -5
done

# Correlation summary
echo ""
echo "========================================"
echo " Correlation summary"
echo "========================================"
echo ""

# Check the correlation between OOMKill and node memory pressure
OOM_COUNT=$(kubectl get pods -n "${NAMESPACE}" -o json | \
  jq '[.items[] | select(.status.containerStatuses[]?.lastState.terminated.reason == "OOMKilled")] | length')
NODE_PRESSURE=$(kubectl get nodes -o json | \
  jq '[.items[] | .status.conditions[] | select(.type == "MemoryPressure" and .status == "True")] | length')

if [ "$OOM_COUNT" -gt 0 ] && [ "$NODE_PRESSURE" -gt 0 ]; then
  echo "[strong correlation] OOMKill (${OOM_COUNT}) and node memory pressure (${NODE_PRESSURE}) occurred together"
  echo "  -> root cause candidate: node memory shortage or over-provisioned resource limits"
elif [ "$OOM_COUNT" -gt 0 ]; then
  echo "[moderate correlation] OOMKill (${OOM_COUNT}) occurred, no node pressure"
  echo "  -> root cause candidate: insufficient container memory limits or a memory leak"
fi

echo ""
echo "Analysis complete. If a deeper investigation is needed, check the Grafana dashboard."

The script gathers events from four angles and then judges the correlation automatically. When a Pod that was OOMKilled and node memory pressure exist at the same time, it judges that a node-level resource shortage is more likely the root cause than a problem in the individual container.

Automated Correlation with Robusta

Robusta is a Kubernetes-native AIOps platform that receives alerts from Prometheus Alertmanager, gathers context automatically and performs correlation analysis.

# robusta-playbook.yaml
# Robusta Playbook: automated Kubernetes event correlation
customPlaybooks:
  # Automatic analysis when an OOMKill occurs
  - triggers:
      - on_pod_oom_killed:
          namespace_prefix: 'production'
    actions:
      # 1. Collect the memory usage graph of the OOMKilled Pod
      - resource_babysitter:
          fields_to_monitor: ['status.containerStatuses']
      # 2. Collect related metrics from Prometheus
      - prometheus_enricher:
          prometheus_url: 'http://prometheus:9090'
          query: |
            container_memory_working_set_bytes{
              pod="{{ $pod_name }}",
              namespace="{{ $namespace }}"
            }
          duration_minutes: 60
      # 3. Check the state of the other Pods on the same node
      - node_running_pods_enricher: {}
      # 4. Send the analysis result to Slack
      - slack_sender:
          slack_channel: '#k8s-alerts'
          message: |
            :rotating_light: OOMKill correlation report
            Pod: {{ $pod_name }}
            Namespace: {{ $namespace }}
            Node: {{ $node }}
            The memory usage trend and the Pod state on the same node are attached.

  # Automatic analysis when CPU throttling occurs
  - triggers:
      - on_prometheus_alert:
          alert_name: CPUThrottlingHigh
          status: 'firing'
    actions:
      - cpu_throttling_analysis: {}
      - prometheus_enricher:
          prometheus_url: 'http://prometheus:9090'
          query: |
            rate(container_cpu_cfs_throttled_periods_total{
              pod="{{ $pod_name }}"
            }[5m])
          duration_minutes: 30
      - slack_sender:
          slack_channel: '#k8s-alerts'

  # Automatic correlation when the error rate rises after a deployment change
  - triggers:
      - on_deployment_update:
          namespace_prefix: 'production'
    actions:
      - deployment_status_enricher: {}
      - prometheus_enricher:
          prometheus_url: 'http://prometheus:9090'
          query: |
            sum(rate(http_requests_total{status=~"5.."}[5m])) /
            sum(rate(http_requests_total[5m])) * 100
          duration_minutes: 15

A Robusta Playbook triggers on a specific Kubernetes event and runs correlation actions automatically. When an OOMKill occurs, it automatically collects the memory usage trend of that Pod, the state of the other Pods on the same node and the related Prometheus metrics, and sends them to Slack.

Alert Noise Reduction Strategies

One of the central goals of adopting AIOps is reducing alert noise. According to the PagerDuty 2025 State of Digital Operations report, about 70% of the alerts an operations team receives are non-actionable noise. This section looks at strategies for reducing it.

Alert Grouping

Bundling alerts that derive from the same root cause into a single group cuts the alert count sharply. The Alertmanager group_by and group_wait settings handle this.

Time-based grouping: set group_wait to 30 seconds~1 minute to bundle alerts of the same type raised within a short window.

Topology-based grouping: use the service dependency graph to suppress downstream service alerts caused by an upstream service failure. When the API Gateway goes down, instead of sending dozens of microservice alerts individually, summarize them as "API Gateway down - 23 services affected".

ML-based grouping: combine the temporal proximity of alerts, the topological similarity of the affected resources and the text similarity of the alert messages to group them automatically.

Deduplication

When the same alert fires repeatedly, send only the first one and just increment a count afterwards. Set the Alertmanager repeat_interval appropriately, but since the anomaly detection output of an ML model updates continuously, do not set repeat_interval too long.

Adaptive Thresholds

Instead of a fixed threshold, use a dynamic threshold learned from historical data. For example, the normal CPU utilization range at 10 AM on a weekday differs from the normal range at 3 AM on a Sunday. A dynamic threshold reflects that and sets an appropriate threshold automatically for each point in time.

Comparing Open Source AIOps Tools

The application scenario for each tool is as follows.

• Robusta: teams centered on Kubernetes that already run Prometheus and prefer open source
• Datadog AIOps: teams monitoring APM, logs and infrastructure together across a multi-cloud environment
• Dynatrace Davis: enterprise teams with complex microservice dependencies for which automatic RCA is essential
• Moogsoft: large operations teams facing a high alert volume where alert noise reduction is the top priority
• Grafana ML: teams already operating the Grafana stack that want to adopt ML-based analysis gradually

Failure Cases and Recovery Procedures

Here are the failure cases that commonly appear while adopting AIOps and the procedures for recovering from them.

Failure Case 1: Excessive False Positives from Insufficient Training Data

Situation: a Prophet model was applied to a newly built service, but with only 3 days of training data it produced more than 100 false positives per day. The on-call team muted the ML alerts entirely and consequently missed a real incident.

Cause analysis: Prophet needs at least 2 weeks of data (on the basis of weekly seasonality) to learn seasonal patterns accurately. With 3 days of data it could not learn the difference between weekend and weekday patterns, so it judged the Saturday traffic drop to be an anomaly.

Recovery procedure:

1. Split ML alerts into a separate Slack channel immediately (separate them rather than muting them)
2. Retrain the model after securing at least 14 days of training data
3. Adopt Shadow Mode: record ML alerts without actually sending them and measure accuracy
4. Switch to real alerting once precision is 90% or higher
5. Raise interval_width from 0.95 to 0.99 to tune sensitivity

Failure Case 2: The Curse of Dimensionality in Isolation Forest

Situation: more than 100 metrics were fed into Isolation Forest at once, but the model detected almost no meaningful anomalies. In a high-dimensional space every data point becomes easy to "isolate", so the anomaly score lost its discriminating power.

Cause analysis: as the feature count grows, the split efficiency of the trees in Isolation Forest degrades. The more unnecessary features (noise metrics) there are, the more the real anomaly pattern is diluted.

Recovery procedure:

1. Apply PCA (principal component analysis) to reduce the features to 10~20
2. Use domain knowledge to pre-select the metrics with high correlation
3. Build an independent Isolation Forest model per service (avoid a single model for the whole cluster)
4. Tune the max_features parameter to limit how many features each tree uses

Failure Case 3: Undetected Model Drift

Situation: a model trained 6 months earlier was still applied unchanged after a service architecture change (a monolith moved to microservices), so it flagged every normal microservice communication pattern as an anomaly.

Cause analysis: an ML model works from the data distribution at training time. When the service architecture changes, the distribution of the metrics themselves changes, which invalidates the existing model.

Recovery procedure:

1. Build an automated model retraining pipeline (once a week, or when a distribution shift is detected)
2. Monitor the change in data distribution with KL Divergence or PSI (Population Stability Index)
3. Add a model validation stage to the CI/CD pipeline: block the deploy if the precision or recall of the new model falls below the bar
4. Wire architecture change events to trigger model retraining

Failure Case 4: A Wrong Automated Response from a Misread Correlation

Situation: a Robusta Playbook was set to roll back automatically whenever it detected "a rising error rate + a recent deployment change", but the error rate rise actually came from an external API outage. Rolling the deployment back unnecessarily doubled the service outage.

Cause analysis: temporal correlation does not imply causation. Errors appeared right after the deployment, but the real cause was an external API outage that happened in the same window.

Recovery procedure:

1. Add an "external dependency health check" step to the automatic rollback condition
2. Change the automatic rollback into a "rollback recommended" alert (a human makes the final call)
3. Adopt a canary deployment strategy to lower the risk of a full rollback
4. Run an impact analysis in dry-run mode before executing the rollback

Operational Checklist

Here are the items to check without fail when putting an AIOps-based anomaly detection system into production.

Model training and deployment:

• Is at least 2 weeks of training data available
• Has validation in Shadow Mode run for at least 1 week
• Is an automated model retraining pipeline in place
• Are model drift monitoring metrics configured
• Have the new and the existing model been compared with an A/B test

Alert quality management:

• Is the false positive rate 10% or below
• Is the false negative rate measured separately
• Are alert grouping and deduplication policies configured
• Is there a mechanism for collecting feedback from alert recipients
• Are the alert channels separated appropriately (critical/warning/info)

Kubernetes integration:

• Are RBAC permissions set according to the principle of least privilege
• Are resource requests/limits set for Robusta and the analysis agent
• Is kube-state-metrics, required for event correlation, deployed
• Is the analysis scope per namespace limited appropriately

Security and compliance:

• Is authentication and authorization applied to Prometheus API access
• Is the input data of the ML model free of sensitive information (PII)
• Does the retention period of the anomaly detection result logs match policy

Operating procedures:

• Does the automated response action include a human approval step
• Is a fallback procedure defined for when an automated response fails
• Is a model performance dashboard in place (precision, recall, F1 score)
• Is a regular model review meeting (once a month) scheduled

Conclusion

AIOps-based anomaly detection is not the fantasy that "AI takes care of everything", but a tool that augments the judgement of the operations team. It finds slow burn failures early that a fixed threshold cannot detect, compresses dozens of alerts into a single root cause, and automates repetitive analysis so engineers can concentrate on actually solving problems.

That said, adopting AIOps depends more on a change in operational culture than on the technical implementation. Gradual adoption through Shadow Mode, continuous monitoring of model performance, and a team-level feedback loop on alert quality are the keys to success. Starting with Isolation Forest and Prophet, verifying the effect on a small scope and then expanding gradually is strongly recommended.

References

• Robusta - Better Prometheus Alerts for Kubernetes (GitHub) - a Kubernetes-native AIOps platform, with Playbook-based automated analysis and alert enrichment
• Prophet for Anomaly Detection in Prometheus Time Series (Medium) - a practical guide to Prometheus time series anomaly detection with the Prophet library
• AI-Powered Observability: ML Anomaly Detection in Kubernetes (Logit.io) - a comprehensive explanation of ML-based anomaly detection architecture in a Kubernetes environment
• Implementing Predictive Monitoring with AIOps (InfoWorld) - strategies and real cases for implementing predictive monitoring with AIOps
• AIOps for Log Anomaly Detection in the Era of LLMs (ScienceDirect) - a systematic literature review of AIOps log anomaly detection in the era of LLMs
• Smarter Cloud: AI Detects Anomalies in Kubernetes (DECICE) - a case of proactive application of AI-based anomaly detection in a cloud environment
• Robusta KRR - Prometheus-based Kubernetes Resource Recommendations (GitHub) - a tool that recommends Kubernetes resource optimizations from Prometheus metrics