Entegrasyon İzleme: Başarısız Senkronizasyonları Kaçırmadan Yakalamak

Entegrasyonun en pahalı arızası gürültülü olanı değil, sessiz olanıdır: sunucular ayakta, uç noktalar 200 dönüyor, ama stok üç gündür güncellenmemiş ya da her gün birkaç sipariş ERP’ye hiç düşmüyor. Sorunu çoğu zaman müşteri veya muhasebe fark eder. Bu noktada artık teknik bir arıza değil, düzeltilmesi gereken bir veri tutarsızlığı vardır. Bunu erken yakalamak için korelasyon kimliğinden iş seviyesi metriklere, alarm eşiklerinden periyodik mutabakat raporuna kadar ayrı bir izleme katmanı kurmak gerekir.

Teknik uptime ile iş akışı sağlığı arasındaki fark

Klasik uptime izlemesi “servis yanıt veriyor mu?” sorusunu yanıtlar. Entegrasyonda asıl soru “veri beklenen sürede, eksiksiz ve doğru biçimde karşı tarafa ulaşıyor mu?” sorusudur. Fark, sahada tekrar tekrar gördüğümüz şu sessiz arızalarda ortaya çıkar:

• Zamanlanmış görev, sunucu yeniden kurulduktan ya da taşındıktan sonra cron tanımı kaybolduğu için hiç çalışmıyor; hata da üretmiyor.
• Kuyruk tüketicisi ayakta, ama ERP’de kilitlenen bir kayıt yüzünden her mesajı yeniden deniyor; kuyruk saatlerdir büyüyor.
• Webhook sağlayıcısı imza sırrının değiştirildiğinden habersiz; tüm olaylar 401 ile reddediliyor ve sağlayıcı bir süre sonra denemeyi bırakıyor.
• API çağrısı başarılı, ama alan eşleştirmesi değiştiği için ürünlerin fiyatı sıfır olarak yazılıyor.
• Toplu aktarım dosyası geliyor ama boş; işlem “0 kayıt işlendi, başarılı” diye bitiyor.

Bu senaryoların hiçbirini HTTP uptime kontrolü yakalamaz. Panoda her şey yeşildir. İzleme bu nedenle üç seviyede kurulur: altyapı (sunucu, kuyruk aracısı, veritabanı), teknik akış (hata oranı, gecikme, kuyruk derinliği) ve iş sonucu (beklenen veri karşı tarafta var mı). Altyapı tarafındaki metrik ve eşikler için sunucu izleme metrikleri ve eşik değerleri yazısına bakabilirsiniz; burada diğer iki seviyeye odaklanıyoruz.

Korelasyon kimliği ve yapılandırılmış loglama

Bir sipariş web sitesinden ERP’ye giderken birden fazla bileşenden geçer: web uygulaması, outbox yayıncısı, kuyruk, tüketici, ERP bağlayıcısı. Arıza anında “10452 numaralı siparişe ne oldu?” sorusunun yanıtı tek bir aramayla bulunabilmelidir. Beş sunucuda beş ayrı log dosyasını grep’lemek inceleme değil, tahmindir. Bunu sağlayan iki uygulama vardır:

1. Korelasyon kimliği: Akışın başında üretilen bir kimlik (veya iş anahtarı) her mesajla, her HTTP çağrısıyla ve her log satırıyla taşınır. HTTP çağrılarında W3C Trace Context belirtimindeki traceparent başlığı bu iş için standart bir taşıyıcıdır; OpenTelemetry gibi araçlar bu başlığı otomatik yayabilir.
2. Yapılandırılmış log: Log satırları serbest metin yerine sabit alanlı JSON olarak yazılır. Log yönetim aracında alan bazında filtreleme ve sayım böylece mümkün olur.

{
  "ts": "2026-11-10T09:14:22.481Z",
  "level": "error",
  "flow": "siparis-erp",
  "step": "erp_post",
  "correlation_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "business_key": "WEB-10452",
  "attempt": 3,
  "http_status": 422,
  "error_code": "CARI_BULUNAMADI",
  "duration_ms": 812
}

Bu yapıda flow ve step alanları metrik üretiminin, business_key alanı ise destek ekibinin müşteri sorusunu yanıtlamasının temelidir. Kişisel veri (ad, telefon, adres) ve kimlik bilgisi (token, parola) loga yazılmaz; iş anahtarı çoğu inceleme için yeterlidir. Hata ayıklarken açılan “tam gövdeyi logla” ayarı üretimde unutulduğunda log dosyası kişisel veri deposuna dönüşür. Kapatmayı unutmayın.

İzlenmesi gereken entegrasyon metrikleri

Her akış için aşağıdaki metrikler sessiz arızaların büyük kısmını görünür kılar:

Metrik	Neyi yakalar	Kaynak
Son başarılı senkron zamanı	Hiç çalışmayan veya takılan görev	Görev sonunda yazılan zaman damgası
İşlenen kayıt sayısı (akış başına)	Boş dosya, sıfır kayıtlı başarılı çalışma	Görev özeti
Kuyruk derinliği	Tüketici yetişemiyor	Aracı veya kuyruk tablosu
En eski bekleyen mesajın yaşı	Takılı mesaj, yavaş tüketici	Aracı veya kuyruk tablosu
Hata sayısı (kod ve tür bazında)	Kalıcı ve geçici hata artışı	Yapılandırılmış log
Dead-letter kayıt sayısı	Yeniden deneme hakkı tükenen mesajlar	DLQ
Uçtan uca gecikme	Olay ile karşı tarafa yazılma arasındaki süre	Korelasyonlu zaman damgaları

Kuyruk derinliği tek başına yanıltıcıdır: kampanya gününde derin ama hızla akan bir kuyruk sağlıklıdır; sığ ama tek mesajın saatlerdir takılı kaldığı kuyruk değildir. Derinlik ile en eski mesajın yaşını birlikte izleyin. Hata türlerinin sınıflandırılması ve dead-letter kurgusu API hata yönetimi, retry ve backoff rehberinde anlatılıyor.

Alarm eşikleri ve gürültü yönetimi

Her hataya alarm üreten sistem, kısa sürede kimsenin bakmadığı bir sisteme dönüşür. Operatör e-posta kuralı yazar, alarmlar bir klasöre akar, gerçek arıza da onlarla birlikte gider. Alarm tasarımında şu ilkeler işe yarar:

• Belirtiye alarm verin, nedene değil. “ERP API’si bir kez 503 döndü” yerine “sipariş akışında son başarılı aktarım 30 dakikadan eski” gibi iş etkisini gösteren koşullar alarm olmalı. Tekil hatalar loglarda ve panolarda kalır.
• Eşiği iş takvimine göre ayarlayın. Gece hiç sipariş gelmemesi normal olabilir; mesai saatinde bir saat boyunca sıfır sipariş ise ya web sitesinde ya da akışta sorun olduğunu gösterir. Zaman dilimine göre farklı eşik veya beklenen hacim karşılaştırması kullanın.
• Kalıcılık süresi tanımlayın. Koşulun birkaç dakika sürmesini beklemek kısa dalgalanmalardan doğan alarmları ayıklar.
• Metriğin yokluğunu da izleyin. Metriği üreten süreç ölürse eşik koşulu hiç tetiklenmez. “Metrik gelmiyor” ayrı bir alarm olmalı.
• Her alarmın bir sahibi ve kısa bir müdahale notu olsun. Alarm metninde akış adı, olası nedenler ve ilk kontrol adımı yazmalı. Gece üçte alarmı açan kişi neye bakacağını aramamalı.

Prometheus kullanılan bir ortamda “son başarılı senkron” kuralı aşağıdaki gibi yazılabilir. Metrik adı örnektir; görev her başarılı çalışmanın sonunda zaman damgasını yayınlamalıdır. Kural sözdiziminin ayrıntıları Prometheus alerting rules belgesinde yer alır.

groups:
  - name: entegrasyon
    rules:
      - alert: StokSenkronuGecikti
        expr: time() - integration_last_success_timestamp_seconds{flow="stok"} > 1800
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Stok senkronu 30 dakikadır başarıyla tamamlanmadı"
      - alert: StokSenkronuMetrikYok
        expr: absent(integration_last_success_timestamp_seconds{flow="stok"})
        for: 15m
        labels:
          severity: warning

Prometheus olmayan ortamlarda aynı mantık zamanlanmış bir SQL kontrolü ve e-posta/Teams bildirimiyle kurulabilir. Araç ikincildir. Koşul iş sonucunu ölçmeli. Dışarıdan çalışan bir “heartbeat” servisi de kullanılabilir: görev her başarılı çalışmada belirli bir adrese istek gönderir, istek beklenen sürede gelmezse servis alarm üretir. Kaybolan cron tanımını en ucuz yakalayan yöntem budur.

Mutabakat raporu ile veri tutarlılığı kontrolü

Metrikler akışın çalıştığını gösterir; verinin doğru olduğunu ise yalnız iki tarafın karşılaştırılması kanıtlar. Mutabakat (reconciliation), kaynak ve hedef sistemdeki kayıtları periyodik olarak eşleştirip farkları raporlayan iştir. Webhook ve kuyruk tabanlı akışlarda kaçırılan olayları yakalamanın da en güvenilir yoludur; bu desenlerin rolü ERP ile web entegrasyon desenleri yazısında anlatılıyor.

Sipariş akışı için örnek bir mutabakat sorgusu: son 48 saatte web’de oluşturulmuş, ödemesi tamamlanmış ama ERP’den dönen sipariş numarası olmayan kayıtlar. Son 30 dakika, normal işlem gecikmesini dışarıda bırakmak için kapsam dışıdır.

SELECT o.id, o.created_at, o.status
  FROM orders o
  LEFT JOIN erp_order_map m ON m.web_order_id = o.id
 WHERE o.created_at BETWEEN now() - interval '48 hours'
                        AND now() - interval '30 minutes'
   AND o.status NOT IN ('cancelled', 'pending_payment')
   AND m.erp_order_no IS NULL
 ORDER BY o.created_at;

Bu sorgu web tarafının kendi eşleştirme tablosuna güvenir. Daha güçlü kontrol, ERP’den aynı zaman aralığında “web referansı olan siparişler” listesini çekip web’deki listeyle iki yönlü karşılaştırmaktır: web’de olup ERP’de olmayan (kayıp) ve ERP’de iki kez bulunan (mükerrer) kayıtlar ayrı ayrı raporlanır. Stok ve fiyat gibi ana veriler için ürün kodu bazında miktar veya fiyat karşılaştırılır; ürün sayısı yüksekse önce kategori bazında toplamlar karşılaştırılır, yalnız farklı çıkan gruplar satır düzeyinde incelenir.

Farklar için de bir süreç yazın: hangi fark otomatik düzeltilir (örneğin eksik siparişin yeniden kuyruğa alınması), hangisi insan incelemesine düşer, sorumlu kim. Sahibi olmayan fark raporu okunmaz.

Entegrasyon izleme kontrol listesi

• Her akışın adı, sahibi, kaynak ve hedef sistemi, beklenen çalışma sıklığı ve kabul edilebilir en uzun gecikmesi belgelenmiş mi?
• Korelasyon kimliği ve iş anahtarı tüm bileşenlerin loglarında aynı alan adıyla yer alıyor mu?
• Loglar yapılandırılmış biçimde merkezi bir yerde toplanıyor ve kişisel veri içermiyor mu?
• Her akış için son başarılı çalışma zamanı ve işlenen kayıt sayısı metrik olarak yayınlanıyor mu?
• Kuyruk derinliği ile en eski mesaj yaşı birlikte izleniyor mu?
• Metrik yokluğu ayrı bir alarm olarak tanımlı mı?
• Alarmların sahibi, müdahale notu ve iş saatine göre eşikleri var mı?
• Kritik akışlar için periyodik mutabakat raporu çalışıyor ve farksız sonuçlar da kaydediliyor mu?
• Dead-letter kayıtları ve mutabakat farkları için düzeltme süreci tanımlı mı?

Bu listeyi yeni bir entegrasyon devreye alınırken kabul kriteri olarak kullanın; izleme sonradan eklenen bir iş olmaktan çıkar. Webhook tabanlı akışlarda alıcı tarafın göstergeleri için webhook alıcısı tasarımı rehberine de bakabilirsiniz. Entegrasyon akışlarınız için izleme ve alarm kurgusunda web izleme ve uptime monitoring ile ERP, CRM ve API entegrasyonları sayfalarımızdan kapsamı inceleyebilirsiniz.

Sık sorulan sorular

Uptime izlemesi entegrasyon hatalarını neden yakalamaz?

Uptime izlemesi yalnız servisin yanıt verip vermediğini ölçer. Entegrasyon hataları ise çoğunlukla servisler ayaktayken oluşur: görev hiç çalışmaz, mesajlar kuyrukta takılır ya da veri yanlış eşleştirmeyle yazılır. Bunları yakalamak için son başarılı senkron zamanı, işlenen kayıt sayısı ve mutabakat gibi iş seviyesi kontroller gerekir.

Mutabakat raporu ne sıklıkla çalışmalı?

Sıklığı akışın kabul edilebilir en uzun gecikmesi belirler. Sipariş gibi kritik akışlarda saatlik veya günde birkaç kez, ürün kartı gibi ana verilerde günlük ya da haftalık mutabakat çoğu senaryoda yeter. Rapor fark bulmasa da her çalışmada sonucunu kaydetmelidir.

Korelasyon kimliği ile iş anahtarı arasındaki fark nedir?

Korelasyon kimliği, tek bir akış çalışmasını veya isteği bileşenler arasında izlemek için üretilen teknik bir kimliktir. İş anahtarı ise sipariş numarası gibi iş tarafının tanıdığı değerdir. İkisi birlikte loglanır; teknik ekip korelasyon kimliğiyle, destek ekibi iş anahtarıyla arar.

Alarm gürültüsü nasıl azaltılır?

Tekil teknik hatalar yerine iş etkisini gösteren koşullara alarm tanımlanır, koşulun bir süre devam etmesi beklenir ve eşikler iş saatlerine göre ayarlanır. Her alarmın bir sahibi ve müdahale notu olur. Uzun süredir aksiyon alınmayan alarmlar gözden geçirilip ya düzeltilir ya da kaldırılır.