Detect Anomalies Aiops

---
name: detect-anomalies-aiops
locale: caveman-lite
source_locale: en
source_commit: 82c77053
fence_basis_commit: 82c77053
translator: "Julius Brussee homage — caveman"
translation_date: "2026-04-23"
description: >
  Implement AI-powered anomaly detection for operational metrics using time series analysis
  (Isolation Forest, Prophet, LSTM), alert correlation, and root cause analysis. Reduce
  alert fatigue by intelligently identifying true anomalies in system metrics, logs, and traces.
  Use when operations teams are overwhelmed by alert volume, when detecting complex multi-metric
  anomalies beyond static thresholds, when seasonal patterns make thresholds ineffective, or
  when needing to predict issues proactively before they impact users.
license: MIT
allowed-tools: Read Write Edit Bash Grep Glob
metadata:
  author: Philipp Thoss
  version: "1.0"
  domain: mlops
  complexity: advanced
  language: multi
  tags: aiops, anomaly-detection, isolation-forest, prophet, alert-correlation, time-series
---

# Detect Anomalies for AIOps


> See [Extended Examples](references/EXAMPLES.md) for complete configuration files and templates.

Apply machine learning to detect anomalies in operational metrics, correlate alerts, and reduce false positives.

## When to Use

- Operations team overwhelmed by alert volume (>100 alerts/day)
- Need to detect complex multi-metric anomalies (not threshold breaches)
- Seasonal patterns make static thresholds ineffective
- Want to predict issues before they impact users (proactive detection)
- Need to correlate related alerts to identify root cause
- Monitoring system generates too many false positives
- Want to detect subtle performance degradation trends

## Inputs

- **Required**: Time series metrics from monitoring system (CPU, memory, latency, error rate)
- **Required**: Historical data (30-90 days minimum)
- **Optional**: Alert history with labels (true positive / false positive)
- **Optional**: System topology (service dependencies)
- **Optional**: Log data for correlation
- **Optional**: Deployment/change events for context

## Procedure

### Step 1: Set Up Environment and Load Data

Install dependencies and prepare time series data for analysis.

```bash
# Create virtual environment
python -m venv venv
source venv/bin/activate

# Install anomaly detection libraries
pip install prophet scikit-learn pandas numpy
pip install tensorflow keras  # for LSTM models
pip install pyod  # Python Outlier Detection library
pip install statsmodels  # for statistical methods
pip install prometheus-api-client  # if using Prometheus

# Visualization
pip install plotly matplotlib seaborn
```

Load and prepare data:

```python
# aiops/data_loader.py
import pandas as pd
import numpy as np
from datetime import datetime, timedelta
from typing import List, Dict
import logging

logging.basicConfig(level=logging.INFO)
# ... (see EXAMPLES.md for complete implementation)
```

**Got:** Time series data loaded with regular intervals, missing values handled, features engineered for ML models.

**If fail:** If Prometheus connection fails, verify URL and network access, if data gaps exist use forward-fill or interpolation, ensure timestamp column is datetime type, check for memory issues with large date ranges (process in chunks).

### Step 2: Implement Isolation Forest for Multivariate Anomaly Detection

Detect anomalies using unsupervised Isolation Forest algorithm.

```python
# aiops/isolation_forest_detector.py
from sklearn.ensemble import IsolationForest
from sklearn.preprocessing import StandardScaler
import pandas as pd
import numpy as np
from typing import Dict, List
import joblib

# ... (see EXAMPLES.md for complete implementation)
```

**Got:** Model trained on historical data, anomalies detected with scores, typically 0.5-2% of points flagged as anomalies.

**If fail:** If too many anomalies (>5%), reduce contamination parameter or retrain on cleaner baseline period, if too few (<0.1%), increase contamination or check feature scaling, verify features have sufficient variance.

### Step 3: Implement Prophet for Time Series Forecasting and Anomaly Detection

Use Facebook Prophet to model seasonality and detect deviations.

```python
# aiops/prophet_detector.py
from prophet import Prophet
import pandas as pd
import numpy as np
from typing import Dict, Tuple
import logging

logger = logging.getLogger(__name__)
# ... (see EXAMPLES.md for complete implementation)
```

**Got:** Prophet models capture daily/weekly seasonality, anomalies detected when actual values fall outside 99% confidence interval, forecasts generated for capacity planning.

**If fail:** If Prophet takes too long (>5 min per metric), reduce history to 30 days or disable weekly_seasonality, if too many false positives increase interval_width to 0.995, if missing seasonal patterns add custom seasonalities, ensure timezone consistency in timestamps.

### Step 4: Correlate Alerts and Identify Root Cause

Group related anomalies and identify potential root causes.

```python
# aiops/alert_correlation.py
import pandas as pd
import numpy as np
from sklearn.cluster import DBSCAN
from typing import List, Dict
from datetime import timedelta
import networkx as nx

# ... (see EXAMPLES.md for complete implementation)
```

**Got:** Related anomalies grouped into incidents, root causes identified based on dependency graph, incident summaries generated for investigation.

**If fail:** If all anomalies separate incidents, increase time_window_minutes, if root cause detection unclear define metric_relationships explicitly based on architecture, verify timestamp sorting is correct.

### Step 5: Integrate with Alerting System

Send intelligent alerts with context and suppression of noise.

```python
# aiops/intelligent_alerting.py
import requests
import logging
from typing import Dict, List
from datetime import datetime, timedelta
import json

logger = logging.getLogger(__name__)
# ... (see EXAMPLES.md for complete implementation)
```

**Got:** High-severity incidents trigger PagerDuty pages, medium-severity go to Slack, low-severity logged only, duplicate alerts suppressed within 15-minute window.

**If fail:** Test webhook URLs with curl first, verify severity calculation produces reasonable values (0.5-0.9 range), check rate limiting doesn't suppress all alerts, ensure timezone handling is correct for last_alerts tracking.

### Step 6: Deploy as Continuous Monitoring Service

Set up automated pipeline that runs periodically.

```python
# aiops/monitoring_service.py
import schedule
import time
import logging
from datetime import datetime, timedelta
from data_loader import MetricsDataLoader
from isolation_forest_detector import IsolationForestDetector
from prophet_detector import ProphetAnomalyDetector
# ... (see EXAMPLES.md for complete implementation)
```

**Got:** Service runs continuously, detects anomalies every 5 minutes, alerts sent for incidents, logs all activity.

**If fail:** Verify scheduler process stays alive (use systemd/supervisor for production), check Prometheus connectivity, ensure models are loaded successfully, implement dead man's switch alert if service stops running, monitor memory usage (reload models periodically if memory grows).

## Validation

- [ ] Historical data loaded correctly with no missing timestamps
- [ ] Isolation Forest detects known anomalies from test set
- [ ] Prophet models capture daily/weekly seasonality in visualizations
- [ ] Alert correlation groups temporally-related anomalies
- [ ] Root cause detection identifies upstream issues correctly
- [ ] Intelligent alerting suppresses duplicate alerts
- [ ] Severity calculation produces reasonable scores (0.5-0.9)
- [ ] Monitoring service runs continuously without crashes for 7+ days
- [ ] False positive rate < 10% (validated against labeled data)
- [ ] True positive rate > 80% for critical incidents

## Pitfalls

- **Training on anomalous data**: Ensure baseline period used for training is clean (no incidents); manually review or use labeled data
- **Ignoring seasonality**: Static models fail on daily/weekly patterns; use Prophet or add time features
- **Too sensitive thresholds**: 99% confidence intervals may flag normal peaks; start with 99.5% and tune based on false positives
- **Not handling missing data**: Gaps in metrics cause model errors; implement robust preprocessing with interpolation
- **Alert fatigue from low severity**: Filter alerts below severity threshold; focus on high-confidence anomalies
- **Ignoring system topology**: Treating all metrics independently misses cascading failures; define dependency relationships
- **Model drift**: Models trained on old data become stale; retrain monthly or when system changes
- **Resource contention**: Running detection on every metric is expensive; prioritize critical services or sample metrics

## Related Skills

- `monitor-model-drift` - Detect when anomaly detection models degrade
- `monitor-data-integrity` - Data quality checks before anomaly detection
- `setup-prometheus-monitoring` - Collect operational metrics
- `forecast-operational-metrics` - Capacity planning with Prophet forecasts