Introduction
Model Monitoring (Model İzleme), üretim ortamına alınmış makine öğrenimi modellerinin doğruluk, performans, kaynak kullanımı ve veri kalitesinin sürekli takip edilmesini sağlar.
Bir modelin sadece ilk yayınlandığında değil, canlı ortamda yaşadığı tüm yaşam döngüsü boyunca izlenmesi gerekir.
Neden Kritik?
- Modeller zamanla drift yaşar (veri dağılımı veya hedef değişir)
- Yanlış tahminler müşteri güvenini azaltır
- Gecikme ve maliyet artışı operasyonel riski büyütür
- Uyarı eksikliği, kritik hataların geç fark edilmesine yol açar
“Ölçemediğin şeyi optimize edemezsin.” — Model Monitoring bu prensibin ML dünyasındaki karşılığıdır.
Prerequisites
Model Monitoring kurulumu öncesi şu altyapının hazır olması gerekir:
- MLOps pipeline: model build → deploy → monitor akışı tanımlı
- Prometheus: metrik toplayıcı (model, sistem, API metrikleri)
- Grafana: görselleştirme ve dashboard yönetimi
- Alertmanager: uyarı yönetimi (Telegram, e-posta, Slack vb.)
- Loki / ELK: log toplama sistemi
- Inference loglama: model çağrılarının kaydı
- Namespace ayrımı: prod / staging için izleme ayrımı
1️⃣ İzlenecek Metriklerin Belirlenmesi
Model izleme yalnızca CPU veya RAM değil, davranışsal ve işlevsel metrikleri de içermelidir.
Aşağıda üç temel kategori yer almaktadır:
a) Sistem Metrikleri
| Metrik | Açıklama | Araç |
|---|---|---|
| CPU / RAM Kullanımı | Model servisinin kaynak yükü | Node Exporter |
| Disk I/O ve Network | Gecikme, paket kaybı | Prometheus |
| Container Sağlığı | Pod durumları, restart sayısı | Kubernetes metrics |
b) Uygulama Metrikleri
| Metrik | Açıklama | Araç |
|---|---|---|
| Request Count / Latency | API çağrı yoğunluğu ve gecikme | FastAPI / Prometheus |
| Error Rate | Hatalı cevap oranı (5xx) | Grafana panel |
| Throughput (RPS) | Saniyelik istek sayısı | PromQL sorgusu |
c) Model Metrikleri
| Metrik | Açıklama | Araç |
|---|---|---|
| Accuracy / F1 / Recall | Performans metrikleri | Model test sonuçları |
| Drift Rate | Veri dağılım değişimi | Evidently AI / custom script |
| Data Freshness | Veri güncelliği | Airflow / MLflow logs |
2️⃣ Prometheus Konfigürasyonu
2.1 prometheus.yml örneği
global:
scrape_interval: 15s
scrape_configs:
- job_name: 'model-api'
static_configs:
- targets: ['10.1.2.20:8000']
- job_name: 'node-exporter'
static_configs:
- targets: ['10.1.2.21:9100']
2.2 Model metrik endpoint’i
Model API kodunda /metrics endpoint’i tanımlanmalıdır:
from prometheus_client import start_http_server, Counter, Histogram
import time
from fastapi import FastAPI
app = FastAPI()
REQUESTS = Counter("model_requests_total", "Total number of requests")
LATENCY = Histogram("model_latency_seconds", "Request latency in seconds")
@app.post("/predict")
def predict(input: dict):
REQUESTS.inc()
start = time.time()
result = {"prediction": "ok"}
LATENCY.observe(time.time() - start)
return result
3️⃣ Grafana Dashboard Kurulumu
3.1 Dashboard örnekleri
- System Overview: CPU, RAM, Disk IO
- Application Metrics: Latency, Throughput, Error Rate
- Model Performance: Accuracy, Drift, Confidence
3.2 Grafana Datasource Ayarı
http://10.1.2.22:3000
Prometheus veri kaynağını ekleyin.
Query örnekleri:
rate(model_requests_total[1m])
histogram_quantile(0.95, sum(rate(model_latency_seconds_bucket[5m])) by (le))
3.3 Alert Panel
expr: rate(model_requests_total[5m]) < 1
for: 5m
labels:
severity: critical
annotations:
description: "Model service might be down!"
4️⃣ Model Drift & Data Quality Ölçümü
4.1 Drift Tespiti
Drift, modelin üretimdeki tahmin dağılımının eğitim dağılımından sapmasıdır.
Araç: Evidently AI
pip install evidently
Kod örneği:
from evidently.report import Report
from evidently.metrics import DataDriftPreset
report = Report(metrics=[DataDriftPreset()])
report.run(reference_data=train_df, current_data=prod_df)
report.save_html("drift_report.html")
Eğer drift %30’un üzerindeyse, yeniden eğitim (retrain) planı tetiklenmelidir.
4.2 Veri Kalitesi
- Eksik değer oranı, dağılım değişimi
- Kategorik değişken dengesizlikleri
- Anormal örnek yoğunluğu
5️⃣ Alertmanager Yapılandırması
alertmanager.yml örneği:
global:
smtp_smarthost: 'smtp.office365.com:587'
smtp_from: 'alerts@hmyn.net'
smtp_auth_username: 'alerts@hmyn.net'
smtp_auth_password: '********'
route:
receiver: 'team-hmyn'
receivers:
- name: 'team-hmyn'
email_configs:
- to: 'devops@hmyn.net'
Opsiyonel Telegram webhook:
receivers:
- name: 'telegram'
webhook_configs:
- url: 'http://10.1.2.22:5678/telegram'
6️⃣ Anomali Tespiti ve Olay Müdahalesi
6.1 Runtime tespiti
- Falco: sistem çağrısı temelli izleme
- Prometheus Alert: CPU/RAM sapmaları
- Grafana Alerts: özel model metrikleri
6.2 Olay Yönetimi
| Süreç | Araç | Sorumlu |
|---|---|---|
| Alarm bildirimi | Alertmanager / Telegram | DevOps |
| Root cause analizi | Grafana / Loki | SRE / MLOps |
| Post-mortem raporu | Confluence / GitHub Wiki | Team Lead |
6.3 Otomatik düzeltme (Self-healing)
kubectl rollout restart deployment model-api -n prod
7️⃣ Üretim Ortamı Check-listesi
| Kategori | Kontrol Maddesi | Durum |
|---|---|---|
| Sistem İzleme | CPU, RAM, Disk, Network metrikleri toplanıyor mu? | ✅ |
| Uygulama İzleme | API latency, throughput ve error oranı takip ediliyor mu? | ✅ |
| Model İzleme | Accuracy / Drift / Confidence loglanıyor mu? | ✅ |
| Loglama | Inference logları merkezi olarak saklanıyor mu? | ✅ |
| Alarm | Uyarılar e-posta / Telegram ile iletiliyor mu? | ✅ |
| Veri Kalitesi | Drift analizi periyodik mi (ör. haftalık)? | ✅ |
| SLA Takibi | Model response < 500ms? | ⚙️ |
| Olay Müdahalesi | Runbook ve sorumlu kişi tanımlı mı? | ⚙️ |
| Güvenlik | Prometheus ve Grafana erişimi role-based mi? | ✅ |
Conclusion
Model Monitoring, bir ML modelinin canlı performansını anlamak ve erken uyarı sistemi kurmak için gereklidir.
Başarılı bir izleme yapısı, yalnızca teknik araçlarla değil, süreç disipliniyle sürdürülebilir hale gelir.
Kısa Özet:
- Prometheus & Grafana temel yapı taşlarıdır
- Model drift ölçümü, retrain stratejisini tetikler
- Alertmanager ile olaylara hızlı müdahale sağlanır
- Check-list, DevOps / MLOps ekipleri arasında standardizasyon sağlar
“Sağlam bir izleme sistemi, üretimdeki her modelin nabzını tutar.”