Self-hosted hata izleme: Sentry alternatifleri

Self-hosted hata izleme sistemlerinin tek bir olay kaydetmeden önceki maliyeti

Self-hosted hata izleme sistemlerinde tüm kararı belirleyen tek bir sayı vardır; o da minimum RAM gereksinimidir. Sentry'nin kendi self-hosted dokümantasyonu, uygulamanız tek bir olay göndermeden önce 4 CPU çekirdeği, 16 GB RAM ve 16 GB swap alanı ile 20 GB boş disk alanı talep eder. GlitchTip ise 512 MB RAM gereksinimi belirtir. Buradaki tüm seçenekler aynı Sentry SDK'larından gelen olayları kabul eder; dolayısıyla bu, kodunuzu nasıl izleyeceğinizle ilgili bir karar değildir. Bu, ne kadar büyük bir sunucu için ödeme yapmaya ve o sunucuyu ayakta tutmaya istekli olduğunuzla ilgili bir karardır.

Yayınlanan kaynak rakamları, yan yana

Bunlar, Ağustos 2026 itibarıyla her projenin kendisi hakkında yayınladığı rakamlardır. Bunlar aynı türden ölçümler değildir; bu nedenle karşılaştırma yapmadan önce her satırdaki notu okuyun.

[
  {
    "tool": "Sentry self-hosted",
    "published_ram_gb": 16,
    "notes": "documented minimum, plus 16 GB of swap"
  },
  {
    "tool": "Bugsink",
    "published_ram_gb": 4,
    "notes": "the vendor's own published benchmark box, 2 vCPU"
  },
  {
    "tool": "GlitchTip",
    "published_ram_gb": 0.5,
    "notes": "documented recommendation, 256 MB stated as the minimum"
  }
]

Sentry'nin 16 GB değeri belgelenmiş bir minimumdur ve aynı sayfada 32 GB önerilmektedir. GlitchTip'in 0.5 GB değeri bir öneridir; proje, çalışma için minimum 256 MB veya dikkatli bir yapılandırma ile 128 MB artı swap alanı belirtmektedir. Bugsink'in 4 GB değeri ise bunların hiçbiri değildir: bu değer, satıcının kendi iş hacmi (throughput) kıyaslaması için kullandığı sunucu donanımıdır. Yayınlanan bir rakam başlangıç noktasıdır, etkinlik hacminizle ilgili bir taahhüt değildir.

Sentry self-hosted: tüm ürün ve tüm maliyet

Resmi yığın, Sentry'nin üretim ortamında çalıştırdığı bileşenlerin aynısını çalıştıran bir Docker Compose projesi olan getsentry/self-hosted'tür. Kendi belgeleri bunu "özellik açısından eksiksiz, düşük hacimli dağıtımlar ve kavram kanıtlama çalışmaları için paketlenmiş" olarak tanımlar. Bu cümle dürüst bir özettir. Tüm özelliklere sahip olursunuz ve bu özelliklerin çalışmasını sağlayan tüm hareketli parçaları da alırsınız.

Kurulumu master yerine etiketli bir sürümden yapın:

VERSION=$(curl -Ls -o /dev/null -w %{url_effective} https://github.com/getsentry/self-hosted/releases/latest)
VERSION=${VERSION##*/}
git clone https://github.com/getsentry/self-hosted.git
cd self-hosted
git checkout ${VERSION}
./install.sh

Ardından başlatın:

docker compose up --wait

Sentry varsayılan olarak http://127.0.0.1:9000 üzerinde dinleme yapar. Docker Engine 19.03.6 veya üzeri ile Docker Compose 2.32.2 veya üzeri gereklidir; daha eski bir Compose sürümü Sentry'nin yaptığı işlemlerden ziyade dosya sözdizimi nedeniyle hata verir.

Gerçekte neyi başlattığınıza bakın:

docker compose ps
free -h

docker compose ps, yığındaki her servisi listeler ve bu liste uzundur: Postgres, ClickHouse, Kafka, Redis, Relay, Snuba, Symbolicator ve çeşitli worker ile cron süreçleri. Bunları bir kez sayın, çünkü bu sayı sizin bakım yükünüzdür. Her girdi; çökebilen, diski doldurabilen veya bir taşıma (migration) sırasında başarısız olabilen bir süreçtir.

Bir servis Restarting durumunda kalırsa, başka hiçbir şeye bakmadan önce belleği kontrol edin:

dmesg -T | grep -i 'out of memory'

Out of memory: Killed process 3412 (java) gibi bir satır, sunucunun RAM'i tükendiği için çekirdeğin OOM killer (bellek yetersizliği sonlandırıcısı) mekanizmasının bir container'ı kapattığı anlamına gelir; bu nedenle servis asla sağlıklı duruma geçemez ve yığın başlatma işlemini tamamlayamaz. Bu, tam yığını belgelenen minimum gereksinimlerin altında çalıştırmanın olağan sonucudur. Belgeler ayrıca disk hızına da dikkat çeker: iowait değerinin %10'un üzerinde olması, makinenin veri alım hattına (ingest pipeline) yetişemediği anlamına gelir. Bu değeri top içindeki wa sütunundan veya sysstat yüklüyse iostat -x 5 üzerinden okuyun.

Yükseltmeler insanların hafife aldığı kısımdır

Sentry self-hosted, her ayın 15'inde ana sürüm yayınlanan, takvim tabanlı bir sürüm şeması olan CalVer altında aylık olarak yayınlanır. Eski bir sürümden doğrudan en son sürüme geçemezsiniz. Proje, zorunlu duraklama sürümlerini (hard stop versions) tanımlar ve veritabanı taşımalarını (migrations) alabilmek için her birine sırayla geçiş yapmanız gerekir. Ağustos 2026 itibarıyla yayınlanan zorunlu duraklama sürümleri 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 ve 26.7.0'dır. Belgeler ayrıca 23.7.0, 25.9.0, 25.12.0 ve 26.3.0 ile 26.4.0 aralığı dahil olmak üzere, taşıma sorunları nedeniyle atlanması gereken sürümleri de listeler.

Bir yükseltme, bir checkout işlemi ve yükleyicinin yeniden çalıştırılmasından ibarettir:

git fetch
git checkout 26.7.0
./install.sh
docker compose up --wait

Başlamadan önce sunucunun anlık görüntüsünü (snapshot) alın, çünkü büyük bir ClickHouse veri kümesi üzerindeki taşıma işlemi saatlerce sürebilir ve yarıda kalan bir başarısızlık veritabanını iki şema arasında bırakır. Başarısız olan çoğu self-hosted Sentry yükseltmesinin temel nedeni şudur: sunucu bir yıl boyunca tek bir sürümde kalmıştır, bu nedenle yapılan atlama aynı anda birkaç zorunlu duraklamayı geçer ve atlanan taşımalardan biri kritik olanıdır.

Taahhütte bulunmadan önce bilmeniz gereken bir şey daha var. Sentry self-hosted, Sentry'nin kendisi tarafından getirilen Functional Source License (FSL) altındadır. Bu, OSI onaylı açık kaynak yerine adil kaynak (fair source) modelidir: kendiniz için çalıştırabilirsiniz ancak rakip bir servis olarak satamazsınız. Her sürüm, yayınlandıktan iki yıl sonra Apache 2.0 lisansına dönüşür.

GlitchTip: 512 MB çözümü

GlitchTip, MIT lisansına sahiptir ve Sentry'nin açık kaynaklı SDK'larından gelen olayları kabul eder. Bu sayede, izleme (instrumentation) eklenmiş bir uygulama, yalnızca tek bir değerin (DSN - SDK'nın olayları gönderdiği URL) değiştirilmesiyle sisteme taşınabilir. PostgreSQL 14 veya daha yeni bir sürüm gerektirir. Valkey veya Redis 7 ve üzeri sürümler isteğe bağlıdır; ancak daha büyük kurulumlarda performansı artırır.

Kurulum, Docker ve bir adet compose dosyası ile gerçekleştirilir:

sudo apt install docker.io
curl -O https://glitchtip.com/assets/compose.sample.yml
mv compose.sample.yml compose.yml

Başlamadan önce environment bölümünü düzenleyin. Ayarlanması zorunlu değerler; secret, domain ve mail yoludur:

SECRET_KEY: <output of openssl rand -base64 50>
GLITCHTIP_DOMAIN: https://errors.example.com
DEFAULT_FROM_EMAIL: errors@example.com
EMAIL_URL: smtp://user:password@smtp.example.com:587

Örnek yapılandırma, DATABASE_URL değerini halihazırda kendi postgres servisine bağlamıştır; başka bir yerde çalışan bir veritabanına bağlanmıyorsanız bu satırı değiştirmeyin. GLITCHTIP_DOMAIN değeri şema bilgisini içermelidir. Başında https:// olmadan, uyarı e-postalarındaki bağlantılar hatalı oluşturulur ve yanıt vermeyen bir URL'ye yönlendirir.

Servisi başlatın ve ilk açılışı izleyin:

docker compose up -d
docker compose logs -f web

Ağustos 2026 itibarıyla örnekteki imaj etiketleri postgres:18, valkey/valkey:9 ve glitchtip/glitchtip:6 şeklindedir. Bu sürümleri sabitleyin. latest içeren bir compose dosyası, bir sonraki docker compose pull komutunda veritabanı motorunuzu yükseltecektir. Çalışan bir instance üzerinde gerçekleşen Postgres ana sürüm yükseltmesi, çalışan bir hata takip sisteminin durmasına neden olur.

256 MB ile 512 MB aralığına ulaşmak için, örnek dosyadaki yorum satırlarında belirtilen özellikleri (Valkey, isteğe bağlı log ve uptime özellikleri gibi) kapatın. Valkey olmadan çalıştırmak, GlitchTip'in önbellek ve kuyruk işlemleri için veritabanını kullanması anlamına gelir; bu yöntem daha yavaştır ancak yine de doğru çalışır. "All in one" modu, worker sürecini web süreci içinde çalıştırır; böylece iki yerine tek bir uygulama container'ı yönetirsiniz.

Önüne bir proxy yerleştirin. GlitchTip dokümantasyonu, istekleri tamponlayan (buffer) ve parçalı (chunked) Transfer-Encoding işlemlerini yönetebilen bir proxy veya yük dengeleyici kullanılmasını önerir ve örnek olarak nginx'i gösterir. Tamponlama yapılmadığında, yavaş bir istemci, yükleme süresi boyunca bir uygulama worker'ını meşgul eder. Bu durumda, birkaç yavaş gönderici tüm worker'ları doldurabilir ve sağlıklı istemciler zaman aşımına uğrar.

Yükseltme işlemleri oldukça basittir:

docker compose pull
docker compose stop
docker compose up -d

Veritabanı migrasyonları başlangıçta otomatik olarak çalışır. Yine de her ihtimale karşı önce bir yedek (dump) alın; çünkü otomatik bir migrasyon yine de bir migrasyondur.

Bugsink: tek bir container ve okumanız gereken bir lisans

Bugsink, bu üç seçenek arasındaki en hafif olanıdır. Sentry SDK protokolünü kullanır; mesaj kuyruğu veya veritabanı dışında herhangi bir harici servis gerektirmeden çalışır. Varsayılan olarak SQLite ile gelir, ancak ihtiyaçlarınız arttığında MySQL ve PostgreSQL desteği de mevcuttur.

Karar vermeden önce arayüzü incelemek için geçici bir örnek:

docker pull bugsink/bugsink:latest
docker run \
  -e SECRET_KEY=PUT_AN_ACTUAL_RANDOM_SECRET_HERE_OF_AT_LEAST_50_CHARS \
  -e CREATE_SUPERUSER=admin@example.org:admin \
  -e PORT=8000 \
  -p 8000:8000 \
  bugsink/bugsink

http://localhost:8000/ adresini açın ve CREATE_SUPERUSER içinde belirttiğiniz adres ve parola ile giriş yapın. Bu container durdurulduğunda hiçbir veri saklamaz. Kalıcı bir kurulum için projenin örnek compose dosyasını kullanın; bu dosya bugsink/bugsink:2 ile postgres:17-alpine bileşenlerini eşleştirir ve DATABASE_URL, BASE_URL ile BEHIND_HTTPS_PROXY ayarlarını yapılandırır. Secret değerini düzgün bir şekilde oluşturun:

openssl rand -base64 50

BASE_URL değeri, kullanıcılarınızın ve SDK'lerinizin gerçekten kullandığı URL ile (şema dahil) eşleşmelidir. Eğer bu değeri http://localhost:8000 olarak bırakır ve sunucuya https://errors.example.com üzerinden erişirseniz, bildirim e-postalarındaki tüm bağlantılar, okuyan kişi için çözümlenemeyen bir ana bilgisayara yönlendirilir. Nginx veya Caddy gibi bir araç ön tarafta TLS (transport layer security) sonlandırması yapıyorsa BEHIND_HTTPS_PROXY değerini true olarak ayarlayın. Aksi takdirde Bugsink, https:// proxy'nizin arkasında http:// URL'ler oluşturur ve tarayıcılar karma içerik (mixed content) nedeniyle bağlantıyı engeller.

Üretici kendi verim rakamlarını yayınlamaktadır: 2 vCPU ve 4 GB RAM'e sahip bir VPS üzerinde, her biri 50 KB olan saniyede 18 olay; bu da günlük 1,5 milyon olay anlamına gelir. Bu verileri iş yükünüz için bir garanti değil, aracın kapasitesini gösteren bir referans olarak kabul edin. Bu rakamlar, tavan noktasının küçük bir uygulamanın ürettiği veriden çok daha yüksek olduğunu göstermektedir.

Şimdi lisans konusuna gelelim; bu, aracın altyapınıza dahil edilmesinden önce okunması gereken kısımdır. Bugsink, PolyForm Shield License 1.0.0 altında yayınlanmıştır. Bu bir "source available" (kaynak kodu erişilebilir) lisansıdır, "open source" (açık kaynak) değildir: yazılımı çalıştırabilir ve değiştirebilirsiniz, ancak Bugsink ile rekabet eden bir ürün oluşturmak için kullanamazsınız. Dahili bir hata takip sistemi için bu kısıtlama bir sorun teşkil etmez. Eğer şirketiniz geliştirici araçları satıyorsa, lisans metnini öncelikle bir hukuk uzmanına inceletin.

Hata takibi ve LLM gözlemlenebilirliği hala iki ayrı araçtır

Hata takibi ve büyük dil modeli (LLM) gözlemlenebilirliğini bir arada sunan tek bir araç aradığınızda, her ikisini de yaptığını iddia eden ürünlerle karşılaşırsınız. Veri yapıları birbirinden farklıdır; bu nedenle bu iki alanın birleşimi gerçekleşmemektedir. Bir hata takip aracı, yığın izleme (stack trace) içeren bir istisnayı alır, bundan bir parmak izi hesaplar ve binlerce oluşumu bir sayaçla tek bir sorun altında toplar. Bir LLM izleme aracı ise istem (prompt), yanıt, token sayısı ve gecikme süresini içeren bir aralık (span) alır; bunların her birini saklamak zorundadır, çünkü aynı girdilere sahip iki çağrı bile incelenmeye değer ayrı olaylardır.

Bu yüzden her ikisini de çalıştırın. İstisnaları hata takip aracına gönderin, model çağrılarını ise bu iş için tasarlanmış bir yere iletin: ajan izleme için self-hosted Langfuse bu tarafı kapsar, self-hosted AI gözlemlenebilirliği ise aynı işe farklı bir açıdan yaklaşır. Uygulamanız halihazırda her iki türde de hata üretmektedir. Kendinden emin bir şekilde saçmalayan bir model çağrısı hiçbir istisna fırlatmaz, bu yüzden hata takip aracı bunu size asla göstermeyecektir.

Disk büyümesi, sizi daha sonra yakalayan bir hatadır

Her hata izleme aracı, sınırsız girişe sahip, yoğun yazma işlemi yapan bir veritabanıdır. Uygulamanız ne kadar yazacağına kendisi karar verir; yoğun kullanılan bir kod yolundaki tek bir yeni hata, bir gecede milyonlarca olay oluşturabilir.

GlitchTip, planlama yaparken dikkate alınması gereken bir rakam sunar: ayda bir milyon olay işleyen bir kurulum, 30 GB disk alanına ihtiyaç duyabilir. Bu rakam, söz konusu hızda bir aylık veri girişini kapsar; saklama süreniz (retention window), aynı anda kaç aylık veriyi depolayacağınızı belirler.

Bugsink konuya diğer uçtan yaklaşır. Sabit bir kota yerine, olay sayısı ve olay yaşı üzerinden bir saklama algoritması uygular ve sınırları doğrudan ortaya koyar: tüm kurulum için MAX_RETENTION_EVENT_COUNT, proje başına MAX_RETENTION_PER_PROJECT_EVENT_COUNT ve mutlak bir kesim noktası olarak MAX_EVENT_AGE_DAYS. Kurulum genelinde bir olay bütçesi belirlemek, diski boyutlandırmanın dürüst yoludur; çünkü bu bütçe doğrudan diskin kendisidir.

Sunucudaki gerçek rakamları izleyin:

df -h /
docker system df -v
du -sh /var/lib/docker/volumes/*

docker system df -v komutu, birim başına boyutları yazdırır; böylece hangi servisin büyüdüğünü görebilirsiniz. Trafikte bir değişiklik olmadığı halde haftada birkaç gigabayt büyüyen bir birim, genellikle saklama ayarlarının hiç yapılandırılmadığı, dolayısıyla hiçbir verinin silinmediği ve tek sınırın bölümün boyutu olduğu anlamına gelir.

Bellek de farklı kılıklara bürünmüş aynı sorundur. Sınırları olmayan bir yığın (stack), çekirdeğin sunduğu her şeyi tüketir. Makinede yer kalmadığında OOM killer, en büyük süreci seçer; bu süreç, soruna neden olan izleme aracından ziyade web sunucunuz olabilir. Her servise bir tavan sınırı koyun: Docker Compose içinde bellek sınırları dokümanı, sözdizimini ve bir container sınırına ulaştığında ne olduğunu gösterir. Kendi sınırında sonlandırılan bir container, sınırlı bir hatadır. Çekirdek tarafından sonlandırılan bir container ise yanındaki servisi de beraberinde götürür.

Hangi yığın hangi VPS için uygundur

• 1 GB veya boş alan kalacak şekilde 2 GB: Valkey kapalıyken "all in one" modunda GlitchTip veya SQLite üzerinde Bugsink. Her ikisi de az sayıda uygulama için bu seviyede rahat çalışır.
• 4 GB: PostgreSQL ile Bugsink veya Valkey açık ve ayrı bir worker servisi ile GlitchTip. Bu, ince ayar yapmayı bırakıp doğrudan çalıştırabileceğiniz boyuttur.
• 8 GB: Resmi Sentry yığını için hala yetersizdir. Bu kaynağı, seçtiğiniz hafif seçenek için daha uzun bir saklama süresi ve daha büyük bir disk alanı için kullanın.
• Minimum 16 GB, önerilen 32 GB: Resmi Sentry self-hosted yığını; yalnızca daha hafif projelerin uygulamadığı bir Sentry özelliğine ihtiyaç duyduğunuzda tercih edilmelidir. Uyumlu projeler yaygın özellikleri kapsadığından, önce ilgili özelliği her projenin kendi dokümantasyonu üzerinden kontrol edin.

Ne çalıştırırsanız çalıştırın, hata takip sistemi kendi çöküşünü raporlayamaz. Onu farklı bir makine üzerinden denetleyin: Başka bir sunucudan izleme yapan Uptime Kuma, takip sisteminin kapalı olduğunu size bildirecektir; bu, uygulamanızın kimsenin kaydetmediği hataları vermeye başladığı kritik andır.

Barındırılan bir planın daha ekonomik olduğu durumlar

Veri yerleşimi kuralları gerektirdiğinde veya etkinlik hacminiz etkinlik başına ücretlendirmeyi maliyetli kılacak kadar yüksek olduğunda, bir hata takip sistemini kendi sunucunuzda barındırmak mantıklıdır. Bu durumların dışındaysanız, hesaplamayı dürüstçe yapın. Sentry için belgelenen minimum gereksinim 16 GB RAM ve 4 çekirdekli, hızlı diske sahip bir sunucudur; bu boyuttaki bir VPS ucuz bir seçenek değildir. Buna bir de operasyonel iş yükünü ekleyin: her kritik aşamayı sırasıyla geçmek ve yılda birkaç kez her güncelleme öncesinde snapshot almak.

GlitchTip ve Bugsink bu hesaplamayı tamamen değiştirir, çünkü 512 MB ile 4 GB arası RAM sunan bir sunucu oldukça ekonomiktir ve yükseltme işlemi bir docker compose pull komutundan ibarettir. Bu soruyu soran çoğu kişinin resmi yığın yerine uyumlu projelerden birine yönelmesinin nedeni budur. İstedikleri şey hata takibi yapmaktı, başında beklemeleri gereken dağıtık bir veri hattı değil.

Sunucuda nelerin barındırılması gerektiğine hala karar veriyorsanız, kendi sunucunuzda barındırmaya değer servislerin geniş listesi, hata takibini aynı RAM kaynağı için yarışan diğer servislerin yanına yerleştirir.

FAQ

2 GB RAM'li bir VPS üzerinde Sentry self-host edebilir miyim?

Hayır. Sentry self-hosted dokümantasyonu, minimum 4 CPU çekirdeği, 16 GB RAM, 16 GB swap alanı ve 20 GB boş disk alanı gerektirir. Yığın; Postgres, ClickHouse, Kafka, Redis ve çeşitli worker süreçlerini aynı anda çalıştırır; bu nedenle küçük bir sunucuda kurulum tamamlanmadan çekirdek (kernel) container'ları sonlandırır. Durumu, sonlandırılan süreci belirten bir satır döndüren dmesg -T | grep -i 'out of memory' komutu ile doğrulayabilirsiniz. 2 GB RAM'li bir VPS için 512 MB gereksinimi olan GlitchTip veya SQLite üzerinde tek bir container olarak çalışan Bugsink tercih edilmelidir.

Sentry'den GlitchTip veya Bugsink'e geçmek için uygulama kodumu değiştirmem gerekir mi?

Hayır. Her ikisi de Sentry'nin açık kaynaklı SDK'larından gelen etkinlikleri kabul eder; bu nedenle halihazırda kurulu olan SDK'yı koruyup yalnızca tek bir değeri, yani SDK'nın etkinlikleri gönderdiği URL olan DSN'i değiştirmeniz yeterlidir. Eğer DSN kod içerisinde sabit olarak tanımlanmışsa bir ortam değişkenine taşıyın, yeni sunucuya yönlendirin, ardından bir test istisnası (exception) oluşturun ve sisteme ulaşıp ulaşmadığını izleyin. Eğer hiçbir şey görünmüyorsa, DSN içindeki proje tanımlayıcısının yeni sunucuda mevcut olan bir proje ile eşleştiğinden ve güvenlik duvarınızın uygulamanın ilgili sunucuya ve porta erişimine izin verdiğinden emin olun.

Self-hosted hata takip sistemi ne kadar disk alanına ihtiyaç duyar?

Bu, kullandığınız araca değil, etkinlik hacminize ve veri saklama (retention) sürenize bağlıdır. GlitchTip, ayda bir milyon etkinlik işleyen bir kurulum için 30 GB disk alanı önermektedir. Bugsink, bütçeyi doğrudan MAX_RETENTION_EVENT_COUNT ve MAX_EVENT_AGE_DAYS ile belirlemenize olanak tanır; bu sayede üst sınırı siz seçersiniz ve disk gereksinimi buna göre şekillenir. Veri saklama politikasını ilk günden yapılandırın. Saklama politikası olmayan bir takip sistemi, df -h çıktısı %100'e ulaşana kadar büyür; bu noktada veri alımı durur ve en çok görmeniz gereken hataları kaybedersiniz.

Self-hosted Sentry yükseltmeleri neden sürekli başarısız oluyor?

Çünkü yükseltme sırasında kritik bir geçiş noktası atlanmıştır. Sentry self-hosted, veritabanı migrasyonlarını içeren belirli ara sürümleri zorunlu kılar; Ağustos 2026 itibarıyla bu sürümler 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 ve 26.7.0'dır. Eski bir sürümden doğrudan en yeni sürüme geçmek bu migrasyonları atlamanıza neden olur; bu durumda şema ile kod uyumsuz hale gelir ve yükseltme yarıda kesilir. Her bir kritik sürümde sırasıyla ilerleyin ve her aşamada ./install.sh komutunu çalıştırın. Başlamadan önce sunucunun yedeğini alın ve 23.7.0, 25.9.0 ve 25.12.0 gibi kaçınılması gereken sürümlerin listelendiği dokümantasyonu mutlaka okuyun.