HTTP Monitor

Web sitelerinizi ve API'lerinizi izleyin: durum kodu, içerik doğrulama ve yanıt süresi kontrolleri.

HTTP monitör en sık kullanılan monitör tipidir. Belirlediğiniz aralıklarla bir URL'e HTTP isteği gönderir; cevabın durum kodunu, opsiyonel olarak içeriğini ve toplam yanıt süresini doğrular. Web siteleri, REST API'ler, GraphQL uç noktaları ve sağlık kontrolü rotaları için varsayılan tercihtir.

Ne zaman kullanmalı?

  • Web sitesi: https://example.com çalışıyor mu, 200 dönüyor mu?
  • REST API: /api/v1/health uç noktanız {"status":"ok"} döndürüyor mu?
  • Üçüncü taraf entegrasyon: Webhook proxy'niz istekleri yukarıya doğru yönlendiriyor mu?
  • Giriş sayfası: 200 dönüyor mu ve "Sign in" metni hâlâ orada mı?
  • CDN edge: Edge düğümleri beklenen önbelleğe alınmış içeriği sunuyor mu?

Desteklenen istek metotları

MetotNe zaman kullanılır
GETVarsayılan, istek gövdesi boşsa her kontrol GET olarak gider
POSTİstek gövdesi doldurulduğunda otomatik olarak POST'a geçer

Tüm isteklere User-Agent: UptimeWarden/1.0.0 başlığı eklenir. İhtiyaç duyduğunuz ek başlıkları formdaki tablodan tanımlayabilirsiniz.

Monitör oluşturma

  1. Monitörler → Yeni Monitör → Tip: Website & API (HTTP)

  2. Temel alanlar:

    • İsim: Örneğin Production API - Health
    • URL: https://api.example.com/health
    • Kontrol Sıklığı: En kısa aralık planınıza bağlıdır; güncel değerler için fiyatlandırma sayfasına bakın
    • Zaman aşımı: Yanıt için maksimum bekleme süresi (varsayılan 30 sn, min 5 sn, max 300 sn)

  3. Beklenen durum kodları: Virgülle ayrılmış liste, örneğin 200,201,204. Boş bırakılırsa varsayılan 200 olur.

  4. Özel başlıklar (opsiyonel): API anahtarı, kullanıcı ajanı, kabul edilen MIME tipi vb.

    Authorization: Bearer eyJhbGc...
X-API-Version: 2024-01
Accept: application/json

  5. İstek gövdesi (opsiyonel): Doldurulduğunda istek otomatik POST olarak gönderilir. JSON, form-data veya düz metin desteklenir.

  6. Kaydet.

Durum kodu doğrulama

Beklenen listede yer alan her cevap up kabul edilir. Liste dışında kalan her şey (500, 503, 404, ağ hatası, zaman aşımı) down olarak değerlendirilir.

Yaygın senaryolar:

  • API sağlık kontrolü: 200
  • 301/302 yönlendirme yapan kamuya açık site: 200,301,302
  • Giriş formu: 200,302 (200 sayfa için, 302 başarılı gönderim için)
  • HEAD veya CDN önbellek doğrulayıcıları: 200,304

İçerik doğrulama

Sadece durum kodu yeterli olmayabilir; sunucu 200 dönerken hata sayfası gösterebilir. UptimeWarden gövdeyi dört farklı yöntemle doğrular:

TipKullanımÖrnek
MetinAlt dize veya tam eşleşme"status":"ok"
RegexRegex deseni eşleşmesi^(OK|HEALTHY)$
JSONBeklenen JSON içeriği{"status":"ok"}
XMLBeklenen XML içeriği<status>ok</status>

Büyük-küçük harf duyarlılığı için ayrı bir geçiş bulunur ve metin ile regex doğrulamaları için geçerlidir.

Örnek. JSON API sağlık kontrolü:

GET /api/health → 200
{"status": "ok", "version": "1.4.2"}

JSON doğrulamasında "ok" beklerseniz {"status":"degraded"} cevabı down olarak işlenir.

Kimlik doğrulama

Özel başlık (önerilen yöntem)

Kimlik doğrulama başlıklarını izlenen isteğe eklemenin yolu özel başlık tablosudur. Burada tanımladığınız başlıklar her kontrolde gönderilir; örneğin Authorization: Bearer <token> (JWT veya API anahtarları), X-API-Key ya da imzalı başlıklar.

Basic Auth / Bearer Token alanları

Formdaki Basic Auth (kullanıcı adı/şifre) ve Bearer Token alanları kimlik bilgilerini şifrelenmiş olarak saklar, ancak şu anda izlenen isteğe otomatik olarak bir Authorization başlığı eklemez. Giriş arkasındaki bir uç noktayı doğrulamak için kimlik bilgisini yukarıdaki özel başlık tablosuna Authorization başlığı olarak girin.

Yönlendirme yönetimi

UptimeWarden yönlendirmeleri otomatik olarak ve en fazla 10 adıma kadar takip eder. Son hedefin durum kodu beklenen liste ile karşılaştırılır. Yönlendirmenin kendisini (örneğin bir 301/302) doğrulamak isterseniz ilgili kodu beklenen durum kodları listesine ekleyin.

SSL doğrulama

HTTPS adreslerinde sertifika varsayılan olarak katı şekilde doğrulanır (geçersiz, süresi dolmuş veya kendinden imzalı sertifikalar down sebebidir). Test ortamlarında Verify SSL kapatılabilir, ancak production'da kapatmayın.

Not: Sertifikanın kalan ömrünü takip etmek için ayrı bir SSL Monitor kullanın. HTTP monitör yalnızca sertifikanın o an geçerli olup olmadığını kontrol eder; kalan gün sayısı için alarm üretmez.

Yanıt süresi eşiği

Yanıt süresi eşiği (ms) ayarlandığında üçüncü bir durum oluşur:

  • Yanıt eşiğe eşit veya altında → up
  • Yanıt eşiğin üzerinde → yavaş kontrol olarak kaydedilir (high_response)
  • Zaman aşımı → down

Yüksek yanıt süresi alarmı ancak art arda N yavaş kontrolden sonra açılır; N, düzelmeyi onaylayan ardışık kontrol sayısının aynısıdır (varsayılan 3). Tek bir yavaşlama sonuçlarınızda ve grafiklerinizde kalır ama kimseye bildirim gitmez. Yavaşlık sürerse alarm N'inci yavaş kontrolde gider, ilkinden en fazla N−1 kontrol aralığı sonra; olayın başlangıcı ilk yavaş kontroldür.

Bu sayede yavaşlama bir kesintiye dönüşmeden uyarılırsınız.

API üzerinden monitör oluşturma

curl -X POST https://app.uptimewarden.online/api/v1/monitors \
  -H "Authorization: Bearer $UW_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Production API",
    "url": "https://api.example.com/health",
    "type": "http",
    "interval": 60,
    "timeout": 30
  }'

Yanıt 201 Created olarak gelir ve yeni monitörün kimliğini içerir. v1 oluşturma uç noktası yalnızca name, url, type, interval ve timeout alanlarını okur (name, url, type zorunludur); beklenen durum kodları varsayılan olarak 200 atanır. Beklenen kodları veya diğer ayrıntıları sonradan panel üzerinden düzenleyebilirsiniz.

Plan limitleri ve kontrol sıklığı

Seçebileceğiniz en kısa kontrol aralığı planınıza bağlıdır ve form, planınızın altındaki sıklıkları kilitleyip bir "yükselt" çağrısı gösterir. Güncel plan sınırları için fiyatlandırma sayfasına bakın; hesabınıza özel değerler panodaki Billing sayfasında canlı görünür.

Sık sorulan sorular

S: 200 dönen sayfada "Database error" yazıyor, yine de up gösteriyor. C: İçerik doğrulama ekleyin: "Database error" ifadesinin yokluğunu (regex ^(?!.*Database error).* ile) ya da beklenen başarı mesajının varlığını doğrulayın.

S: Giriş arkasındaki bir uç noktayı izlemek istiyorum. C: Kimlik bilgisini özel başlık tablosuna Authorization başlığı olarak ekleyin (her kontrolde gönderilir). UptimeWarden tek istek gönderir; çok adımlı akışlar için Heartbeat monitör artı dış bir script daha temizdir.

S: POST kontrolleri her dakika veritabanıma satır yazmasın istiyorum. C: API'nizde dry-run veya ?ping modu açın ya da etkisi olmayan bir uç nokta kullanın. Sağlık uç noktaları her zaman yan etkisiz olmalıdır.

İlgili konular