Superlog self-hosting kurulumu ve yapılandırması

Superlog self-hosting kurulumu neleri içerir

Superlog'u kendi sunucunuzda barındırmak için depoyu klonlamanız, Docker Compose ile Postgres, ClickHouse ve bir OpenTelemetry toplayıcısını ayağa kaldırmanız, bir veritabanı migrasyonu çalıştırmanız ve ardından dört Node servisini kaynak koddan başlatmanız gerekir. Uygulamalarınız OTLP (OpenTelemetry protokolü) izlerini, günlüklerini ve metriklerini bir giriş portuna gönderir; Superlog bunları parmak iziyle tanımlar, tekrarlananları tek bir olayda gruplandırır ve bir aracı, triyajın ilk aşamasını gerçekleştirir. Kurulum bir öğleden sonra sürer. Başlamadan önce kaynak kullanımı ve gerçekçi limitler bölümlerini okumanız önerilir.

Superlog, Apache 2.0 lisansına sahiptir ve github.com/superloglabs/superlog adresinde yer alır. Ağustos 2026 itibarıyla yaklaşık 1.2 bin yıldıza, main üzerinde yaklaşık 460 commite sahiptir ve herhangi bir sürüm etiketi bulunmamaktadır. Bu son durum kurulum sürecini belirler: git checkout v1.0.0 üzerinde kontrol edilecek bir sürüm bulunmadığından, ya kendiniz bir commit sabitlemeli ya da klonladığınız sabah main üzerinde hangi kod mevcutsa onunla çalışmalısınız.

Superlog'un Uptime Kuma ve Langfuse'un yanıtlamadığı sorular

Self-hosted izleme araçları dışarıdan bakıldığında birbirinin aynısı gibi görünür. Ancak durum böyle değildir; yanlış aracı çalıştırmak, hiçbir fayda sağlamadan sunucu kaynaklarınızı tüketir.

• Uptime Kuma uç noktalarınızı dışarıdan denetler ve tek bir soruya yanıt verir: servis ayakta mı?
• Zabbix, Ubuntu 24.04 üzerindeki ana bilgisayarları ve servisleri izler; CPU, bellek, disk ve servis durumunu belirlediğiniz eşik değerlerine göre kontrol eder.
• Langfuse, LLM çağrılarını izler; her bir çağrının istemini, modelini, token sayısını, gecikme süresini ve maliyetini kaydeder.
• Superlog, sıradan servislerinizin zaten ürettiği telemetri verilerini alır ve tekrarlayan hataları birer olaya (incident) dönüştürür.

Superlog farklı bir soruya odaklanır: bir şey bozuldu, ne bozuldu ve neden bozuldu? LLM çağrıları hakkında bir görüşü yoktur ve sizi dışarıdan denetlemez. Normal uygulama kodunuzdan OTLP verilerini alır ve triyaj aşamasına bir aracı yerleştirir; bu, nöbetçi bir uzmanın zaten yapacağı ilk inceleme adımıdır.

VPS bütçesi için önemli olan ayrım depolamadır. Uptime Kuma, birkaç bin kontrol sonucunu sakladığı için 1 GB RAM ile sorunsuz çalışır. Superlog ise bir sütun tabanlı depolama (column store) kullanır; çünkü telemetri verileri bir kez yazılır ve ardından milyonlarca satır üzerinde zaman aralığına göre sorgulanır. ClickHouse bunun içindir, Postgres ise bunun için değildir. Postgres, projeler, kullanıcılar, olaylar ve alım anahtarları gibi küçük ilişkisel verileri tutarak yığındaki yerini korumaya devam eder.

docker compose up -d komutu aslında neyi başlatır?

Üç container başlatılır ve bunlardan hiçbiri Superlog değildir. Bu durum, tek komutla kurulum bekleyen kullanıcılar için şaşırtıcı olabilir.

• postgres:16, 5434 numaralı ana makine portunda yayınlanır
• clickhouse/clickhouse-server:26.1, HTTP için 8123 ve yerel protokol için 9000 numaralı portlarda çalışır
• otel/opentelemetry-collector-contrib:0.150.1, gRPC için 4317 ve HTTP üzerinden OTLP için 4318 numaralı portlarda çalışır

Superlog uygulamaları, pnpm dev tarafından başlatılarak kaynak koddan ana makine üzerinde çalıştırılır. Ağustos 2026 itibarıyla depoda bir üretim (production) compose dosyası bulunmamaktadır; bu nedenle uzun süreli bir kurulum, her uygulamanın start betiği etrafında kendi systemd birimlerinizi oluşturmanızı veya ağaç yapısında sunulan uygulama bazlı Dockerfile dosyalarını kullanmanızı gerektirir.

Bir verinin izlediği yolu aklınızda tutun, çünkü aşağıda belirtilen her hata bu yolun bir aşamasındaki kopukluktan kaynaklanır. Uygulamanız OTLP verisini Superlog alım proxy'sine gönderir. Proxy, isteği ingest key değerinizle doğrular, üzerine proje kimliğini ekler ve collector bileşenine iletir. Collector, istemcinin ayarlamaya çalıştığı tüm superlog.* özniteliklerini temizler, proxy tarafından sağlanan başlıktan superlog.project_id değerini ekler, verileri gruplandırır ve ClickHouse üzerine yazar. Web uygulaması ve API, telemetri verilerini ClickHouse'dan, diğer tüm verileri ise Postgres üzerinden okur.

Bu öznitelik temizleme işlemi bir süsleme değil, gerçek bir çoklu kiracılık (multi-tenancy) denetimidir. Bu işlem olmasaydı, geçerli bir ingest key değerine sahip herhangi biri superlog.project_id değerini kendisi ayarlayabilir ve başka bir projenin verilerine yazabilirdi.

VPS ne kadar büyük olmalı?

Düşük veri girişi hacmine sahip tek düğümlü bir kurulum için 4 vCPU, 8 GB RAM ve 40 GB SSD planlayın. Bu bir ölçüm değil, planlama tabanıdır; bu nedenle bunu başlangıç boyutu olarak kabul edin ve kendi trafiğinize göre kontrol edin.

Bellek dört farklı yere gider. ClickHouse, yüksek RAM kapasiteli makineler için tasarlanmıştır ve varsayılan ayarları bunu temel alır. Postgres 16, telemetri yerine meta veri tuttuğu için bu konuda daha mütevazıdır. Collector da aynı şekilde mütevazıdır. Dört Node süreci ise öyle değildir: Bir Vite geliştirme sunucusu ve üç adet tsx watch süreci, her biri yüzlerce megabayt bellek kullanır; bu yüzden 2 GB kapasiteli bir makinede pnpm dev çalıştırmak oldukça zordur.

Disk, daha az belirgin olan sorundur. Bu monorepo üzerindeki pnpm install, siz henüz tek bir span bile almadan AWS SDK, ClickHouse istemcisi, OpenTelemetry SDK ve React araç zincirini çeker. ClickHouse ise trafiğinizle birlikte büyür. Her ikisini de ölçün:

df -h /
free -m
docker stats --no-stream
docker compose exec clickhouse clickhouse-client --database superlog --query "SELECT table, formatReadableSize(sum(bytes_on_disk)) AS size FROM system.parts WHERE active AND database = 'superlog' GROUP BY table ORDER BY sum(bytes_on_disk) DESC"

Düşük hacimde, yani dakikada birkaç yüz span gönderen bir avuç servis varken, makine sessizdir ve ClickHouse çoğu zaman boştadır. Asıl yük oluşturan durum ani artışlardır: Hatalı bir dağıtımın dakikada binlerce aynı hatayı üretmesi gibi. Fingerprinting özelliği bunları okuyucu için tek bir olayda birleştirir, ancak ClickHouse arka planda her satırı yazmaya devam eder.

Veri saklama süresini belirlemek size aittir. Collector'ın ClickHouse dışa aktarıcısı tabloları, otel_traces, otel_logs ve metrik türü başına bir tablo olacak şekilde oluşturur; yalnızca infra/collector/config.yaml içindeki yapılandırmada bir yaşam süresi (TTL) belirlenmişse bunu uygular. Hiçbir veri kendiliğinden silinmez, bu nedenle planlama yapmazsanız yoğun bir ayın sonunda diskiniz tamamen dolacaktır.

Sabitlenmiş bir commit üzerinden kurulum

git clone https://github.com/superloglabs/superlog.git
cd superlog
git tag -l
git log -1 --format='%H %cs %s'

git tag -l hiçbir şey yazdırmaması, Ağustos 2026 itibarıyla beklenen sonuçtur. Test ettiğiniz commit'i seçin ve o commit üzerinde kalın:

git checkout 0d3a6c8bb63eda3493e6ba0003e7c2a70750bc1e

Sırada araç zinciri var:

node -v
corepack enable
corepack prepare pnpm@9.12.0 --activate
pnpm -v

package.json, engines.node değerini >=20.0.0 olarak, packageManager değerini ise pnpm@9.12.0 olarak tanımlar. Kurulumu daha eski bir Node sürümü üzerinde çalıştırırsanız pnpm, istediği sürümü belirterek ERR_PNPM_UNSUPPORTED_ENGINE hatasıyla durur. Ubuntu 24.04 arşivindeki nodejs paketi 20'den daha eski bir sürümdür; bu nedenle Node 20 veya daha yeni bir sürümü NodeSource üzerinden ya da nvm kullanarak kurun. Depo bir .nvmrc içerir, bu sayede nvm kullanıyorsanız nvm use komutu hedeflenen sürümü otomatik olarak seçer.

pnpm install
docker compose up -d
docker compose ps

up -d komutunun hazır olduğunu varsaymak yerine sağlık kontrollerinin tamamlanmasını bekleyin. Postgres ve ClickHouse, compose dosyasında birer sağlık kontrolü tanımlar:

curl -sS http://127.0.0.1:8123/ping
pg_isready -h 127.0.0.1 -p 5434 -U postgres

ClickHouse Ok. yanıtını verirken, pg_isready ise accepting connections yanıtını verir. 8123 numaralı portta bağlantının reddedilmesi, container'ın hala başlatılıyor olduğu veya çöktüğü anlamına gelir. docker compose logs clickhouse hangisinin gerçekleştiğini gösterir; docker inspect $(docker compose ps -q clickhouse) | grep -i oomkilled ise çekirdek (kernel) bellek yetersizliği nedeniyle süreci sonlandırdığında true raporunu verir. Bu durum, yapılandırmanızdan ziyade sunucunun yetersiz kaynaklara sahip olduğuna işaret eder.

Ardından migrasyon ve uygulamalar:

pnpm --filter @superlog/db db:migrate
pnpm dev

Port numarasına dikkat edin: 5432 değil, 5434. Compose dosyası, ana makinede halihazırda kurulu olan bir Postgres ile çakışmaması için Postgres'i 5434 numaralı portta yayınlar. Uygulamanın .env.example dosyaları, DATABASE_URL=postgres://postgres:postgres@localhost:5434/superlog ile bu yapılandırmayla eşleşir. Migrasyonu halihazırda Postgres çalıştıran bir sunucuda 5432 numaralı porta yönlendirirseniz, ya bağlantı reddedilir ya da daha kötüsü, migrasyon yanlış veritabanına uygulanır.

pnpm dev, deponun Procfile dosyasında listelenen dört süreci başlatır: api, web, worker ve proxy. Her biri çıktısını tmp/logs/ dosyasına yönlendirir; bu nedenle veri alımını izlemek için tail -f tmp/logs/proxy.log dosyasını takip etmelisiniz. README dosyası web uygulamasını http://localhost:5173, API'yi http://localhost:4100 ve OTLP veri alımını http://localhost:4101 portuna yerleştirir.

Herhangi bir şeyi yönlendirmeden önce hangi portun dinlendiğini doğrulayın:

ss -lntp | grep -E '4100|4101|5173'
curl -sS http://127.0.0.1:4101/health

Bu durum daha sonra önem kazanır. Proxy, kendi portunu PORT ortam değişkeninden okur ve PORT değişkeni ayarlanmadığında 4000 numaralı porta döner. Geliştirme ortamı bu değişkeni sizin yerinize ayarlar. Kendi yazdığınız bir systemd birimi bunu yapmaz; bu nedenle 4000 numaralı portu dinleyen bir proxy'ye karşı 4101 numaralı porta yönlendirilen bir dışa aktarıcı (exporter), bağlantı reddedildi hatası verir ve size başka bir ipucu sunmaz.

Bir iz gönderin, bir hata oluşturun, bir olay görün

Web uygulamasında bir proje oluşturun ve ingest key değerini kopyalayın. Alım servisi (intake), her isteği bu anahtara göre doğrular; dolayısıyla anahtar olmadan gönderilen telemetri verileri asla ClickHouse'a ulaşmaz.

Herhangi bir OpenTelemetry SDK'sını, standart ortam değişkenlerini kullanarak alım servisine yönlendirin:

export OTEL_SERVICE_NAME=checkout-api
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_ENDPOINT=http://127.0.0.1:4101
export OTEL_EXPORTER_OTLP_HEADERS='x-api-key=YOUR_INGEST_KEY'

Alım servisi, anahtarı x-api-key başlığından okur; dışa aktarıcınızı (exporter) yapılandırmak daha kolaysa authorization: bearer YOUR_INGEST_KEY değerini de kabul eder. Üç standart OTLP yoluna (/v1/traces, /v1/logs ve /v1/metrics) ek olarak /health yoluna da hizmet verir.

Dikkat edilmesi gereken bir tuzak vardır. OTEL_EXPORTER_OTLP_ENDPOINT bir temel URL'dir ve SDK, sinyal yolunu buna ekler. OTEL_EXPORTER_OTLP_TRACES_ENDPOINT gibi sinyale özel değişkenler, sonuna herhangi bir yol eklenmeden, yazıldığı gibi kullanılır. Sinyale özel değişkeni http://127.0.0.1:4101 olarak ayarlarsanız, her dışa aktarma işlemi / adresine gönderilir. Bu bir rota olmadığı için hiçbir veri ulaşmaz ve uygulamanız sağlıklı görünürken SDK bir dışa aktarma hatası günlüğü oluşturur.

Node servisi için kodsuz (zero code) yol, işlem hattını doğrulamak için yeterlidir:

npm install @opentelemetry/api @opentelemetry/auto-instrumentations-node
node --require @opentelemetry/auto-instrumentations-node/register server.js

Şimdi kasıtlı olarak bir şeyi bozun. Hata fırlatan herhangi bir rota işinizi görecektir:

curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000/boom

Sıçrama noktalarını (hops) sırasıyla kontrol edin; çünkü ilk boşluk, hangisinin başarısız olduğunu size söyler:

tail -n 50 tmp/logs/proxy.log
docker compose exec clickhouse clickhouse-client --database superlog --query 'SELECT count() FROM otel_traces'

Web uygulamasında boş bir proje varken otel_traces değerindeki artış, bir proje uyuşmazlığına işaret eder; bu nedenle ingest key değerinin hangi projeye ait olduğunu kontrol edin. Proxy günlüğünde hareket varken sabit kalan bir sayaç, collector veya ClickHouse yazma işlemine işaret eder; bu durumda docker compose logs collector dosyasını okuyun. Proxy günlüğünde hiçbir hareket olmaması, dışa aktarıcının alım servisine hiç ulaşmadığı anlamına gelir: yanlış port, yanlış yol veya reddedilen bir anahtar.

Web uygulamasında bu tekrarlayan hatalar, istek başına bir satır yerine tek bir olay olarak ulaşır. Superlog, gelen sinyallerin parmak izini alır ve eşleşenleri gruplandırır; bu, gelen kutusunda 4.000 özdeş hata tutmak ile tek bir sayfa tutmak arasındaki farktır. Ajan daha sonra araştırmasını bu grubun üzerine yazar.

Araştırma adımı bir model çağırır, bu nedenle worker üzerinde yapılandırılmış bir model sağlayıcısı gerekir. Bu değişken isimlerini, herhangi bir harici dokümandan değil, sabitlediğiniz commit içindeki her uygulama dizininde bulunan .env.example dosyasından alın; çünkü bu isimler main ile birlikte değişir. Aynı durum, kendi kurulum belgelerini docs/github-app-setup.md ve docs/sentry-app-setup.md adreslerinde barındıran, webhook yükleri docs/webhooks.md içinde belgelenmiş GitHub ve Sentry entegrasyonları için de geçerlidir.

Giriş noktasını gizli tutun ve ajanı salt okunur yapın

Docker, konteyner portlarını varsayılan olarak 0.0.0.0 üzerinde yayınlar. Docker, kendi kurallarını ufw paketleri görmeden önce değerlendirilen DOCKER-USER zincirine yazdığı için bu yayınlanan portlar ufw'yi atlatır. Genel IP adresine sahip bir VPS üzerinde, dağıtılan compose dosyası ClickHouse HTTP'yi 8123 ve Postgres'i 5434 portuna koyar; böylece internet üzerinden bunlara erişilebilir hale gelir. Bu dosyadaki kimlik bilgileri geliştirme aşamasına ait varsayılanlardır: boş parolalı default kullanıcısı ile ClickHouse ve hem kullanıcı adı hem de parola olarak postgres kullanılan Postgres.

Bunları loopback arayüzüne bağlayın. Compose dosyasındaki her yayınlanan port, ana makine tarafını bir ortam değişkeninden alır, bu nedenle depo kök dizinindeki bir .env yeterlidir:

POSTGRES_HOST_PORT=127.0.0.1:5434
CLICKHOUSE_HTTP_HOST_PORT=127.0.0.1:8123
CLICKHOUSE_TCP_HOST_PORT=127.0.0.1:9000
COLLECTOR_GRPC_HOST_PORT=127.0.0.1:4317
COLLECTOR_HTTP_HOST_PORT=127.0.0.1:4318

Güvenmeden önce sonucu doğrulayın ve ardından konteynerleri yeniden oluşturun:

docker compose config
docker compose up -d
ss -lntp | grep -E '5434|8123|9000|4317|4318'

docker compose config, çözümlenmiş dosyayı yazdırır; böylece tahmin etmek yerine 127.0.0.1:5434:5432 dosyasını okuyabilirsiniz. ss komutu daha sonra 127.0.0.1:5434 çıktısını vermeli ve asla 0.0.0.0:5434 çıktısını göstermemelidir. Bunu, ports değerini yeniden tanımlayan bir compose override dosyası ile düzeltmeye çalışmayın; çünkü Compose, port listelerini dosyalar arasında değiştirmek yerine birleştirir. Bu durumda hem yerel bağlamalar hem de herkese açık olan port açık kalmaya devam eder.

Giriş noktasının da aynı özeni göstermesi gerekir. Veri alım anahtarınız bir başlık (header) içinde taşınır, bu nedenle önünde TLS (transport layer security) olması gerekir: TLS sonlandırmasını proxy'nin önündeki nginx veya Caddy üzerinde yapın ya da veri alımını özel bir ağ veya WireGuard tüneli içinde tutun. 5173 portundaki web uygulaması bir Vite geliştirme sunucusudur ve internete açık olmaması gerekir.

Sırada ajanın kendisi var. Superlog'un temel vaadi, ajanın inceleme yapması ve bir düzeltme önermesidir; burada önemli olan kelime "önermek"tir. Birkaç gerçek olay üzerinde nasıl çalıştığını gözlemleyene kadar ajanı üretim ortamına karşı salt okunur tutun. GitHub App'e okuma kapsamları verin ve inceleyeceğiniz pull request'ler oluşturmasına izin verin. Telemetriyi okuyan ve bir yama yazan bir ajan faydalıdır. Servislerinizi yeniden başlatabilen bir ajan farklı bir risk seviyesidir ve bu, devraldığınız bir varsayılan değil, bilinçli olarak verdiğiniz bir karar olmalıdır. Maliyet de aynı ilgiyi hak eder, çünkü her inceleme bir model çağrısıdır: yoğun bir üretim sistemine yönlendirmeden önce VPS üzerinde ajan harcamaları için bütçe belirleyin ve şaşırtıcı bir pull request durumunda izlenebilir bir kayıt olması için ajanın gerçekte ne yaptığına dair bir kayıt tutun.

Karşılaşacağınız hatalar ve bunları tanımlayan dizgeler

• ERR_PNPM_UNSUPPORTED_ENGINE sırasında pnpm install, Node sürümünün 20'den eski olduğu anlamına gelir. node -v bunu tek satırda doğrular.
• Geçiş sırasında ECONNREFUSED 127.0.0.1:5434, compose yığınının çalışmadığı veya DATABASE_URL ifadesinin yanlış portu belirttiği anlamına gelir.
• ClickHouse'un döngüsel olarak yeniden başlaması genellikle bellek kaynaklıdır. docker compose logs clickhouse dosyasını okuyun, ardından container içinde OOMKilled değerinin true olup olmadığını kontrol edin.
• Web uygulaması boş kalırken başarı raporlayan bir exporter, verinin doğrudan 4318 portundaki collector'a gittiği ve proxy'nin yaptığı proje damgalama işlemini atladığı anlamına gelir.
• Üretim kurulumunda 4101 portunda bağlantının reddedilmesi, proxy'nin PORT=4000 değerine geri döndüğü anlamına gelir. PORT değerini unit dosyası içinde açıkça tanımlayın.
• 0.0.0.0:8123 gösteren docker compose ps, loopback bağlamalarınızın etkin olmadığı anlamına gelir. docker compose config komutunu çalıştırın ve çözümlenen portları okuyun.

Flawless, HyperProbe ve Superlog'un konumu

Bu kategori henüz yenidir ve araçlar, ajanın nelere müdahale edebileceği konusunda farklı yaklaşımlara sahiptir. Flawless, Kubernetes odaklı açık kaynaklı bir AI SRE (site güvenilirliği mühendisliği) aracıdır; veri hattını yönetmek yerine mevcut Prometheus, Loki ve Grafana yığınından okuma yapar. HyperProbe ise tam tersi bir yol izler: Ağustos 2026 itibarıyla kapalı kaynak kodlu, barındırılan bir üründür. Çalışan bir sürecin içine salt okunur problar yerleştirerek değişken durumunu yakalar ve bu durumu MCP (model context protocol) üzerinden bir asistana sunar.

Superlog ise bu ikisinin arasında yer alır. OTLP alımından ClickHouse depolamasına kadar veri hattının tamamını yönetir ve ajanını düzeltme aşaması yerine triyaj aşamasına yerleştirir. Bu tasarım, Superlog'u kendi sunucunuzda barındırmanın neden sadece bir container çalıştırmaktan ibaret olmadığını, aksine bir altyapı kararı olduğunu açıklar. Superlog'u çalıştırdığınızda bir sütun tabanlı veritabanı (column store) çalıştırmış olursunuz ve bu veritabanı, sahip olduğunuz diğer tüm veritabanları ile aynı özeni gerektirir.

FAQ

Kendi sunucumda barındırdığım Superlog ne kadar RAM gerektirir?

Düşük veri girişi hacmine sahip tek bir düğüm için 8 GB RAM, 4 vCPU ve 40 GB disk alanı planlayın. Yığın; Postgres, ClickHouse, bir OpenTelemetry toplayıcısı ve dört Node sürecinden oluşur; ClickHouse ise çalışma alanı (headroom) bekler. 1 GB veya 2 GB kapasiteli bir VPS yeterli değildir: pnpm install tek başına ağırdır ve ClickHouse, yük altında çekirdeğin bellek yetersizliği sonlandırıcısı (OOM killer) tarafından kapatılır. Buradaki dahil olmak üzere yayınlanan hiçbir rakama güvenmek yerine, kendi değerlerinizi docker stats --no-stream ve free -m ile ölçün.

OTLP dışa aktarıcımı (exporter) hangi porta yönlendirmeliyim?

README dosyasında http://localhost:4101 üzerinde belirtilen Superlog giriş proxy'sine yönlendirin. Bu proxy /v1/traces, /v1/logs ve /v1/metrics servislerini sunar ve kimlik doğrulamayı x-api-key başlığından veya bir authorization: bearer başlığından alınan proje giriş anahtarınızla yapar. 4318 numaralı port alttaki OpenTelemetry toplayıcısına aittir; doğrudan oraya dışa aktarım yapmak, verilerinize proje kimliğinizi damgalayan proxy bileşenini devre dışı bırakır. PORT ayarlanmadığında proxy 4000 numaralı porta döner; bu nedenle 4101 varsayımında bulunmadan önce ss -lntp komutunu çalıştırın ve hangi porta bağlandığını doğrulayın.

Superlog, Uptime Kuma veya Zabbix'in yerini alır mı?

Hayır. Uptime Kuma, bir uç noktanın ağınızın dışından yanıt verip vermediğini kontrol eder; Zabbix ise ana makine ve servis metriklerini belirlediğiniz eşik değerlerine göre izler. Superlog, uygulamalarınızın ürettiği izleri (traces), günlükleri (logs) ve metrikleri tüketir ve tekrarlanan hataları olaylar (incidents) halinde gruplandırır. Yanında harici bir çalışma süresi (uptime) sondası bulundurmaya devam edin; çünkü telemetri hattınızı barındıran sunucu çöktüğünde, başka bir yerde çalışan sonda durumu raporlamaya devam edecektir.

Superlog ajanı üretim sistemlerimi değiştirebilir mi?

Yalnızca sizin verdiğiniz izinler dahilinde. Çıktısı bir inceleme ve bir insan tarafından gözden geçirilen önerilen bir değişikliktir. GitHub uygulamasını başlangıçta okuma kapsamlarında tutun ve pull request yetkisi verin; çalışanın sahip olduğu tüm kimlik bilgilerini okuma ile sınırlayın. Üretim ortamına yazma erişimini bilinçli ve ayrı bir karar olarak değerlendirin; servisleri yeniden başlatabilen bir ajan, telemetri okuyan ve inceleme için yama yazan bir ajandan çok daha büyük bir sorumluluktur.

Bir commit'i sabitlemeli miyim yoksa main dalını mı takip etmeliyim?

Bir commit'i sabitleyin. Ağustos 2026 itibarıyla depoda herhangi bir sürüm etiketi bulunmamaktadır, bu nedenle main sunulan tek hareketli hedeftir ve haftada birkaç commit almaktadır. Test ettiğiniz SHA değerini kaydedin, onu dağıtın ve ilerlemeden önce farkları (diff) okuyun. git log --oneline <old-sha>..main inceleme sürecidir; uygulama bazlı .env.example dosyaları ise herhangi bir sürüm yükseltmesinden sonra yeni gerekli değişkenleri arayacağınız ilk yerdir.