SSD Nodes Learn 🎉 VPS từ $5.50/tháng
Hướng dẫn Matt ConnorBởi Matt Connor · Cập nhật ngày 2026-08-16

Analytics self-hosted nào hợp với VPS nhỏ?

So sánh Plausible, Umami, Matomo, GoatCounter và GoAccess trên VPS nhỏ: RAM, database, disk tăng ra sao, reverse proxy và khoảng trống do ad blocker.

Bạn nên chạy công cụ phân tích web self-hosted nào trên VPS?

Phân tích web self-hosted có 2 nhóm. Chọn sai nhóm gây tốn kém hơn chọn sai sản phẩm. Một nhóm chạy một script nhỏ trong trình duyệt của khách truy cập rồi lưu dữ liệu mà script đó báo cáo. Nhóm còn lại đọc access log mà web server đã ghi sẵn. Tất cả yếu tố sau đó, bao gồm database và lượng memory cần dùng, đều phụ thuộc vào lựa chọn này.

Câu trả lời ngắn gọn cho một máy chủ nhỏ: GoatCounter và Medama chạy được trên 1 GB vì mỗi công cụ chỉ gồm một process và một file. Umami thêm một Postgres container và cung cấp dashboard mà người không chuyên về kỹ thuật vẫn có thể đọc. Plausible Community Edition và Rybbit đều chạy ClickHouse, vì vậy hãy chuẩn bị ít nhất 2 GB RAM. Matomo là một sản phẩm đầy đủ tính năng và cần server có cấu hình phù hợp với lưu lượng của bạn. GoAccess không thêm gì vào trang web vì nó đọc một log đã tồn tại.

Thẻ script hoặc log máy chủ: mỗi loại nhìn thấy được gì

Thẻ script đo lường trình duyệt. Trang được tải, script chạy, rồi gửi một request đến collector của bạn. Bất kỳ yếu tố nào làm đứt chuỗi này đều không thể quan sát được: JavaScript bị tắt, filter list chặn request, request đến collector thất bại hoặc crawler không bao giờ chạy script.

Log parser đo lường request. Web server ghi một dòng cho mỗi request, dù bạn có cài thêm gì hay không, nên dữ liệu đã có sẵn trên disk. Nó thấy mọi crawler và mọi lượt truy cập vào file không chứa thẻ script. Nó không thấy những gì xảy ra bên trong trình duyệt. Nó cũng không thấy trang được phục vụ từ browser cache hoặc từ CDN (content delivery network) nằm phía trước máy chủ của bạn, vì request đó không bao giờ đến server.

Hai con số sẽ không khớp, và không con số nào sai. Matomo hỗ trợ cả hai cách. Matomo cũng ghi rõ log import không có được những dữ liệu nào so với JavaScript tracker: độ phân giải màn hình và tiêu đề trang, event, content tracking, heatmap, session recording và form analytics. Đó là phần dữ liệu phải đánh đổi khi đếm request thay vì trình duyệt.

Bot traffic là phần còn lại tạo ra chênh lệch. Số liệu dựa trên log sẽ bao gồm crawler nếu bạn không lọc chúng. Với một site thông thường, tỷ lệ crawler đủ lớn để làm thay đổi kết luận của bạn. GoAccess và log import của Matomo đều lọc các bot đã biết. Không công cụ nào lọc được crawler giả mạo user agent. Vì vậy, nên kết hợp mọi cách đếm dựa trên log với chặn AI crawler tại server và đọc log sau khi chặn thay vì trước khi chặn.

GoAccess: phân tích từ log bạn đang có

Cài GoAccess từ repository Debian và Ubuntu chính thức của dự án, vì package do distribution cung cấp thường chậm hơn các bản release mới.

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

Sau đó trỏ GoAccess vào log và ghi báo cáo tĩnh.

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

Lệnh đó sẽ lỗi với Permission denied khi chạy bằng user thông thường, vì trên Ubuntu, log nginx thuộc sở hữu của root và có group adm. Thêm user của bạn vào group đó bằng sudo usermod -aG adm $USER, sau đó đăng xuất rồi đăng nhập lại, vì hệ thống chỉ đọc membership của group khi đăng nhập. Chạy id và kiểm tra adm xuất hiện trong danh sách trước khi thử lại.

Báo cáo đọc từ log hiện tại chỉ bao phủ phần log mà logrotate chưa chuyển đi. Request của ngày hôm qua nằm trong access.log.1, còn các file cũ hơn đã được nén, vì vậy báo cáo theo tuần cũng phải đọc các file đã rotate.

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

GoAccess cũng có chế độ live, --real-time-html, cập nhật trang qua WebSocket. Chế độ này cần thêm một port và một proxy rule riêng. Với hầu hết website, báo cáo theo giờ được cron ghi ra là đủ và cần bảo vệ ít hơn.

GoatCounter: một file nhị phân Go và một file SQLite

GoatCounter được phát hành dưới dạng file nhị phân đã biên dịch tĩnh, nên không cần cài runtime. Tải một bản build từ trang release rồi chạy, hoặc dùng image.

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

Khi chạy dưới dạng file nhị phân, goatcounter serve lắng nghe trên cổng 8080 và tạo cơ sở dữ liệu SQLite tại ./goatcounter-data/db.sqlite3. Khi instance đã nằm sau proxy, hãy tạo site đầu tiên từ command line thay vì dùng web wizard.

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

GoatCounter có thể tự quản lý chứng chỉ bằng goatcounter serve -listen=:443 -tls=tls,rdr,acme, sử dụng ACME (môi trường quản lý chứng chỉ tự động). Cách này phù hợp với máy chủ không chạy dịch vụ nào khác. Nếu nginx hoặc Caddy đã quản lý cổng 443, hãy để GoatCounter chạy trên cổng 8080 rồi proxy đến đó. Theo số liệu của dự án, tracking script có kích thước khoảng 3.5K. GoatCounter cũng có tracking pixel cho các trang không có JavaScript. Nếu SQLite trở thành giới hạn trên site có lưu lượng cao, cùng file nhị phân đó có thể dùng Postgres với goatcounter serve -db 'postgresql+dbname=goatcounter'. Backup chỉ cần copy file. Đây là ưu điểm thực tế của mô hình này.

Medama: một container duy nhất yêu cầu 256 MB

Medama là lựa chọn binary duy nhất mới nhất trong danh sách này. Theo thiết kế, nó không dùng cookie. Dự án cho biết tracker có kích thước dưới 1 KB và các site nhỏ có thể chạy trên virtual machine với 256 MB bộ nhớ. Đây là các tuyên bố do dự án công bố, không phải số liệu được đo cho hướng dẫn này.

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

Lệnh chính thức publish port là 8080:8080. Prefix loopback ở trên là có chủ ý; phần reverse proxy giải thích lý do. Lần đăng nhập đầu tiên dùng admin với mật khẩu CHANGE_ME_ON_FIRST_LOGIN, và tên của mật khẩu đó chính là hướng dẫn.

Có một lỗi đã được ghi nhận mà bạn dễ gặp phải. Bạn chỉ đăng nhập được qua HTTPS hoặc trên localhost. Vì vậy, nếu bạn thiết lập proxy trước khi có certificate, form sẽ từ chối mật khẩu đúng nhưng không in ra lý do. Hãy hoàn tất thiết lập TLS (transport layer security) trước, rồi đăng nhập.

Umami: Postgres và dashboard quen thuộc

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

Lệnh này khởi động ứng dụng trên cổng 3000 cùng với một container PostgreSQL. Tài liệu yêu cầu tối thiểu PostgreSQL v12.14. Nếu build từ source, cần Node.js 18.18 trở lên. Umami có image dựng sẵn là docker.umami.is/umami-software/umami:postgresql-latest. Image này cần DATABASE_URL trỏ đến database bạn đã chạy sẵn.

Thông tin đăng nhập đầu tiên là admin, với mật khẩu umami. Hãy đổi mật khẩu trước khi trỏ DNS đến máy chủ. Ngay khi bản ghi phân giải và proxy phản hồi, instance đã có thể truy cập từ Internet. Xem chi tiết Compose, các file môi trường và restart policy trong stack Docker Compose trên VPS, thay vì sao chép một stack mà bạn chưa đọc.

Mức sử dụng tài nguyên gồm một tiến trình Node và Postgres. Cách này nặng hơn một binary đơn lẻ nhưng nhẹ hơn nhiều so với các hệ thống chạy ClickHouse.

Plausible Community Edition: ClickHouse đặt mức RAM tối thiểu

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

Phiên bản v3.2.1 là phiên bản hiện tại vào tháng 8 năm 2026, và lệnh clone cố định phiên bản này theo chủ ý. Stack gồm ba phần: ứng dụng, Postgres lưu tài khoản và cài đặt, và ClickHouse lưu dữ liệu sự kiện. SECRET_KEY_BASE phải là chuỗi có độ dài ít nhất 64 byte. Lệnh gọi openssl tạo ra chuỗi như vậy.

Yêu cầu của Plausible là ít nhất 2 GB RAM để ClickHouse và ứng dụng không bị OOM killer kết thúc, cùng CPU hỗ trợ SSE 4.2 hoặc NEON vì ClickHouse cần các tập lệnh này. Bạn nên kiểm tra yêu cầu thứ hai trước khi mua VPS. Đây cũng là một khác biệt thực tế khi chọn giữa VPS ARM và x86. ClickHouse cũng sẽ sử dụng lượng bộ nhớ mà nó cho là khả dụng. Vì vậy, trên máy chủ dùng chung, hãy đặt giới hạn như mô tả trong giới hạn bộ nhớ container trong Compose.

BASE_URL phải khớp chính xác với URL public. Nếu không, bạn đăng nhập nhưng ứng dụng chuyển hướng sang host sai. Session cookie được ghi cho một domain mà trình duyệt không truy cập, nên bạn quay lại form đăng nhập mà không có thông báo lỗi.

File compose được cung cấp không publish port vì thiết kế mặc định là đặt một proxy phía trước. Hãy thêm một file override để publish port mặc định của ứng dụng chỉ trên loopback.

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

Matomo: sản phẩm đầy đủ và máy chủ mà nó yêu cầu

Matomo chạy trên PHP với MySQL hoặc MariaDB, nên phù hợp với web stack truyền thống hơn là container stack. Đây cũng là công cụ duy nhất trong danh sách này công bố yêu cầu phần cứng theo lưu lượng truy cập.

ChartMatomo sizing guidance by monthly pageviews
The data behind this chart
[
  {
    "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
  }
]

Đó là mức tối thiểu do Matomo công bố tính đến tháng 8 năm 2026, không phải số liệu đo cho bài hướng dẫn này. Với tối đa 100,000 lượt xem trang mỗi tháng, Matomo yêu cầu 2 core CPU, 2 GB RAM và 50 GB SSD; một máy chủ chạy cả ứng dụng và database. Ở mức 1M/month, yêu cầu tăng lên 8 GB RAM và 250 GB disk. Ở mức 10M/month, Matomo khuyến nghị dùng hai máy chủ; hàng cuối hiển thị máy chủ database với 16 GB RAM và 400 GB disk. Hãy so sánh các mức disk này với các tùy chọn single binary, trong đó toàn bộ dataset nằm trong một file SQLite.

Archiving là phần thường khiến người dùng bất ngờ. Theo mặc định, Matomo tạo report khi có người mở dashboard. Khi dữ liệu tăng, dashboard sẽ chậm hơn và cuối cùng có thể timeout. Cách khắc phục được ghi trong tài liệu là tắt archiving do browser kích hoạt trong general settings, rồi chạy archiver bằng cron từ thư mục Matomo, với user sở hữu các file Matomo.

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

Matomo cũng lưu các bảng raw log bên cạnh các bảng report đã xử lý. Bạn có thể cấu hình để Matomo định kỳ xóa raw data cũ và report cũ. Hãy bật tùy chọn này khi cài đặt, không chờ đến khi disk đầy. Matomo cũng có thể import server access log, nên đây là sản phẩm duy nhất trong danh sách này bao quát cả hai nhóm cùng lúc.

Rybbit và các stack mới hơn

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

Rybbit là một lựa chọn mới với dashboard hiện đại. Script cài đặt ghi file môi trường và khởi động stack bằng Docker Compose. Rybbit chạy ClickHouse và tích hợp Caddy làm web server riêng. Caddy chiếm cổng 443 và yêu cầu chứng chỉ cho domain bạn truyền vào. Nếu nginx đã sử dụng cổng 443 trên máy chủ, script sẽ không bind được cổng này. Khi đó, hãy dùng cách triển khai Compose thủ công của dự án và đặt Rybbit phía sau proxy hiện có. Tài liệu yêu cầu ít nhất 2 GB RAM, được thử nghiệm trên Ubuntu 24 LTS, và ARMv8.2-A hoặc mới hơn trên ARM vì ClickHouse.

Điểm cần lưu ý khi dùng một dự án còn mới là các tính năng được bổ sung nhanh, nhưng các thay đổi phá vỡ tương thích cũng xuất hiện nhanh. Hãy pin một tag, đọc release notes trước khi pull và sao lưu database trước.

Lưu trữ và mức tăng dung lượng đĩa: tự đo trên máy chủ của bạn

Mức tăng dung lượng đĩa phụ thuộc vào dữ liệu tool lưu cho mỗi event. GoatCounter tổng hợp lượt truy cập thành các counter, nên file của nó tăng theo số trang và số ngày khác nhau nhiều hơn theo volume thô. Umami và Matomo lưu row cho từng event, còn Matomo lưu thêm các bảng report đã xử lý bên cạnh các bảng raw. ClickHouse lưu event theo column và nén rất mạnh. Vì vậy, Plausible có thể xử lý volume khiến một row store gặp vấn đề.

Guide này không đưa ra con số megabyte trên mỗi triệu pageview, vì chưa đo trên traffic của bạn. Hãy tự đo. Điều chỉnh tên service và user cho khớp với file Compose của bạn.

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"

Ghi lại con số, chờ một tuần, rồi ghi lại lần nữa. Sau đó lấy phần chênh lệch chia cho số pageview mà dashboard báo cáo trong tuần đó. Con số này phản ánh site và cơ chế lọc bot của bạn, nên có giá trị hơn mọi mức trung bình được công bố. Sau đó đặt giới hạn retention khi con số vẫn còn nhỏ. Đĩa đầy sẽ làm dừng mọi service trên VPS, không chỉ analytics. Đây là lý do quan trọng nhất để đặt database volume ở nơi mà df -h sẽ cảnh báo cho bạn. Rủi ro này cần được chú ý hơn trên máy chủ đã chứa dữ liệu cồng kềnh, vì một photo server tự host sẽ làm đầy đĩa từ lâu trước khi bất kỳ analytics database nào đến gần giới hạn đó.

Cách hoạt động phía sau reverse proxy trên subdomain

Đặt collector trên một subdomain của website mà nó đo lường, chẳng hạn như stats.example.com. Khi đó request đến collector được xem là first-party, nên không bị các quy tắc của trình duyệt dùng để chặn request third-party tác động.

Bind ứng dụng vào loopback khi publish port của container. Docker ghi các firewall rule riêng trước ufw, nên container được publish dưới dạng -p 3000:3000 vẫn có thể được truy cập từ Internet dù ufw status cho biết port bị từ chối. Test từ một máy khác bằng curl http://SERVER_IP:3000, bạn sẽ nhận được dashboard. Khi publish dưới dạng -p 127.0.0.1:3000:3000, cùng phép test đó trả về Connection refused và chỉ proxy mới truy cập được.

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

Các forwarding header là bắt buộc trong trường hợp này. Nếu không có X-Forwarded-For, mọi lượt truy cập đều đến từ 127.0.0.1, nên báo cáo quốc gia sẽ trống và số visitor duy nhất sẽ bị dồn về gần một. Mỗi project tự quyết định sẽ tin cậy header nào và dùng setting nào, vì vậy hãy xem tài liệu proxy của project đó một lần thay vì tự giả định. Caddy tự đặt các header này, và một Caddyfile cho cùng công việc chỉ cần hai dòng.

stats.example.com {
    reverse_proxy 127.0.0.1:3000
}

Nếu bạn chưa chọn proxy, bài so sánh nginx, Caddy và Traefik sẽ trình bày proxy nào phù hợp với một máy chủ đơn có vài subdomain.

Tự host thay đổi bên nào lưu giữ dữ liệu. Việc này không thay đổi quy định pháp luật áp dụng cho dữ liệu đó. Hãy tách riêng hai quy tắc. Quy định về sự đồng ý theo ePrivacy áp dụng cho việc lưu hoặc đọc bất kỳ dữ liệu nào trên thiết bị của khách truy cập. Vì vậy, một công cụ không đặt cookie và không ghi dữ liệu vào local storage sẽ không thuộc yêu cầu cụ thể đó. GDPR áp dụng cho việc xử lý dữ liệu cá nhân. Địa chỉ IP được xem là dữ liệu cá nhân, nên bạn vẫn cần cơ sở pháp lý, thời hạn lưu giữ và phương án trả lời khi có người hỏi bạn đang lưu dữ liệu gì về họ.

Plausible, Umami, GoatCounter và Medama mặc định không đặt cookie. Dữ liệu mỗi công cụ suy ra thay thế là gì còn tùy từng project và thay đổi giữa các phiên bản, nên hãy đọc tài liệu privacy của chính project đó thay vì dựa vào bản tóm tắt. Matomo có sẵn tính năng ẩn danh IP và endpoint opt out mà bạn bật trong giao diện quản trị.

Cơ quan quản lý ở mỗi quốc gia có thể đưa ra kết luận khác nhau. Ví dụ, CNIL của Pháp công bố các điều kiện mà theo đó việc đo lường audience có thể được miễn yêu cầu xin consent. Phần này chỉ là tóm tắt thông tin, không phải tư vấn pháp lý. Nếu bạn vận hành một site thực tế với người dùng thực tế, hãy hỏi luật sư tại jurisdiction của bạn.

Một điểm thường bị bỏ qua: access log cũng là dữ liệu cá nhân. GoAccess không thêm script vào trang nhưng vẫn xử lý địa chỉ IP, nên analytics dựa trên log không tự động nằm ngoài các quy định này.

Trình chặn quảng cáo và lý do số liệu của bạn sẽ giảm

Filter list đối chiếu hostname và mẫu URL. Một sản phẩm analytics được host sẵn rất dễ bị nhận diện vì mọi người đều tải nó từ cùng một hostname phổ biến. Chuyển collector sang subdomain của bạn sẽ loại hostname đó khỏi request. Phục vụ script từ một path do bạn chọn sẽ loại tên file phổ biến. Cả hai thay đổi này đều thay đổi nội dung mà filter list cần đối chiếu.

Bài viết này không đưa ra tỷ lệ bị chặn vì không đo tỷ lệ đó. Tỷ lệ visitor chặn một setup cụ thể phụ thuộc vào audience của bạn. Audience là developer thường chặn nhiều hơn audience phổ thông. Thay vào đó, hãy tự đo khoảng chênh lệch của bạn. Trong cùng một tuần, dùng GoAccess đếm các request đến trang HTML trong access log, rồi so sánh với số pageview mà tool dựa trên script của bạn báo cáo. Trên site của bạn, phần chênh lệch là số lượt truy cập bị chặn cộng với các trang được phục vụ từ cache.

Hãy dự kiến tổng số liệu sẽ thay đổi vào ngày bạn chuyển từ sản phẩm được host sẵn. Đồng thời, hãy dự kiến một phần thay đổi đó không liên quan đến việc bị chặn. Các sản phẩm không thống nhất về định nghĩa pageview, việc route change bên trong một single-page application có được tính là một pageview hay không, và thời điểm một session kết thúc. Hãy so sánh xu hướng qua nhiều tuần trước khi kết luận rằng traffic đã giảm.

Dùng công cụ nào cho từng loại site

  • Site cá nhân hoặc blog có khoảng dưới 50,000 lượt xem trang mỗi tháng: GoatCounter hoặc Medama trên VPS 1 GB, với cơ chế backup chỉ là sao chép file.
  • Site không thể thêm script, hoặc có nhiều người dùng chặn script: GoAccess đọc log hiện có theo lịch.
  • Site doanh nghiệp nhỏ có người khác xem dashboard: Umami cùng container Postgres.
  • Site cần theo dõi goal và funnel, chạy trên máy có từ 2 GB RAM trở lên: Plausible Community Edition, hoặc Rybbit nếu muốn dashboard mới hơn và chấp nhận dự án còn non trẻ.
  • Nhiều site, nhiều tài khoản người dùng hoặc yêu cầu giữ dữ liệu thô theo chính sách retention của riêng bạn: Matomo, cấp tài nguyên theo hướng dẫn đã công bố ở trên.

Hãy bắt đầu bằng công cụ nhỏ nhất có thể trả lời đúng câu hỏi thực tế của bạn. Sau này chuyển từ GoatCounter sang Plausible chỉ tốn một subdomain và một phần lịch sử dữ liệu. Chuyển từ Matomo sang công cụ khác sẽ cần một lần migration mà bạn sẽ không muốn thực hiện. Nếu bạn vẫn đang quyết định nên đặt thêm gì trên cùng máy đó, bài tổng hợp rộng hơn về self-hosting sẽ cho biết những gì có thể chạy cùng nó. Nếu điều bạn thực sự cần là tracing ở cấp request của một ứng dụng thay vì đếm visitor, một dịch vụ observability tự host mới là công cụ phù hợp.

FAQ

Không, và đây là 2 vấn đề riêng. Quy định về consent trong ePrivacy áp dụng cho việc lưu hoặc đọc dữ liệu trên thiết bị của khách truy cập. Vì vậy, một tool không đặt cookie và không ghi gì vào local storage thì không thuộc phạm vi của yêu cầu cụ thể đó. GDPR là quy định khác và áp dụng cho việc xử lý dữ liệu cá nhân. Địa chỉ IP là dữ liệu cá nhân, nên ngay cả khi không dùng cookie, bạn vẫn cần có cơ sở pháp lý và thời hạn lưu trữ. Tự host đưa dữ liệu lên server của bạn và khiến bạn trở thành bên chịu trách nhiệm về dữ liệu đó. Hãy kiểm tra hướng dẫn của cơ quan quản lý tại nơi bạn hoạt động và hỏi luật sư về trường hợp cụ thể.

Analytics tự host cần bao nhiêu RAM trên VPS?

Datastore quyết định nhu cầu tài nguyên, không phải dashboard. GoatCounter và Medama chạy dưới dạng một process trên một file. Tài liệu của Medama cho biết các site nhỏ có thể chạy trên máy với 256 MB. Umami thêm một Postgres container bên cạnh ứng dụng Node. Plausible Community Edition và Rybbit đều chạy ClickHouse, và cả 2 project đều nêu mức tối thiểu là 2 GB. Hướng dẫn của Matomo bắt đầu từ 2 CPU cores và 2 GB RAM cho tối đa 100,000 lượt xem trang mỗi tháng.

Vì sao số liệu self-hosted của tôi thấp hơn analytics mà tôi đã thay thế?

Có 2 nguyên nhân, và cả 2 đều có thật. Filter list chặn một số request đến collector, nên mọi tool dựa trên script đều bỏ sót những lượt truy cập đó. Các product cũng đếm khác nhau, vì cách xác định pageview và thời điểm kết thúc session không giống nhau. Hãy so sánh số request đến HTML page trong access log của một tuần với số pageview dựa trên script trong cùng tuần đó. Khoảng chênh lệch là số lượt truy cập bị chặn cộng với các page được phục vụ từ cache. Đây là số đo trên site của bạn, không phải tỷ lệ được công bố từ một nơi khác.

Tôi có thể chạy Plausible hoặc Rybbit trên ARM VPS không?

Cả 2 đều chạy ClickHouse. ClickHouse cần SSE 4.2 trên x86 hoặc NEON trên ARM. Yêu cầu của Plausible nêu chính xác điều này, còn tài liệu của Rybbit cho biết hệ thống ARM cần ARMv8.2-A hoặc mới hơn. Các ARM server core hiện nay đáp ứng yêu cầu đó, nhưng các core cũ hơn thì không. Lỗi sẽ xuất hiện dưới dạng ClickHouse từ chối khởi động với lỗi instruction set, thay vì xuất hiện trong application log. Trên một máy ARM nhỏ, các tool dùng một file sẽ tránh được vấn đề này vì không tool nào trong số đó chạy ClickHouse.

Tôi có nên parse server log thay vì dùng tracking script không?

Hãy dùng log parsing khi bạn không thể thêm script, khi phần lớn audience chặn tracking, hoặc khi muốn có số đếm bao gồm cả crawler. GoAccess đọc log mà server đã ghi, nên không làm tăng page weight và không cần database. Bạn sẽ mất toàn bộ hoạt động xảy ra bên trong browser. Bạn cũng không thấy các page được phục vụ từ CDN hoặc browser cache, vì request đó không đến server của bạn. Nhiều site chạy cả 2 cách và xem chúng là 2 phép đo khác nhau.