OpenAnalytics Kendi Sunucunuzda Nasıl Kurulur?

İlk adımdan önceki 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 sunucuya yönlendirilmiş dört adet DNS kaydına ihtiyacınız vardır. Bu, dürüst bir özet niteliğindedir ve ilk komuttan sonra değil, ö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; biri kalıcı bir etkinlik kuyruğu, diğeri ise sistemin kaybetmeyi göze alabileceği bir önbellek olarak görev yapar; çünkü bu iki işin zıt tahliye politikalarına ihtiyacı vardır. Sadece tek bir süreç olan sorgu ağ geçidinin (query gateway) ClickHouse'u okumasına izin verilir 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 huniler, web verileri, kendi Stripe hesabınızdan gelir ilişkilendirmesi ve bir MCP (model context protocol) sunucusu sağlar. Kendi kendine barındırılan analiz araçları arasında seçim yapmak başlıklı yazı, bu tercihi değerlendiren makaledir. Bu kılavuz, kararı çoktan 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 çözümlenmesi 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 (challenge) başarısız olur.

• app.example.com paneli sunar.
• api.example.com API ve OAuth geri çağrılarını (callbacks) 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 A kaydı ile ona işaret eden üç adet CNAME kaydı kullanın. Devam etmeden önce dig +short app.example.com ile doğrulama yapın. Bir dakika önce eklediğiniz bir isim, Let's Encrypt'in kullandığı çözümleyici (resolver) 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

Etiketli bir sürümü (release) kontrol edin. Varsayılan dal (branch) geliştirme sürecinin yürütüldüğü yerdir; yayınlanan imajlar ise 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 için ön sürüm etiketlerini 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 içerisinde GEOIP_DB_PATH=/geoip/dbip-city-lite.mmdb ayarını yaparak 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 çekme işlemini her ay tekrarlayın.

İlerlemeden önce oluşturulan gizli verileri yedekleyin

Üretici üç farklı öğe oluşturur. .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ı bir PEM dosyası env dosyasında barındırılamayacağı için üç adet Ed25519 anahtar çiftini YAML blok skalerleri olarak tutar. Bunların tamamı git-ignored kapsamındadır ve hiçbirinin aynı değerlerle yeniden oluşturulması mümkün değildir.

Bu dosyaları şimdi sunucudan kopyalayın. Her bir kaybın belirli bir maliyeti vardır:

• Veri deposu parolalarını kaybederseniz Postgres ve ClickHouse sistemlerine erişiminizi kaybedersiniz; 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 bağlantıyı yeniden kurması 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 veri, ikişer dosyada bayt bazında aynı olmalıdır. ANONYMOUS_IDENTITY_SECRET, collector.env ve worker.env içinde 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çinde yer alır. Diğer tüm veriler kasıtlı olarak tam olarak tek bir servise atanmıştır; kendisine ait olmayan bir gizli veri verilen servis, başlamak 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 dosyasını 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 görünmelidir. Döngüsel olarak yeniden başlayan bir servis, neredeyse her zaman ortam doğrulama aşamasında başarısız oluyordur; günlük kayıtları, her yeniden başlatma için tek bir hata yerine tüm sorunları tek bir liste halinde yazdırır. İki yaygın neden şunlardır: boş bırakılan ve unset olarak kabul edilmek yerine reddedilen bir değişken ile yanlış servis dosyasına yerleştirilen bir secret.

arm64 mimarisinde veya bir branch üzerinden kurulum yaparken 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 süresince 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 oluşturun

https://app.example.com adresini açın. Henüz kimsenin giriş yapmadığı bir dağıtım, giriş formu göstermez; bunun yerine ilk hesabı oluşturmanızı önerir. Bu hesap kalıcı olarak yetkili hesaptır ve dağıtım ayarları ekranını görebilen tek hesaptır. Hesap oluşturulduktan sonra ilgili yol 409 yanıtını verir, böylece sizden sonra başkası sisteme erişemez. Bu işlemi yığının sağlıklı olduğu ilk dakikada yapın, bir sonraki haftaya bırakmayın.

Takipçinin kurulumu

Kontrol panelinde bir site eklediğinizde size bir etiket verilir. Etiketin yapısı sabittir:

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

Bu etiketi sayfa başlığına (head) 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 taslak (stub) tarafından kuyruğa alınarak dosya yüklendiğinde gönderilir; böylece erken tetiklenen özel bir olay kaybolmaz. Sayfadaki başka bir öğe halihazırda window.oa kullanıyorsa, takipçi bunun yerine window.openanalytics olarak kurulur. Aynı site bir onion servisi olarak da hizmet veriyorsa, etiketi bu yapıdan uzak tutun; çünkü c.example.com üzerinden çekilen bir betik, Tor Browser kullanıcısını tekrar clearnet ağına çeker ve aynı sayfa yüklemesinde iki adresi birbirine bağlar.

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ç kilobayt veri döndürmelidir. Sitenizde bir sayfayı yükleyin, ardından saniyeler içinde worker günlüğünde bir toplu işlem (batch) satırı olup olmadığını kontrol edin. Toplayıcı (collector), bir olayı kabul ettiği anda 202 yanıtını verir; 202 ise olayın depolanmadığını, kuyruğa alındığını ifade eder. Olayları ClickHouse içine taşıyan yapı worker'dır. Olaylar kabul edilmesine rağmen kontrol panelinde 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 migrasyonun yeni eklediği bir tablo üzerindeki eksik yetkilendirmelerdir.

Toplayıcıyı 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 başlık işleme ayarlarını olduğu gibi 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 "";

Toplayıcı, günlük ziyaretçi özetini (hash) istemci IP adresinden türetir; bu nedenle IP adresini bağlantıdan almalı, asla bir başlıktan almamalıdır. CF-Connecting-IP değerinin güvenilmeyen bir noktadan geçirilmesi, herhangi bir istemcinin istediği adresi beyan etmesine olanak tanır; bu durum coğrafi konum verilerini bozar ve ziyaretçi sayılarını yapay olarak artırır.

Erişim, ana bilgisayar adına (hostname) 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 izin listesi koymayın. app. ve api. adreslerine ise yalnızca giriş yapan kişilerin erişmesi yeterlidir. Paneli koruyan şey uygulamanın kendi kimlik doğrulama mekanizmasıdır: Parola ile giriş, env/api.env dosyasındaki 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) mevcut olduğunda görünür. Sihirli bağlantılar (magic links) bir posta aktarım 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. Eğer diğer self-hosted uygulamalarınız halihazırda tek bir Authentik girişi arkasında çalışıyorsa, bu panelin onlara mı dahil olacağına yoksa kendi hesaplarını mı kullanacağına erkenden karar verin; çünkü burada oluşturduğunuz ilk hesap kalıcı olarak yetkili hesap olacaktır.

Panelin çalışıp çalışmayacağını belirleyen tek bir ayar vardır. env/api.env içindeki AUTH_TRUSTED_ORIGINS değeri, panelin kaynak adresiyle (origin) tam olarak eşleşmelidir. Hatalı veya eksik olması durumunda API, CORS (cross-origin resource sharing) başlıklarını üretmez, tarayıcı tüm çağrıları reddeder ve docker compose ps her şeyin sağlıklı olduğunu raporlarken paneliniz arayüzü yükler ancak veri göstermez.

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

Burada "çerezsiz" ifadesi ne anlama gelir ve size maliyeti nedir

Çerez kullanılmaz. Ziyaretçi kimliği tuzlanmış bir hash değeridir, tuz her gün değişir ve ham IP adresleri asla saklanmaz. Coğrafi konum, kendi diskinizdeki DB-IP dosyası üzerinden yerel olarak çözümlenir; bu nedenle ziyaretçiyle ilgili hiçbir sorgu sunucudan dışarı çıkmaz. Sorguların yerel tutulması veriyi değil, sağlayıcıyı aradan çıkarır; bu durum, kendi SearXNG örneğinizi çalıştırdığınızda arama motorlarının sunucunuzun IP adresini görmesiyle ortaya çıkan kısıtlamanın aynısıdır.

Bunun size sağladığı avantaj, ziyaretçinin cihazında kalıcı bir tanımlayıcının bulunmamasıdır; bu, bir izleyiciyi AB ePrivacy onay kurallarına dahil eden temel unsurdur. Bu yapıdaki gibi yalnızca toplu veri (aggregate) toplayan sistemler, 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 takibinin yapılamamasıdır. Tuz rotasyonu, Pazartesi günü ziyaret edip Çarşamba günü tekrar gelen bir kişinin, tasarım gereği ve herhangi bir geçici çözüm olmaksızın iki ayrı ziyaretçi olarak sayılması anlamına gelir. 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österecektir; bu nedenle uzun vadeli "geri gelen ziyaretçi" verileri, etiketinde belirtilen şeyi ölçmemektedir. Oturumlar ve kullanıcı yolculukları tek bir gün içinde güvenilirdir. ANONYMOUS_IDENTITY_SECRET değerinin döndürülmesi, gün sınırı ile aynı etkiye sahiptir; bu nedenle rotasyonu rutin bir temizlikten ziyade veri değişikliği olarak değerlendirin.

Toplayıcı, Do Not Track ve bir siteye kişisel verileri satmaması veya paylaşmaması talimatını veren tarayıcı sinyali Global Privacy Control özelliklerine saygı duyar. Komut dosyası etiketi (script tag), 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 yanıtı oa.consent anahtarı altında localStorage içinde hatırlayan data-require-consent. data-storage="none" ayarının yapılması, tarayıcı depolamasını tamamen devre dışı bırakır.

Disk neden altı ay sonra dolar

Self-hosted bir analitik sunucusunu durma noktasına getiren temel sebep budur; olay kayıtları genellikle asıl suçlu 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üre boyunca iki nesli aynı anda tutarsınız. Tek bir sayfa görüntülemesi bile gelmeden önce 25 GB gereksiniminin büyük kısmı bu şekilde oluşur.

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 kopyadır, çünkü ClickHouse arka planda parçaları birleştirir ve birleştirme sırasında alınan kopya tutarlı olmaz. upgrade.sh her yükseltme öncesinde otomatik olarak bir kopya alır, bu nedenle siz sınırlama getirene kadar arşivler aynı disk üzerinde birikmeye devam eder.

./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 temizleyin. Yığın çalışırken bu işlem güvenlidir, çünkü çalışan container'ların dayandığı imajlar hala referans edilmektedir:

docker image prune -a -f

Sırada olay kayıtlarının kendisi var. ClickHouse sütun tabanlı verileri yüksek oranda 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 oldukça 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ı veriler için, infra/selfhost/env/ altında oluşturulan ClickHouse kimlik bilgileriyle şu komutu ç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 bu 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 süresi veya yaşam süresi (TTL) ayarı içermemektedir; bu nedenle eski satırların kendiliğinden silineceğini varsaymak yerine diski ölçülen büyüme oranınıza göre boyutlandırın.

Silme işlemiyle ilgili, sorun yaşamadan önce bilmeniz 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ı, ayrıca ClickHouse içinde eşleşen bir oa_maintenance kullanıcısının bulunması gerekir. Bunlar olmadan silme işlemi sonsuza kadar kuyrukta bekler. Site dashboard üzerinden kaybolur ancak tüm satırlar diskte kalmaya devam eder; böylece temizlik yapılmış gibi görünür ancak diskte hiçbir alan açı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 yazdırır. Kesinti gerçektir: toplayıcı kapalıyken denenen olaylar kaybolur, çünkü izleyici bunları yeniden denemez. Geri alma 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ü alındıktan sonra yazılan her satırı atar. Disk, yukarıda açıklanan anlık görüntü yığını olan üçüncü maliyettir.

İ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. Ayrıca ClickHouse, yeniden başlatma yerine yeniden oluşturma (recreate) gerektirir, çünkü docker compose restart container'ın 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 benzer bir tuzak barındırır. env/web.env içindeki üç NEXT_PUBLIC_* kaynağı, tarayıcı paketine derlenir ve container başladığında yerine 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 container'ının 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. Diğer her şey genellikle yapılandırma dosyasının geçersiz XML olduğu anlamına gelir ve bunun en yaygın nedeni, XML yorumu içinde bulunan ve orada yasak olan çift tire işaretidir.

AGPL-3.0 ve isim

Kod, AGPL-3.0 lisansı ile lisanslanmıştır. Kodu kendi siteleriniz için değiştirmeden çalıştırmak, 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 servisin kullanıcılarına sunmanızı şart koşar. Bu durum, istemcilere kendi örneğiniz üzerinden paneller sağlamayı ve bunu sattığınız bir ürünün içine dahil etmeyi kapsar. Değişikliklerinizi herkese açık bir fork üzerinde tutmak, başka bir işleme gerek kalmaksızın bu şartı yerine getirir.

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üşterilere 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 kapasiteli bir sunucuda container'lar başlar ancak çekirdeğin bellek yönetimi (OOM killer), genellikle ClickHouse olmak üzere bunlardan birini sonlandırır. Eğer 1 GB planı kesin bir kısıt ise, harici 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 ekleyin: bu durumda takipçi, izin verilene kadar hiçbir veri toplamaz ve yanıtı oa.consent altında localStorage içinde saklar.

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

202, toplayıcının etkinliği kabul edip kuyruğa aldığını belirtir, depoladığını değil. Worker, bu kuyruğu ClickHouse'a aktarır; bu nedenle başarılı isteklere rağmen boş bir panel, worker ile ilgili bir soruna işaret eder. docker compose logs --tail=50 worker bölümünü okuyun ve Valkey kuyruk derinliğini izleyin. Sürekli büyüyen bir kuyruk, worker'ın engellendiği anlamına gelir; bunun yaygın nedenleri worker.env içindeki hatalı ClickHouse kimlik bilgileri veya yakın zamandaki bir migrasyon ile oluşturulan bir tabloda eksik olan yetkilendirmelerdir.

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

Öncelikle env/api.env içindeki AUTH_TRUSTED_ORIGINS değerini kontrol edin. Bu değer, panelin kaynak adresiyle tam olarak eşleşmelidir; eşleşmediği takdirde API, CORS başlıklarını üretmez ve tarayıcı her çağrıyı reddeder; sonuç olarak arayüz çalışır ancak veri görünmez. İkinci olarak, web container'ı başladığında yerine yerleştirilen env/web.env içindeki üç NEXT_PUBLIC_* değerini kontrol edin. Bunları düzeltmek docker compose up -d --force-recreate web gerektirir, çünkü basit bir yeniden başlatma eski değerleri korur.

AGPL-3.0, bu yazılımı müşterilere sunmamı engeller mi?

Hayır, yalnızca 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 karşılayabilirsiniz. Ayrıca, "OpenAnalytics" ismi kodla birlikte lisanslanmamıştır, bu nedenle sattığınız herhangi bir ürünün kendi ismi olmalıdır.