VPS-ல் சிறந்த self-hosted web analytics கருவிகள் எவை?

VPS-ல் எந்த self-hosted web analytics கருவியை இயக்க வேண்டும்?

Self-hosted web analytics கருவிகள் இரண்டு வகைகளாகப் பிரிக்கப்படுகின்றன. தவறான வகையைத் தேர்ந்தெடுப்பது, தவறான தயாரிப்பைத் தேர்ந்தெடுப்பதை விட அதிக பாதிப்பை ஏற்படுத்தும். முதல் வகை, பார்வையாளரின் browser-ல் ஒரு சிறிய script-ஐ இயக்கி, அது அனுப்பும் தகவல்களைச் சேமிக்கிறது. இரண்டாவது வகை, உங்கள் web server ஏற்கனவே உருவாக்கும் access log-ஐப் படித்து பகுப்பாய்வு செய்கிறது. இதன்பின் வரும் database மற்றும் memory பயன்பாடு போன்ற அனைத்துத் தேவைகளும் இந்தத் தேர்வைப் பொறுத்தே அமையும்.

சிறிய server-களுக்கான சுருக்கமான பதில் இதோ: GoatCounter மற்றும் Medama ஆகியவற்றை 1 GB RAM-ல் இயக்கலாம், ஏனெனில் இவை ஒவ்வொன்றும் ஒரு கோப்பின் மீது இயங்கும் ஒற்றை process ஆகும். Umami ஒரு Postgres container-ஐச் சேர்க்கிறது, இது தொழில்நுட்ப அறிவு இல்லாதவர்களும் பயன்படுத்தக்கூடிய dashboard-ஐ வழங்குகிறது. Plausible Community Edition மற்றும் Rybbit ஆகிய இரண்டுமே ClickHouse-ஐப் பயன்படுத்துவதால், அவற்றுக்கு 2 GB அல்லது அதற்கு மேற்பட்ட RAM தேவைப்படும். Matomo ஒரு முழுமையான தயாரிப்பு என்பதால், உங்கள் traffic-க்கு ஏற்ப server-ன் அளவைத் தீர்மானிக்க வேண்டும். GoAccess உங்கள் web page-ல் எந்த மாற்றத்தையும் ஏற்படுத்தாது, ஏனெனில் இது ஏற்கனவே உள்ள log கோப்பை மட்டுமே படிக்கிறது.

Script tag அல்லது server log: ஒவ்வொன்றும் எதைக் காண முடியும்

Script tag என்பது browser-களை அளவிடுகிறது. பக்கம் ஏற்றப்படும்போது, script இயங்கி, உங்கள் collector-க்கு ஒரு கோரிக்கையை (request) அனுப்பும். அந்தச் சங்கிலித் தொடரில் ஏற்படும் எந்தத் தடையும் உங்களுக்குத் தெரியாது: JavaScript முடக்கப்பட்டிருப்பது, கோரிக்கையைத் தடுக்கும் filter list, collector-க்குச் சென்ற கோரிக்கை தோல்வியடைவது, அல்லது script-களை இயக்காத crawler.

Log parser என்பது கோரிக்கைகளை அளவிடுகிறது. நீங்கள் எதையும் நிறுவவில்லை என்றாலும், உங்கள் web server ஒவ்வொரு கோரிக்கைக்கும் ஒரு வரியை எழுதும், எனவே தரவு ஏற்கனவே வட்டில் (disk) இருக்கும். இது ஒவ்வொரு crawler-ஐயும், script tag இல்லாத கோப்புகளுக்கான ஒவ்வொரு hit-ஐயும் காணும். இது browser-க்குள் என்ன நடந்தது என்பதைக் காண முடியாது, மேலும் browser cache-லிருந்து அல்லது உங்கள் server-க்கு முன்னால் உள்ள CDN (content delivery network)-லிருந்து வழங்கப்பட்ட பக்கத்தைக் காண முடியாது, ஏனெனில் அந்த கோரிக்கை உங்கள் server-ஐ அடையவில்லை.

இந்த இரண்டு எண்களும் ஒத்துப்போகாது, ஆனால் இதில் எதுவுமே தவறல்ல. Matomo இரண்டையும் செய்ய முடியும், மேலும் அதன் JavaScript tracker-ஐ விட log import எவற்றைக் கைவிடுகிறது என்பதை அது ஆவணப்படுத்துகிறது: screen resolution மற்றும் page titles, events, content tracking, heatmaps, session recordings மற்றும் form analytics. அந்தப் பட்டியல், browser-களுக்குப் பதிலாக கோரிக்கைகளை எண்ணுவதற்கான விலையாகும்.

Bot traffic என்பது இந்த இடைவெளியின் மறுபாதி. நீங்கள் அவற்றை filter செய்யாவிட்டால், log-அடிப்படையிலான எண்ணிக்கையில் crawler-கள் அடங்கும், மேலும் ஒரு சாதாரண தளத்தில், crawler-களின் பங்கு உங்கள் முடிவுகளை மாற்றும் அளவுக்குப் பெரியதாக இருக்கும். GoAccess மற்றும் Matomo-வின் log import ஆகிய இரண்டுமே அறியப்பட்ட bot-களை filter செய்கின்றன. எவை தங்கள் user agent-ஐப் பற்றிப் பொய் சொல்கின்றனவோ, அந்த crawler-களை இவற்றால் filter செய்ய முடியாது. எனவே, log-அடிப்படையிலான எந்தவொரு கணக்கீட்டையும் server-ல் AI crawler-களைத் தடுப்பது போன்றவற்றுடன் இணைப்பதற்கும், தடுப்புக்கு முன்னால் அல்லாமல் பின்னால் log-ஐப் படிப்பதற்கும் இதுவே நல்ல காரணமாகும்.

GoAccess: உங்களிடம் ஏற்கனவே உள்ள log-லிருந்து analytics பெறுதல்

இதனை திட்டத்தின் சொந்த Debian மற்றும் Ubuntu repository-லிருந்து நிறுவுங்கள், ஏனெனில் distribution packages-ல் புதிய releases தாமதமாகவே கிடைக்கும்.

wget -O - https://deb.goaccess.io/gnugpg.key | gpg --dearmor | sudo tee /usr/share/keyrings/goaccess.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/goaccess.gpg arch=$(dpkg --print-architecture)] https://deb.goaccess.io/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/goaccess.list
sudo apt-get update
sudo apt-get install goaccess

பிறகு, log கோப்பைச் சுட்டிக்காட்டி ஒரு static report-ஐ உருவாக்குங்கள்.

goaccess /var/log/nginx/access.log -o ~/report.html --log-format=COMBINED

சாதாரண பயனராக இயக்கும்போது இந்த command Permission denied பிழையுடன் தோல்வியடையும். ஏனெனில், Ubuntu-வில் nginx log-ன் உரிமையாளர் root மற்றும் அதன் group adm ஆகும். sudo usermod -aG adm $USER மூலம் உங்களை அந்த group-ல் சேர்த்துக்கொள்ளுங்கள். பிறகு, logout செய்து மீண்டும் login செய்யுங்கள், ஏனெனில் group membership login செய்யும்போதே படிக்கப்படும். id-ஐ இயக்கி, மீண்டும் முயற்சிக்கும் முன் adm பட்டியலில் உள்ளதா எனச் சரிபார்க்கவும்.

Live log-ல் எடுக்கப்படும் அறிக்கை, logrotate இன்னும் நகர்த்தாத தகவல்களை மட்டுமே கொண்டிருக்கும். நேற்றைய கோரிக்கைகள் access.log.1-ல் இருக்கும், பழையவை compressed நிலையில் இருக்கும். எனவே, வாராந்திர அறிக்கையைப் பெற சுழற்றப்பட்ட (rotated) கோப்புகளையும் படிக்க வேண்டும்.

zcat /var/log/nginx/access.log.*.gz | goaccess - --log-format=COMBINED -o ~/last-week.html

இதில் --real-time-html என்ற live mode-ம் உள்ளது, இது WebSocket வழியாகப் பக்கத்தைப் புதுப்பிக்கும். இதற்கு இரண்டாவது port மற்றும் அதற்கெனத் தனி proxy rule தேவை. பெரும்பாலான தளங்களுக்கு, cron மூலம் மணிநேரத்திற்கு ஒருமுறை அறிக்கை உருவாக்குவதே போதுமானது; மேலும் இது பாதுகாப்பதற்கும் எளிதானது.

GoatCounter: ஒரு Go binary மற்றும் ஒரு SQLite file

GoatCounter ஒரு statically compiled binary-ஆக வழங்கப்படுகிறது, எனவே இதில் runtime எதையும் நிறுவ வேண்டியதில்லை. Release பக்கத்திலிருந்து ஒரு build-ஐ எடுத்து இயக்கவும் அல்லது image-ஐப் பயன்படுத்தவும்.

docker run -p 8080:8080 -v goatcounter-data:/home/goatcounter/goatcounter-data arp242/goatcounter

Binary-ஆக இயக்கும்போது, goatcounter serve ஆனது 8080 port-ல் listening செய்யும் மற்றும் ./goatcounter-data/db.sqlite3-ல் SQLite கோப்பை உருவாக்கும். உங்கள் instance ஏற்கனவே ஒரு proxy-க்கு பின்னால் இருக்கும்போது, web wizard-க்கு பதிலாக command line மூலமாகவே முதல் site-ஐ உருவாக்கவும்.

goatcounter db create site -vhost=stats.example.com -user.email=me@example.com

இது goatcounter serve -listen=:443 -tls=tls,rdr,acme மூலம் தனது சொந்த certificate-ஐ ACME (automatic certificate management environment) பயன்படுத்தி கையாளும். இது வேறு எந்த சேவையும் இயங்காத ஒரு server-ல் பயனுள்ளதாக இருக்கும். ஏற்கனவே nginx அல்லது Caddy ஆகியவை 443 port-ஐப் பயன்படுத்தினால், GoatCounter-ஐ 8080 port-லேயே விட்டுவிட்டு, அதற்கு proxy செய்யவும். திட்டத்தின் மதிப்பீட்டின்படி tracking script சுமார் 3.5K அளவு கொண்டது, மேலும் JavaScript இல்லாத பக்கங்களுக்காக ஒரு tracking pixel-உம் உள்ளது. அதிக traffic உள்ள தளங்களில் SQLite ஒரு தடையாக மாறினால், அதே binary goatcounter serve -db 'postgresql+dbname=goatcounter' மூலம் Postgres-ஐயும் ஏற்கும். Backup எடுப்பது என்பது ஒரு கோப்பை நகலெடுப்பது மட்டுமே; இத்தகைய கருவி வடிவத்திற்கு இதுவே மிகச்சிறந்த சாதகமாகும்.

Medama: 256 MB நினைவகத்தில் இயங்கும் ஒற்றை container

Medama என்பது இந்த வரிசையில் உள்ள புதிய ஒற்றை binary விருப்பமாகும். இது வடிவமைப்பிலேயே cookie-களைப் பயன்படுத்துவதில்லை. இதன் tracker அளவு 1 KB-க்கும் குறைவு என்றும், 256 MB நினைவகம் கொண்ட virtual machine-களில் சிறிய தளங்களை இயக்க முடியும் என்றும் இந்தத் திட்டம் குறிப்பிடுகிறது. இவை அந்தத் திட்டத்தின் அதிகாரப்பூர்வ கூற்றுகள்; இந்த வழிகாட்டிக்காக அளவிடப்பட்ட எண்கள் அல்ல.

docker volume create medama-data
docker run -d -p 127.0.0.1:8080:8080 -v medama-data:/app/data ghcr.io/medama-io/medama:latest

இதன் அதிகாரப்பூர்வ கட்டளை port-ஐ 8080:8080-ல் வெளியிடுகிறது. மேலே உள்ள loopback prefix வேண்டுமென்றே சேர்க்கப்பட்டுள்ளது; இதற்கான காரணத்தை reverse proxy பகுதியில் காணலாம். முதல்முறை உள்நுழைய admin-ஐப் பயன்படுத்தவும், கடவுச்சொல்லாக CHANGE_ME_ON_FIRST_LOGIN-ஐப் பயன்படுத்தவும்; அந்த கடவுச்சொல்லின் பெயரே அதற்கான அறிவுறுத்தலாகும்.

ஆவணப்படுத்தப்பட்ட ஒரு தோல்வி நிலை உங்களைப் பாதிக்கலாம். HTTPS வழியாக அல்லது localhost-ல் மட்டுமே உள்நுழைவு செயல்படும். எனவே, certificate-ஐ அமைப்பதற்கு முன்பே proxy-ஐ அமைத்துவிட்டால், சரியான கடவுச்சொல்லை உள்ளிட்டாலும் படிவம் (form) அதை நிராகரிக்கும்; அதற்கான காரணம் திரையில் காட்டப்படாது. முதலில் TLS (transport layer security) அமைப்பை முடித்துவிட்டு, அதன் பிறகு உள்நுழையவும்.

Umami: Postgres மற்றும் அனைவரும் அறிந்த ஒரு dashboard

git clone https://github.com/umami-software/umami.git
cd umami
docker compose up -d

இது PostgreSQL container-உடன் சேர்த்து, port 3000-ல் application-ஐத் தொடங்குகிறது. குறைந்தபட்சத் தேவையாக PostgreSQL v12.14-ஐயும், source-லிருந்து build செய்வதாக இருந்தால் Node.js 18.18 அல்லது அதற்குப் பிந்தைய பதிப்பையும் ஆவணங்கள் குறிப்பிடுகின்றன. ஏற்கனவே இயங்கும் database-ஐ இணைக்க DATABASE_URL தேவைப்படும், இதற்காக docker.umami.is/umami-software/umami:postgresql-latest என்ற prebuilt image பயன்படுத்தப்படுகிறது.

முதல்முறை login செய்ய admin என்ற username மற்றும் umami என்ற password-ஐப் பயன்படுத்தவும். DNS-ஐ இந்த server-க்கு மாற்றும் முன்பே password-ஐ மாற்றிவிடவும்; ஏனெனில் DNS record resolve ஆகி proxy செயல்படத் தொடங்கியவுடன், இந்த instance இணையத்திலிருந்து அணுகக்கூடியதாக மாறிவிடும். Compose விவரங்கள், environment files மற்றும் restart policy ஆகியவற்றிற்கு, நீங்கள் முழுமையாகப் படிக்காத stack-ஐ அப்படியே நகலெடுப்பதற்குப் பதிலாக, VPS-ல் ஒரு Docker Compose stack என்பதைப் பார்க்கவும்.

இதன் footprint என்பது ஒரு Node process மற்றும் Postgres ஆகும். இது ஒரு single binary-ஐ விட அதிகமானது, ஆனால் ClickHouse-ஐப் பயன்படுத்தும் எதையும் விட மிகக் குறைவானது.

Plausible Community Edition: ClickHouse RAM அளவை நிர்ணயித்தல்

git clone -b v3.2.1 --single-branch https://github.com/plausible/community-edition plausible-ce
cd plausible-ce
touch .env
echo "BASE_URL=https://stats.example.com" >> .env
echo "SECRET_KEY_BASE=$(openssl rand -base64 48)" >> .env
docker compose up -d

ஆகஸ்ட் 2026 நிலவரப்படி v3.2.1 பதிப்பு தற்போதைய பதிப்பாகும், எனவே clone கட்டளை அதைத் திட்டமிட்டே குறிப்பிடுகிறது. இந்த stack மூன்று பகுதிகளைக் கொண்டது: application, கணக்குகள் மற்றும் அமைப்புகளுக்கான Postgres, மற்றும் நிகழ்வுத் தரவுகளுக்கான (event data) ClickHouse. SECRET_KEY_BASE குறைந்தபட்சம் 64 byte நீளம் கொண்டதாக இருக்க வேண்டும், இதைத்தான் openssl அழைப்பு உருவாக்குகிறது.

Plausible-ன் சொந்தத் தேவைகளின்படி, ClickHouse மற்றும் application ஆகியவை out of memory killer-ஆல் நிறுத்தப்படாமல் இருக்க குறைந்தபட்சம் 2 GB RAM தேவைப்படுகிறது. மேலும், ClickHouse-க்குத் தேவையான SSE 4.2 அல்லது NEON-ஐ ஆதரிக்கும் CPU அவசியம். நீங்கள் வாங்குவதற்கு முன் இந்த இரண்டாவது தேவையைச் சரிபார்ப்பது முக்கியம், இது ARM மற்றும் x86 VPS-க்கு இடையே தேர்ந்தெடுக்கும்போது உள்ள நடைமுறை வேறுபாடுகளில் ஒன்றாகும். ClickHouse தனக்குக் கிடைக்கும் அனைத்து நினைவகத்தையும் பயன்படுத்திக்கொள்ளும், எனவே பகிரப்பட்ட server-ல் Compose-ல் container நினைவகத்தை வரம்பிடல் பகுதியில் விவரிக்கப்பட்டுள்ளபடி ஒரு உச்சவரம்பை அமைக்கவும்.

BASE_URL பொது URL-உடன் சரியாகப் பொருந்த வேண்டும். அவ்வாறு பொருந்தவில்லை எனில், நீங்கள் உள்நுழையும்போது, application தவறான host-க்கு உங்களை வழிமாற்றும் (redirect). இதனால் session cookie உங்கள் browser இல்லாத ஒரு domain-க்கு எழுதப்படும், எனவே எந்தப் பிழைச் செய்தியும் இன்றி நீங்கள் மீண்டும் login பக்கத்திற்கே வருவீர்கள்.

வழங்கப்பட்ட compose file எந்த port-ஐயும் public-ஆகத் திறக்காது, ஏனெனில் இதற்கு முன்னால் ஒரு proxy இருக்கும் என்று எதிர்பார்க்கப்படுகிறது. loopback-ல் மட்டும் default application port-ஐத் திறக்கும் வகையில் ஒரு override-ஐச் சேர்க்கவும்.

cat > compose.override.yml << EOF
services:
    plausible:
        ports:
            - 127.0.0.1:8000:8000
EOF

Matomo: முழுமையான தயாரிப்பு மற்றும் அதற்குத் தேவையான server

Matomo, PHP மற்றும் MySQL அல்லது MariaDB-ல் இயங்குகிறது. இது container stack-ஐ விட, பாரம்பரிய web stack-க்கு மிகவும் பொருத்தமானது. இந்தத் தொகுப்பில் உள்ள கருவிகளில், traffic அளவைப் பொறுத்து வன்பொருள் (hardware) வழிகாட்டுதல்களை வெளியிடும் ஒரே கருவி இதுவாகும்.

[
  {
    "label": "100K/month",
    "cpu_cores": 2,
    "ram_gb": 2,
    "disk_gb": 50
  },
  {
    "label": "1M/month",
    "cpu_cores": 4,
    "ram_gb": 8,
    "disk_gb": 250
  },
  {
    "label": "10M/month",
    "cpu_cores": 8,
    "ram_gb": 16,
    "disk_gb": 400
  }
]

இவை ஆகஸ்ட் 2026 நிலவரப்படி Matomo வெளியிட்ட குறைந்தபட்சத் தேவைகள்; இந்த வழிகாட்டலுக்காக எடுக்கப்பட்ட அளவீடுகள் அல்ல. மாதத்திற்கு 100,000 pageviews வரை, இதற்கு 2 CPU cores, 2 GB RAM மற்றும் 50 GB SSD தேவைப்படுகிறது. ஒரே server-ல் application மற்றும் database ஆகிய இரண்டையும் இயக்கலாம். 1M/month அளவில், இதற்கு 8 GB RAM மற்றும் 250 GB disk தேவை. 10M/month அளவில், Matomo இரண்டு server-களைப் பரிந்துரைக்கிறது. கடைசி வரிசையில் database server-க்கான தேவை கொடுக்கப்பட்டுள்ளது: 16 GB RAM மற்றும் 400 GB disk. இந்த disk அளவுகளை, முழு தரவுத்தொகுப்பும் ஒரே SQLite கோப்பாக இருக்கும் ஒற்றை binary விருப்பங்களுடன் ஒப்பிட்டுப் பார்க்கவும்.

Archiving செயல்முறைதான் பலரை ஆச்சரியப்படுத்தும். இயல்பாக, யாராவது dashboard-ஐத் திறக்கும்போது Matomo அறிக்கைகளை உருவாக்குகிறது. எனவே, தரவு வளர வளர dashboard-ன் வேகம் குறைந்து, இறுதியில் timeout ஆகிவிடும். இதற்குப் பரிந்துரைக்கப்படும் தீர்வு: general settings-ல் browser triggered archiving-ஐ முடக்கிவிட்டு, Matomo கோப்புகளை வைத்திருக்கும் பயனரின் கணக்கிலிருந்து, Matomo directory-க்குள் cron மூலம் archiver-ஐ இயக்குவதாகும்.

php console core:archive --url=https://analytics.example.com

Matomo, செயலாக்கப்பட்ட அறிக்கை அட்டவணைகளுக்கு (report tables) அருகிலேயே மூலப் பதிவு அட்டவணைகளையும் (raw log tables) வைத்திருக்கிறது. பழைய மூலத் தரவுகளையும் அறிக்கைகளையும் ஒரு கால அட்டவணைப்படி நீக்க முடியும். disk நிறைந்த பிறகு இதைச் செய்யாமல், நிறுவும்போதே இந்த வசதியைச் செயல்படுத்தவும். Matomo, server access logs-ஐயும் இறக்குமதி செய்யக்கூடியது. எனவே, இந்த இரண்டு வகை தரவுகளையும் ஒரே நேரத்தில் கையாளும் ஒரே தயாரிப்பு இதுவாகும்.

Rybbit மற்றும் புதிய stacks

git clone https://github.com/rybbit-io/rybbit.git
cd rybbit
chmod +x *.sh
./setup.sh your.domain.name

Rybbit என்பது நவீன dashboard-ஐக் கொண்ட ஒரு புதிய மென்பொருள். இதன் setup script, environment file-ஐ உருவாக்கி, Docker Compose மூலம் stack-ஐ இயக்குகிறது. இது ClickHouse-ஐ இயக்குவதுடன், Caddy-ஐ அதன் சொந்த web server-ஆகப் பயன்படுத்துகிறது. இது 443 port-ஐ எடுத்துக்கொண்டு, நீங்கள் குறிப்பிடும் domain-க்கு certificate-ஐப் பெறுகிறது. ஏற்கனவே nginx 443 port-ஐப் பயன்படுத்தும் server-ல், இந்த script-ஆல் port-ஐ bind செய்ய முடியாது. எனவே, project-ன் manual Compose முறையைப் பயன்படுத்தி, அதை உங்கள் ஏற்கனவே உள்ள proxy-க்கு பின்னால் அமைக்கவும். ClickHouse-ன் தேவைக்காக, குறைந்தது 2 GB RAM, Ubuntu 24 LTS, மற்றும் ARM-ல் ARMv8.2-A அல்லது அதற்கு மேற்பட்ட பதிப்பு தேவை என்று ஆவணங்கள் குறிப்பிடுகின்றன.

எந்தவொரு புதிய project-க்கும் பொருந்தும் எச்சரிக்கை: இதில் வசதிகள் விரைவாகச் சேர்க்கப்படுகின்றன, அதேபோல் மாற்றங்களும் (breaking changes) அடிக்கடி நிகழ்கின்றன. ஒரு குறிப்பிட்ட tag-ஐப் பயன்படுத்தவும் (pin), pull செய்வதற்கு முன் release notes-ஐப் படிக்கவும், முதலில் database backup எடுக்கவும்.

Retention மற்றும் disk growth: உங்கள் server-ல் அளவிடுதல்

Disk growth என்பது ஒரு event-க்கு அந்த tool எவ்வளவு தரவைச் சேமிக்கிறது என்பதைப் பொறுத்தது. GoatCounter hits-களை counters-ஆகத் தொகுக்கிறது, எனவே raw volume-ஐ விட, தனித்துவமான பக்கங்கள் மற்றும் நாட்களின் எண்ணிக்கையைப் பொறுத்தே அதன் கோப்பு அளவு வளரும். Umami மற்றும் Matomo ஒவ்வொரு event-க்கும் தனித்தனி rows-களைச் சேமிக்கின்றன; Matomo raw tables-க்கு மேலாகச் செயலாக்கப்பட்ட report tables-களையும் சேமிக்கிறது. ClickHouse நிகழ்வுகளை columns-ஆகச் சேமித்து அவற்றை வலுவாகக் குறுக்குகிறது (compress); இதனால்தான் row store-களை விட Plausible அதிக volume-ஐக் கையாள முடிகிறது.

இந்த வழிகாட்டி ஒரு மில்லியன் pageviews-க்கு இத்தனை megabytes தேவை என்ற புள்ளிவிவரத்தை வழங்கவில்லை, ஏனெனில் உங்கள் traffic-ல் அது அளவிடப்படவில்லை. நீங்களே அந்த அளவீட்டைச் செய்யுங்கள். உங்கள் Compose கோப்பிற்கு ஏற்ப service மற்றும் user பெயர்களை மாற்றிக்கொள்ளுங்கள்.

du -h goatcounter-data/db.sqlite3
docker compose exec db psql -U umami -d umami -c "SELECT pg_size_pretty(pg_database_size('umami'));"
docker compose exec plausible_events_db clickhouse-client -q "SELECT formatReadableSize(sum(bytes_on_disk)) FROM system.parts WHERE active"

அந்த எண்ணைப் பதிவு செய்யுங்கள், ஒரு வாரம் காத்திருங்கள், மீண்டும் பதிவு செய்யுங்கள், அந்த வாரத்திற்கு dashboard காட்டும் pageviews எண்ணிக்கையால் அந்த வித்தியாசத்தைப் பிரியுங்கள். அந்த எண் உங்கள் தளம் மற்றும் bot filtering-ஐப் பொறுத்தது, எனவே வெளியிடப்பட்ட எந்த சராசரியை விடவும் இதுவே துல்லியமானது. அந்த எண் சிறியதாக இருக்கும்போதே retention limit-ஐ அமைத்துவிடுங்கள். Disk முழுமையாக நிரம்பினால், analytics மட்டுமல்லாமல் VPS-ல் உள்ள அனைத்து service-களும் முடங்கிவிடும். இதுவே database volume-ஐ df -h எச்சரிக்கும் இடத்தில் வைத்திருப்பதற்கான மிக முக்கியமான காரணம். ஏற்கனவே அதிக இடம் எடுக்கும் கோப்புகளைக் கொண்ட server-களில் இந்த அபாயத்திற்கு அதிக கவனம் தேவை, ஏனெனில் a self-hosted photo server எந்த analytics database-ஐ விடவும் மிக விரைவாக disk-ஐ நிரப்பிவிடும்.

Reverse proxy-க்கு பின்னால் இது எவ்வாறு செயல்படுகிறது

நீங்கள் அளவிடும் தளத்தின் subdomain-ல் collector-ஐ வைக்கவும், உதாரணமாக stats.example.com. இது collector கோரிக்கையை first-party ஆக மாற்றுகிறது, எனவே third-party கோரிக்கைகளைத் தடுக்கும் browser விதிகளால் இது பாதிக்கப்படாது.

Container port-ஐ வெளியிடும்போது, application-ஐ loopback-ல் bind செய்யவும். Docker தனது சொந்த firewall விதிகளை ufw-க்கு முன்னதாகவே எழுதிவிடுகிறது, எனவே -p 3000:3000 என வெளியிடப்பட்ட container, ufw status அந்த port மறுக்கப்பட்டதாகக் காட்டினாலும், இணையத்திலிருந்து அணுகக்கூடியதாகவே இருக்கும். மற்றொரு கணினியிலிருந்து curl http://SERVER_IP:3000 மூலம் சோதித்துப் பாருங்கள், உங்களுக்கு dashboard கிடைக்கும். -p 127.0.0.1:3000:3000 என வெளியிடப்பட்டால், அதே சோதனை Connection refused என்று காட்டும் மற்றும் proxy மட்டுமே அதை அணுக முடியும்.

server {
    listen 443 ssl;
    server_name stats.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Forwarding headers இங்கே கட்டாயமானவை. X-Forwarded-For இல்லையென்றால், ஒவ்வொரு வருகையும் 127.0.0.1-லிருந்து வருவது போலத் தோன்றும், இதனால் நாட்டின் அடிப்படையிலான அறிக்கை காலியாக இருக்கும் மற்றும் தனித்துவமான பார்வையாளர்களின் எண்ணிக்கை ஒன்றாகக் குறையும். ஒவ்வொரு project-ம் எந்த header-ஐ நம்புவது மற்றும் எந்த அமைப்பின் கீழ் செயல்படுவது என்பதைத் தீர்மானிக்கிறது, எனவே ஊகிப்பதற்குப் பதிலாக அதன் proxy ஆவணங்களை ஒருமுறை சரிபார்க்கவும். Caddy அந்த headers-ஐ தானாகவே அமைக்கிறது, அதே வேலைக்கான Caddyfile வெறும் இரண்டு வரிகள் மட்டுமே.

stats.example.com {
    reverse_proxy 127.0.0.1:3000
}

நீங்கள் இன்னும் proxy-ஐத் தேர்ந்தெடுக்கவில்லை என்றால், nginx, Caddy மற்றும் Traefik ஆகியவற்றின் ஒப்பீடு சில subdomain-களைக் கொண்ட ஒரு server-க்கு எது பொருத்தமானது என்பதை விளக்குகிறது.

நீங்கள் self-host செய்யும்போது cookie banner தேவைப்படுமா?

Self-hosting செய்வதால் தரவை வைத்திருப்பவர் மாறுகிறார். ஆனால், தரவு குறித்த சட்ட விதிகள் மாறுவதில்லை. இரண்டு விதிகளைத் தனித்தனியாகப் புரிந்துகொள்ள வேண்டும். ePrivacy ஒப்புதல் விதி என்பது பார்வையாளரின் சாதனத்தில் எதையாவது சேமிப்பது அல்லது வாசிப்பது தொடர்பானது. எனவே, cookie-களைப் பயன்படுத்தாத மற்றும் local storage-ல் எதையும் எழுதாத ஒரு கருவி இந்த விதிக்கு உட்பட்டது அல்ல. GDPR என்பது தனிப்பட்ட தரவைச் செயலாக்குவது தொடர்பானது. IP address என்பது தனிப்பட்ட தரவாகக் கருதப்படுகிறது. எனவே, உங்களுக்குச் சட்டப்பூர்வமான அடிப்படை, தரவு சேமிப்பு வரம்பு மற்றும் உங்களிடம் உள்ள தரவு குறித்து யாராவது கேட்டால் பதில் சொல்லும் கடமை ஆகியவை தொடர்ந்து இருக்கும்.

Plausible, Umami, GoatCounter மற்றும் Medama ஆகியவை இயல்பாகவே cookie-களைப் பயன்படுத்துவதில்லை. ஒவ்வொன்றும் எதிலிருந்து தரவைப் பெறுகின்றன என்பது திட்டத்திற்குத் திட்டம் மற்றும் version-க்கு version மாறுபடும். எனவே, சுருக்கமான குறிப்புகளை நம்பாமல், அந்தந்தத் திட்டத்தின் அதிகாரப்பூர்வ privacy ஆவணங்களை வாசிக்கவும். Matomo-வில் IP anonymisation வசதி உள்ளது; மேலும், admin interface-ல் நீங்கள் enable செய்யக்கூடிய opt-out endpoint-ம் உள்ளது.

ஒவ்வொரு நாட்டிலும் உள்ள கட்டுப்பாட்டாளர்கள் வெவ்வேறு முடிவுகளை எடுக்கிறார்கள். உதாரணமாக, பிரான்சின் CNIL, பார்வையாளர் அளவீட்டுத் தரவுகள் (audience measurement) எந்தச் சூழலில் ஒப்புதல் பெறுவதிலிருந்து விலக்கு பெறலாம் என்பதற்கான நிபந்தனைகளை வெளியிட்டுள்ளது. இந்தப் பகுதி ஒரு உண்மைச் சுருக்கம் மட்டுமே, இது சட்ட ஆலோசனை அல்ல. உண்மையான பயனர்களைக் கொண்ட ஒரு தளத்திற்கு, உங்கள் அதிகார வரம்பிற்குள் உள்ள ஒரு வழக்கறிஞரை அணுகவும்.

பலர் கவனிக்கத் தவறும் ஒரு விஷயம்: access log-ம் ஒரு தனிப்பட்ட தரவுதான். GoAccess பக்கத்தில் எந்த script-ஐயும் சேர்ப்பதில்லை, ஆனாலும் அது IP address-களைச் செயலாக்குகிறது. எனவே, log-அடிப்படையிலான analytics தானாகவே சட்ட விதிகளிலிருந்து விலக்கு பெற்றுவிடாது.

Ad blockers மற்றும் உங்கள் புள்ளிவிவரங்கள் ஏன் குறையும்

Filter lists-கள் hostname மற்றும் URL pattern-ஐ அடிப்படையாகக் கொண்டு செயல்படுகின்றன. ஒரு hosted analytics தயாரிப்பை எளிதாகக் கண்டறிய முடியும், ஏனெனில் அனைவரும் அதை ஒரே நன்கு அறியப்பட்ட hostname-லிருந்துதான் ஏற்றுகிறார்கள். collector-ஐ உங்கள் சொந்த subdomain-க்கு மாற்றுவது அந்த hostname-ஐ கோரிக்கையிலிருந்து நீக்குகிறது, மேலும் நீங்கள் தேர்ந்தெடுத்த path-லிருந்து script-ஐ வழங்குவது நன்கு அறியப்பட்ட filename-ஐ நீக்குகிறது. இவை இரண்டுமே ஒரு list எதை வைத்து கண்டறிய வேண்டும் என்பதை மாற்றுகின்றன.

இந்தக் கட்டுரை ஒரு குறிப்பிட்ட hit rate-ஐ உறுதிப்படுத்தவில்லை, ஏனெனில் அது எதையும் அளவிடவில்லை. எந்தவொரு அமைப்பையும் தடுக்கும் பார்வையாளர்களின் பங்கு உங்கள் வாசகர்களைப் பொறுத்தது; பொதுவான பார்வையாளர்களை விட, தொழில்நுட்ப வல்லுநர்கள் (developer audience) அதிக அளவில் தடுக்கிறார்கள். அதற்குப் பதிலாக உங்கள் இடைவெளியை நீங்களே அளவிடுங்கள். ஒரே வாரத்தில், access log-ல் உள்ள HTML பக்கங்களுக்கான கோரிக்கைகளை GoAccess மூலம் எண்ணுங்கள், அதை உங்கள் script அடிப்படையிலான கருவி தெரிவிக்கும் pageviews-உடன் ஒப்பிடுங்கள். அந்த வித்தியாசம் என்பது தடுக்கப்பட்ட வருகைகள் மற்றும் உங்கள் தளத்தில் cache-லிருந்து வழங்கப்பட்ட பக்கங்களின் கூட்டுத்தொகை ஆகும்.

நீங்கள் ஒரு hosted தயாரிப்பிலிருந்து மாறும்போது, அந்த நாளில் மொத்த எண்ணிக்கை மாறுவதை எதிர்பார்க்கலாம். அந்த மாற்றத்தின் ஒரு பகுதி தடுப்பு நடவடிக்கையுடன் தொடர்புடையதாக இருக்காது என்பதையும் கவனத்தில் கொள்ளுங்கள். ஒரு pageview என்பது என்ன, single page application-க்குள் ஒரு route மாற்றம் ஒரு pageview-ஆகக் கருதப்படுமா, மற்றும் ஒரு session எப்போது முடிவடைகிறது என்பதில் தயாரிப்புகளுக்கிடையே கருத்து வேறுபாடுகள் உள்ளன. போக்குவரத்து (traffic) குறைந்துவிட்டது என்று முடிவெடுப்பதற்கு முன், வாரங்களுக்கு இடையிலான போக்குகளை ஒப்பிட்டுப் பாருங்கள்.

எந்த தளத்திற்கு எது சிறந்தது

• மாதத்திற்கு சுமார் 50,000 பக்கப் பார்வைகளைக் கொண்ட தனிப்பட்ட தளம் அல்லது வலைப்பதிவு: 1 GB VPS-ல் GoatCounter அல்லது Medama, கோப்பு நகல் (file copy) மூலம் செய்யப்படும் காப்புப்பிரதிகளுடன்.
• ஸ்கிரிப்ட் சேர்க்க முடியாத தளம் அல்லது பார்வையாளர்கள் அதிக அளவில் தடுக்கும் தளம்: ஏற்கனவே உள்ள log கோப்புகளைக் கொண்டு, குறிப்பிட்ட கால இடைவெளியில் இயங்கும் GoAccess.
• மற்றவர்கள் dashboard-ஐப் பார்க்கும் சிறு வணிகத் தளம்: Postgres container-உடன் கூடிய Umami.
• இலக்குகள் (goals) மற்றும் புனல் (funnels) தேவைப்படும் தளம், 2 GB RAM அல்லது அதற்கு மேற்பட்ட வசதி கொண்ட server: Plausible Community Edition, அல்லது புதிய dashboard தேவைப்பட்டு, புதிய திட்டங்களை ஏற்றுக்கொள்பவர்களுக்கு Rybbit.
• பல தளங்கள், பல பயனர் கணக்குகள் அல்லது உங்கள் சொந்த தரவு சேமிப்புக் கொள்கையின்படி மூலத் தரவை (raw data) வைத்திருக்க வேண்டிய தேவை: Matomo, மேலே குறிப்பிடப்பட்டுள்ள அதன் வழிகாட்டுதல்களின்படி அளவிடப்பட்டது.

உங்கள் தேவைக்கு ஏற்ற மிகச்சிறிய கருவியிலிருந்து தொடங்குங்கள். GoatCounter-லிருந்து பிறகு Plausible-க்கு மாறுவது ஒரு subdomain மற்றும் சில வரலாற்றுத் தரவுகளை இழக்கச் செய்யும். Matomo-விலிருந்து வேறு எந்த கருவிக்கு மாறுவதும் கடினமான இடப்பெயர்ச்சி (migration) செயல்முறையை உள்ளடக்கியது. அதே server-ல் வேறு என்னென்ன சேவைகளை நிறுவலாம் என்று நீங்கள் இன்னும் முடிவு செய்யவில்லை என்றால், பரந்த அளவிலான self-hosting தொகுப்பு அடுத்ததாக எதை நிறுவலாம் என்பதை விளக்குகிறது. உங்களுக்கு பார்வையாளர்களின் எண்ணிக்கையை விட, application-ன் கோரிக்கை அளவிலான கண்காணிப்பு (request level tracing) தேவைப்பட்டால், அதற்கு self-hosted observability service என்பதே சரியான கருவியாகும்.

FAQ

self-hosted analytics பயன்படுத்துவது cookie banner தேவையை நீக்குமா?

இல்லை, இவை இரண்டும் தனித்தனி விஷயங்கள். ePrivacy விதியின் கீழ், பார்வையாளரின் சாதனத்தில் எதையாவது சேமிப்பது அல்லது வாசிப்பது தொடர்பான கட்டுப்பாடுகள் உள்ளன. எனவே, cookie-களைப் பயன்படுத்தாத மற்றும் local storage-ல் எதையும் எழுதாத ஒரு கருவி இந்தத் தேவையின் கீழ் வராது. GDPR என்பது தனிப்பட்ட தரவுகளைக் கையாளுவது தொடர்பான வேறொரு விதிமுறை. IP address என்பது தனிப்பட்ட தரவு என்பதால், cookie இல்லையென்றாலும் உங்களுக்குச் சட்டப்பூர்வமான அடிப்படை மற்றும் தரவு சேமிப்பு வரம்பு தேவை. Self-hosting மூலம் தரவு உங்கள் server-க்கு மாறுகிறது, எனவே அதற்கு நீங்களே பொறுப்பாவீர்கள். உங்கள் நாட்டின் ஒழுங்குமுறை ஆணையத்தின் வழிகாட்டுதல்களைச் சரிபார்த்து, உங்கள் சூழலுக்கு ஏற்ப வழக்கறிஞரிடம் ஆலோசனை பெறவும்.

VPS-ல் self-hosted analytics-க்கு எவ்வளவு RAM தேவைப்படும்?

Dashboard அல்ல, datastore-தான் தேவையைத் தீர்மானிக்கிறது. GoatCounter மற்றும் Medama ஆகியவை ஒரே கோப்பின் மீது ஒரு process-ஆக இயங்குகின்றன; Medama ஆவணங்களின்படி, சிறிய தளங்களை 256 MB RAM கொண்ட இயந்திரங்களில் இயக்கலாம். Umami, Node application-உடன் ஒரு Postgres container-ஐச் சேர்க்கிறது. Plausible Community Edition மற்றும் Rybbit ஆகிய இரண்டுமே ClickHouse-ஐப் பயன்படுத்துகின்றன, இவை இரண்டுக்கும் குறைந்தது 2 GB RAM தேவைப்படுகிறது. Matomo-வின் வழிகாட்டுதலின்படி, மாதத்திற்கு 100,000 pageviews வரை கையாள 2 CPU cores மற்றும் 2 GB RAM தேவை.

நான் முன்பு பயன்படுத்திய analytics-ஐ விட self-hosted analytics-ல் ஏன் எண்ணிக்கை குறைவாக உள்ளது?

இதற்கு இரண்டு உண்மையான காரணங்கள் உள்ளன. Filter lists சில collector requests-ஐத் தடுப்பதால், script அடிப்படையிலான அனைத்துக் கருவிகளும் அந்த வருகைகளை இழக்கின்றன. மேலும், ஒவ்வொரு தயாரிப்பும் pageview மற்றும் session முடிவை வெவ்வேறு விதமாகக் கணக்கிடுகின்றன. உங்கள் access log-ல் உள்ள ஒரு வார கால HTML page requests-ஐ, அதே வாரத்தின் script அடிப்படையிலான pageviews-உடன் ஒப்பிட்டுப் பாருங்கள். அந்த இடைவெளி என்பது தடுக்கப்பட்ட வருகைகள் மற்றும் cached pages ஆகும்; இதை மற்றவர்களின் தரவுகளுடன் ஒப்பிடாமல், உங்கள் தளத்தின் தரவுகளைக் கொண்டே அளவிட வேண்டும்.

ARM VPS-ல் Plausible அல்லது Rybbit-ஐ இயக்க முடியுமா?

இவை இரண்டுமே ClickHouse-ஐப் பயன்படுத்துகின்றன. ClickHouse-க்கு x86-ல் SSE 4.2 அல்லது ARM-ல் NEON தேவை. Plausible-ன் தேவைகள் இதைத் தெளிவாகக் குறிப்பிடுகின்றன, Rybbit ஆவணங்களின்படி ARM system-களுக்கு ARMv8.2-A அல்லது அதற்குப் பிந்தைய பதிப்பு தேவை. தற்போதைய ARM server cores இந்தத் தேவையைப் பூர்த்தி செய்கின்றன, பழையவை பூர்த்தி செய்வதில்லை. இது நிகழும்போது, application log-ல் பிழை காட்டாமல், instruction set பிழை காரணமாக ClickHouse தொடங்க மறுக்கும். சிறிய ARM box-களில், single file கருவிகளைப் பயன்படுத்தினால் இந்தச் சிக்கல் வராது, ஏனெனில் அவை ClickHouse-ஐப் பயன்படுத்துவதில்லை.

tracking script-க்கு பதிலாக server logs-ஐப் பகுப்பாய்வு செய்யலாமா?

Script சேர்க்க முடியாத சூழலில், உங்கள் பார்வையாளர்கள் அதிக அளவில் தடுப்புகளைப் பயன்படுத்தும் போது, அல்லது crawlers-ஐயும் உள்ளடக்கிய எண்ணிக்கை தேவைப்படும்போது log parsing-ஐப் பயன்படுத்தவும். GoAccess உங்கள் server ஏற்கனவே எழுதும் log-ஐ வாசிப்பதால், இது கூடுதல் page weight-ஐயோ அல்லது database-ஐயோ உருவாக்காது. ஆனால், browser-க்குள் நடக்கும் எதையும் உங்களால் கண்காணிக்க முடியாது. CDN அல்லது browser cache மூலம் வழங்கப்படும் பக்கங்களை உங்களால் கணக்கிட முடியாது, ஏனெனில் அந்த request உங்கள் server-ஐ வந்தடையாது. பல தளங்கள் இரண்டையும் பயன்படுத்தி, அவற்றை இரண்டு வெவ்வேறு அளவீடுகளாகக் கருதுகின்றன.