Sentry ile Hata Takibi: 30 Dakikada Prod’a Hakim Ol

Meta Description

Sentry ile hata takibi kurun: frontend ve backend hatalarını toplayın, sourcemap ve release’lerle prod sorunlarını hızlıca çözün.

Giriş

Prod’a çıktınız, kullanıcı sayısı arttı… ve o klasik cümle geldi: “Uygulama bazen hata veriyor.” Hangi kullanıcıda? Hangi ekranda? Hangi request’te? Loglarda bir şey yoksa ya da “500” dışında ipucu yoksa, sorun çözmek tahmine dönüşür.

Bu yazıda Sentry ile hata takibi kurmayı ve gerçekten işe yarayan şekilde yapılandırmayı adım adım öğreneceksiniz. Hedef: hatayı sadece “görmek” değil; hangi commit/release ile geldiğini, hangi kullanıcıyı etkilediğini ve nasıl tekrar üretileceğini birkaç dakika içinde bulmak.

Ana İçerik

Sentry ile hata takibi nedir ve neden yapmalıyım?

Sentry ile hata takibi, uygulamanızdaki (web, mobil, backend) beklenmeyen hataları otomatik toplayıp tek bir yerde analiz etmenizi sağlar.

Bunu neden yapmalıyım?

• Prod’da hatayı yakalarsınız (kullanıcı raporuna kalmaz).
• Stack trace, request bilgileri, environment ve kullanıcı bağlamı gelir.
• Release/commit bazlı takip ile “hangi deploy bozuldu?” sorusunu netleştirir.
• Alert’ler ile ekip “geç fark etme” problemini çözer.

İlişkili (LSI) kavramlar: error monitoring, crash reporting, observability, sourcemap, release tracking, alerting, issue grouping.

Sentry kurulumu: Proje oluşturma ve temel ayarlar

Sentry’i iki şekilde kullanabilirsiniz:

• Sentry Cloud (en hızlı başlangıç)
• Self-hosted (daha fazla kontrol, daha çok operasyon)

Başlangıç için Cloud genelde yeterli.

Temel ayarlar checklist’i

Aşağıdakileri en baştan belirleyin:

• Environment: development, staging, production
• Sampling (özellikle performance/trace için)
• PII (kişisel veri): e-posta/telefon gibi verileri maskeleme
• Alert kanalı: Slack, e-posta, Opsgenie vb.

İpucu: Prod’da Sentry’i açıp staging’de kapatmak çoğu ekipte “hataları geç görme” sebebi. Staging’de de açın ama ayrı environment tutun.

Frontend’de Sentry ile hata takibi (Next.js/React örneği)

Aşağıdaki örnek Next.js/React için genel bir kurulum mantığı verir.

1) Paket kurulumu

npm i @sentry/nextjs

# veya
yarn add @sentry/nextjs

2) Sentry init

npx @sentry/wizard -i nextjs

Wizard genelde gerekli dosyaları ve örnek konfigürasyonu oluşturur.

3) Manuel temel konfigürasyon (örnek)

SENTRY_DSN değerini .env.production gibi bir dosyada tutun.

// sentry.client.config.ts
import * as Sentry from "@sentry/nextjs";

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  environment: process.env.NEXT_PUBLIC_APP_ENV || "development",
  tracesSampleRate: 0.1, // ilk etapta düşük tutun
});

4) Gerçek hayattan kullanım: kullanıcı aksiyonuna breadcrumb ekleme

Sentry otomatik breadcrumb toplar; ama kritik akışlarda siz de ekleyebilirsiniz:

import * as Sentry from "@sentry/nextjs";

export async function checkout(orderId: string) {
  Sentry.addBreadcrumb({
    category: "checkout",
    message: `Checkout started for order: ${orderId}`,
    level: "info",
  });

  // ... ödeme akışı
}

Neden önemli? Stack trace tek başına yetmeyebilir. Breadcrumb, hatadan önceki adımları gösterir; “kullanıcı hangi ekrandan geldi?” sorusunu cevaplar.

Backend’de Sentry ile hata takibi (Node.js/Express örneği)

Backend tarafında amaç:

• unhandled exception’ları yakalamak
• request context’i (URL, method, user) eklemek
• hatayı doğru şekilde gruplamak

1) Kurulum

npm i @sentry/node

2) Express middleware ile entegrasyon

import express from "express";
import * as Sentry from "@sentry/node";

const app = express();

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  environment: process.env.APP_ENV || "development",
  tracesSampleRate: 0.05,
});

app.use(Sentry.Handlers.requestHandler());

app.get("/api/orders/:id", async (req, res) => {
  // Örnek: user context
  Sentry.setUser({ id: req.header("x-user-id") || "anonymous" });

  if (req.params.id === "0") {
    throw new Error("Invalid order id");
  }
  res.json({ ok: true });
});

app.use(Sentry.Handlers.errorHandler());

app.listen(3000);

“Bunu neden yapmalıyım?”

• requestHandler() request bağlamını ekler.
• errorHandler() hatayı Sentry’ye doğru formatta yollar.
• setUser() ile “hangi kullanıcı etkileniyor” netleşir.

Güvenlik notu: Kullanıcı bilgisi eklerken PII’yi (e-posta/telefon) doğrudan göndermeyin. ID tercih edin.

Sourcemap ve release takibi: “Prod’da minified hata” kabusu

Frontend’de prod build’lerinde stack trace çoğu zaman minified olur. Sourcemap olmadan “Satır 1, sütun 34920” gibi anlamsız hatalar görürsünüz.

Release stratejisi (pratik)

Her deploy’a bir release etiketi verin:

• web@1.12.0
• api@2026.01.21-1

Bu sayede:

• “Hata hangi deploy ile başladı?” sorusunu yanıtlayabilirsiniz.
• Rollback kararını hızlandırırsınız.

Mini tablo: Release ve sourcemap faydası

Uyarılar (Alert) ve gürültü kontrolü: “Sentry spam”i önleyin

Sentry’i kurup bırakmak, bir süre sonra yüzlerce issue ile boğulmanıza yol açabilir.

Gürültüyü azaltan 5 pratik

1. Environment filtreleme: production alert’lerini ayrı yönetin.
2. Issue grouping ayarı: aynı hatayı doğru gruplasın.
3. Ignore patterns: bilinen/önemsiz hataları susturun.
4. Alert threshold: tek hata yerine “son 10 dakikada 20 kez” gibi eşik koyun.
5. Ownership rules: hatalar doğru ekibe düşsün.

Örnek alert kurgusu

• Kritik API için: “5 dakikada 10+ error” → Slack + e-posta
• UI tarafı için: “Yeni issue oluştu” → sadece Slack

Bunu neden yapmalıyım? Alarm yorgunluğu (alert fatigue) gerçek bir problem. Doğru eşikler, Sentry’i “gürültü” değil “erken uyarı sistemi” yapar.

Gerçek hayat senaryosu: Ödeme ekranında rastgele hata

Diyelim ki ödeme ekranında bazı kullanıcılarda hata oluşuyor.

Sentry ile şu yolu izlersiniz:

1. Issue ekranında en çok etkilenen version/release’i görürsünüz.
2. Breadcrumb’lardan kullanıcı akışını incelersiniz (kupon uyguladı mı? hangi adımda?).
3. Request context ile backend endpoint’ini ve status code’u yakalarsınız.
4. Stack trace + sourcemap ile hatanın gerçek satırını bulursunuz.
5. Aynı issue altında etkilenen kullanıcı sayısını görürsünüz.

Bu yaklaşım, “log kazıma” yerine doğrudan kök sebep analizi sağlar.

Sık Sorulan Sorular (FAQ)

1) Sentry ile hata takibi ücretsiz mi?

Sentry Cloud’da ücretsiz plan vardır; ekip büyüdükçe event limiti ve gelişmiş özellikler için ücretli planlara geçilir.

2) Sentry performansı düşürür mü?

Doğru örnekleme (sampling) ve sadece gerekli environment’larda etkinleştirme ile etkisi düşük olur. En büyük risk, gereksiz yüksek tracesSampleRate kullanmaktır.

3) Sentry’ye kişisel veri gider mi?

Gidebilir. Bu yüzden PII maskeleme, user context’te sadece ID gönderme ve request body/headers filtreleme önerilir.

4) Sourcemap olmadan Sentry işe yarar mı?

Backend’de çoğu zaman evet. Frontend’de ise minified hataları çözmek zorlaşır; sourcemap ciddi fark yaratır.

5) Sentry mi, log mu? Hangisi daha önemli?

İkisi farklıdır. Log detaylı iz sürme sağlar; Sentry ise hata odaklı sinyal üretir ve prod’da “ne bozuldu?” sorusunu hızlandırır.

Sonuç

Sentry ile hata takibi, prod ortamında sorunları hızlı yakalayıp kök sebebe inmeyi kolaylaştırır. Bu yazıda frontend/backend entegrasyonu, sourcemap + release yaklaşımı ve alert gürültüsünü azaltma pratiklerini gördünüz.

Şimdi aksiyon:

• Projenize Sentry’i ekleyin,
• production environment’ında bir test hatası gönderin,
• Alert eşiklerini belirleyin.

Deneyiminizde en çok hangi hata tipi başınızı ağrıtıyor? (Ödeme, auth, dosya yükleme vb.) Yorum olarak yazın; ona göre bir “en iyi pratik” checklist’i paylaşabilirim.