Entegrasyon İzleme: Senkronizasyon Hatalarının Gelire Maliyet Olmadan Önce Tespit Edilmesi

En pahalı entegrasyon hatası kimsenin fark etmediği başarısızlıktır. Bir web kancası uç noktası, Cuma öğleden sonra etkinlik almayı sessizce durdurur. Pazartesi sabahı itibarıyla 200 sipariş ithal edilmedi, stoklar tüm kanallarda 48 saattir eski durumda ve müşteriler Cumartesi günü tükenen ürünler için "stokta" vaatleri alıyor.

Bu senaryo herkesin kabul ettiğinden daha sık gerçekleşir. Entegrasyon izleme, 30 saniyelik bir uyarı ile Pazartesi sabahı krizi arasındaki farktır. Her çok kanallı entegrasyon, e-Ticaret veri senkronizasyonunun belirli hata modları için tasarlanmış sağlık kontrollerine, hata sınıflandırmasına, yeniden deneme mantığına ve uyarılara ihtiyaç duyar.

Önemli Çıkarımlar

• Yalnızca çalışma süresini değil, veri tazeliğini de izleyin — olay almayı bırakan çalışan bir sistem, temel durum kontrollerine göre sağlıklı görünüyor
• Hataları, doğru yanıta yönlendirmek için önem derecesine ve kurtarılabilirliğe göre kategorilere ayırın (otomatik yeniden deneme veya manuel düzeltme)
• Geçersiz mektup kuyrukları, zehirli mesajların tüm boru hattınızı engellemesini önler
• Yalnızca teknik ölçümler (CPU, bellek) değil, iş etkisi ölçümleri (içe aktarılmayan siparişler, envanter kayması) hakkında uyarı

---

Neler İzlenmeli

Entegrasyon izleme üç katmanı kapsar: altyapı durumu, veri akışı durumu ve iş sonucu durumu.

Altyapı Sağlığı

Veri Akışı Durumu

İş Sonuç Sağlığı

---

Hata Sınıflandırması

Tüm hatalar eşit değildir. Geçici ağ zaman aşımı yeniden denemede kendi kendine çözülür. Bir veri doğrulama hatası insan araştırması gerektirir. Hız sınırı hatasının geri alınması gerekir. Hataların doğru şekilde sınıflandırılması yanıtı belirler.

Hata Türünden Çözüm Stratejisine

Hata Zenginleştirme

Ham hataları teşhis etmek zordur. Her hatayı bağlamla zenginleştirin:

• Zaman damgası: Hatanın oluştuğu zaman (UTC)
• Kanal: Hangi pazaryeri veya sistem
• İşlem: Ne yapılıyordu (ithalat siparişi, envanteri güncelleme, ürünü listeleme)
• Varlık: Belirli sipariş kimliği, SKU veya etkilenen müşteri
• İstek/yanıt: Başarısız olan API isteği ve alınan yanıt
• Yeniden deneme sayısı: Bunun kaç kez yeniden denendiği
• Korelasyon Kimliği: İlgili işlemleri hizmetler arasında birbirine bağlayan benzersiz bir kimlik

---

Stratejileri Yeniden Deneyin

Yeniden denemeler, geçici arızaları otomatik olarak ele alır, ancak kötü tasarlanmış yeniden deneme mantığı işleri daha da kötüleştirir; sorunlu bir API'yi yeniden denemelerle zorlamak, kurtarılabilir bir sorunu kesintiye dönüştürebilir.

Jitter ile Üstel Gerileme

Standart yaklaşım: senkronize yeniden deneme fırtınalarını önlemek için rastgele titreşimle yeniden denemeler arasında giderek daha uzun süre bekleyin.

Bütçeyi Yeniden Dene

Hata türü başına maksimum yeniden deneme sayısını ve maksimum yeniden deneme aralığını ayarlayın. 30 dakika içinde 5 kez başarısız olan bir siparişin içe aktarımı, yeniden denemeyi bırakmalı ve inceleme için teslim edilemeyen iletiler kuyruğuna taşınmalıdır. Sınırsız yeniden deneme, kaynakları boşa harcar ve kalıcı sorunları maskeler.

Devre Kesici Modeli

Bir kanal API'si sürekli olarak hata döndürdüğünde, devre kesici istek göndermeyi geçici olarak durdurur. Bu, sisteminizin kapalı bir hizmet için kaynak israfını önler ve hizmetin iyileşmesi için zaman tanır.

• Kapalı (normal): İstekler iletilir. Hata oranını takip edin.
• Açık (tetiklendi): Tüm istekler, API çağrılmadan hemen başarısız olur. Periyodik olarak kontrol edilir.
• Yarı açık (test): Hizmetin kurtarılıp kurtarılmadığını test etmek için bir isteğin geçmesine izin verin. Başarılı olursa devreyi kapatın. Başarısız olursa yeniden açın.

Hata oranı 60 saniyelik bir pencerede %50'yi aştığında devre kesiciyi açın. Kurtarma işlemini her 30 saniyede bir test edin.

---

Geçersiz Mektup Sıraları

Tüm yeniden denemelerde başarısız olan olaylar, geçersiz iletiler kuyruğuna (DLQ) taşınır. DLQ iki amaca hizmet eder: Zehirli mesajların ana hattı engellemesini önler ve başarısız olayları araştırma ve manuel olarak yeniden işleme için korur.

DLQ Yönetimi

• Günlük inceleme: Her iş gününde DLQ girişlerini incelemesi için birini atayın. Girişlerin çoğu düzeltilebilecek ve yeniden işlenebilecek veri sorunlarıdır.
• Örüntüleri kategorilere ayırın: Aynı hata türü tekrar tekrar görünüyorsa, olayları tek tek yeniden işlemek yerine temel nedeni düzeltin.
• Saklama politikası: DLQ girişlerini 30 gün boyunca saklayın. 30 gün sonra uyumluluk için soğuk depoya arşivleyin ancak etkin kuyruktan kaldırın.
• Yeniden işleme araçları: Operatörlerin, temel sorunu düzelttikten sonra tek bir DLQ girişini veya bir grup girişi yeniden işlemesine olanak tanıyan bir araç oluşturun.

DLQ Metrikleri

DLQ sağlığı için şu ölçümleri izleyin:

• Giriş hızı: Saatte DLQ'ya kaç olayın girdiği. Ani yükselişler sistematik bir soruna işaret ediyor.
• Yaşlanma: Olayların çözümlenmeden önce DLQ'da ne kadar süre kaldığı. Yaşlanma olayları çözülmemiş sorunları temsil eder.
• Çözünürlük oranı: DLQ olaylarının yüzde kaçı başarıyla yeniden işlendi, manuel olarak çözümlendi ve terk edildi.

---

Uyarıcı Tasarım

Uyarılar eyleme dönüştürülebilir, bağlamsal olmalı ve doğru kişiye yönlendirilmelidir. Günde 50 kez tetiklenen bir uyarı dikkate alınmaz. Birisini kritik olmayan bir sorun nedeniyle uyandıran bir uyarı, sisteme olan güveni zedeler.

Uyarı Önem Düzeyleri

Uyarı Yorulma Önleme

• İlgili uyarıları birleştirin: 50 ayrı "sipariş içe aktarma başarısız" uyarısı, tek bir "sipariş içe aktarma hatasında ani artış: 15 dakikada 50 hata" uyarısında birleştirilmelidir.
• Geçici sorunları otomatik çözme: Bir P2 uyarısı 5 dakika içinde çözülürse (devre kesici devreye girer, kanal kurtarılır), P4'e düşürün ve yükseltme yerine günlüğe kaydedin.
• Bakım pencereleri: Kanallarda veya kendi altyapınızda planlı bakım sırasında uyarıları bastırın.
• Runbook'lar: Her uyarı, uyarının ne anlama geldiğini, olası nedenlerini ve adım adım çözüm talimatlarını açıklayan bir runbook'a bağlanmalıdır.

---

Kontrol Panelleri ve Görünürlük

Bir izleme panosu, operasyon ekipleri, yönetim ve mühendislik için entegrasyon durumuna ilişkin bir bakışta görünürlük sağlar.

Önerilen Kontrol Paneli Panelleri

Genel bakış paneli: Kanal başına yeşil/sarı/kırmızı durum göstergesi. Yeşil = SLA dahilinde senkronizasyon. Sarı = bozulmuş (gecikmeli veya yüksek hatalar). Kırmızı = aşağı (eşik penceresinde senkronizasyon yok).

Sipariş akış paneli: Geçen haftanın aynı saatiyle karşılaştırıldığında kanal başına saat başına içe aktarılan siparişlerin gerçek zamanlı sayısı. Ani bir düşüş bir soruna işaret eder.

Envanter tazelik paneli: Kanal başına son başarılı envanter senkronizasyonundan bu yana geçen süre. Çalışma saatleri içinde 10 dakikayı aşan her şey sarıdır; 30 dakikanın üzerinde süre kırmızıdır.

Hata eğilimi paneli: Son 24 saatte türe göre hata sayısı. Yeni hata türlerini ve trend olan sorunları vurgular.

DLQ paneli: Mevcut DLQ derinliği ve yaşlanma dağılımı. 1 saatten kısa, 1-24 saatten eski ve 24 saatten uzun girişlerin sayısı.

Mutabakat paneli: SKU'ya göre sapmayı gösteren son mutabakat sonuçları. İlk önce en büyük sürüklenmeye göre sıralanır.

Daha geniş entegrasyon mimarisi için sütun gönderisine bakın: The Ultimate e-Commerce Integration Guide.

---

SLA İzleme

Entegrasyonunuzun temel veri akışları için SLA'ları tanımlayın ve izleyin.

SLA uyumluluğunu yüzde olarak izleyin (hedef: %99,5 veya daha yüksek) ve aylık olarak inceleyin. Kalıcı SLA eksiklikleri, yatırım gerektiren kapasite veya mimari sorunlarına işaret eder.

Bu SLA'ların bağlı olduğu envanter senkronizasyon mimarisine ilişkin ayrıntılar için bkz. Gerçek Zamanlı Envanter Senkronizasyon Mimarisi.

---

Sıkça Sorulan Sorular

E-Ticaret entegrasyonları için hangi izleme araçları en iyi sonucu verir?

Altyapı izleme için Datadog, New Relic veya Grafana + Prometheus standart seçeneklerdir. Uygulama düzeyinde izleme (hata izleme, istek izleme) açısından Sentry, Node.js/Python yığınları için mükemmeldir. Sıra izleme için BullMQ'nun yerleşik bir kontrol paneli (Bull Board) vardır ve RabbitMQ'nun yönetim kullanıcı arayüzü vardır. Önemli olan hangi aracı kullandığınız değil; önemli olan üç katmanın tamamını (altyapı, veri akışı, iş sonuçları) tutarlı bir şekilde izlemenizdir.

Göndereni kontrol etmezsem webhook güvenilirliğini nasıl izlerim?

Bir pazar yerinin web kancaları gönderip göndermediğini doğrudan izleyemezsiniz. Bunun yerine beklenen olayların yokluğunu izleyin. Shopify mağazanız genellikle saatte 10 sipariş web kancası alıyorsa ve siz 2 saat boyunca sıfır sipariş alıyorsanız uyarı verin. Bu "negatif izleme"dir; hataların varlığından ziyade beklenen etkinliğin yokluğunun tespit edilmesidir.

Entegrasyon işlemi için kabul edilebilir hata oranı nedir?

%0,5'in altı mükemmel. %0,5 ila %2 arası kabul edilebilir ancak araştırmayı gerektirir. %2'nin üzeri sistematik bir soruna işaret eder; büyük olasılıkla bir eşleme sorunu, API değişikliği veya kaynakta veri kalitesi sorunu. Sorunları hızlı bir şekilde tespit etmek için kanal başına ve işlem türüne göre hata oranlarını izleyin.

Özel izleme oluşturmalı mıyım yoksa yönetilen bir hizmet mi kullanmalıyım?

Uygulama hızı için yönetilen hizmetlerle (Datadog, Sentry) başlayın. Genel araçların hemen kapsamadığı, işletmeye özel ölçümler (sipariş akışı, envanter güncelliği, SLA uyumluluğu) için özel kontrol panelleri oluşturun. İş katmanı izleme, en fazla değeri elde ettiğiniz ve genel araçların yetersiz kaldığı yerdir.

Pazar yerindeki kesintiler sırasında izlemeyi nasıl halledebilirim?

Pazar yerindeki kesintiler (Amazon API'sinin bozulması, Shopify platform sorunları) kontrolünüz dışındadır. İzlemeniz "sistemimiz bozuk" ile "piyasa çökmüş" arasındaki ayrımı yapmalıdır. Pazar yeri durum sayfalarını programlı olarak kontrol edin (ör. Amazon'un SHD'si, Shopify'ın durum sayfası) ve harici kesintiler sırasında kontrol panellerinize açıklamalar ekleyin. Bilinen dış sorunlarla karşılaşan kanallar için uyarıları bastırın.

---

Sırada Ne Var

İzleme, gönderip unutacağınız bir özellik değildir. Entegrasyonunuzla birlikte gelişen bir uygulamadır. Kanal ekledikçe, hacmi artırdıkça ve yeni arıza modlarıyla karşılaştıkça, izlemeniz bunları kapsayacak şekilde artmalıdır. Yatırım, ilk kez 30 saniyelik bir uyarının hafta sonu sürecek bir kesintiyi önlediği anda kendini amorti ediyor.

Odoo ile üretime hazır entegrasyon izleme için ECOSIRE entegrasyon hizmetlerini keşfedin veya mevcut entegrasyon gözlemlenebilirlik boşluklarınızı değerlendirmek için ekibimizle iletişime geçin.

---

ECOSIRE tarafından yayınlandı — işletmelerin Odoo ERP, Shopify eCommerce ve OpenClaw AI genelinde yapay zeka destekli çözümlerle ölçeklenmesine yardımcı oluyor.