VPS वर OpenAnalytics self-host कसे करावे

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

OpenAnalytics self-host करण्यासाठी सुमारे 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 म्हणून आणि एकदा system गमावू शकणाऱ्या cache म्हणून. या दोन कामांसाठी परस्परविरुद्ध eviction policies आवश्यक असल्यामुळे ही विभागणी केली आहे. ClickHouse वाचण्याची परवानगी फक्त query gateway या एका process ला आहे. Query चालवण्यापूर्वी तो प्रत्येक 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 मिळतो. self-hosted analytics tools मधील निवड या trade-off चे मूल्यमापन करणारे post आहे. या guide मध्ये तुम्ही आधीच निर्णय घेतला आहे असे गृहीत धरले आहे.

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

कोणतेही काम सुरू करण्यापूर्वी चार 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 स्वतः host कसे करावे

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 चा backup घ्या

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

आता या files मशीनबाहेर copy करा. प्रत्येक file हरवल्याची स्वतंत्र किंमत असते:

• Store passwords हरवल्यास Postgres आणि ClickHouse मधून access बंद होतो. ते फक्त containers च्या आतूनच reset करता येतात.
• OA_CREDENTIAL_KEYRING हरवल्यास साठवलेली प्रत्येक third-party credential कायमची unrecoverable होते. त्यामुळे 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 प्रत्येकी दोन files मध्ये 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 दिल्यास ती सुरू होण्याऐवजी 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 container ही योग्य अंतिम स्थिती आहे. tracker-build oa.js compile करून Caddy कडून उपलब्ध करून दिल्या जाणाऱ्या volume मध्ये ठेवते आणि नंतर तेही बंद होते. इतर सर्व सेवा docker compose ps मधील healthy वाचायला हव्यात. एखादी service सतत restart होत असल्यास, ती जवळजवळ नेहमीच environment validation मध्ये अपयशी ठरत असते. Log प्रत्येक restart साठी वेगळी नोंद करण्याऐवजी सर्व समस्या एका यादीत दाखवतो. नेहमीची दोन कारणे अशी आहेत: एखादा variable रिकामा ठेवलेला असतो; तो unset मानण्याऐवजी नाकारला जातो. किंवा secret चुकीच्या service file मध्ये ठेवलेले असते.

arm64 वर किंवा एखाद्या branch मधून काम करताना published images उपलब्ध नसतात. त्यामुळे docker compose up -d --build वापरून local 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 निरोगी स्थितीत येताच हे करा; पुढील आठवड्यापर्यंत थांबू नका.

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

डॅशबोर्डमध्ये साइट जोडा. त्यानंतर तुम्हाला 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 स्थापित करतो. तीच साइट onion service म्हणूनही उपलब्ध असल्यास, त्या build मधून tag काढून ठेवा. कारण c.example.com मधून fetch केलेली script Tor Browser वरील visitor ला clearnet कडे परत नेते आणि त्याच page load मध्ये दोन्ही addresses जोडते.

त्यानंतर संपूर्ण मार्ग 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 प्रदर्शित झाले पाहिजेत. तुमच्या साइटवरील एखादे page load करा. त्यानंतर काही seconds मध्ये worker log मध्ये batch line शोधा. Collector event स्वीकारताच 202 परत करतो. 202 याचा अर्थ event queued आहे, stored नाही. Events ClickHouse मध्ये हलवण्याचे काम worker करतो. Events स्वीकारले जात असूनही dashboard मध्ये काही दिसत नसेल, तर worker blocked आहे. सतत वाढणारी Valkey queue depth याची पुष्टी करते. नेहमीची कारणे म्हणजे worker.env मधील चुकीची ClickHouse credentials किंवा migration ने नुकतीच जोडलेल्या table वरील आवश्यक 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 वरून दैनंदिन visitor hash तयार करतो. त्यामुळे तो पत्ता connection मधूनच घेतला पाहिजे; header मधून कधीही घेऊ नये. अविश्वसनीय 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 ने सुरू असते. एखाद्या provider साठी client ID आणि client secret दोन्ही उपलब्ध असतील तेव्हाच Google किंवा GitHub buttons दिसतात. Magic links साठी mail transport आवश्यक आहे. तो नसल्यास API फक्त send ची नोंद outbox मध्ये करते. त्यामुळे संदेश वितरित होत नाही आणि कोणतीही error देखील येत नाही. तुमचे इतर self-hosted apps आधीपासून एका Authentik login मागे असतील, तर हे dashboard त्या व्यवस्थेत सामील करायचे की स्वतंत्र accounts ठेवायचे हे लवकर ठरवा. कारण येथे तयार केलेले पहिले account कायमस्वरूपी privileged account असते.

एक 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 सर्व काही healthy असल्याचे दाखवते.

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

याचा अर्थ cookieless काय आहे आणि त्यासाठी कोणती किंमत मोजावी लागते

कोणतेही cookie नसते. अभ्यागताची ओळख salted hash स्वरूपात असते, salt दररोज बदलते आणि मूळ IP addresses कधीही साठवले जात नाहीत. Geolocation तुमच्या स्वतःच्या disk वरील DB-IP file विरुद्ध locally resolve केले जाते. त्यामुळे अभ्यागताविषयीची कोणतीही lookup माहिती host बाहेर जात नाही. Lookups local ठेवल्याने vendor दूर होतो; data नाही. तुमचे स्वतःचे SearXNG instance चालवताना दिसणारी हीच मर्यादा येथेही लागू होते: search engines ना तुमच्या server चा IP दिसतो.

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

याची किंमत म्हणजे cross-day identity उपलब्ध राहत नाही. Salt rotation मुळे सोमवारी आणि पुन्हा बुधवारी भेट देणारी व्यक्ती design नुसार दोन visitors म्हणून मोजली जाते. यावर कोणताही workaround नाही. Daily unique counts अचूक असतात. Weekly आणि monthly unique counts daily counts पासून तयार केले जातात आणि reach जास्त दाखवतात. त्यामुळे दीर्घ कालावधीतील कोणताही "returning visitor" आकडा त्याच्या label मध्ये सांगितलेली गोष्ट मोजत नाही. Sessions आणि journeys एकाच दिवसाच्या मर्यादेत विश्वसनीय असतात. ANONYMOUS_IDENTITY_SECRET rotate केल्याने 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 जागा घेतात. जुनी generation हटवण्यापूर्वी upgrade नवीन generation pull करते. त्यामुळे काही काळ दोन generations साठवलेल्या असतात. एकही page view येण्यापूर्वीच 25 GB requirement मधील बहुतांश जागा येथे वापरली जाते.

त्यानंतर snapshots येतात. snapshot.sh stack थांबवते, दोन्ही data volumes प्रत्येक secretसह 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सह ही command चालवा:

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 documented केलेला नाही. त्यामुळे जुन्या rows आपोआप expire होतील असे गृहीत न धरता, मोजलेल्या rateनुसार डिस्कचा आकार ठरवा.

Deletionबाबतचा एक सापळा आधीच लक्षात ठेवा. Site किंवा account delete केल्यावर workerसाठी काम queue केले जाते. त्या workerसाठी CLICKHOUSE_MAINTENANCE_USER आणि CLICKHOUSE_MAINTENANCE_PASSWORD set असणे आवश्यक आहे आणि ClickHouseमध्ये matching 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 ला call करणारा dashboard docker compose up -d --force-recreate web ने दुरुस्त केला जातो; restart ने कधीही नाही. Web container च्या log मध्ये तो ज्या origins सह सुरू झाला ते दाखवले जातात. दुरुस्ती लागू झाली आहे का हे तपासण्याचा हा सर्वात जलद मार्ग आहे.

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

AGPL-3.0 आणि नाव

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

Brand हा code पासून स्वतंत्र असतो. "OpenAnalytics" हे नाव आणि project's 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 वर चालते आणि बाह्य database आवश्यक नसतो.

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

हा प्रश्न आपल्या वकिलांना विचारावा. मात्र तांत्रिक तथ्ये आपल्या बाजूने आहेत. कोणताही cookie नाही. Visitor identity ही दररोज बदलणारी salted hash असते. Raw IP addresses कधीही साठवले जात नाहीत. त्यामुळे visitor ओळखण्यासाठी टिकाऊ स्वरूपाची कोणतीही माहिती लिहिली जात नाही. तरीही आपण काय साठवता आणि किती काळ ठेवता यावर GDPR लागू राहतो. Collection स्पष्ट संमतीनंतरच सुरू करायचे असल्यास script tag वर data-require-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 नाकारतो आणि data नसलेला, पण कार्यरत layout दिसतो. तपासण्याची दुसरी गोष्ट म्हणजे 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 नाही. त्यामुळे आपण विकत असलेल्या कोणत्याही उत्पादनासाठी स्वतंत्र नाव आवश्यक आहे.