VPS वर OpenAnalytics स्वतः होस्ट करण्याची पद्धत

पहिल्या पायरीपूर्वीची आवश्यकता

OpenAnalytics स्वतः होस्ट करण्यासाठी सुमारे 4 GB RAM, 25 GB मोकळी डिस्क जागा, Compose plugin सह Docker आणि या सर्व्हरकडे आधीपासून निर्देश करणारे चार DNS records असलेला Linux VPS आवश्यक आहे. हीच खरी प्राथमिक माहिती आहे. ती पहिल्या command पूर्वी असली पाहिजे, नंतर नाही.

या stack मध्ये सहा application services आणि तीन data stores आहेत. Postgres मध्ये control plane मधील accounts, sites, API keys आणि share links साठवले जातात. ClickHouse मध्ये raw events आणि dashboard वाचत असलेले rollups साठवले जातात. Valkey दोन वेळा चालते: एकदा durable event queue म्हणून आणि एकदा cache म्हणून, जी गमावली तरी चालते. या दोन कामांसाठी परस्परविरुद्ध eviction policies आवश्यक आहेत. फक्त query gateway या process ला ClickHouse वाचण्याची अनुमती आहे. तो प्रत्येक query envelope चालवण्यापूर्वी त्यावरील Ed25519 signature पडताळतो.

तुम्हाला एक binary आणि एक config file हवे असेल, तर हा पर्याय तुमच्यासाठी नाही. या श्रेणीतील single-binary पर्याय GoatCounter आहे: एक Go executable, default म्हणून SQLite आणि कोणताही external database नाही. या अधिक जड stack मुळे funnels, web vitals, तुमच्या स्वतःच्या Stripe account मधून revenue attribution आणि MCP (model context protocol) server मिळतो. स्वतः होस्ट केलेल्या analytics tools मधील निवड या trade-off चे मूल्यमापन करणाऱ्या post मध्ये त्याची चर्चा आहे. या मार्गदर्शकात तुम्ही निवड आधीच केली आहे असे गृहीत धरले आहे.

प्रथम चार DNS records या सर्व्हरकडे निर्देशित करा

तुम्ही पुढील प्रक्रिया सुरू करण्यापूर्वी चार subdomains सर्व्हरच्या public IP कडे resolve होणे आवश्यक आहे. कारण Caddy पहिल्यांदा सुरू होताना Let's Encrypt कडून certificates मागवते. अद्याप resolve न होणाऱ्या नावासाठी challenge अयशस्वी होते.

• app.example.com dashboard उपलब्ध करून देतो.
• api.example.com API आणि OAuth callbacks उपलब्ध करून देतो.
• c.example.com collector आणि tracker script उपलब्ध करून देतो.
• rt.example.com realtime stream उपलब्ध करून देतो.

चार A records वापरा किंवा एक A record आणि त्याकडे निर्देश करणारे तीन CNAMEs वापरा. पुढे जाण्यापूर्वी dig +short app.example.com वापरून पडताळणी करा. तुम्ही एका मिनिटापूर्वी जोडलेले नाव, Let's Encrypt ज्या resolver चा वापर करेल त्याच्याकडून अद्याप NXDOMAIN म्हणून cache केलेले असू शकते. त्यामुळे पहिला certificate प्रयत्न अयशस्वी झाल्यास थोडा वेळ प्रतीक्षा करा आणि Caddy logs तपासा. Install पुन्हा चालवल्याने DNS propagation जलद होत नाही.

Docker Compose वापरून OpenAnalytics स्वतःच्या सर्व्हरवर कसे चालवावे

Tagged release तपासा. Default branch वर development सुरू असते, तर प्रकाशित images प्रत्यक्षात release tag शी जुळतात. खालील commands मध्ये Docker आणि Compose plugin आधीच install केलेले आहेत असे गृहीत धरले आहे. VPS वर Docker Compose services चालवणे याचे स्पष्टीकरण देते.

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 line मधील sed '/-/d' pre-release tags वगळते. त्यामुळे release candidate ऐवजी सर्वात नवीन stable version मिळते. Generation दरम्यान --with-geoip DB-IP city database fetch करते. हे वगळल्यास प्रत्येक event मध्ये country साठी null value येते आणि geography view मध्ये काहीही दिसत नाही. हे नंतर जोडण्यासाठी infra/selfhost/geoip/fetch-dbip.sh चालवा, env/collector.env मध्ये GEOIP_DB_PATH=/geoip/dbip-city-lite.mmdb सेट करा आणि त्यानंतर docker compose up -d --force-recreate collector वापरून collector पुन्हा तयार करा. हा database दर महिन्याला refresh केला जातो. त्यामुळे city data अचूक ठेवण्यासाठी fetch प्रक्रिया दर महिन्याला पुन्हा करा.

पुढे जाण्यापूर्वी निर्माण केलेली secrets बॅकअप करा

generator तीन गोष्टी लिहितो. .env मध्ये domain names आणि image references असतात. env/*.env मध्ये प्रत्येक service साठी secrets असलेली एक फाइल असते. docker-compose.override.yml मध्ये YAML block scalars म्हणून तीन Ed25519 key pairs असतात, कारण multi-line PEM env file मध्ये ठेवता येत नाही. या सर्व फाइल्स git-ignored आहेत आणि यापैकी कोणतीही गोष्ट पूर्वीच्या मूल्यांवर पुन्हा निर्माण करता येत नाही.

आता या फाइल्स machine च्या बाहेर copy करा. प्रत्येक गोष्ट गमावल्यास विशिष्ट परिणाम होतो:

• store passwords गमावल्यास Postgres आणि ClickHouse मधून तुमचा access बंद होतो. ते फक्त containers च्या आतून reset करता येतात.
• OA_CREDENTIAL_KEYRING गमावल्यास साठवलेली प्रत्येक third-party credential परत मिळवता येत नाही. त्यामुळे Stripe account connect केलेल्या प्रत्येक व्यक्तीला ते पुन्हा connect करावे लागते.
• ANONYMOUS_IDENTITY_SECRET गमावल्यास visitor identity पुन्हा baseline होते: कालचे सर्व visitors नवीन म्हणून मोजले जातात आणि हा बदल charts मध्ये दिसतो.
• AUTH_SECRET गमावल्यास प्रत्येक session invalidated होते. त्यामुळे सर्वांना पुन्हा sign in करावे लागते.
• signing private key गमावल्यास key pair rotate करा. कोणताही data गमावत नाही.

दोन secrets प्रत्येकी दोन फाइल्समध्ये byte-identical असणे आवश्यक आहे. ANONYMOUS_IDENTITY_SECRET हे collector.env आणि worker.env मध्ये असते, कारण collector visitor hash compute करतो आणि worker तो लिहितो. OA_CREDENTIAL_KEYRING हे api.env आणि worker.env मध्ये असते. इतर प्रत्येक secret जाणीवपूर्वक नेमक्या एका service पुरते मर्यादित आहे. ज्या service कडे असू नये असे secret दिले जाते, ती service सुरू होण्याऐवजी exit होते.

स्टॅक सुरू करा आणि तो तपासा

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

migrate Postgres आणि ClickHouse schema लागू करते आणि त्यानंतर बंद होते. त्यामुळे थांबलेला migrate कंटेनर ही अपेक्षित अंतिम स्थिती आहे. tracker-build, oa.js ला Caddy सेवा देत असलेल्या volume मध्ये compile करते आणि तेही बंद होते. इतर सर्व सेवांनी docker compose ps मध्ये healthy वाचले पाहिजे. एखादी सेवा सतत restart होत असल्यास, ती जवळजवळ नेहमीच environment validation मध्ये अपयशी ठरत असते. Log प्रत्येक restart साठी वेगवेगळी नोंद करण्याऐवजी सर्व समस्या एकाच यादीत दाखवतो. नेहमीची दोन कारणे अशी आहेत: एखादा variable रिकामा ठेवलेला असतो आणि तो unset मानण्याऐवजी नाकारला जातो; किंवा secret चुकीच्या service file मध्ये ठेवलेले असते.

arm64 वर किंवा एखाद्या branch मधून काम करताना published images उपलब्ध नसतात. त्यामुळे docker compose up -d --build वापरून image स्थानिक पातळीवर build करा. 4 GB host वर हा build सुरू असताना memory संपते. आधी swap जोडा. ती फक्त build करताना आवश्यक असते:

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

Build पूर्ण होण्यासाठी साधारण दहा मिनिटे लागतात. Pull करण्यासाठी काही मिनिटे पुरतात. म्हणूनच release images उपलब्ध आहेत.

पहिले खाते त्वरित तयार करा

https://app.example.com उघडा. अद्याप कोणीही साइन इन न केलेल्या deployment मध्ये sign-in form दिसत नाही; त्याऐवजी पहिले खाते तयार करण्याचा पर्याय दिला जातो. हे खाते कायमचे privileged खाते असते आणि deployment settings screen पाहू शकणारे हे एकमेव खाते असते. ते खाते तयार झाल्यानंतर route 409 प्रतिसाद देते. त्यामुळे तुमच्यानंतर कोणीही अनधिकृतपणे प्रवेश करू शकत नाही. Stack निरोगी स्थितीत येताच हे करा; पुढील आठवड्यापर्यंत थांबू नका.

ट्रॅकर स्थापित करा

Dashboard मध्ये site जोडा. त्यानंतर tag उपलब्ध होईल. त्याचा आकार निश्चित आहे:

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

तो page head मध्ये ठेवा. Tracking key ही रचनात्मकदृष्ट्या सार्वजनिक असते. त्यामुळे ती कोणीही वाचू शकेल अशा HTML मध्ये ठेवणे योग्य आहे. Script window.oa स्थापित करते. oa("track", ...) सारख्या calls stub कडे queue केल्या जातात आणि file load झाल्यावर त्या flush केल्या जातात. त्यामुळे file load होण्यापूर्वी fire केलेला custom event गहाळ होत नाही. Page वर आधीच दुसरे काहीतरी window.oa वापरत असेल, तर tracker त्याऐवजी window.openanalytics स्थापित करतो.

आता संपूर्ण मार्ग end to end तपासा:

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

पहिल्या command ने 200 आणि काही kilobytes दाखवले पाहिजेत. तुमच्या site वरील एखादे page load करा. त्यानंतर काही seconds मध्ये worker log मध्ये batch line शोधा. Collector event स्वीकारताच 202 उत्तर देतो. 202 म्हणजे event queue मध्ये ठेवले आहे; तो stored आहे असे नाही. Events ClickHouse मध्ये हलवण्याचे काम worker करतो. Events स्वीकारले जात असूनही dashboard मध्ये काही दिसत नसेल, तर worker blocked आहे. Valkey queue depth सतत वाढत राहणे याची पुष्टी करते. नेहमीची कारणे म्हणजे worker.env मधील चुकीचे ClickHouse credentials किंवा नुकत्याच migration ने जोडलेल्या table वर missing grant.

कलेक्टर सार्वजनिक ठेवा आणि डॅशबोर्डला प्रमाणीकरणामागे ठेवा

Caddy compose file मध्ये समाविष्ट आहे आणि चारही नावांसाठी स्वतःहून प्रमाणपत्रे मिळवतो. त्यामुळे default path साठी तुमच्याकडून proxy configuration ची आवश्यकता नाही. मशीनवर आधीपासून nginx reverse proxy चालू असल्यास, त्याऐवजी दिलेला infra/selfhost/nginx.conf.example वापरून या stack समोर ठेवा आणि त्याचे header handling जसे आहे तसेच ठेवा:

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 "";

कलेक्टर client IP वरून daily visitor hash तयार करतो. त्यामुळे हा पत्ता header मधून कधीही न घेता connection मधूनच घ्यावा. अविश्वसनीय hop कडून CF-Connecting-IP पुढे पाठवल्यास कोणताही caller कोणताही पत्ता सांगू शकतो. त्यामुळे geolocation चुकीचे होते आणि visitor counts एकाच वेळी फुगतात.

Hostname नुसार access स्पष्टपणे विभागता येतो. तुम्ही मोजत असलेल्या प्रत्येक site च्या प्रत्येक visitor साठी c. आणि rt. उपलब्ध असणे आवश्यक आहे. त्यामुळे या दोन्हीसमोर basic auth किंवा IP allowlist कधीही ठेवू नका. app. आणि api. फक्त sign in करणाऱ्या लोकांसाठी उपलब्ध असणे आवश्यक आहे. Dashboard चे संरक्षण application चे स्वतःचे auth करते: env/api.env मधील AUTH_PASSWORD_SIGNIN=enabled द्वारे password sign-in default ने सुरू असते. Google किंवा GitHub buttons संबंधित provider साठी client ID आणि client secret दोन्ही उपलब्ध असतील तेव्हाच दिसतात. Magic links साठी mail transport आवश्यक आहे. तो नसल्यास API फक्त send ची नोंद outbox मध्ये करते. त्यामुळे काहीही वितरित होत नाही आणि कोणतीही error दिसत नाही.

एक setting dashboard मुळात कार्य करेल की नाही हे ठरवते. env/api.env मधील AUTH_TRUSTED_ORIGINS dashboard origin शी अचूक जुळले पाहिजे. ते चुकीचे किंवा अनुपस्थित असल्यास API कोणतेही CORS (cross-origin resource sharing) headers पाठवत नाही. Browser प्रत्येक call नाकारतो. परिणामी dashboard चे layout दिसते, परंतु data दिसत नाही; तरीही docker compose ps सर्व काही निरोगी असल्याचे दाखवते.

Proxy config मध्ये असताना automated traffic कडेही लक्ष द्या. Crawlers इतर कोणत्याही traffic प्रमाणे collector वर येतात. त्यांच्या page views ClickHouse मध्ये आणि तुमच्या numbers मध्ये नोंदवल्या जातात. Server वर AI crawlers अवरोधित करणे database मध्ये जाणारा या traffic चा काही भाग आधीच थांबवते. त्यामुळे accuracy आणि disk space या दोन्हींचे नुकसान कमी होते.

येथे cookieless याचा अर्थ काय आहे आणि त्याची किंमत काय आहे

येथे cookie नाही. Visitor identity हा salted hash असतो. Salt दररोज बदलतो. Raw IP addresses कधीही साठवले जात नाहीत. Geolocation तुमच्या स्वतःच्या disk वरील DB-IP file विरुद्ध स्थानिक पातळीवर निश्चित केले जाते. त्यामुळे visitor विषयीची कोणतीही lookup माहिती host बाहेर जात नाही.

यामुळे visitor च्या device वर टिकून राहणारा identifier नसतो. नेमका हाच identifier tracker ला EU ePrivacy consent नियमांच्या कक्षेत आणतो. म्हणून या प्रकारची aggregate-only रचना अनेकदा consent banner शिवाय चालवली जाते. तुम्ही जे काही साठवता आणि किती काळ साठवता, त्यावर GDPR तरीही लागू असतो. तुमच्या प्रकरणाचा निर्णय README नाही, तर तुमचे स्वतःचे कायदेशीर सल्लागार घेतात.

याची किंमत म्हणजे वेगवेगळ्या दिवसांमधील identity उपलब्ध राहत नाही. Salt बदलल्यामुळे सोमवारी भेट देणारी आणि बुधवारी पुन्हा भेट देणारी व्यक्ती डिझाइननुसार दोन visitors म्हणून मोजली जाते. यावर कोणताही workaround नाही. Daily unique counts अचूक असतात. Weekly आणि monthly unique counts हे daily counts वरून तयार केले जातात आणि reach जास्त दाखवतात. त्यामुळे मोठ्या कालावधीतील कोणताही "returning visitor" आकडा त्याच्या label मध्ये सांगितलेली गोष्ट मोजत नाही. Sessions आणि journeys एकाच दिवसाच्या मर्यादेत विश्वसनीय असतात. ANONYMOUS_IDENTITY_SECRET फिरवल्याने day boundary सारखाच परिणाम होतो. त्यामुळे त्या rotation कडे routine hygiene म्हणून नव्हे, तर data change म्हणून पाहा.

Collector Do Not Track आणि Global Privacy Control यांचा आदर करतो. हा browser signal site ला personal data विकू किंवा share करू नये असे सांगतो. Script tag मध्ये याच उद्देशासाठी स्वतःचे switches आहेत: data-respect-gpc, data-respect-dnt आणि data-require-consent. data-require-consent consent मिळेपर्यंत सर्व collection थांबवतो आणि उत्तर localStorage मध्ये oa.consent key अंतर्गत लक्षात ठेवतो. data-storage="none" सेट केल्यास browser storage पूर्णपणे बंद होते.

सहा महिन्यांनी डिस्क का भरते

यामुळे self-hosted analytics box बंद पडतो; आणि सामान्यतः events यामागचे कारण नसतात.

सुरुवात images पासून करा. एखाद्या release मध्ये त्यापैकी दहा images प्रकाशित होतात आणि डिस्कवर त्यांना एकूण सुमारे 13 GB जागा लागते. Upgrade दरम्यान जुनी generation हटवण्यापूर्वी नवीन generation pull केली जाते. त्यामुळे काही काळ दोन generations डिस्कवर ठेवाव्या लागतात. एकही page view येण्यापूर्वीच 25 GB आवश्यक जागेपैकी बहुतांश जागा येथेच वापरली जाते.

त्यानंतर snapshots येतात. snapshot.sh stack थांबवते, प्रत्येक secret सह दोन्ही data volumes archive करते आणि पुन्हा सुरू करते. येथे cold copies हाच सुरक्षित प्रकार आहे, कारण ClickHouse पार्श्वभूमीत parts merge करते आणि merge सुरू असताना घेतलेली copy consistent नसते. upgrade.sh प्रत्येक upgrade पूर्वी आपोआप एक snapshot घेते. त्यामुळे archives त्याच डिस्कवर साठत राहतात, जोपर्यंत तुम्ही त्यांची मर्यादा निश्चित करत नाही.

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

मर्यादेजवळ असलेल्या host वर upgrade करण्यापूर्वी मागील generation हटवून जागा मोकळी करा. stack चालू असताना हे सुरक्षित आहे, कारण चालू containers वापरत असलेल्या images अजूनही referenced असतात:

docker image prune -a -f

यानंतर events स्वतः येतात. ClickHouse columnar data मोठ्या प्रमाणात compress करते. त्यामुळे raw event volume बहुतेकांच्या अपेक्षेपेक्षा हळूहळू वाढतो. Dashboard ज्या rollup tables वाचतो, त्या raw table च्या तुलनेत लहान असतात. अंदाज न बांधता मोजमाप करा:

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

प्रत्येक table साठीचा आकडा मिळवण्यासाठी, generator ने infra/selfhost/env/ अंतर्गत लिहिलेली ClickHouse credentials वापरून हे चालवा:

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;

हे मोजमाप पहिल्या आठवड्यात आणि पुन्हा चौथ्या आठवड्यात घ्या. दोन मोजमापांमधून growth rate मिळतो. Growth rate वरून volume साठी डिस्कचा आकार कधी वाढवावा हे ठरवता येते. August 2026 पर्यंत self-hosting guide मध्ये raw events साठी retention किंवा time-to-live knob दस्तऐवजीकृत केलेला नाही. त्यामुळे जुन्या rows आपोआप expire होतील असे गृहीत न धरता, मोजलेल्या growth rate नुसार डिस्कचा आकार ठरवा.

एक deletion trap आधीच जाणून घेणे उपयुक्त आहे. एखादी site किंवा account हटवल्यावर worker साठी काम queue केले जाते. त्या worker साठी CLICKHOUSE_MAINTENANCE_USER आणि CLICKHOUSE_MAINTENANCE_PASSWORD सेट असणे आवश्यक आहे आणि ClickHouse मध्ये त्यांच्याशी जुळणारा oa_maintenance user अस्तित्वात असणे आवश्यक आहे. हे नसल्यास deletion queue मध्ये कायम राहते. Site dashboard मधून नाहीशी होते, पण प्रत्येक row डिस्कवर तशीच राहते. त्यामुळे cleanup झाल्यासारखे दिसते, पण जागा मोकळी होत नाही.

अपग्रेड आणि त्यासाठी लागणारे तीन खर्च

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

upgrade.sh कृती करण्यापूर्वी तीन खर्च दाखवते. डाउनटाइमचा प्रत्यक्ष परिणाम होतो: collector बंद असताना केलेले प्रयत्न गमावले जातात, कारण tracker त्यांचा पुन्हा प्रयत्न करत नाही. Rollback केल्यावर डेटा गमावला जातो, कारण rollback.sh --to backups/<snapshot> दोन्ही stores पूर्णपणे बदलते आणि तो snapshot घेतल्यानंतर लिहिलेली प्रत्येक row टाकून देते. Disk हा तिसरा खर्च आहे. वर वर्णन केलेला snapshot pile त्यासाठी कारणीभूत असतो.

दोन restart नियम सहज चुकीचे लागू होतात. API सुरू करण्यापूर्वी query gateway सुरू करा, कारण नवीन API असे query fields पाठवते जे जुना gateway नाकारतो. तसेच ClickHouse साठी restart ऐवजी recreate आवश्यक आहे, कारण docker compose restart container चे मूळ environment पुन्हा वापरते आणि तुम्ही केलेला बदल शांतपणे दुर्लक्षित करते:

docker compose up -d --force-recreate clickhouse

Dashboard मध्येही असाच अडथळा असतो. env/web.env मधील तीन NEXT_PUBLIC_* origins browser bundle मध्ये compile केले जातात आणि container सुरू होताना त्यांची मूल्ये बसवली जातात. त्यामुळे चुकीचा hostname वापरणाऱ्या dashboard ची दुरुस्ती docker compose up -d --force-recreate web ने करावी; restart ने कधीही करू नये. Web container च्या log मध्ये सुरुवातीला वापरलेले origins दिसतात. दुरुस्ती लागू झाली आहे की नाही हे तपासण्याचा हा सर्वात जलद मार्ग आहे.

Config edit केल्यानंतर ClickHouse सुरू होण्यास नकार देत असल्यास, त्याच्या log मधील पहिली ओळ वाचा. oa-entrypoint: ने सुरू होणारी ओळ म्हणजे तुम्ही सेट केलेले value entrypoint ने नाकारले आहे. इतर कोणतीही स्थिती सहसा config file मधील XML अमान्य असल्याचे दर्शवते. त्याचे सर्वात सामान्य कारण म्हणजे XML comment मध्ये असलेले double hyphen. तेथे ते अमान्य आहे.

AGPL-3.0 आणि नाव

हा code AGPL-3.0 अंतर्गत परवानाकृत आहे. तुमच्या स्वतःच्या sites साठी तो कोणताही बदल न करता चालवल्यास publishing ची कोणतीही obligation लागू होत नाही. तुम्ही code मध्ये बदल करून ती बदललेली आवृत्ती network service म्हणून चालवता तेव्हा obligation सुरू होते. त्या वेळी license नुसार तुम्हाला त्या service च्या users ना बदललेला source उपलब्ध करून द्यावा लागतो. तुमच्या instance वर clients ना dashboards देणे आणि तुम्ही विकत असलेल्या एखाद्या product मध्ये हा code समाविष्ट करणे, या दोन्ही परिस्थितींवर हे लागू होते. तुमचे बदल public fork मध्ये ठेवणे पुरेसे आहे; त्यासाठी आणखी कोणतीही प्रक्रिया आवश्यक नाही.

Brand हा code पासून स्वतंत्र आहे. "OpenAnalytics" हे नाव आणि project चा hosted domain, त्याचे authors चालवत असलेल्या instance ची ओळख करतात. ते license grant चा भाग नाहीत. तुमचे deployment brand न वापरता software चालवते. त्यामुळे paying customers समोर service उपलब्ध करण्यापूर्वी तिला स्वतःचे नाव द्या.

FAQ

मी OpenAnalytics 1 GB VPS वर चालवू शकतो का?

नाही. या प्रकल्पाला सुमारे 4 GB RAM आणि 25 GB मोकळी डिस्क जागा आवश्यक आहे, कारण एका deployment मध्ये Postgres, ClickHouse आणि दोन Valkey instances सोबत सहा application services चालतात. ClickHouse ही एकटीच लहान process नाही. 1 GB मशीनवर containers सुरू होतात; त्यानंतर kernel out-of-memory killer त्यांपैकी एखादा container बंद करतो, सामान्यतः ClickHouse. 1 GB plan ही कठोर मर्यादा असल्यास GoatCounter सारखे single-binary tool वापरा. ते SQLite वर चालते आणि external database आवश्यक नसतो.

OpenAnalytics सोबत cookie banner आवश्यक आहे का?

हा प्रश्न तुमच्या वकिलांसाठी आहे; मात्र तांत्रिक बाबी तुमच्या बाजूने आहेत. कोणतीही cookie वापरली जात नाही, visitor identity दररोज बदलणारा salted hash असतो आणि raw IP addresses कधीही साठवले जात नाहीत. त्यामुळे visitor ओळखण्यासाठी टिकणारी कोणतीही माहिती लिहिली जात नाही. तरीही तुम्ही काय साठवता आणि किती काळ ठेवता यावर GDPR लागू राहतो. Collection स्पष्ट संमतीवर आधारित ठेवायचे असल्यास script tag वर data-require-consent सेट करा. त्यानंतर consent मिळेपर्यंत tracker काहीही collect करत नाही आणि उत्तर localStorage मध्ये oa.consent अंतर्गत ठेवतो.

Events 202 परत करतात, पण dashboard मध्ये कधीच दिसत नाहीत. असे का?

202 याचा अर्थ collector ने event स्वीकारून queue मध्ये ठेवला आहे; तो साठवला आहे असा त्याचा अर्थ नाही. Worker ही queue ClickHouse मध्ये पाठवतो. त्यामुळे requests यशस्वी असून dashboard रिकामा दिसत असल्यास समस्या worker मध्ये असण्याची शक्यता आहे. docker compose logs --tail=50 worker वाचा आणि Valkey queue depth monitor करा. Queue सतत वाढत राहिल्यास worker अडलेला आहे. याची सामान्य कारणे म्हणजे worker.env मधील चुकीची ClickHouse credentials किंवा अलीकडील migration ने तयार केलेल्या table वर आवश्यक grant नसणे.

प्रत्येक container healthy असताना dashboard रिकामा का दिसतो?

सर्वप्रथम env/api.env मधील AUTH_TRUSTED_ORIGINS तपासा. ते dashboard origin शी अचूक जुळले पाहिजे. ते जुळत नसल्यास API कोणतेही CORS headers पाठवत नाही. त्यामुळे browser प्रत्येक call नाकारतो आणि layout कार्यरत दिसतो, पण data दिसत नाही. दुसरी तपासायची गोष्ट म्हणजे env/web.env मधील तीन NEXT_PUBLIC_* values. Web container सुरू होताना त्या values substitute केल्या जातात. त्या दुरुस्त करण्यासाठी docker compose up -d --force-recreate web आवश्यक आहे, कारण साधा restart केल्यास जुन्या values कायम राहतात.

AGPL-3.0 मुळे मला हे clients ना देण्यास अडथळा येतो का?

नाही. त्यामध्ये एक अट लागू होते. Code मध्ये बदल न करता तो चालवल्यास तुम्हाला कोणालाही काहीही देणे बंधनकारक नाही. Code मध्ये बदल करून ती modified version इतर लोक वापरत असलेल्या service म्हणून चालवल्यास, त्या users ना तुमचा modified source उपलब्ध करून द्यावा लागतो. Public fork ही अट पूर्ण करते. याशिवाय, "OpenAnalytics" हे नाव code सोबत licensed नाही. त्यामुळे तुम्ही विकत असलेल्या कोणत्याही सेवेसाठी स्वतंत्र नाव आवश्यक आहे.