API Sağlık Kontrolü

Genel Bakış

7/24 İzleme

API'lerinizin erişilebilirliğini sürekli izleyin

Performans Metrikleri

Yanıt süreleri ve başarı oranlarını takip edin

Erken Uyarı

Sorunları kullanıcılar etkilenmeden önce tespit edin

Otomatik Bildirimler

Hızlı müdahale için anında bildirim alın

API Sağlık Kontrolü Nedir?

Temel Kavram

API Sağlık Kontrolü, belirlediğiniz bir API endpoint'ine veya web servisine belirli aralıklarla otomatik olarak test istekleri gönderen bir izleme sistemidir.

Ne Zaman Kullanılır?

Kritik API İzleme

Ödeme, kimlik doğrulama gibi kritik API'lerin sürekli izlenmesi

SLA Takibi

Servis seviyesi anlaşmalarının takibi ve raporlanması

Performans İzleme

API yanıt sürelerinin izlenmesi ve trend analizi

Uptime Monitoring

Servislerin çalışma süresi (uptime) takibi

Nasıl Çalışır?

Yapılandırma

Kontrol edilecek URL, HTTP metodu, beklentiler ve zamanlama belirlenir

Zamanlama

Belirlenen zamanlarda (örn: her 5 dakikada bir) otomatik olarak test isteği gönderilir

Test Çalıştırma

HTTP isteği gönderilir ve yanıt alınır

Doğrulama

Beklentiler (assertion'lar) kontrol edilir:

• Yanıt süresi kontrolü
• HTTP durum kodu kontrolü
• Yanıt içeriği kontrolü
• XPath/JSONPath kontrolleri

Sonuç Kaydetme

Test sonucu kaydedilir (başarılı/başarısız)

Bildirim

Eğer test başarısız olursa, yapılandırılmış bildirimler tetiklenir

Hızlı Başlangıç

İlk Sağlık Kontrolünüzü Oluşturma

Menüden Erişim

Administration → Monitoring → Uptime Monitor menü girişine tıklayın (doküman başlığı: API Sağlık Kontrolü)

Yeni Kontrol Oluştur

"Yeni Oluştur" butonuna tıklayın

Temel Bilgileri Doldurun

• Ad: Kontrolünüz için bir isim (örn: "Ödeme API Kontrolü")
• Açıklama: İsteğe bağlı açıklama

İstek Bilgilerini Girin

• HTTP Metodu: GET, POST, vb.
• URL: Test edilecek API endpoint'i

Zamanlama Ayarlayın

Kontrol sıklığını belirleyin (örn: Her 5 dakikada bir)

Kaydet

"Kaydet" butonuna tıklayın

Yeni Sağlık Kontrolü Oluşturma

Adım 1: Temel Bilgiler

Ad - Zorunlu

Sağlık kontrolü için benzersiz bir isim girin. Bu isim:

• Proje içinde benzersiz olmalıdır — aynı isimle ikinci bir sağlık kontrolü kaydedilemez, aynı isim başka bir projede kullanılabilir
• Boşlukla başlayamaz
• Sistem otomatik olarak ismin kullanılabilirliğini kontrol eder

İsim yalnızca değiştirildiğinde yeniden denetlenir. İsmi aynı kalan bir sağlık kontrolü her zaman kaydedilebilir; bu nedenle aynı projede aynı ismi taşıyan iki kontrol varsa — daha eski bir sürümden yükseltilmiş kurulumlarda ya da özgün ismi korunarak içe aktarılan kontrollerde mümkündür — ikisi de düzenlenebilir kalır, birini yeniden adlandırarak tekrarı giderebilirsiniz.

Bir ismin yalnızca harf büyüklüğünü değiştirmek, düzenlediğiniz kaydın tekrarı sayılmaz: Ödeme API İzleme ismini ödeme api izleme olarak değiştirmek kabul edilir ve kaydedilebilir.

İyi İsim Örnekleri:

• Ödeme API İzleme
• Kullanıcı Servisi Health Check
• Üçüncü Taraf Entegrasyon Kontrolü
• Ana Sayfa Erişilebilirlik Kontrolü

Açıklama - Opsiyonel

Sağlık kontrolü hakkında açıklayıcı bilgi girebilirsiniz:

• Maksimum 1000 karakter
• Maksimum 1000 karakter
• Kontrolün amacını ve kapsamını açıklamak için kullanılır
• Liste sayfasında görüntülenir

Örnek Açıklamalar:

• Kritik ödeme API'sinin 7/24 izlenmesi için oluşturulmuştur
• Müşteri portalı ana sayfa erişilebilirlik kontrolü
• Üçüncü taraf servis sağlayıcı entegrasyonu izleme

Durum (Status) - Varsayılan: Aktif

Sağlık kontrolünün aktif/pasif durumunu belirler:

• Aktif: Kontrol çalışır, zamanlanmış testler gönderilir
• Pasif: Kontrol durdurulur, test gönderilmez (geçmiş veriler korunur)

Adım 2: Zamanlama Ayarları

Sağlık kontrolünün ne sıklıkla çalışacağını belirleyin. Cron Expression kullanarak zamanlama yapılır.

Yaygın Zamanlama Örnekleri

Açıklama	Cron Expression	Kullanım Senaryosu
Her 5 dakikada bir	0 */5 * ? * *	Kritik API'ler için (en yaygın)
Her 15 dakikada bir	0 */15 * ? * *	Normal API'ler için
Her saat başı	0 0 * ? * *	Test/Development ortamları için
Her gün saat 09:00	0 0 9 * ? *	Günlük raporlama için
Her hafta Pazartesi 09:00	0 0 9 ? * MON	Haftalık kontrol için

ipucu

Öneriler:

• Kritik API'ler için: Her 5 dakikada bir
• Normal API'ler için: Her 15-30 dakikada bir
• Test/Development için: Her saat başı
• Raporlama amaçlı kontroller için: Günlük veya haftalık

Bakım Penceresi (Maintenance Window)

Planlı kesintiler için isteğe bağlı bir bakım penceresi (başlangıç ve bitiş saati, örn. 02:00–03:00) tanımlayabilirsiniz. Pencere her gün aynı saatlerde tekrar eder. Başlangıç saati pencereye dahildir, bitiş saati dahil değildir; bitiş saati başlangıçtan önceyse pencere gece yarısını geçer (örn. 23:00–01:00 gece 23:00'dan gece 01:00'e kadar geçerlidir). Başlangıç ve bitiş aynı saat olarak girilirse veya yalnızca biri doldurulursa bakım penceresi tanımlı sayılmaz.

Saat alanlarının yanında isteğe bağlı bir saat dilimi alanı vardır — bölge kimliği (örn. Europe/Istanbul) veya ofset (örn. +03:00) girilebilir; boş bırakılırsa sunucunun saat dilimi kullanılır.

Bu aralıktayken kontroller çalışmaya devam eder ve sonuçlar kaydedilir, ancak hata bildirimleri bastırılır; pencere kapandıktan sonraki ilk başarısız kontrol normal şekilde bildirilir. Bakım penceresi içindeki bir kontrol, listelerde ve Genel Bakış'taki sayımlarda Çalışıyor/Kapalı yerine ayrı bir Bakımda durumuyla gösterilir. Çalışma oranı (uptime%) ve servis seviyesi (SLA) hesaplamaları bu penceredeki kontrolleri de kapsamaya devam eder — bakım penceresi ölçümü silmez, yalnızca bildirimi durdurur. İhtiyacınız yoksa alanları boş bırakın.

Servis Seviyesi (SLA) Ayarları

Kontrolün sağlık durumunu yalnızca Çalışıyor/Erişilemiyor yerine Performans Düşüşü (Degraded) olarak da sınıflandırmanızı sağlayan isteğe bağlı eşik değerleri:

• Bildirim eşiği (Alert after): Kontrolün "erişilemiyor" sayılması için gereken ardışık başarısızlık sayısı (tek seferlik geçici bir hatada bildirim gitmesini önler)
• Yanıt süresi bütçesi (p95): 95. yüzdelik dilim yanıt süresi bu değerin üzerine çıkarsa kontrol Performans Düşüşü olarak işaretlenir. Devre dışı bırakmak için boş bırakın.
• Hedef çalışma oranı (Target uptime): Çalışma oranı bu yüzdenin altına düşerse kontrol Performans Düşüşü olarak işaretlenir. Devre dışı bırakmak için boş bırakın.

Adım 3: İstek Ayarları

Bu bölümde test edilecek endpoint'in bilgilerini yapılandırırsınız.

Koleksiyondan Seçin (Select From Collection) - Önerilen

Daha önce Test Console'da oluşturduğunuz test senaryolarını kullanabilirsiniz:

Butona Tıklayın

"Koleksiyondan Seçin" butonuna tıklayın

Koleksiyonu Seçin

Açılan dialog'da test koleksiyonlarınızı görüntüleyin

Senaryoyu Seçin

İstediğiniz test senaryosunu seçin

Otomatik Doldurma

Test bilgileri otomatik olarak formu doldurur

bilgi

Avantajları:

• Zaman kazanırsınız
• Tutarlı test senaryoları kullanırsınız
• Test senaryolarınızı merkezi olarak yönetebilirsiniz

HTTP Metodu (Method) - Zorunlu

HTTP istek metodunu seçin:

GET

Veri okuma (en yaygın kullanılan)

POST

Veri gönderme

PUT

Veri güncelleme

DELETE

Veri silme

PATCH

Kısmi güncelleme

HEAD

Sadece header bilgisi

URL - Zorunlu

Test edilecek endpoint'in tam URL'ini girin:

Örnekler:

• https://api.example.com/users
• https://api.example.com/payment/verify
• http://localhost:8080/health
• https://api.example.com/v1/products?category=electronics

uyarı

Notlar:

• URL mutlak (absolute) olmalıdır
• HTTPS ve HTTP desteklenir
• Query parametreleri URL'ye eklenebilir veya ayrı bir alanda belirtilebilir

Parametreler (Parameters) - Opsiyonel

URL'ye query parametreleri eklemek için kullanılır:

Örnek:

• Parametre Adı: userId
• Parametre Değeri: 12345

Sonuç URL: https://api.example.com/users?userId=12345

Başlıklar (Headers) - Opsiyonel

HTTP isteğine header eklemek için kullanılır:

Yaygın Kullanımlar:

• Authorization: Bearer token123 veya Basic base64encoded
• Content-Type: application/json, application/xml
• X-API-Key: your-api-key
• Custom Headers: Özel header'lar

Örnek:

• Başlık Adı: Authorization
• Başlık Değeri: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Gövde (Body) - POST/PUT/PATCH için

İstek gövdesi (request body) girebilirsiniz:

Desteklenen Formatlar:

• Raw: JSON, XML, Text
• Form URL Encoded: Form verileri

JSON Örneği:

{
    "userId": 12345,
    "action": "verify",
    "timestamp": "2024-01-15T10:30:00Z"
}

XML Örneği:

<request>
    <userId>12345</userId>
    <action>verify</action>
</request>

Adım 4: Doğrulama Ayarları

Doğrulama (Assertion) ayarları, test sonucunun başarılı sayılması için gerekli kontrolleri belirler.

Zamanaşımı Kontrolü (Timeout Assertion)

Bu seçenek aktif edildiğinde, belirlenen zamanaşımı değeri doğrulama için de kullanılır:

• İstek belirlenen süre içinde yanıtlanmalıdır
• Aksi halde test başarısız sayılır

HTTP Durum Kodu Kontrolü (Status Code Assertion)

HTTP status code kontrolü yapmak için:

Toggle'ı Aktif Edin

"Sonuç Durum Kodu" toggle'ını aktif edin

Status Code Girin

"Beklenen Durum Kodu" alanına beklenen status code'u girin

Varsayılan Değer: 200 (OK)

Yaygın Status Code'lar:

• 200: Başarılı
• 201: Oluşturuldu
• 204: İçerik yok
• 400: Hatalı istek
• 401: Yetkisiz
• 404: Bulunamadı
• 500: Sunucu hatası

Örnek Senaryo:

• Beklenen Status Code: 200
• Gerçek Status Code: 200 → ✅ Başarılı
• Gerçek Status Code: 500 → ❌ Başarısız

Yanıt Gövdesi Kontrolü (Body Assertion)

Response body'nin belirli bir içerik içerip içermediğini kontrol eder:

Toggle'ı Aktif Edin

"Sonuç Gövdesi" toggle'ını aktif edin

İçerik Girin

"Beklenen Sonuç Gövdesi" alanına beklenen içeriği girin

Kullanım Senaryoları:

• Response'ta belirli bir metin olmalı: "status": "success"
• Response belirli bir değer içermeli: "active": true
• Response boş olmamalı

Örnek:

• Beklenen: "status": "ok"
• Gerçek: {"status": "ok", "data": {...}} → ✅ Başarılı
• Gerçek: {"status": "error"} → ❌ Başarısız

XPath Kontrolü (XPath Assertion) - XML için

XML response'larda XPath kullanarak kontrol yapar:

Toggle'ı Aktif Edin

"XPath Sonucu" toggle'ını aktif edin

XPath Girin

XPath alanına XPath ifadesini girin

Beklenen Değeri Girin

Beklenen XPath Sonucu alanına beklenen değeri girin

Örnek:

• XPath: /response/status
• Beklenen Sonuç: success
• Gerçek XML: <response><status>success</status></response> → ✅ Başarılı

JSONPath Kontrolü (JSONPath Assertion) - JSON için

JSON response'larda JSONPath kullanarak kontrol yapar:

Toggle'ı Aktif Edin

"JsonPath Sonucu" toggle'ını aktif edin

JSONPath Girin

JsonPath alanına JSONPath ifadesini girin

Beklenen Değeri Girin

Beklenen JsonPath Sonucu alanına beklenen değeri girin

Örnek:

• JSONPath: $.status
• Beklenen Sonuç: ok
• Gerçek JSON: {"status": "ok", "data": {...}} → ✅ Başarılı

Yaygın JSONPath Örnekleri:

• $.status: Root'taki status alanı
• $.data.items[0].id: İlk item'ın id'si
• $.user.name: User objesinin name alanı
• $.results[*].id: Tüm result'ların id'leri

Adım 5: Ayarlar

Zamanaşımı (Timeout) - Varsayılan: 30 saniye

İstek için maksimum bekleme süresini belirler:

• Saniye cinsinden girilir
• Varsayılan değer: 30 saniye
• Bu süre içinde yanıt alınamazsa test başarısız sayılır

ipucu

Öneriler:

• Hızlı API'ler için: 10-15 saniye
• Normal API'ler için: 30 saniye
• Yavaş API'ler için: 60 saniye veya daha fazla

SSL Sertifikası (Enable Certificate)

HTTPS isteklerinde SSL sertifikası kullanmak için:

• Bu seçenek aktif edildiğinde, özel SSL sertifikası kullanılabilir
• Genellikle self-signed sertifikalar veya özel CA sertifikaları için kullanılır

Adım 6: Yeniden Deneme Ayarları (Retry Settings)

Geçici sorunlarda otomatik yeniden deneme yapmak için:

Başarısızsa Yeniden Dene (Retry On Fail)

Toggle'ı Aktif Edin

"Başarısızsa Yeniden Dene" toggle'ını aktif edin

Sayı Seçin

"Yeniden Deneme Sayısı" seçin: 1, 3, 5, veya 10

Nasıl Çalışır:

• İlk istek başarısız olursa
• Belirlenen sayı kadar tekrar denenir
• Her deneme arasında bekleme yapılabilir (opsiyonel)

Örnek Senaryo:

• Yeniden Deneme Sayısı: 3
• İlk istek başarısız → 1. yeniden deneme → başarısız → 2. yeniden deneme → başarısız → 3. yeniden deneme → başarılı → ✅ Başarılı

İstekler Arası Bekleme (Delay Between Requests)

Yeniden denemeler arasında bekleme yapmak için:

Toggle'ı Aktif Edin

"İstekler Arası Bekleme" toggle'ını aktif edin

Bekleme Süresi Girin

"Bekleme" alanına saniye cinsinden bekleme süresini girin

Varsayılan Değer: 3 saniye

Kullanım Senaryosu:

• Sunucu yükünü azaltmak için
• Rate limiting'den kaçınmak için
• Geçici sorunların çözülmesi için zaman tanımak

Örnek:

• Yeniden Deneme Sayısı: 3
• Bekleme: 5 saniye
• İlk istek başarısız → 5 sn bekle → 1. yeniden deneme → başarısız → 5 sn bekle → 2. yeniden deneme → başarılı

Adım 7: Bildirim Alıcıları (Recipients)

Test başarısız olduğunda tetiklenecek bildirimleri yapılandırın:

Bildirim Ekleme

Bildirim Ekle

Recipients tablosunda "+" butonuna tıklayın

Bildirim Türünü Seçin

Bildirim türünü seçin:

• Email: Email bildirimi gönderir
• Webhook: HTTP POST isteği gönderir
• Slack: Slack kanalına mesaj gönderir
• SMS: SMS bildirimi gönderir
• Ve daha fazlası...

Yapılandırmayı Tamamlayın

Bildirim yapılandırmasını tamamlayın

Bildirim Yönetimi:

• Düzenle: Bildirim bilgilerini güncellemek için menüden "Düzenle" seçin
• Sil: Bildirimi kaldırmak için menüden "Sil" seçin
• Aktif/Pasif: Toggle ile bildirimi aktif/pasif yapabilirsiniz

Bildirim İçeriği: Bildirimlerde şu bilgiler gönderilir:

• Sağlık kontrolü adı
• Proxy adı (varsa)
• Hedef URL
• Hata mesajı
• Zaman damgası
• Test sonucu detayları

Adım 8: Kaydetme

Tüm bilgileri doldurduktan sonra:

Validasyon Kontrolü

Form validasyonlarının geçtiğinden emin olun:

• ✅ Ad girilmiş ve kullanılabilir
• ✅ URL girilmiş
• ✅ Zamanlama ayarları yapılmış
• ✅ En az bir assertion aktif (önerilir)

Kaydet

"Kaydet" butonuna tıklayın

Yönlendirme

Sağlık kontrolü kaydedildikten sonra otomatik olarak listeleme sayfasına yönlendirilirsiniz

Sağlık Kontrolü Yönetimi

Liste sayfası Overview ve All monitors olmak üzere iki sekmeden oluşur.

Overview Sekmesi

• Özet kartları: Çalışır durumdaki (Operational), performansı düşmüş (Degraded) ve erişilemeyen (Down) kontrol sayıları ile son 24 saatteki genel çalışma oranı (global uptime). Bakım penceresi içindeki kontroller bu sayımların hiçbirine girmez; kaç kontrolün bakımda olduğu ayrı bir satırda gösterilir (örn. "3 monitör bakım penceresinde (Çalışıyor veya Kapalı sayımına girmez)")
• Servis seviyesi (SLA): Hedef çalışma oranı tanımlanmış kontrollerden kaçının bu hedefi karşılamadığını özetler; hedefi karşılamayan her kontrol için ad ve durum (kritik/performans düşüşü) listelenir
• Yanıt süresi grafiği: Tüm kontrollerin p50/p95/p99 yanıt sürelerini zaman içinde gösterir
• Dikkat gerektirenler: Şu anda erişilemeyen veya performansı düşmüş kontrolleri, ne zamandır bu durumda olduklarıyla birlikte listeler; bakım penceresindeki kontroller bu listede görünmez

All Monitors Sekmesi

Bu sekme tüm sağlık kontrollerini tablo halinde listeler:

Arama ve Filtreleme

• Ad arama: Kontrol adına göre arama yapabilirsiniz
• Durum filtre çipleri: All / Up / Degraded / Down / Bakımda / Paused — kontrolleri anlık duruma göre daraltır; Bakımda yalnızca o anda bakım penceresi içinde olan kontrolleri listeler
• Proje Filtresi (Admin modunda): Birden fazla projeden kontrolleri görüntüleyebilirsiniz

Tablo Sütunları

• Monitor: Durum noktası + ad (tıklanabilir, Detay sayfasına gider) + HTTP metodu ve URL; pasif kontroller "Paused" rozetiyle, bakım penceresi içindeki kontroller mavi BAKIM rozetiyle işaretlenir (üzerine gelindiğinde "kontroller çalışmaya devam eder, pencere kapanana kadar hata bildirimleri gönderilmez" açıklaması görünür)
• Son 24 saat: Çalıştırma sonuçlarını gösteren bar grafiği
• Uptime: Son 24 saatteki çalışma oranı (%)
• SLA: Servis seviyesi tanımlıysa hedefi karşılıyor/karşılamıyor rozeti ve hedef değeri
• Ort. yanıt süresi: Sparkline grafiği ile birlikte ortalama yanıt süresi (ms)
• Son kontrol: En son kontrolün ne zaman yapıldığı
• Proje (Admin modunda): Kontrolün ait olduğu proje
• İşlemler: Menü butonu (⋮)

İşlemler Menüsü

Her kontrol için menü butonuna (⋮) tıklayarak şu işlemleri yapabilirsiniz:

1. Detay: Kontrolün sonuçlarını ve yapılandırmasını görüntüle
2. Etkinleştir / Devre Dışı Bırak (Activate/Deactivate): Kontrolü aktif/pasif yap
3. Düzenle: Kontrol ayarlarını güncelle
4. Çoğalt: Kontrolün kopyasını oluştur
5. Sil: Kontrolü sil
6. Global'e Taşı (Proje kontrolü ise): Kontrolü global projeye taşı

Durum Değiştirme (Activate/Deactivate)

Kontrolün etkin/pasif durumunu değiştirmek için işlemler menüsünden (⋮) Etkinleştir veya Devre Dışı Bırak'ı seçin. Aynı işlem Detay ekranının üst barındaki Activate/Deactivate butonundan da yapılabilir. Pasif kontroller çalışmaz, ancak geçmiş verileri korunur.

not

Ayrı bir "Görüntüle (View)" ekranı kaldırılmıştır; kontrol adına tıklandığında doğrudan Detay sayfası açılır.

Detay Sayfası

Kontrol adına tıklandığında açılan Detay sayfası, kontrolün sonuçlarını ve yapılandırmasını tek ekranda gösterir.

not

Detay sayfasından Düzenle'ye girildiğinde Geri veya Kaydet işlemi sizi aynı kaydın Detay sayfasına geri döndürür; Detay sayfasındaki Geri düğmesi ise her zaman izleme listesine gider.

Üst Bölüm

• Tarih aralığı seçici ve hızlı aralık seçenekleri
• Run now: Kontrolü hemen, zamanlamayı beklemeden bir kez çalıştırır (yönetme yetkisi gerektirir)
• 5 özet metrik kartı: Uptime (24s), Ortalama yanıt süresi, p95 yanıt süresi, Başarısız kontrol sayısı, MTTR (ortalama onarım süresi)
• Uptime zaman çizelgesi: Seçilen aralıktaki her kontrolün durumunu (başarılı/başarısız) gösteren şerit
• Yanıt süresi grafiği: p50/p95/p99 çizgileriyle birlikte

Sekmeler

Check results (Kontrol sonuçları)

Her test çalışmasının detaylı sonuçlarını gösteren tablo:

• İstek Gönderildi: Test isteğinin gönderildiği tarih ve saat
• İstek Tipi: İlk İstek veya Tekrar (yeniden deneme isteği)
• Yanıt Süresi: İsteğin yanıtlanma süresi (milisaniye)
• Teyitler: Yapılan kontroller ve sonuçları (Timeout, Status Code, Result Body, XPath, JSONPath)
• Sonuç: 🟢 Başarılı · 🔴 Başarısız
• Detay: Sonuç detaylarını JSON formatında görüntülemek için göz ikonu (👁️)

Tablo başlığındaki çöp kutusu (🗑️) ikonuyla tüm sonuçlar kalıcı olarak silinebilir.

uyarı

Tüm sonuçları silme işlemi geri alınamaz!

Configuration (Yapılandırma)

Kontrolün salt-okunur tanımı, kartlar ve katlanabilir bölümler halinde gösterilir:

• Monitor definition: Ad, açıklama, durum (Aktif/Pasif)
• Request & assertions: Metot/URL, header özeti, aktif doğrulamaların özeti
• Schedule & SLA: Kontrol sıklığı, zaman aşımı, bakım penceresi (maintenance window) ve saat dilimi, yeniden deneme politikası, kaç ardışık başarısızlıktan sonra bildirim gönderileceği, yanıt süresi bütçesi ve hedef çalışma oranı
• Actions: Bildirim alıcılarının özeti

Altında, kaydedilen isteğin tüm ayrıntılarını gösteren katlanabilir salt-okunur bölümler yer alır:

• Request details: Metot/URL, zaman aşımı, sertifika kullanımı ve seçili sertifika, parametre ve header tabloları, gövde (raw/form-data/URL-encoded)
• Assertions: Aktif edilen tüm doğrulamalar (zaman aşımı, status code, gövde, XPath, JSONPath) ve beklenen değerleri
• Retry: Yeniden deneme ayarı, deneme sayısı ve istekler arası bekleme süresi
• Actions: Bildirim alıcıları tablosu (ad, tip, durum, açıklama)

not

Parametre ve header değerlerinden isim olarak gizli görünenler (ör. Authorization, api-key, token, password, cookie) maskeli gösterilir; adları görünür kalır.

Yetkiler

Sağlık kontrollerine erişim, projedeki rolünüzün İzleme (Monitoring) yetkisiyle belirlenir. Rolünüzün hangi işlemleri taşıdığını Yönetim → Roller altından görebilirsiniz.

• İzleme → Görüntüleme: Sağlık kontrolü listesini, Detay sayfasını ve kontrol sonuçlarını açabilirsiniz. Detay sayfasındaki Yapılandırma sekmesi isteği, beklentileri, yeniden deneme ayarlarını ve bildirim alıcılarını salt okunur gösterir; böylece bir kontrolün ayarlarını değiştiremeden inceleyebilirsiniz.
• İzleme → Yönetme: Yukarıdakilere ek olarak bir kontrolü oluşturabilir, düzenleyebilir, çoğaltabilir ve silebilir, aktif/pasif yapabilir ve Şimdi çalıştır işlemini kullanabilirsiniz. Bu yetki yoksa Yeni ve Düzenle ekranları hiç açılmaz, ilgili işlemler de işlemler menüsünde görünmez.

Bir sağlık kontrolü her zaman oluşturulduğu projeye aittir ve kararı o proje verir. Bir kontrolü açmak, değiştirmek, duraklatmak, çalıştırmak veya silmek sahibi olan projedeki İzleme yetkinize göre değerlendirilir; başka bir projede İzleme yetkisi taşımak burada bir şey kazandırmaz.

not

Bildirim alıcıları ve e-posta bağlantıları. Alıcı penceresinde daha önce tanımlanmış bir e-posta bağlantısı seçmek ayrıca Bağlantılar → Görüntüleme, o pencereden yeni bir tane tanımlamak ise Bağlantılar → Yönetme yetkisi ister. Bunlar İzleme'den ayrı yetkilerdir: rolünüzde İzleme varken Bağlantılar yoksa alıcı penceresini açtığınızda bir yetki uyarısı görünür ve kayıtlı e-posta bağlantısı listesi boş kalır. Formun diğer tüm bölümleri çalışmaya devam eder; kontrol üzerinde zaten kayıtlı olan alıcılar her durumda görünür.

uyarı

2026.09.3 ile değişti. İki davranış farklılaştı:

• Rolünde İzleme → Yönetme olup Bağlantılar olmayan kullanıcılar, kontrolü sorunsuz düzenleyip kaydedebildikleri hâlde Düzenle ekranı açılır açılmaz "yetkiniz yok" uyarısı görüyordu. Bu uyarıyı ekranın artık yüklemediği bir arka plan listesi üretiyordu; uyarı kalktı.
• Yeni ve Düzenle ekranları artık İzleme → Yönetme yetkisi ister. Yalnızca İzleme → Görüntüleme yetkisi olan bir rol, daha önce doğrudan bağlantıyla forma ulaşabiliyor ve yetkisi olmadığını ancak kaydederken fark ediyordu.

En İyi Uygulamalar

1. İsimlendirme Kuralları

• Açıklayıcı İsimler Kullanın: Ödeme API Kontrolü gibi net isimler
• Proje/Modül Öneki Ekleyin: E-Ticaret - Ödeme API gibi
• Ortam Bilgisi Ekleyin: Production - Kullanıcı API gibi

2. Zamanlama Stratejisi

• Kritik API'ler: Her 5 dakikada bir kontrol edin
• Normal API'ler: Her 15-30 dakikada bir kontrol edin
• Test Ortamları: Her saat başı kontrol edin
• Sunucu yükünü göz önünde bulundurun

3. Assertion Kullanımı

• En az bir assertion kullanın (Status Code önerilir)
• Timeout assertion'ı mutlaka aktif edin
• Body assertion'larını dikkatli kullanın (değişken içerik varsa)
• JSONPath/XPath kullanarak spesifik kontroller yapın

4. Yeniden Deneme Stratejisi

• Geçici sorunlar için retry kullanın
• Retry sayısını makul tutun (3-5 arası)
• Delay kullanarak sunucu yükünü azaltın
• Rate limiting durumlarında delay'i artırın

5. Bildirim Yönetimi

• Kritik kontroller için email + SMS bildirimi kullanın
• Webhook kullanarak entegrasyon sistemlerinize bildirim gönderin
• Bildirim spam'inden kaçınmak için filtreleme yapın
• Bildirim grupları oluşturun

6. Performans İzleme

• Yanıt sürelerini düzenli olarak kontrol edin
• Başarı oranlarını takip edin (%95+ hedefleyin)
• Trend analizi yapın (grafikleri inceleyin)
• Anomali tespiti için eşik değerleri belirleyin

Sık Sorulan Sorular

Sağlık Kontrolü Ne Sıklıkla Çalışır?

Kontrolün çalışma sıklığı, oluştururken belirlediğiniz Zamanlama (Cron Expression) ayarlarına bağlıdır. Örneğin:

• 0 */5 * ? * * → Her 5 dakikada bir
• 0 0 * ? * * → Her saat başı
• 0 0 9 * ? * → Her gün saat 09:00

Kontrol Pasif Yapıldığında Ne Olur?

Kontrol pasif yapıldığında:

• Yeni test istekleri gönderilmez
• Mevcut zamanlanmış işler iptal edilir
• Geçmiş sonuçlar korunur ve görüntülenebilir
• Kontrol tekrar aktif yapıldığında normal çalışmaya devam eder

Yeniden Deneme Nasıl Çalışır?

"Başarısızsa Yeniden Dene" özelliği aktif edildiğinde:

1. İlk istek gönderilir
2. Eğer başarısız olursa (herhangi bir assertion başarısız)
3. Belirlediğiniz sayı kadar tekrar denenir
4. İstekler arası bekleme varsa, belirtilen süre kadar beklenir
5. Tüm denemeler başarısız olursa, sonuç "Başarısız" olarak kaydedilir

Bildirimler Ne Zaman Gönderilir?

Bildirimler (Recipients) şu durumlarda tetiklenir:

• Test başarısız olduğunda
• Her başarısız test için ayrı bildirim gönderilir
• Başarılı testlerde bildirim gönderilmez (varsayılan davranış)

Assertion Kontrolleri Nasıl Çalışır?

Assertion kontrolleri şu sırayla yapılır:

1. Timeout Kontrolü: İstek belirlenen süre içinde yanıtlandı mı?
2. Status Code Kontrolü: HTTP status code beklenen değerle eşleşiyor mu?
3. Body Kontrolü: Response body beklenen içerikle eşleşiyor mu?
4. XPath Kontrolü: XML response'ta XPath ifadesi doğru sonuç veriyor mu?
5. JSONPath Kontrolü: JSON response'ta JSONPath ifadesi doğru sonuç veriyor mu?

uyarı

Önemli: Tüm aktif assertion'lar başarılı olmalıdır. Herhangi biri başarısız olursa, test sonucu "Başarısız" olarak işaretlenir.

Test Koleksiyonundan Seçme Ne İşe Yarar?

Test koleksiyonundan seçme özelliği, daha önce Test Console'da oluşturduğunuz test senaryolarını yeniden kullanmanızı sağlar. Bu sayede:

• Zaman kazanırsınız
• Tutarlı test senaryoları kullanırsınız
• Test senaryolarınızı merkezi olarak yönetebilirsiniz

Kontrol Silindiğinde Ne Olur?

Kontrol silindiğinde:

• Kontrol tanımı veritabanından silinir
• Tüm test sonuçları silinir
• Zamanlanmış işler iptal edilir
• Geçmiş veriler kalıcı olarak kaybolur

uyarı

Silme işlemi geri alınamaz!

Sonuçlar Ne Kadar Süre Saklanır?

Sonuçlar, manuel olarak silinene kadar saklanır. Eski sonuçları temizlemek için:

• Sonuçlar sayfasında "Tüm Sonuçları Sil" butonunu kullanabilirsiniz
• Veya sonuçları düzenli olarak temizleyebilirsiniz

Birden Fazla Assertion Kullanabilir miyim?

Evet, birden fazla assertion kullanabilirsiniz. Tüm aktif assertion'lar başarılı olmalıdır. Örneğin:

• Status Code: 200 ✅
• Body içinde "success" metni ✅
• JSONPath: $.status = "ok" ✅

Tümü başarılı olursa test başarılı sayılır.

URL'de Dinamik Parametreler Kullanabilir miyim?

Hayır, URL'de dinamik parametreler kullanılamaz. Ancak:

• Query parametreleri ekleyebilirsiniz
• Headers'da dinamik değerler kullanabilirsiniz (bazı durumlarda)
• Body'de dinamik içerik kullanabilirsiniz

Sorun Giderme

Kontrol Çalışmıyor

Olası Nedenler:

1. Kontrol pasif durumda olabilir → Durum toggle'ını kontrol edin
2. Zamanlama ayarları yanlış olabilir → Cron expression'ı kontrol edin
3. URL erişilebilir değil → URL'yi manuel olarak test edin

Çözüm:

• Kontrol durumunu aktif yapın
• Zamanlama ayarlarını kontrol edin
• URL'nin erişilebilir olduğundan emin olun

Tüm Testler Başarısız

Olası Nedenler:

1. URL yanlış veya erişilebilir değil
2. Assertion ayarları çok katı
3. Timeout süresi çok kısa
4. Authentication sorunları

Çözüm:

• URL'yi kontrol edin
• Assertion ayarlarını gözden geçirin
• Timeout süresini artırın
• Headers'da authentication bilgilerini kontrol edin

Bildirimler Gelmiyor

Olası Nedenler:

1. Bildirim pasif durumda
2. Bildirim yapılandırması hatalı
3. Email/SMS servisi çalışmıyor

Çözüm:

• Bildirim durumunu aktif yapın
• Bildirim yapılandırmasını kontrol edin
• Email/SMS servis ayarlarını kontrol edin

Yanıt Süreleri Çok Yüksek

Olası Nedenler:

1. API performans sorunları
2. Network gecikmeleri
3. Sunucu yükü

Çözüm:

• API performansını optimize edin
• Network bağlantısını kontrol edin
• Sunucu kaynaklarını kontrol edin

Sonuçlar Görünmüyor

Olası Nedenler:

1. Kontrol henüz çalışmadı
2. Tarih aralığı filtresi yanlış
3. Sonuçlar silinmiş olabilir

Çözüm:

• Kontrolün çalıştığından emin olun
• Tarih aralığı filtresini kontrol edin
• Sonuçların silinmediğinden emin olun

Ek Kaynaklar

Test Console Kullanım Kılavuzu

Test senaryoları oluşturma

Konnektörler

Bildirim ve eylem yapılandırması

Zamanlanmış İşler

Zamanlama ayarları ve cron expression

API Dokümantasyonu

REST API kullanımı