### Overview and What You Will Learn * What an anomaly is in plain language and how it shows up in production systems * The three types of anomalies and how each one appears in real ops data * Why simple threshold-based alerting breaks down at scale * How ML-based anomaly detection solves the problems that rules cannot ### Why This Matters Every production system generates signals — CPU percentages, response times, memory usage, error rates, request counts. Most of the time these signals are boring and predictable. But occasionally something happens that should not: a server's memory starts climbing at 3am, response times spike for exactly one API endpoint, or disk write latency doubles for no obvious reason. These are anomalies. Finding them before a customer notices is the entire job of an AIOps engineer. If you wait for a human to spot a pattern in a dashboard, you have already lost minutes or hours. The goal is to teach a machine to notice when something is wrong before any threshold is crossed. ### What an Anomaly Actually Is An anomaly is a data point that is significantly different from what you would normally expect. It is not necessarily bad — an unusually high number of orders during a sale event is an anomaly too — but it is unexpected, and unexpected things deserve attention. In plain language: if you plot a week of CPU usage and almost every data point clusters between 40% and 60%, a data point sitting at 94% at 2am on a Tuesday is an anomaly. It does not fit the pattern everything else follows. The key word is context. A CPU at 80% during a scheduled batch job at midnight is normal. The same CPU at 80% on an idle service at 3pm on a Sunday is suspicious. Anomaly detection is not just about the value — it is about whether the value makes sense given everything else going on. ### The Three Types of Anomalies Production systems produce all three types and you need to recognize each one. A **point anomaly** is a single data point that stands out from the rest of the data. This is the simplest type. One request that took 45 seconds when all others took under 200 milliseconds. One CPU sample at 98% surrounded by samples at 45%. The value itself is the problem, regardless of what came before or after it. Normal CPU readings: 45% 47% 43% 46% 44% 98% 45% 46% ^ This single point is the anomaly A **contextual anomaly** is a data point that looks normal on its own but is suspicious given its context. Traffic of 10,000 requests per minute is perfectly normal during business hours for a large platform. The same 10,000 requests per minute at 4am is deeply suspicious. The value has not changed — the context has. Time of day, day of week, and recent history are all context. A **collective anomaly** is a group of data points that each look individually normal but are suspicious when considered together. Imagine a service where response time gradually increases by 2ms every minute for three hours. No single data point crosses any threshold. But the steady directional drift — the trend — is the anomaly. Collectively, those hundreds of normal-looking data points are telling you something is wrong. ### Why Threshold-Based Alerting Fails Set CPU above 85% — alert. Error rate above 1% — alert. This works for a small stable system. It breaks down at scale for three reasons: **Static thresholds, dynamic systems.** A payment service at 60% CPU during a sale event is fine. The same 60% at 3am Sunday is suspicious. One number cannot represent both. **Alert fatigue.** Set thresholds too sensitive and you get paged constantly. Raise them to reduce noise and real problems slip through. Either way engineers stop trusting alerts. **Gradual degradation is invisible.** A connection pool slowly filling over hours, a memory leak growing by 10MB per restart, disk filling at 0.1% per hour — none of these cross any threshold until the moment of failure. ML catches the trend, not just the crash. ### How ML-Based Detection Changes This Instead of "did this value cross a fixed number", ML asks "is this value consistent with what this metric normally looks like at this time and for this service?" It learns normal from your data, adapts as the system evolves, and catches subtle multivariate patterns no threshold ever could. Isolation Forest does exactly this — without labeled data, without defining what normal looks like manually. > 📌 **Remember:** Anomaly detection in ops is not about finding bugs or errors. It is about finding things that do not fit the expected pattern — whatever that pattern happens to be. The ML model learns the pattern from historical data and flags deviations. ---
### Overview and What You Will Learn * What supervised anomaly detection means and when it makes sense * Why ops data is almost always unlabeled and why that matters * What unsupervised detection means and why it is the right fit for most ops work * The two core assumptions behind unsupervised methods * Simple statistical baselines — Z-score and IQR — and when they are enough * How to decide which approach to reach for in a given situation ### Why This Matters Before you can choose the right anomaly detection method, you need to understand the landscape. Isolation Forest is an unsupervised method — it works without labeled data. Understanding why that matters, and what the alternatives look like, will help you make better decisions about when to use it and when a simpler or different approach is more appropriate. ### Supervised Anomaly Detection In supervised anomaly detection, you have a dataset where every data point is labeled — this one is normal, this one is an anomaly. You train a model on those labeled examples and it learns to classify new data points as normal or anomalous. This sounds ideal but it has a fundamental practical problem: labeled data for anomalies is almost never available in ops work. To have labeled anomaly data, you need someone to have gone through historical metric data and manually tagged every incident and every false alarm. That almost never happens. Even when you do have labels, anomalies are by definition rare — so the dataset is extremely imbalanced, which creates its own modeling challenges. Supervised methods make sense when anomalies are well-defined and consistent — fraud detection in banking, for example, where fraudulent transactions follow recognizable patterns and labeled historical data exists. For general infrastructure monitoring, they are rarely practical. ### Why Ops Data Is Almost Always Unlabeled Think about what you have in a real ops environment. You have weeks or months of Prometheus metric exports. Time-series data with thousands of data points per service per hour. Nobody has gone through and labeled each data point as normal or anomalous. You do not even know which past anomalies were real incidents and which were noise. This is the reality for almost every ops team. The data exists in abundance but the labels do not. Any anomaly detection approach that requires labeled training data is immediately impractical. ### Unsupervised Anomaly Detection Unsupervised anomaly detection makes no assumption about labels. It looks at the raw data and uses the structure of the data itself to find things that seem out of place. Two assumptions underlie all unsupervised methods: * Anomalies are rare. Most of your data is normal. If 99% of your CPU readings are between 30% and 70%, the model can learn what normal looks like from that majority. * Anomalies are different. A data point that is anomalous behaves differently from the normal majority in some measurable way — it is farther away, it has different density, or it is harder to fit into the pattern that normal data follows. These two assumptions hold extremely well for infrastructure monitoring data. Most of the time, your servers are doing normal things. Real anomalies are rare. And when something is genuinely wrong, it usually shows up in the data in a measurable way. ### Statistical Baselines - Z-Score and IQR Before reaching for a full ML model, it is worth knowing the simpler statistical approaches. They work well for single metrics and are easy to understand and explain. A **Z-score** measures how many standard deviations a data point is from the mean. A Z-score above 3 or below -3 is conventionally considered anomalous. ```python import pandas as pd import numpy as np ## Load metric data df = pd.read_csv("cpu_metrics.csv") df["timestamp"] = pd.to_datetime(df["timestamp"]) ## Calculate rolling mean and standard deviation ## Window of 60 points = 60 minutes at 1-minute intervals df["rolling_mean"] = df["cpu_usage"].rolling(window=60).mean() df["rolling_std"] = df["cpu_usage"].rolling(window=60).std() ## Z-score: how many standard deviations from the rolling mean df["z_score"] = (df["cpu_usage"] - df["rolling_mean"]) / df["rolling_std"] ## Flag anything beyond 3 standard deviations df["is_anomaly"] = df["z_score"].abs() > 3 anomalies = df[df["is_anomaly"] == True] print(f"Found {len(anomalies)} anomalies") ``` **IQR (Interquartile Range)** is more robust to extreme outliers than Z-score. It defines the normal range as between Q1 - 1.5*IQR and Q3 + 1.5*IQR, where Q1 and Q3 are the 25th and 75th percentiles. ```python ## IQR-based anomaly detection Q1 = df["cpu_usage"].quantile(0.25) Q3 = df["cpu_usage"].quantile(0.75) IQR = Q3 - Q1 lower_bound = Q1 - 1.5 * IQR upper_bound = Q3 + 1.5 * IQR df["is_anomaly_iqr"] = ( (df["cpu_usage"] < lower_bound) | (df["cpu_usage"] > upper_bound) ) ``` ### When Statistical Methods Are Enough Z-score and IQR work well when you are monitoring a single metric in isolation and the data follows a roughly normal distribution. They are fast, simple, and easy to explain. They fail when you need to detect anomalies in the combination of multiple metrics. A CPU at 60% is normal. Memory at 85% is normal. Disk I/O at 40% is normal. But all three happening simultaneously on a service that normally runs quiet could be very abnormal. Statistical methods look at one column at a time. Isolation Forest looks at all columns together — which is exactly what makes it powerful for ops data. | Method | Good For | Struggles With | | :--- | :--- | :--- | | Z-score | Single metric, normally distributed | Multiple metrics, non-normal data | | IQR | Single metric, resistant to outliers | Multiple metrics, temporal patterns | | Isolation Forest | Multiple metrics, high-dimensional, no labels needed | Very small datasets, clustered anomalies | ---
### Overview and What You Will Learn * The simple intuition behind why Isolation Forest works * What a decision tree is in plain language before introducing isolation trees * How isolation trees differ from classification trees * The role of random feature selection and random split values * Why anomalies reach leaf nodes in fewer splits than normal points * How path length becomes an anomaly score * Why this approach is faster and more scalable than alternatives ### Why This Matters Isolation Forest is one of the most widely used anomaly detection algorithms in production systems. Understanding how it works — not just how to call the scikit-learn function — means you can tune it intelligently, debug it when results seem wrong, and explain it to a colleague or interviewer. The algorithm is genuinely elegant and the core idea is simple enough to explain in a few sentences once you understand it. ### The Central Intuition **Anomalies are easier to isolate than normal points.** Imagine 1000 CPU readings. 980 cluster between 40% and 65%. Twenty sit between 80% and 99%. If you randomly draw a line through this data, the clustered normal points are hard to separate — they are packed together. The 20 outliers are easy to cut off with one or two lines. The algorithm measures this: how many random cuts does it take to isolate a data point? Fewer cuts means more anomalous. That count becomes the anomaly score. Here is a visual showing the difference in path depth: Data: 8 normal points (N) clustered together, 1 anomaly (A) off to the side Values: N=40,42,44,46,48,50,52,54 A=91 Isolation Tree splits (random): Split 1: value < 70? YES (N,N,N,N,N,N,N,N) NO → A is ALONE after 1 split! | Split 2: value < 47? YES (N,N,N,N) NO (N,N,N,N) | Split 3: value < 43? YES (N,N) NO (N,N) ...keeps splitting... Anomaly A: path length = 1 (isolated immediately) Normal N: path length = 5+ (needs many splits) Lower path length = more anomalous ### What a Decision Tree Is Before introducing isolation trees, a brief foundation. A **decision tree** is a structure that repeatedly splits data based on feature values. At each node it asks a yes/no question about one feature: "Is CPU usage above 70%?" If yes, go left. If no, go right. It keeps splitting until each group is pure or a stopping condition is reached. Normal decision trees are trained to make accurate predictions — they learn which splits best separate classes or minimize prediction error. The splits are chosen carefully based on the training data. An isolation tree is different. It does not try to make good predictions. It makes random, meaningless splits. And that randomness is exactly what makes it useful. ### How an Isolation Tree Works Building one isolation tree proceeds as follows: First, take a sample of your data — typically 256 points, regardless of how large your full dataset is. Second, randomly select one feature from your dataset. If you have CPU, memory, and request rate as features, you might randomly choose memory. Third, randomly select a split value anywhere between the minimum and maximum value of that feature in your current sample. If memory ranges from 20% to 90%, you might randomly pick 54%. Fourth, split the data: points with memory below 54% go left, points above go right. Fifth, repeat the process recursively on each resulting group — pick another random feature, pick another random split — until every data point is alone in its own leaf node or you hit a maximum tree depth. The diagram below shows conceptually what happens: Full dataset (mixed normal and anomalous points) | Random split on Feature A at value 61 / \ Points < 61 Points > 61 | | Random split Point is ALONE on Feature B (anomaly isolated at value 42 in just 2 splits) / \ ... ... (many more splits needed to isolate normal points) The anomalous point far from the cluster gets isolated in 2 splits. Normal points packed together take many more splits to separate from their neighbors. ### Path Length as an Anomaly Score The **path length** is the number of splits to isolate a data point in one tree. Short path = easy to isolate = likely anomaly. Long path = surrounded by similar points = likely normal. One tree is noisy due to randomness. Building 100 trees and averaging the path length gives a stable score. Tree 1: path length for point X = 4 Tree 2: path length for point X = 3 Tree 3: path length for point X = 5 ... Tree 100: path length for point X = 4 Average = 4.1 → normalized score → -1 if anomaly, 1 if normal > 💡 **Tip:** You do not need to understand the exact formula. What matters: shorter average path = more anomalous. scikit-learn returns -1 for anomaly and 1 for normal. ### Why This Is Faster Than Distance-Based Methods Many anomaly detection methods — like k-nearest neighbors — work by measuring how far each data point is from its neighbors. To do this for N points, you need to calculate distances between all pairs of points. This scales as O(N²) which becomes impossibly slow for large datasets. Isolation Forest builds trees from small random subsamples (default 256 points per tree) and each tree is built independently. This scales linearly — O(N) — which means it works just as well on a million points as on a thousand. For ops data where you might have millions of metric samples, this efficiency matters enormously. ---
### Overview and What You Will Learn * Building a full isolation forest from multiple trees * Why a forest gives better results than a single tree * The contamination parameter and how to set it practically * What the decision_function scores mean * What -1 and 1 in the predict output mean * The relationship between anomaly score and threshold ### Why This Matters Knowing the intuition is not enough to use the algorithm correctly. Understanding the parameters and what the output means lets you tune the model for your specific data, avoid common mistakes, and interpret results correctly when presenting them to a team. ### Building a Forest from Many Trees A single isolation tree is noisy because splits are random — two trees on the same data give different results. Building 100 trees and averaging path lengths across all of them produces a reliable, stable score. Beyond 200 trees the accuracy improvement is minimal. ### The contamination Parameter `contamination` is the most important parameter to set correctly. It tells the model what percentage of your data you expect to be anomalous. If you set `contamination=0.05`, the model will flag approximately 5% of your data points as anomalies. It does this by setting the threshold for the anomaly score at the 5th percentile — the 5% of points with the shortest average path lengths are labeled -1. Setting contamination too high flags too many normal points as anomalies — lots of false alerts. Setting it too low misses real anomalies. For ops data where genuine incidents are rare, values between 0.01 and 0.05 (1% to 5%) are typically appropriate. Start at 0.02 and adjust based on how many alerts you see. ```python from sklearn.ensemble import IsolationForest ## contamination=0.02 means we expect roughly 2% of data to be anomalous model = IsolationForest( n_estimators=100, ## number of trees in the forest contamination=0.02, ## expected proportion of anomalies max_samples=256, ## data points used to build each tree random_state=42 ## for reproducibility ) ``` ### The decision_function Output The `decision_function` method returns a raw anomaly score for each data point. The exact values depend on your data but the direction is always the same: * More negative scores = more anomalous (shorter path length, easier to isolate) * Scores near zero or positive = normal (longer path length, harder to isolate) ```python ## Get raw anomaly scores for every data point scores = model.decision_function(X) ## Print the 5 most anomalous points import numpy as np most_anomalous = np.argsort(scores)[:5] print("Most anomalous data points:") for idx in most_anomalous: print(f" Index {idx}: score = {scores[idx]:.4f}") ``` ### The predict Output — -1 and 1 The `predict` method applies the contamination threshold and returns a simple label for each point: * **1** means normal — this point looks like the majority of your data * **-1** means anomaly — this point was easy to isolate and falls in the anomalous portion ```python labels = model.predict(X) ## Count normal and anomalous predictions normal_count = (labels == 1).sum() anomaly_count = (labels == -1).sum() print(f"Normal points: {normal_count}") print(f"Anomalous points: {anomaly_count}") print(f"Anomaly rate: {anomaly_count / len(labels) * 100:.1f}%") ``` > 🔴 **Common Mistake:** Confusing -1 as "bad output" when it just means anomaly. The value -1 is a label, not an error code. It means the model flagged this point as potentially anomalous based on the contamination threshold you set. ---
### Overview and What You Will Learn * Installing the required libraries * Loading and preparing metric data for the model * The complete code from raw data to anomaly labels * Tuning n_estimators, contamination, and max_samples * Common mistakes in setup and how to avoid them ### Why This Matters Reading about an algorithm and running it on real data are two very different experiences. This topic walks through the complete setup process — every step from installing packages to getting anomaly labels — so that by the end you have working code you can adapt for any ops metric dataset. ### Installing Required Libraries ```bash pip install scikit-learn pandas numpy matplotlib ``` Verify the installation: ```python import sklearn import pandas import numpy print(f"scikit-learn: {sklearn.__version__}") print(f"pandas: {pandas.__version__}") print(f"numpy: {numpy.__version__}") ``` ### Preparing Your Data Isolation Forest expects a 2D array where each row is one observation and each column is one feature. For ops data, each row is typically one time period (say, one minute) and each column is one metric. ```python import pandas as pd import numpy as np ## Load your metric data ## Each row = one minute of metrics for one service df = pd.read_csv("prod-metrics.csv") print(df.head()) print(df.shape) print(df.isnull().sum()) ## check for missing values ## Handle missing values - fill with previous value df = df.fillna(method="ffill") ## Select the feature columns to use for anomaly detection ## Do NOT include timestamp, service name, or ID columns features = ["cpu_usage", "memory_usage", "request_rate", "error_rate", "response_time_p99"] X = df[features].values ## convert to numpy array print(f"Feature matrix shape: {X.shape}") ## Expected: (number_of_rows, 5) ``` ### Fitting the Model and Getting Predictions ```python from sklearn.ensemble import IsolationForest ## Create and fit the model model = IsolationForest( n_estimators=100, ## 100 trees - good default for most datasets contamination=0.02, ## expect about 2% anomalies max_samples="auto", ## uses min(256, n_samples) automatically random_state=42 ## makes results reproducible ) model.fit(X) ## Get predictions labels = model.predict(X) ## 1 = normal, -1 = anomaly scores = model.decision_function(X) ## raw anomaly scores ## Add results back to the DataFrame df["anomaly_label"] = labels df["anomaly_score"] = scores ## View the anomalous rows anomalies = df[df["anomaly_label"] == -1] print(f"\nTotal data points: {len(df)}") print(f"Anomalies detected: {len(anomalies)}") print(f"\nTop anomalies by score:") print(anomalies.nsmallest(10, "anomaly_score")[["timestamp", "cpu_usage", "memory_usage", "anomaly_score"]]) ``` ### Key Parameter Tuning Guide | Parameter | Default | What It Does | When to Change | | :--- | :--- | :--- | :--- | | `n_estimators` | 100 | Number of trees | Increase to 200 for more stable results on noisy data | | `contamination` | "auto" | Expected anomaly fraction | Set explicitly based on your domain knowledge | | `max_samples` | "auto" | Samples per tree | Reduce on very large datasets to speed up training | | `random_state` | None | Random seed | Always set for reproducible results in production | | `max_features` | 1.0 | Features per split | Reduce to 0.5 to introduce more randomness | ### Feature Scaling Isolation Forest is generally robust to feature scaling because it uses random splits rather than distances. However, if your features have very different ranges (CPU is 0-100, memory bytes is in millions), it can sometimes help to normalize them. ```python from sklearn.preprocessing import StandardScaler scaler = StandardScaler() X_scaled = scaler.fit_transform(X) ## Use X_scaled instead of X when fitting the model model.fit(X_scaled) labels = model.predict(X_scaled) ``` > 💡 **Tip:** Always set `random_state=42` (or any fixed integer) in production models. Without it, every time you retrain the model you get slightly different results, which makes debugging inconsistent behavior very difficult. > 🔴 **Common Mistake:** Including the timestamp column in your feature matrix. A datetime object is not a numeric feature the model understands. Either drop the timestamp column or convert it to numeric features like hour_of_day and day_of_week before using it. ---
### Overview and What You Will Learn * Why evaluating unsupervised models is harder than supervised models * Visual inspection as the first line of evaluation * Using precision, recall, and F1 score when labels are available * What a confusion matrix looks like for anomaly detection * Why ROC-AUC matters for imbalanced anomaly datasets * The practical ops question - does the alert fire when it should? ### Why This Matters A model that flags everything as anomalous is useless. So is one that never flags anything. Evaluation tells you whether your model is actually useful, and choosing the right evaluation method depends on what data you have available. Getting evaluation wrong leads to deploying a model that looks good on paper but generates either constant false alarms or silent failures in production. ### The Core Challenge In supervised learning, evaluation is straightforward: you have test labels, you compare predictions to those labels, and you calculate accuracy or other metrics. Anomaly detection is harder. You trained the model without labels. You probably do not have a clean test set with labeled anomalies either. And even if you do, anomalies are rare — a model that labels everything as normal would be 99% accurate on a dataset with 1% anomalies. Accuracy is a useless metric here. ### Visual Inspection First Before any metric, visualize your results. Plot your time-series data and mark the points the model flagged as anomalies. Do the flagged points correspond to things you know were real incidents? Are most anomalies clustered at times you know were unusual? ```python import matplotlib.pyplot as plt fig, axes = plt.subplots(2, 1, figsize=(14, 8)) ## Top plot: CPU usage with anomalies highlighted normal = df[df["anomaly_label"] == 1] flagged = df[df["anomaly_label"] == -1] axes[0].plot(df["timestamp"], df["cpu_usage"], color="steelblue", linewidth=0.8, label="CPU Usage", alpha=0.7) axes[0].scatter(flagged["timestamp"], flagged["cpu_usage"], color="red", s=50, zorder=5, label="Flagged Anomaly") axes[0].set_title("CPU Usage with Isolation Forest Anomalies") axes[0].set_ylabel("CPU %") axes[0].legend() ## Bottom plot: Anomaly scores over time axes[1].plot(df["timestamp"], df["anomaly_score"], color="purple", linewidth=0.8) axes[1].axhline(y=0, color="red", linestyle="--", alpha=0.5, label="Threshold") axes[1].set_title("Anomaly Scores Over Time") axes[1].set_ylabel("Score (more negative = more anomalous)") axes[1].legend() plt.tight_layout() plt.savefig("anomaly_visualization.png", dpi=150) plt.show() ``` ### When You Have Labels - Precision, Recall, F1 If you have historical incident data or can label a subset of your data, you can calculate proper evaluation metrics. **Precision** answers: of all the points the model flagged as anomalies, what fraction were genuinely anomalous? High precision means few false alarms. **Recall** answers: of all the genuine anomalies in the data, what fraction did the model catch? High recall means few missed incidents. **F1 score** is the harmonic mean of precision and recall. It balances both concerns in a single number. ```python from sklearn.metrics import precision_score, recall_score, f1_score, confusion_matrix ## Assuming you have ground truth labels ## true_labels: 1 = normal, -1 = anomaly (matching IsolationForest output) true_labels = df["known_anomaly"].map({0: 1, 1: -1}).values pred_labels = df["anomaly_label"].values ## Convert to binary: 1 = anomaly, 0 = normal for sklearn metrics true_binary = (true_labels == -1).astype(int) pred_binary = (pred_labels == -1).astype(int) precision = precision_score(true_binary, pred_binary) recall = recall_score(true_binary, pred_binary) f1 = f1_score(true_binary, pred_binary) print(f"Precision: {precision:.3f} (of flagged anomalies, {precision*100:.1f}% were real)") print(f"Recall: {recall:.3f} (of real anomalies, {recall*100:.1f}% were caught)") print(f"F1 Score: {f1:.3f}") ## Confusion matrix cm = confusion_matrix(true_binary, pred_binary) print(f"\nConfusion Matrix:") print(f" True Normal flagged as Normal: {cm[0][0]}") print(f" True Normal flagged as Anomaly: {cm[0][1]} (False Positives)") print(f" True Anomaly flagged as Normal: {cm[1][0]} (False Negatives)") print(f" True Anomaly flagged as Anomaly: {cm[1][1]} (True Positives)") ``` ### ROC-AUC for Imbalanced Data When anomalies are rare (1-5% of data), the ROC-AUC score gives a more complete picture than precision or recall alone. It measures how well the model ranks anomalous points above normal points across all possible thresholds. ```python from sklearn.metrics import roc_auc_score ## Use the raw anomaly score rather than the binary prediction ## Negate scores because lower score = more anomalous ## but roc_auc_score expects higher score = more anomalous roc_auc = roc_auc_score(true_binary, -df["anomaly_score"]) print(f"ROC-AUC: {roc_auc:.3f}") ## Closer to 1.0 is better. 0.5 is random. Above 0.8 is generally good. ``` ### The Practical Ops Question In production, evaluation often comes down to a simpler question: when a real incident happened, did the model flag it before a human noticed? After you deploy, compare the model's alert timestamps to your incident log. How many minutes before the incident was declared did the model first flag anomalous behavior? This operational lead time — the gap between model alert and incident declaration — is the metric that matters most in practice. ---
Overview and What You Will Learn What an anomaly is in plain language and how it shows up in production systems The thre...
Overview and What You Will Learn What supervised anomaly detection means and when it makes sense Why ops data is almost ...
Overview and What You Will Learn The simple intuition behind why Isolation Forest works What a decision tree is in plain...
Overview and What You Will Learn Building a full isolation forest from multiple trees Why a forest gives better results ...
Overview and What You Will Learn Installing the required libraries Loading and preparing metric data for the model The c...
Overview and What You Will Learn Why evaluating unsupervised models is harder than supervised models Visual inspection a...
Overview and What You Will Learn Structuring CPU, memory, and request rate data as input features Injecting synthetic an...
Overview Build a complete anomaly detection pipeline from scratch. You will generate synthetic server metrics, preproces...
When to Use Isolation Forest Isolation Forest is a strong default choice when you have unlabeled ops metric data, multip...
Aligns directly with DevOps, Site Reliability (SRE), and Platform Engineering job descriptions.