OpenAnalytics Kendi Sunucuna Nasıl Kurulur?

Adım öncesi gereksinimler

OpenAnalytics'i kendi sunucunuzda barındırmak için yaklaşık 4 GB RAM'e, 25 GB boş disk alanına, Docker Compose eklentisine sahip bir Linux VPS'e ve sunucunuza yönlendirilmiş dört adet DNS kaydına ihtiyacınız vardır. Bu, dürüst bir özet niteliğindedir ve ilk komuttan önce belirtilmesi gerekir.

Yığın, altı uygulama servisi ve üç veri deposundan oluşur. Postgres kontrol düzlemini tutar: hesaplar, siteler, API anahtarları ve paylaşım bağlantıları. ClickHouse, ham etkinlikleri ve panonun okuduğu özet verileri saklar. Valkey iki kez çalışır; bir kez kalıcı bir etkinlik kuyruğu olarak, bir kez de sistemin kaybetmeyi göze alabileceği bir önbellek olarak; çünkü bu iki işin zıt tahliye politikalarına ihtiyacı vardır. ClickHouse'u okumasına izin verilen tek süreç sorgu ağ geçididir ve bu süreç, her sorgu zarfındaki Ed25519 imzasını çalıştırmadan önce doğrular.

Eğer tek bir ikili dosya ve tek bir yapılandırma dosyası arıyorsanız, bu doğru seçenek değildir. GoatCounter, bu kategorideki tek ikili dosya seçeneğidir: tek bir Go çalıştırılabilir dosyası, varsayılan olarak SQLite ve hiçbir harici veritabanı gerektirmez. Daha ağır olan bu yığın size dönüşüm hunileri, web verileri, kendi Stripe hesabınızdan gelir ilişkilendirmesi ve bir MCP (model context protocol) sunucusu sağlar. Self-hosted analiz araçları arasında seçim yapmak başlıklı yazı, bu tercihi değerlendiren makaledir. Bu kılavuz, kararı zaten verdiğinizi varsayar.

Önce dört DNS kaydını sunucuya yönlendirin

Herhangi bir işleme başlamadan önce dört alt alan adının sunucunun genel IP adresine yönlendirilmesi gerekir. Caddy, ilk başlatma sırasında Let's Encrypt sertifikaları talep eder ve henüz çözümlenmeyen bir isim için doğrulama süreci başarısız olur.

• app.example.com paneli sunar.
• api.example.com API ve OAuth geri çağrılarını sunar.
• c.example.com toplayıcıyı ve takip betiğini sunar.
• rt.example.com gerçek zamanlı akışı sunar.

Dört adet A kaydı veya bir adet A kaydı ile ona işaret eden üç adet CNAME kaydı kullanın. Devam etmeden önce dig +short app.example.com ile doğrulamayı yapın. Bir dakika önce eklediğiniz bir isim, Let's Encrypt'in kullandığı çözümleyici tarafından hala NXDOMAIN olarak önbelleğe alınmış olabilir. Bu nedenle başarısız olan ilk sertifika denemesinde beklemek ve Caddy günlüklerini incelemek faydalıdır. Kurulumu yeniden çalıştırmak DNS yayılımını hızlandırmaz.

Docker Compose ile OpenAnalytics self-host etme

Etiketlenmiş bir sürümü (tagged release) kontrol edin. Varsayılan dal (default branch) geliştirme sürecinin yürütüldüğü yerdir; yayınlanan imajlar ise doğrudan sürüm etiketleriyle eşleşir. Aşağıdaki komutlar, Docker ve Compose eklentisinin halihazırda kurulu olduğunu varsayar; bu konu bir VPS üzerinde Docker Compose servislerini çalıştırma rehberinde ele alınmıştır.

git clone https://github.com/OpenLabs-so/openanalytics
cd openanalytics
git checkout "$(git tag -l 'v*' --sort=-v:refname | sed '/-/d' | head -1)"
cd infra/selfhost
./generate-secrets.sh --domain example.com --email you@example.com --with-geoip
docker compose pull && docker compose up -d

Checkout satırındaki sed '/-/d', sürüm adayı (release candidate) yerine en yeni kararlı sürüme ulaşmanızı sağlamak için ön sürümleri eler. --with-geoip, oluşturma sırasında DB-IP şehir veritabanını çeker. Bu adımı atlarsanız her etkinlik boş (null) bir ülke bilgisiyle kaydedilir ve coğrafi görünümde hiçbir veri görüntülenemez. Bu veritabanını daha sonra infra/selfhost/geoip/fetch-dbip.sh komutunu çalıştırarak, env/collector.env dosyasında GEOIP_DB_PATH=/geoip/dbip-city-lite.mmdb ayarını yapılandırarak ve ardından docker compose up -d --force-recreate collector ile toplayıcıyı (collector) yeniden oluşturarak ekleyebilirsiniz. Söz konusu veritabanı aylık olarak güncellenir; bu nedenle şehir verilerinizin güncelliğini yitirmemesi için indirme işlemini aylık olarak tekrarlayın.

İlerlemeden önce oluşturulan gizli verileri yedekleyin

Oluşturucu üç farklı öğe yazar. .env, alan adlarını ve imaj referanslarını tutar. env/*.env, her servis için bir adet gizli veri dosyası barındırır. docker-compose.override.yml, çok satırlı PEM formatı bir env dosyasında barındırılamayacağı için üç adet Ed25519 anahtar çiftini YAML blok skalerleri olarak tutar. Bunların tamamı git tarafından yoksayılır (git-ignored) ve hiçbiri aynı değerlerle yeniden oluşturulamaz.

Bu dosyaları şimdi makineden başka bir yere kopyalayın. Her bir kaybın belirli bir maliyeti vardır:

• Veri deposu parolalarını kaybederseniz Postgres ve ClickHouse'a erişiminiz kesilir; bu parolalar yalnızca container içinden sıfırlanabilir.
• OA_CREDENTIAL_KEYRING dosyasını kaybederseniz depolanan tüm üçüncü taraf kimlik bilgileri kurtarılamaz hale gelir; bu durumda Stripe hesabı bağlamış olan herkesin hesabı yeniden bağlaması gerekir.
• ANONYMOUS_IDENTITY_SECRET dosyasını kaybederseniz ziyaretçi kimlikleri yeniden temel alınır: dünkü ziyaretçilerin tamamı yeni ziyaretçi olarak sayılır ve bu kopukluk grafiklerde görünür hale gelir.
• AUTH_SECRET dosyasını kaybederseniz tüm oturumlar geçersiz kılınır ve herkesin tekrar giriş yapması gerekir.
• Bir imzalama özel anahtarını kaybederseniz anahtar çiftini yenilersiniz. Hiçbir veri kaybolmaz.

İki gizli verinin, ikişer dosya içerisinde bayt bazında aynı olması gerekir. ANONYMOUS_IDENTITY_SECRET, collector.env ve worker.env içerisinde yer alır; çünkü toplayıcı (collector) ziyaretçi özetini (hash) hesaplar ve çalışan (worker) bunu yazar. OA_CREDENTIAL_KEYRING, api.env ve worker.env içerisinde yer alır. Diğer tüm veriler kasıtlı olarak yalnızca tek bir servise özel olarak tanımlanmıştır; kendisine ait olmayan bir gizli veri verilen servis, başlatılmak yerine hata vererek kapanır.

Yığını ayağa kaldırın ve kontrol edin

grep OA_IMAGE .env
docker compose pull
docker compose up -d
docker compose logs -f migrate
docker compose ps

migrate, Postgres ve ClickHouse şemalarını uygular ve ardından sonlanır; bu nedenle durdurulmuş bir migrate container'ı doğru nihai durumdur. tracker-build, oa.js'i Caddy'nin servis ettiği bir volume içine derler ve o da sonlanır. Diğer her şey docker compose ps içinde healthy durumunda olmalıdır. Döngüsel olarak yeniden başlayan bir servis, neredeyse her zaman ortam doğrulama hatası veriyordur; günlük kayıtları, her yeniden başlatma için bir tane yerine tüm sorunları tek bir liste halinde yazdırır. İki yaygın neden şunlardır: boş bırakılan bir değişkenin unset olarak kabul edilmek yerine reddedilmesi ve yanlış servis dosyasına yerleştirilen bir secret.

arm64 mimarisinde veya bir branch üzerinden çalışırken yayınlanmış imajlar bulunmaz; bu durumda docker compose up -d --build ile yerel olarak derleme yapmanız gerekir. 4 GB belleğe sahip bir sunucu, derleme sırasında bellek yetersizliği hatası verebilir. Yalnızca derleme esnasında gerekli olan swap alanını önceden ekleyin:

fallocate -l 4G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

Derleme işlemi yaklaşık on dakika sürer. İmajların çekilmesi ise birkaç dakika alır; yayınlanan imajların var olma nedeni de budur.

İlk hesabı derhal tanımlayın

https://app.example.com adresini açın. Henüz kimsenin giriş yapmadığı bir kurulumda giriş formu görüntülenmez; bunun yerine ilk hesabın oluşturulması istenir. Bu hesap kalıcı olarak yetkili hesaptır ve kurulum ayarları ekranını görebilen tek hesaptır. Hesap oluşturulduğu anda rota 409 yanıtını verir, böylece sizden sonra başka kimse sisteme erişemez. Bu işlemi yığın (stack) sağlıklı hale geldiği anda yapın, bir sonraki haftaya bırakmayın.

Takipçiyi yükleyin

Dashboard üzerinde bir site eklediğinizde size bir etiket verilir. Etiketin biçimi sabittir:

<script
  async
  src="https://c.example.com/oa.js"
  data-key="YOUR_TRACKING_KEY"
  data-collector="https://c.example.com"
></script>

Bu etiketi sayfanın head kısmına yerleştirin. Takip anahtarı tasarımı gereği herkese açıktır, bu nedenle HTML dosyanızda herkesin okuyabileceği bir yerde bulunmalıdır. Betik window.oa kurulumunu yapar ve oa("track", ...) gibi çağrılar bir stub tarafından kuyruğa alınır; dosya yüklendiğinde bu çağrılar işlenir. Böylece erken tetiklenen özel bir etkinlik kaybolmaz. Sayfadaki başka bir öğe halihazırda window.oa kullanıyorsa, takipçi bunun yerine window.openanalytics olarak kurulur.

Ardından tüm yolu uçtan uca kontrol edin:

curl -s https://c.example.com/oa.js -o /dev/null -w '%{http_code} %{size_download}\n'
curl -s https://api.example.com/health | head -c 200
docker compose logs --tail=50 worker | grep -i batch

İlk komut 200 ve birkaç kilobaytlık veri çıktısı vermelidir. Sitenizde bir sayfa yükleyin, ardından birkaç saniye içinde worker günlüğünde bir toplu iş (batch) satırı olup olmadığını kontrol edin. Toplayıcı (collector), bir etkinliği kabul ettiği anda 202 yanıtını döner; 202 ise verinin depolandığı değil, kuyruğa alındığı anlamına gelir. Etkinlikleri ClickHouse içine taşıyan yapı worker'dır. Etkinlikler kabul edildiği halde dashboard üzerinde görünmüyorsa, worker engellenmiş demektir; sürekli artan bir Valkey kuyruk derinliği bunu doğrular. Bunun yaygın nedenleri worker.env içindeki hatalı ClickHouse kimlik bilgileri veya bir migration sonrası tablo üzerinde eksik kalan yetkilendirmelerdir.

Collector'ı herkese açık, paneli ise kimlik doğrulama arkasında tutun

Caddy, compose dosyası içerisinde gelir ve dört alan adının tamamı için sertifikaları kendi başına alır; bu nedenle varsayılan kurulumda herhangi bir proxy yapılandırması yapmanız gerekmez. Eğer sunucuda halihazırda bir nginx reverse proxy çalışıyorsa, yığını sağlanan infra/selfhost/nginx.conf.example ile öne alın ve header işleme kurallarını değiştirmeden koruyun:

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header CF-Connecting-IP "";
proxy_set_header True-Client-IP "";
proxy_set_header Fly-Client-IP "";

Collector, günlük ziyaretçi hash değerini istemci IP adresinden türetir; bu nedenle IP adresini bağlantı üzerinden almalı, asla bir header bilgisinden almamalıdır. CF-Connecting-IP değerini güvenilmeyen bir noktadan geçirmek, herhangi bir istemcinin istediği adresi taklit etmesine olanak tanır; bu durum hem coğrafi konum verilerini bozar hem de ziyaretçi sayılarını hatalı şekilde artırır.

Erişim, alan adına göre net bir şekilde ayrılır. c. ve rt., ölçüm yaptığınız her sitenin ziyaretçisi tarafından erişilebilir olmalıdır; bu nedenle bu iki adresin önüne asla temel kimlik doğrulama (basic auth) veya IP beyaz listesi koymayın. app. ve api. ise yalnızca giriş yapan kişiler tarafından erişilebilir olmalıdır. Paneli koruyan şey uygulamanın kendi kimlik doğrulama mekanizmasıdır: Parola ile giriş, env/api.env içindeki AUTH_PASSWORD_SIGNIN=enabled ayarı ile varsayılan olarak etkindir; Google veya GitHub butonları ise yalnızca ilgili sağlayıcı için istemci kimliği (client ID) ve istemci gizli anahtarı (client secret) tanımlandığında görünür hale gelir. Sihirli bağlantılar (magic links) bir posta iletim servisine ihtiyaç duyar; bu servis olmadan API gönderimi yalnızca bir giden kutusuna yazar, dolayısıyla hiçbir şey iletilmez ve hata da oluşmaz.

Panelin çalışıp çalışmayacağına tek bir ayar karar verir. env/api.env içindeki AUTH_TRUSTED_ORIGINS, panelin kaynak adresiyle (origin) tam olarak eşleşmelidir. Yanlış veya eksik olduğunda, API herhangi bir CORS (cross-origin resource sharing) header bilgisi üretmez, tarayıcı tüm çağrıları reddeder ve siz de arayüzü yüklenen ancak hiçbir veri göstermeyen bir panel ile karşılaşırsınız; bu sırada docker compose ps her şeyin sağlıklı olduğunu raporlar.

Proxy yapılandırması üzerindeyken otomatik trafiği de ele alın. Botlar ve tarayıcılar (crawlers), collector'a diğer her şey gibi erişir ve sayfa görüntüleme verileri ClickHouse'a, dolayısıyla istatistiklerinize yansır. Yapay zeka botlarını sunucu seviyesinde engellemek, bu trafiğin bir kısmını veritabanına girmeden durdurur; böylece hem veri doğruluğunuzu korur hem de disk kullanımından tasarruf edersiniz.

Burada cookieless ne anlama gelir ve size maliyeti nedir

Çerez kullanılmaz. Ziyaretçi kimliği tuzlanmış bir hash değeridir, tuz her gün yenilenir ve ham IP adresleri asla saklanmaz. Coğrafi konum belirleme, kendi diskinizdeki DB-IP dosyası üzerinden yerel olarak çözümlenir; bu nedenle ziyaretçiye dair hiçbir sorgu sunucudan dışarı çıkmaz.

Bunun size sağladığı avantaj, ziyaretçinin cihazında kalıcı bir tanımlayıcının bulunmamasıdır; AB ePrivacy onay kuralları kapsamında bir takipçiyi kapsama alanına sokan temel unsur budur. Bu yapıdaki gibi yalnızca toplu veri (aggregate) kullanan kurulumlar, bu nedenle genellikle onay başlığı olmadan çalıştırılır. GDPR, neyi ne kadar süreyle sakladığınızı düzenlemeye devam eder; durumunuzu bir README dosyası değil, kendi hukuk danışmanınız belirler.

Bunun size maliyeti ise günler arası kimlik takibidir. Tuz rotasyonu, Pazartesi günü ziyaret eden bir kişinin Çarşamba günü tekrar geldiğinde iki farklı ziyaretçi olarak sayılması anlamına gelir; bu tasarımın bir parçasıdır ve bir çözümü yoktur. Günlük tekil ziyaretçi sayıları doğrudur. Haftalık ve aylık tekil ziyaretçi sayıları günlük verilerden oluşturulur ve erişimi olduğundan fazla gösterir; bu nedenle uzun vadeli "geri gelen ziyaretçi" verileri, etiketinde belirtilen şeyi ölçmez. Oturumlar ve kullanıcı yolculukları tek bir gün içerisinde güvenilirdir. ANONYMOUS_IDENTITY_SECRET rotasyonu, gün sınırı ile aynı etkiye sahiptir; bu nedenle rotasyonu rutin bir temizlikten ziyade bir veri değişikliği olarak değerlendirin.

Toplayıcı, Do Not Track ve Global Privacy Control sinyallerine saygı duyar; bunlar tarayıcının siteye kişisel verileri satmaması veya paylaşmaması gerektiğini bildiren sinyallerdir. Script etiketi, aynı amaç için kendi anahtarlarını taşır: data-respect-gpc, data-respect-dnt ve onay verilene kadar tüm veri toplamayı durduran ve cevabı localStorage içerisinde oa.consent anahtarı ile hatırlayan data-require-consent. data-storage="none" ayarının yapılması, tarayıcı depolamasını tamamen kapatır.

Disk neden altı ay sonra dolar

Self-hosted bir analitik sunucusunu devre dışı bırakan temel sebep budur ve genellikle olay kayıtları bunun nedeni değildir.

İşe imajlarla başlayın. Bir sürüm yayınlandığında on adet imaj yayınlanır ve bunlar diskte yaklaşık 13 GB yer kaplar. Bir yükseltme işlemi, eski nesli silmeden önce yeni nesli çeker; bu nedenle bir süreliğine iki nesli birden tutarsınız. Tek bir sayfa görüntüleme bile gerçekleşmeden önce 25 GB gereksiniminin büyük kısmı bu şekilde dolar.

Ardından snapshot'lar gelir. snapshot.sh yığını durdurur, her iki veri birimini ve tüm gizli anahtarları arşivler ve ardından yeniden başlatır. Burada tek güvenli yöntem soğuk kopyalardır; çünkü ClickHouse arka planda parçaları birleştirir ve birleştirme sırasında alınan bir kopya tutarlı olmaz. upgrade.sh, her yükseltme öncesinde otomatik olarak bir tane alır, bu nedenle siz onları sınırlandırana kadar arşivler aynı disk üzerinde birikir.

./snapshot.sh create --label before-something-risky
./snapshot.sh list
./snapshot.sh --keep 3

Sınırına yaklaşmış bir sunucuda, yükseltme yapmadan önce önceki nesli geri kazanın. Yığın çalışırken bu işlem güvenlidir; çünkü çalışan container'ları destekleyen imajlar hala referans gösterilmektedir:

docker image prune -a -f

Daha sonra olayların kendisi gelir. ClickHouse sütun tabanlı verileri yoğun bir şekilde sıkıştırır, bu nedenle ham olay hacmi çoğu kişinin beklediğinden daha yavaş büyür ve dashboard'un okuduğu özet tabloları, ham tabloya kıyasla küçüktür. Tahmin etmek yerine ölçüm yapın:

docker system df -v
docker compose exec clickhouse df -h /var/lib/clickhouse

Tablo bazlı rakamlar için, bunu infra/selfhost/env/ altında oluşturulan ClickHouse kimlik bilgileriyle çalıştırın:

SELECT table, formatReadableSize(sum(bytes_on_disk)) AS size, sum(rows) AS row_count
FROM system.parts
WHERE active
GROUP BY table
ORDER BY sum(bytes_on_disk) DESC;

Bu ölçümü birinci haftada ve dördüncü haftada tekrar alın. İki veri noktası size bir büyüme oranı verir ve büyüme oranı, birimin ne zaman yeniden boyutlandırılması gerektiğini söyler. Ağustos 2026 itibarıyla self-hosting kılavuzu, ham olaylar için herhangi bir saklama veya yaşam süresi (TTL) ayarı içermemektedir; bu nedenle eski satırların kendiliğinden silineceğini varsaymak yerine diski ölçtüğünüz orana göre boyutlandırın.

Silme işlemiyle ilgili, sorun yaşamadan önce bilinmesi gereken bir tuzak vardır. Bir siteyi veya hesabı silmek, worker için bir iş kuyruğu oluşturur ve bu worker'ın CLICKHOUSE_MAINTENANCE_USER ve CLICKHOUSE_MAINTENANCE_PASSWORD ayarlarının yapılmış olmasına, ayrıca ClickHouse içinde eşleşen bir oa_maintenance kullanıcısının bulunmasına ihtiyacı vardır. Bunlar olmadan silme işlemi sonsuza kadar kuyrukta bekler. Site dashboard'dan kaybolur ancak tüm satırlar diskte kalır; böylece temizlik yapılmış gibi görünür ancak hiçbir alan geri kazanılmaz.

Yükseltmeler ve üç maliyet

git fetch --tags
git checkout "$(git tag -l 'v*' --sort=-v:refname | sed '/-/d' | head -1)"
cd infra/selfhost
./upgrade.sh

upgrade.sh, işlem yapmadan önce üç maliyeti listeler. Kesinti süresi gerçektir: toplayıcı (collector) kapalıyken denenen olaylar kaybolur, çünkü izleyici (tracker) bunları yeniden denemez. Geri alma (rollback) işlemi veri kaybına yol açar; çünkü rollback.sh --to backups/<snapshot> her iki depoyu da tamamen değiştirir ve o anlık görüntü (snapshot) alındıktan sonra yazılan her satırı siler. Üçüncü maliyet ise yukarıda açıklanan anlık görüntü yığını olan disktir.

İki yeniden başlatma kuralını yanlış anlamak kolaydır. Sorgu ağ geçidini (query gateway) API'den önce ayağa kaldırın; çünkü daha yeni bir API, eski bir ağ geçidinin reddedeceği sorgu alanları gönderir. ClickHouse ise yeniden başlatma yerine yeniden oluşturma (recreate) gerektirir; çünkü docker compose restart konteynerin orijinal ortamını yeniden kullanır ve yaptığınız düzenlemeyi sessizce görmezden gelir:

docker compose up -d --force-recreate clickhouse

Dashboard da aynı tuzak yapısına sahiptir. env/web.env içindeki üç NEXT_PUBLIC_* kaynağı, tarayıcı paketine derlenir ve konteyner başladığında yerlerine yerleştirilir. Bu nedenle yanlış bir ana bilgisayar adını (hostname) çağıran bir dashboard, docker compose up -d --force-recreate web ile düzeltilir; restart ile asla düzelmez. Web konteynerinin günlüğü, başladığı kaynakları yazdırır; bu, düzeltmenin uygulandığını doğrulamanın en hızlı yoludur.

ClickHouse bir yapılandırma düzenlemesinden sonra başlamayı reddederse, günlüğünün ilk satırını okuyun. oa-entrypoint: ile başlayan bir satır, giriş noktasının (entrypoint) ayarladığınız bir değeri reddettiği anlamına gelir. Bunun dışındaki herhangi bir durum genellikle yapılandırma dosyasının geçersiz XML olduğu anlamına gelir. En yaygın neden ise, XML yorumu içinde çift tire kullanılmasıdır; bu, XML içinde yasaktır.

AGPL-3.0 ve isim

Kod, AGPL-3.0 lisansı ile lisanslanmıştır. Kodu kendi siteleriniz için değiştirmeden çalıştırmanız, herhangi bir yayınlama yükümlülüğü doğurmaz. Yükümlülük, kodu değiştirdiğinizde ve bu değiştirilmiş sürümü bir ağ servisi olarak çalıştırdığınızda başlar: lisans bu durumda, değiştirilmiş kaynak kodunuzu söz konusu servisin kullanıcılarına sunmanızı gerektirir. Bu durum, istemcilere kendi örneğiniz üzerinden paneller sunmayı ve kodu sattığınız bir ürünle paketlemeyi kapsar. Değişikliklerinizi herkese açık bir fork üzerinde tutmak, başka bir işleme gerek kalmaksızın bu yükümlülüğü karşılar.

Marka, koddan ayrıdır. "OpenAnalytics" ismi ve projenin barındırıldığı alan adı, yazarların işlettiği örneği tanımlar ve lisans kapsamına dahil değildir. Dağıtımınız yazılımı markayı taşımadan çalıştırır; bu nedenle, servisi ücretli müşterilerinize sunmadan önce ona kendi ismini verin.

FAQ

OpenAnalytics'i 1 GB RAM'e sahip bir VPS üzerinde çalıştırabilir miyim?

Hayır. Proje yaklaşık 4 GB RAM ve 25 GB boş disk alanı gerektirir; çünkü tek bir kurulum, Postgres, ClickHouse ve iki Valkey örneğinin yanı sıra altı uygulama servisini çalıştırır. ClickHouse tek başına küçük bir süreç değildir. 1 GB'lık bir sunucuda container'lar başlar ancak çekirdeğin bellek yöneticisi (OOM killer) genellikle ClickHouse olmak üzere bunlardan birini sonlandırır. Eğer 1 GB'lık bir plan zorunluysa, harici bir veritabanı gerektirmeyen ve SQLite üzerinde çalışan GoatCounter gibi tek ikili dosyadan oluşan araçları kullanın.

OpenAnalytics ile çerez banner'ına ihtiyacım var mı?

Bu sorunun cevabı hukuk danışmanınızdadır, ancak teknik gerçekler lehinizedir. Çerez kullanılmaz; ziyaretçi kimliği günlük olarak değişen tuzlanmış (salted) bir hash değeridir ve ham IP adresleri asla saklanmaz; dolayısıyla ziyaretçiyi tanımlayacak kalıcı hiçbir veri yazılmaz. GDPR, neyi ne kadar süreyle sakladığınızı düzenlemeye devam eder. Veri toplamayı açık bir izne bağlamak isterseniz, script etiketine data-require-consent parametresini ekleyin: bu durumda izleyici, onay verilene kadar hiçbir veri toplamaz ve yanıtı oa.consent altında localStorage içerisinde saklar.

Etkinlikler neden 202 dönüyor ancak dashboard üzerinde görünmüyor?

202, toplayıcının etkinliği kabul edip kuyruğa aldığını belirtir, veritabanına işlendiği anlamına gelmez. Worker süreci bu kuyruğu boşaltıp ClickHouse'a aktarır; bu nedenle başarılı istekler olmasına rağmen boş bir dashboard görüyorsanız sorun worker sürecindedir. docker compose logs --tail=50 worker belgesini okuyun ve Valkey kuyruk derinliğini izleyin. Sürekli büyüyen bir kuyruk, worker sürecinin tıkandığını gösterir; bunun yaygın nedenleri worker.env içerisindeki hatalı ClickHouse kimlik bilgileri veya yakın zamanda yapılan bir migrasyon ile oluşturulan tablo üzerinde eksik olan yetkilendirmelerdir.

Tüm container'lar sağlıklı görünmesine rağmen dashboard neden boş?

Öncelikle env/api.env içerisindeki AUTH_TRUSTED_ORIGINS değerini kontrol edin. Bu değer, dashboard'un kaynak adresiyle tam olarak eşleşmelidir; eşleşmediği durumlarda API, CORS başlıklarını üretmez. Bu nedenle tarayıcı tüm çağrıları reddeder ve siz de verisiz, çalışan bir arayüz görürsünüz. İkinci olarak, web container'ı başladığında yerine yerleştirilen env/web.env içerisindeki üç NEXT_PUBLIC_* değerini kontrol edin. Bunları düzeltmek için docker compose up -d --force-recreate web gereklidir, çünkü basit bir yeniden başlatma işlemi eski değerleri korur.

AGPL-3.0 lisansı, bu hizmeti müşterilere sunmamı engeller mi?

Hayır, sadece bir koşul getirir. Kodu değiştirmeden çalıştırırsanız kimseye karşı bir yükümlülüğünüz olmaz. Kodu değiştirip bu değiştirilmiş sürümü başkalarının kullandığı bir servis olarak sunarsanız, bu kullanıcılara değiştirdiğiniz kaynak kodunu sunmanız gerekir; bunu halka açık bir fork ile sağlayabilirsiniz. Ayrıca, "OpenAnalytics" ismi kodla birlikte lisanslanmamıştır; bu nedenle sattığınız her şeyin kendi ismi olmalıdır.