Superlog-ஐ self-host செய்வது எப்படி?

Superlog-ஐ self-host செய்யும்போது உண்மையில் என்ன நிறுவப்படுகிறது

Superlog-ஐ self-host செய்ய, நீங்கள் repository-ஐ clone செய்ய வேண்டும். Docker Compose மூலம் Postgres, ClickHouse மற்றும் OpenTelemetry collector ஆகியவற்றை இயக்க வேண்டும். ஒரு database migration-ஐ முடித்துவிட்டு, நான்கு Node services-ஐ source-லிருந்து தொடங்க வேண்டும். உங்கள் applications OTLP (OpenTelemetry protocol) traces, logs மற்றும் metrics-ஐ ஒரு intake port-க்கு அனுப்பும். Superlog அவற்றை fingerprint செய்து, மீண்டும் மீண்டும் வரும் தரவுகளை ஒரே incident-ஆகக் குழுவாக்கும். ஒரு agent triage-ன் முதல் கட்டத்தை எழுதும். இந்த நிறுவல் முறைக்கு ஒரு மதியம் தேவைப்படும். நீங்கள் தொடங்குவதற்கு முன், அதன் footprint மற்றும் உண்மையான வரம்புகள் (honest limits) குறித்த பகுதிகளைப் படிப்பது அவசியம்.

Superlog, Apache 2.0 உரிமம் பெற்றது மற்றும் github.com/superloglabs/superlog-ல் கிடைக்கிறது. ஆகஸ்ட் 2026 நிலவரப்படி, இது சுமார் 1.2k stars பெற்றுள்ளது, main-ல் சுமார் 460 commits உள்ளன, மேலும் எந்தவொரு release tags-ம் இல்லை. இந்த கடைசி அம்சம் நிறுவலைத் தீர்மானிக்கிறது: git checkout v1.0.0-ல் checkout செய்ய எதுவும் இல்லை என்பதால், நீங்கள் ஒரு குறிப்பிட்ட commit-ஐ நீங்களே pin செய்ய வேண்டும் அல்லது நீங்கள் clone செய்த அன்று main-ல் என்ன இருந்ததோ அதைத்தான் இயக்க வேண்டும்.

Uptime Kuma மற்றும் Langfuse வழங்காதவற்றை Superlog எவ்வாறு வழங்குகிறது

Self-hosted monitoring கருவிகள் வெளியிலிருந்து பார்க்கும்போது ஒரே மாதிரியாகத் தோன்றலாம். ஆனால் அவை அவ்வாறு இல்லை; தவறான கருவியைப் பயன்படுத்துவது எந்தப் பயனும் இன்றி உங்கள் server-ன் வளங்களை வீணடிக்கும்.

• Uptime Kuma உங்கள் endpoints-ஐ வெளியிலிருந்து சோதிக்கிறது மற்றும் அது இயங்குகிறதா என்ற ஒரு கேள்விக்கு மட்டுமே பதிலளிக்கிறது.
• Zabbix, Ubuntu 24.04-ல் உள்ள hosts மற்றும் services-ஐக் கண்காணிக்கிறது, நீங்கள் அமைக்கும் வரம்புகளுக்கு ஏற்ப CPU, memory, disk மற்றும் service நிலையை இது சரிபார்க்கிறது.
• Langfuse, LLM அழைப்புகளைத் தடமறிகிறது (trace), ஒவ்வொரு அழைப்பின் prompt, model, tokens, latency மற்றும் அதன் செலவு ஆகியவற்றை இது பதிவு செய்கிறது.
• Superlog உங்கள் சாதாரண services ஏற்கனவே வெளியிடும் telemetry தரவுகளை எடுத்துக்கொண்டு, மீண்டும் மீண்டும் நிகழும் தோல்விகளை incidents-ஆக மாற்றுகிறது.

Superlog ஒரு மாறுபட்ட கேள்வியைக் கையாள்கிறது: ஏதோ ஒன்று பழுதடைந்துள்ளது, அது எது, ஏன் பழுதடைந்தது? LLM அழைப்புகள் குறித்து இதற்கு எந்தக் கருத்தும் இல்லை, மேலும் இது உங்களை வெளியிலிருந்து சோதிப்பதும் இல்லை. இது உங்கள் சாதாரண application code-லிருந்து OTLP-ஐ உள்ளீடாகப் பெற்று, triage நிலையில் ஒரு agent-ஐ அமர்த்துகிறது; இது on-call பணியில் இருக்கும் ஒரு மனிதர் செய்யும் முதல் கட்டப் பணியாகும்.

VPS பட்ஜெட்டில் கவனிக்க வேண்டிய முக்கிய வேறுபாடு storage ஆகும். Uptime Kuma சில ஆயிரம் check முடிவுகளை மட்டுமே சேமிப்பதால், 1 GB RAM-ல் இது சிறப்பாக இயங்கும். Superlog ஒரு column store-ஐப் பயன்படுத்துகிறது, ஏனெனில் telemetry தரவுகள் ஒருமுறை எழுதப்பட்டு, மில்லியன் கணக்கான rows-ல் கால இடைவெளியின் அடிப்படையில் வினவப்படுகின்றன (queried). இதற்காகவே ClickHouse பயன்படுத்தப்படுகிறது, Postgres இதற்கு ஏற்றதல்ல. Postgres இந்த stack-ல் தொடர்ந்து இருக்கும், இது projects, users, incidents மற்றும் ingest keys போன்ற சிறிய relational தரவுகளை மட்டுமே கையாளும்.

docker compose up -d உண்மையில் எதைத் தொடங்குகிறது?

மூன்று containers தொடங்கப்படுகின்றன, அவற்றில் எதுவுமே Superlog அல்ல. ஒரே கட்டளையில் நிறுவல் முடியும் என்று எதிர்பார்ப்பவர்களுக்கு இது ஆச்சரியமாக இருக்கலாம்.

• postgres:16, host port 5434-ல் வெளியிடப்பட்டது
• clickhouse/clickhouse-server:26.1, HTTP-க்காக 8123 மற்றும் native protocol-க்காக 9000-ல் இயங்குகிறது
• otel/opentelemetry-collector-contrib:0.150.1, gRPC-க்காக 4317 மற்றும் OTLP over HTTP-க்காக 4318-ல் இயங்குகிறது

Superlog applications host-ல், source-லிருந்து, pnpm dev மூலம் தொடங்கப்படுகின்றன. ஆகஸ்ட் 2026 நிலவரப்படி, repository-ல் production compose file எதுவும் இல்லை. எனவே, நீண்ட காலம் இயங்கும் ஒரு நிறுவலுக்கு, ஒவ்வொரு app-ன் start script-ஐயும் உள்ளடக்கிய உங்கள் சொந்த systemd units அல்லது tree-ல் உள்ள per-app Dockerfiles-ஐப் பயன்படுத்த வேண்டும்.

ஒரு span செல்லும் பாதையை நினைவில் கொள்ளுங்கள், ஏனெனில் கீழே உள்ள ஒவ்வொரு தோல்வியும் அந்தப் பாதையின் ஒரு கட்டத்தில் ஏற்படும் தடையாகும். உங்கள் app, OTLP-ஐ Superlog intake proxy-க்கு அனுப்புகிறது. அந்த proxy உங்கள் ingest key-ஐக் கொண்டு கோரிக்கையை அங்கீகரித்து, அதில் project id-ஐ முத்திரையிட்டு, collector-க்கு அனுப்புகிறது. அந்த collector, client அமைக்க முயன்ற எந்தவொரு superlog.* attributes-ஐயும் நீக்கிவிட்டு, proxy வழங்கிய header-லிருந்து superlog.project_id-ஐச் சேர்த்து, அவற்றை batch செய்து, ClickHouse-ல் எழுதுகிறது. பின்னர் web app மற்றும் API ஆகியவை telemetry-ஐ ClickHouse-லிருந்தும், மற்ற அனைத்தையும் Postgres-லிருந்தும் படிக்கின்றன.

அந்த attribute நீக்கம் என்பது வெறும் அலங்காரம் அல்ல, அது ஒரு உண்மையான multi-tenancy கட்டுப்பாடாகும். அது இல்லையென்றால், செல்லுபடியாகும் ingest key-ஐ வைத்திருக்கும் எவரும் superlog.project_id-ஐத் தாங்களே அமைத்து, மற்றொரு project-ன் தரவுகளில் எழுத முடியும்.

VPS-ன் அளவு எவ்வளவு இருக்க வேண்டும்?

குறைந்த அளவு தரவுகளை உள்வாங்கும் (ingest) ஒரு ஒற்றை node நிறுவலுக்கு, 4 vCPU, 8 GB RAM மற்றும் 40 GB SSD கொண்ட திட்டத்தைத் தேர்வு செய்யவும். இது ஒரு அடிப்படைத் திட்டமே தவிர, துல்லியமான அளவீடு அல்ல. எனவே, இதை ஒரு தொடக்க அளவாகக் கருதி, உங்கள் network traffic-க்கு ஏற்ப மாற்றிக்கொள்ளுங்கள்.

நினைவகம் (memory) நான்கு பகுதிகளுக்குப் பயன்படுத்தப்படுகிறது. ClickHouse அதிக RAM கொண்ட கணினிகளுக்காக உருவாக்கப்பட்டது, அதன் இயல்புநிலை அமைப்புகளும் அதையே எதிர்பார்க்கின்றன. Postgres 16, telemetry தரவுகளை விட metadata-வை மட்டுமே சேமிப்பதால், இதற்கு குறைந்த நினைவகமே போதுமானது. collector-ம் குறைவான நினைவகத்தையே பயன்படுத்துகிறது. ஆனால், நான்கு Node processes அவ்வாறு இல்லை: ஒரு Vite development server மற்றும் மூன்று tsx watch processes ஒவ்வொன்றும் நூற்றுக்கணக்கான megabytes நினைவகத்தை எடுத்துக்கொள்ளும். இதனால்தான் 2 GB அளவுள்ள கணினியில் pnpm dev-ஐ இயக்குவது கடினமாக உள்ளது.

வட்டு (disk) பயன்பாடு கவனிக்கப்பட வேண்டிய மற்றொரு முக்கிய அம்சம். இந்த monorepo-வில் உள்ள pnpm install, நீங்கள் ஒரு span-ஐக் கூட உள்வாங்குவதற்கு முன்பே AWS SDK, ClickHouse client, OpenTelemetry SDK மற்றும் React toolchain ஆகியவற்றைத் தரவிறக்கம் செய்கிறது. அதன் பிறகு, உங்கள் traffic-க்கு ஏற்ப ClickHouse-ன் அளவு அதிகரிக்கும். இரண்டையும் கண்காணிக்கவும்:

df -h /
free -m
docker stats --no-stream
docker compose exec clickhouse clickhouse-client --database superlog --query "SELECT table, formatReadableSize(sum(bytes_on_disk)) AS size FROM system.parts WHERE active AND database = 'superlog' GROUP BY table ORDER BY sum(bytes_on_disk) DESC"

குறைந்த traffic இருக்கும்போது, அதாவது சில சேவைகள் நிமிடத்திற்குச் சில நூறு spans-களை அனுப்பும்போது, கணினி அமைதியாக இருக்கும் மற்றும் ClickHouse பெரும்பாலான நேரம் செயலற்ற நிலையில் இருக்கும். ஆனால், திடீரென ஏற்படும் அதிகப்படியான சுமை (burst) சிக்கலை உண்டாக்கும்: தவறான deploy ஒன்றினால் நிமிடத்திற்கு ஆயிரக்கணக்கான ஒரே மாதிரியான பிழைகள் உருவாகலாம். Fingerprinting மூலம் அவற்றை ஒரே ஒரு சம்பவமாக (incident) சுருக்கினாலும், ClickHouse அதன் பின்னணியில் ஒவ்வொரு வரிசையையும் தொடர்ந்து எழுதிக்கொண்டே இருக்கும்.

தரவுகளை எவ்வளவு காலம் வைத்திருக்க வேண்டும் (retention) என்பதை நீங்களே தீர்மானிக்க வேண்டும். collector-ன் ClickHouse exporter அட்டவணைகளை உருவாக்குகிறது, அவை otel_traces, otel_logs மற்றும் ஒவ்வொரு metric வகைக்கும் ஒரு அட்டவணை என அமையும். infra/collector/config.yaml-ல் உள்ள configuration-ல் காலாவதி நேரம் (time to live) அமைக்கப்பட்டால் மட்டுமே தரவுகள் நீக்கப்படும். தானாகவே எதுவும் நீங்காது என்பதால், அதிக traffic உள்ள மாதங்களில், நீங்கள் திட்டமிடவில்லை என்றால் வட்டு விரைவில் நிரம்பிவிடும்.

Pinned commit-லிருந்து நிறுவுதல்

git clone https://github.com/superloglabs/superlog.git
cd superlog
git tag -l
git log -1 --format='%H %cs %s'

git tag -l எதையும் அச்சிடாமல் இருப்பது ஆகஸ்ட் 2026 நிலவரப்படி எதிர்பார்க்கப்படும் முடிவாகும். நீங்கள் சோதித்த commit-ஐத் தேர்ந்தெடுத்து அதிலேயே இருக்கவும்:

git checkout 0d3a6c8bb63eda3493e6ba0003e7c2a70750bc1e

அடுத்து, toolchain:

node -v
corepack enable
corepack prepare pnpm@9.12.0 --activate
pnpm -v

package.json ஆனது engines.node-ஐ >=20.0.0 ஆகவும், packageManager-ஐ pnpm@9.12.0 ஆகவும் அறிவிக்கிறது. பழைய Node பதிப்பில் நிறுவலை இயக்கினால், pnpm ERR_PNPM_UNSUPPORTED_ENGINE பிழையுடன் நின்றுவிடும், அது கோரிய பதிப்பையும் குறிப்பிடும். Ubuntu 24.04 archive-ல் உள்ள nodejs தொகுப்பு 20-ஐ விடப் பழையது, எனவே NodeSource அல்லது nvm மூலம் Node 20 அல்லது அதற்குப் புதிய பதிப்பை நிறுவவும். இந்த repository ஒரு .nvmrc-ஐக் கொண்டுள்ளது, எனவே உங்களிடம் nvm இருந்தால் nvm use சரியான பதிப்பைத் தேர்ந்தெடுக்கும்.

pnpm install
docker compose up -d
docker compose ps

up -d என்பது தயாராகிவிட்டது என்று அர்த்தம் என்று நம்புவதற்குப் பதிலாக, health checks முடியும் வரை காத்திருக்கவும். Postgres மற்றும் ClickHouse ஆகிய இரண்டும் compose file-ல் ஒன்றைக் குறிப்பிடுகின்றன:

curl -sS http://127.0.0.1:8123/ping
pg_isready -h 127.0.0.1 -p 5434 -U postgres

ClickHouse Ok. என்று பதிலளிக்கிறது மற்றும் pg_isready ஆனது accepting connections என்று பதிலளிக்கிறது. 8123 port-ல் Connection refused என்பது container இன்னும் தொடங்குகிறது அல்லது செயலிழந்துவிட்டது என்று பொருள். docker compose logs clickhouse எதனால் என்று காட்டும், மேலும் docker inspect $(docker compose ps -q clickhouse) | grep -i oomkilled ஆனது true என்று தெரிவித்தால், நினைவகப் பற்றாக்குறையால் kernel அதை நிறுத்தியுள்ளது என்று பொருள்; இது உங்கள் configuration-ல் உள்ள பிழையை விட, server-ன் திறன் குறைவாக இருப்பதையே குறிக்கிறது.

பிறகு migration மற்றும் applications:

pnpm --filter @superlog/db db:migrate
pnpm dev

Port-ஐக் கவனிக்கவும்: 5432 அல்ல, 5434. Compose file ஆனது Postgres-ஐ 5434-ல் வெளியிடுகிறது, இதனால் host-ல் ஏற்கனவே நிறுவப்பட்ட Postgres-உடன் மோதல் ஏற்படாது. App .env.example கோப்புகள் DATABASE_URL=postgres://postgres:postgres@localhost:5434/superlog உடன் பொருந்துகின்றன. ஏற்கனவே Postgres இயங்கும் ஒரு server-ல் 5432-க்கு migration-ஐச் சுட்டிக்காட்டினால், connection refused பிழை வரும் அல்லது தவறான database-ல் migration அமல்படுத்தப்படும்.

pnpm dev ஆனது repository-ன் Procfile-ல் பட்டியலிடப்பட்டுள்ள நான்கு process-களைத் தொடங்குகிறது: api, web, worker மற்றும் proxy. ஒவ்வொன்றும் அதன் வெளியீட்டை tmp/logs/-க்கு அனுப்புகிறது, எனவே tail -f tmp/logs/proxy.log-ல் நீங்கள் ingest-ஐக் கண்காணிக்கலாம். README-ல் web app http://localhost:5173-லும், API http://localhost:4100-லும், OTLP intake http://localhost:4101-லும் இருப்பதாகக் குறிப்பிடப்பட்டுள்ளது.

எந்தெந்த port-கள் உண்மையில் bound ஆகியுள்ளன என்பதை உறுதிப்படுத்தவும்:

ss -lntp | grep -E '4100|4101|5173'
curl -sS http://127.0.0.1:4101/health

இது பிற்காலத்தில் முக்கியமானது. Proxy அதன் சொந்த port-ஐ PORT environment variable-லிருந்து படிக்கிறது, PORT அமைக்கப்படாதபோது 4000-ஐப் பயன்படுத்துகிறது. Development stack இதை உங்களுக்காக அமைக்கிறது. நீங்கள் நீங்களாக எழுதும் systemd unit இதைச் செய்யாது, எனவே 4000-ல் இயங்கும் proxy-க்கு எதிராக 4101-ஐ நோக்கிய exporter, connection refused பிழையைத் தரும், வேறு எந்தத் தகவலையும் தராது.

ஒரு trace-ஐ அனுப்பி, ஒரு error-ஐ உருவாக்கி, ஒரு incident-ஐக் காணுதல்

Web app-ல் ஒரு project-ஐ உருவாக்கி அதன் ingest key-ஐ நகலெடுக்கவும். Intake ஒவ்வொரு கோரிக்கையையும் அந்த key-ஐக் கொண்டு அங்கீகரிக்கும், எனவே key இல்லாமல் அனுப்பப்படும் telemetry தரவுகள் ClickHouse-ஐ அடையாது.

Standard environment variables-ஐப் பயன்படுத்தி ஏதேனும் ஒரு OpenTelemetry SDK-ஐ intake-க்குச் சுட்டிக்காட்டவும்:

export OTEL_SERVICE_NAME=checkout-api
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_ENDPOINT=http://127.0.0.1:4101
export OTEL_EXPORTER_OTLP_HEADERS='x-api-key=YOUR_INGEST_KEY'

Intake ஆனது x-api-key header-லிருந்து key-ஐப் படிக்கும். உங்கள் exporter-ஐ அவ்வாறு கட்டமைப்பது எளிது என்றால், அது authorization: bearer YOUR_INGEST_KEY-ஐயும் ஏற்கும். இது மூன்று standard OTLP paths-களான /v1/traces, /v1/logs மற்றும் /v1/metrics, மற்றும் /health ஆகியவற்றில் இயங்குகிறது.

ஒரு முக்கியமான சிக்கலைக் கவனிக்க வேண்டும். OTEL_EXPORTER_OTLP_ENDPOINT என்பது ஒரு base URL ஆகும், SDK அதனுடன் signal path-ஐ இணைக்கும். OTEL_EXPORTER_OTLP_TRACES_ENDPOINT போன்ற signal-க்குரிய variables-ஐ எந்தப் பாதையும் சேர்க்காமல், அப்படியே பயன்படுத்த வேண்டும். Signal-க்குரிய variable-ஐ http://127.0.0.1:4101 என அமைத்தால், ஒவ்வொரு export-ம் /-க்கு அனுப்பப்படும். இது ஒரு சரியான route அல்ல என்பதால், தரவுகள் எங்கும் சேராது. உங்கள் app சரியாக இயங்குவது போலத் தெரிந்தாலும், SDK ஒரு export failure-ஐப் பதிவு செய்யும்.

Node service-க்கு, pipeline-ஐச் சோதிக்க zero code path போதுமானது:

npm install @opentelemetry/api @opentelemetry/auto-instrumentations-node
node --require @opentelemetry/auto-instrumentations-node/register server.js

இப்போது வேண்டுமென்றே ஒரு பிழையை உருவாக்கவும். பிழையைத் தூண்டும் (throw) எந்த route-ம் இதற்குப் பயன்படும்:

curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000/boom

ஒவ்வொரு கட்டத்தையும் வரிசையாகச் சரிபார்க்கவும், ஏனெனில் முதல் இடைவெளி எங்கு தோல்வி ஏற்பட்டது என்பதைக் காட்டும்:

tail -n 50 tmp/logs/proxy.log
docker compose exec clickhouse clickhouse-client --database superlog --query 'SELECT count() FROM otel_traces'

Web app காலியாக இருக்கும்போது otel_traces-ல் எண்ணிக்கை அதிகரித்தால், அது project mismatch ஆகும். எனவே, ingest key எந்த project-க்குச் சொந்தமானது என்பதைச் சரிபார்க்கவும். Proxy log-ல் செயல்பாடு இருந்து, எண்ணிக்கை மாறாமல் இருந்தால், அது collector அல்லது ClickHouse write-ல் உள்ள சிக்கலைக் குறிக்கும். எனவே docker compose logs collector-ஐப் படிக்கவும். Proxy log-ல் எந்தச் செயல்பாடும் இல்லை என்றால், exporter intake-ஐ அடையவில்லை என்று அர்த்தம்: தவறான port, தவறான path அல்லது நிராகரிக்கப்பட்ட key காரணமாக இருக்கலாம்.

Web app-ல், அந்தத் தொடர் தோல்விகள் ஒவ்வொரு கோரிக்கைக்கும் ஒரு வரிசை என வராமல், ஒரே incident-ஆகத் திரட்டப்படும். Superlog உள்வரும் signals-ஐ fingerprint செய்து, ஒத்தவற்றை ஒன்றாகக் குழுவாக்கும். இது 4,000 ஒரே மாதிரியான பிழைகள் inbox-ல் குவிவதற்கும், ஒரு பக்கத்தில் ஒரே ஒரு incident தெரிவதற்கும் உள்ள வித்தியாசமாகும். அந்த agent பின்னர் அந்தக் குழுவின் மீது தனது ஆய்வை எழுதும்.

இந்த ஆய்வுப் படிமுறை ஒரு model-ஐ அழைக்கும், எனவே worker-க்கு ஒரு model provider கட்டமைக்கப்பட்டிருக்க வேண்டும். நீங்கள் pinned செய்த commit-ல் உள்ள ஒவ்வொரு app directory-க்கும் உள்ளே இருக்கும் .env.example கோப்பிலிருந்து அந்த variable பெயர்களை எடுக்கவும். வெளிப்புறக் கட்டுரைகளை நம்ப வேண்டாம், ஏனெனில் அவை main-உடன் மாறிக்கொண்டே இருக்கும். GitHub மற்றும் Sentry integrations-க்கும் இது பொருந்தும்; அவை தத்தமது setup ஆவணங்களை docs/github-app-setup.md மற்றும் docs/sentry-app-setup.md-ல் கொண்டுள்ளன, மேலும் webhook payloads docs/webhooks.md-ல் ஆவணப்படுத்தப்பட்டுள்ளன.

Intake-ஐத் தனிப்பட்டதாக வைத்திருங்கள், agent-க்கு read-only அனுமதி மட்டும் வழங்குங்கள்

Docker இயல்பாகவே container ports-ஐ 0.0.0.0-ல் வெளியிடுகிறது. Docker தனது சொந்த விதிகளை DOCKER-USER chain-ல் எழுதுவதால், இந்த ports ufw-ஐத் தாண்டிச் செயல்படுகின்றன; ufw பாக்கெட்டுகளைப் பார்ப்பதற்கு முன்பே இந்த விதிகள் மதிப்பீடு செய்யப்படுகின்றன. பொது IP கொண்ட ஒரு VPS-ல், வழங்கப்பட்ட compose file-ஆனது ClickHouse HTTP-ஐ 8123-லும், Postgres-ஐ 5434-லும் இணையம் அணுகக்கூடிய வகையில் வைக்கிறது. அந்த file-ல் உள்ள நற்சான்றிதழ்கள் (credentials) மேம்பாட்டுக்கான இயல்புநிலை அமைப்புகள் ஆகும்: ClickHouse பயனர் default கடவுச்சொல் இல்லாமலும், Postgres பயனர் மற்றும் கடவுச்சொல் postgres என்றும் உள்ளது.

அவற்றை loopback-க்கு bind செய்யுங்கள். Compose file-ல் உள்ள ஒவ்வொரு published port-ம் அதன் host side-ஐ ஒரு environment variable-லிருந்து பெறுகிறது, எனவே repository root-ல் ஒரு .env போதுமானது:

POSTGRES_HOST_PORT=127.0.0.1:5434
CLICKHOUSE_HTTP_HOST_PORT=127.0.0.1:8123
CLICKHOUSE_TCP_HOST_PORT=127.0.0.1:9000
COLLECTOR_GRPC_HOST_PORT=127.0.0.1:4317
COLLECTOR_HTTP_HOST_PORT=127.0.0.1:4318

நீங்கள் நம்புவதற்கு முன்பு முடிவைச் சரிபார்க்கவும், பின்னர் containers-ஐ மீண்டும் உருவாக்கவும்:

docker compose config
docker compose up -d
ss -lntp | grep -E '5434|8123|9000|4317|4318'

docker compose config தீர்மானிக்கப்பட்ட file-ஐ அச்சிடுகிறது, எனவே நீங்கள் 127.0.0.1:5434:5432-ஐ ஊகிப்பதற்குப் பதிலாக நேரடியாகப் படிக்கலாம். ss இப்போது 127.0.0.1:5434-ஐக் காட்ட வேண்டும், ஒருபோதும் 0.0.0.0:5434-ஐக் காட்டக்கூடாது. ports-ஐ மீண்டும் அறிவிக்கும் compose override file மூலம் இதைச் சரிசெய்ய முயற்சிக்காதீர்கள், ஏனெனில் Compose கோப்புகளுக்கு இடையே port பட்டியல்களை இணைக்கிறது (concatenate), அவற்றை மாற்றுவதில்லை (replace). இதனால் இரண்டு bindings-ம் இருக்கும் மற்றும் பொதுவான port இன்னும் திறந்தே இருக்கும்.

Intake-க்கும் இதே போன்ற கவனம் தேவை. உங்கள் ingest key ஒரு header-ல் பயணிக்கிறது, எனவே அதற்கு முன்னால் TLS (transport layer security) தேவை: proxy-க்கு முன்னால் nginx அல்லது Caddy-ல் TLS-ஐ terminate செய்யுங்கள், அல்லது ingest-ஐ ஒரு private network அல்லது WireGuard tunnel-க்குள் வைத்திருங்கள். 5173-ல் உள்ள web app ஒரு Vite development server ஆகும், இதற்கு இணையத்தை எதிர்கொள்ளும் எந்த வேலையும் இல்லை.

பிறகு agent-ன் முறை. Superlog-ன் நோக்கம் என்னவென்றால், agent ஒரு சிக்கலை ஆராய்ந்து தீர்வை முன்மொழியும்; இதில் முக்கியமான வார்த்தை 'முன்மொழியும்' (proposes) என்பதுதான். சில உண்மையான சம்பவங்களில் அது எவ்வாறு செயல்படுகிறது என்பதைக் கவனிக்கும் வரை, production-ல் அதற்கு read-only அனுமதியை மட்டும் வைத்திருங்கள். GitHub App-க்கு read scopes வழங்கி, நீங்கள் மதிப்பாய்வு செய்யும் pull requests-ஐ உருவாக்க அனுமதிக்கவும். telemetry-ஐப் படித்து patch எழுதும் agent பயனுள்ளது. உங்கள் services-ஐ restart செய்யக்கூடிய agent ஒரு மாறுபட்ட ஆபத்து நிலை; இது இயல்பாகக் கிடைக்கும் அமைப்பாக இல்லாமல், நீங்கள் திட்டமிட்டு எடுக்கும் முடிவாக இருக்க வேண்டும். செலவும் அதே கவனத்திற்கு உரியது, ஏனெனில் ஒவ்வொரு ஆய்வும் ஒரு model call ஆகும்: ஒரு noisy production system-ல் பயன்படுத்துவதற்கு முன்பு VPS-ல் agent செலவுக்கான வரவு செலவுத் திட்டம் (budget) குறித்து கவனத்தில் கொள்ளுங்கள், மேலும் agent உண்மையில் என்ன செய்தது என்பதற்கான பதிவை வைத்திருங்கள், அப்போதுதான் எதிர்பாராத pull request-க்கு பின்னால் ஒரு தணிக்கை பாதை (audit trail) இருக்கும்.

நீங்கள் சந்திக்கும் தோல்விகள் மற்றும் அவற்றை அடையாளம் காணும் சரங்கள் (strings)

• ERR_PNPM_UNSUPPORTED_ENGINE, pnpm install-ன் போது நிகழ்ந்தால், Node பதிப்பு 20-க்கும் பழையது என்று பொருள். node -v இதை ஒரே வரியில் உறுதிப்படுத்தும்.
• இடம்பெயர்வு (migration) செயல்பாட்டின் போது ECONNREFUSED 127.0.0.1:5434 நிகழ்ந்தால், compose stack இயங்கவில்லை அல்லது DATABASE_URL தவறான port-ஐக் குறிப்பிடுகிறது என்று பொருள்.
• ClickHouse சுழற்சி முறையில் (loop) restart ஆவது பெரும்பாலும் நினைவகப் (memory) பற்றாக்குறையினால் நிகழ்கிறது. docker compose logs clickhouse-ஐப் படித்துவிட்டு, container-ல் OOMKilled என்பது true என உள்ளதா எனச் சரிபார்க்கவும்.
• Web app காலியாக இருக்கும்போது, exporter வெற்றி எனத் தெரிவித்தால், தரவு நேரடியாக 4318 port-ல் உள்ள collector-க்குச் சென்றுவிட்டது என்று பொருள்; இது proxy செய்யும் project stamping-ஐத் தவிர்க்கிறது.
• Production நிறுவலின் போது 4101 port-ல் Connection refused என வந்தால், proxy PORT=4000-க்குத் திரும்பிவிட்டது என்று பொருள். Unit file-ல் PORT-ஐத் தெளிவாக அமைக்கவும்.
• docker compose ps-ல் 0.0.0.0:8123 என்று காட்டினால், உங்கள் loopback bindings செயல்பாட்டில் இல்லை என்று பொருள். docker compose config-ஐ இயக்கி, resolved ports-ஐப் படிக்கவும்.

Flawless, HyperProbe மற்றும் Superlog-ன் நிலை

இந்த வகைப்பாடு புதியது. முகவர் (agent) எவற்றை அணுகலாம் என்பதில் இந்த கருவிகள் மாறுபடுகின்றன. Flawless என்பது Kubernetes-ஐ மையமாகக் கொண்ட ஒரு open source AI SRE (site reliability engineering) கருவியாகும். இது pipeline-ஐக் கட்டுப்படுத்துவதற்குப் பதிலாக, ஏற்கனவே உள்ள Prometheus, Loki மற்றும் Grafana stack-லிருந்து தரவுகளைப் படிக்கிறது. HyperProbe இதற்கு நேர்மாறானது: இது ஒரு hosted தயாரிப்பு. ஆகஸ்ட் 2026 நிலவரப்படி இது closed source ஆகும். இது இயங்கும் process-க்குள் read-only probes-ஐ வைத்து, variable state-ஐக் கைப்பற்றி, MCP (model context protocol) மூலம் ஒரு assistant-க்கு வழங்குகிறது.

Superlog இவ்விரண்டிற்கும் இடையில் அமைகிறது. இது OTLP intake முதல் ClickHouse storage வரை முழு pipeline-ஐயும் நிர்வகிக்கிறது. இது fix step-ல் இல்லாமல், triage step-ல் முகவரை வைக்கிறது. இந்த வடிவமைப்பின் காரணமாகவே, இதை self-host செய்வது என்பது ஒரு முக்கியமான infrastructure முடிவாகும்; இது சாதாரணமாக விட்டுவிடக்கூடிய ஒரு container அல்ல. நீங்கள் Superlog-ஐ இயக்கினால், ஒரு column store-ஐயும் இயக்குகிறீர்கள் என்று அர்த்தம். எனவே, நீங்கள் வைத்திருக்கும் மற்ற database-களைப் போலவே இதற்கும் அதே அளவு பராமரிப்பு தேவை.

FAQ

ஒரு self-hosted Superlog-க்கு எவ்வளவு RAM தேவை?

குறைந்த அளவு தரவு உள்ளீடு (ingest volume) கொண்ட ஒரு node-க்கு 8 GB RAM, 4 vCPU மற்றும் 40 GB disk ஆகியவற்றைத் திட்டமிடுங்கள். இந்த stack-ல் Postgres, ClickHouse, ஒரு OpenTelemetry collector மற்றும் நான்கு Node processes உள்ளன; ClickHouse-க்கு கூடுதல் நினைவகம் (headroom) தேவைப்படும். 1 GB அல்லது 2 GB VPS போதுமானதல்ல: pnpm install மட்டுமே அதிக நினைவகத்தைப் பயன்படுத்தும், மேலும் சுமை அதிகரிக்கும் போது ClickHouse-ஐ kernel-ன் out of memory killer நிறுத்திவிடும். வெளியிடப்பட்ட எந்தவொரு புள்ளிவிவரத்தையும் நம்புவதை விட, docker stats --no-stream மற்றும் free -m மூலம் உங்கள் சொந்த பயன்பாட்டு அளவீடுகளைச் சரிபார்க்கவும்.

எனது OTLP exporter-ஐ எந்த port-க்கு அனுப்ப வேண்டும்?

README-ல் குறிப்பிடப்பட்டுள்ளபடி, Superlog intake proxy-க்கு அனுப்ப வேண்டும், இது http://localhost:4101-ல் இயங்குகிறது. இது /v1/traces, /v1/logs மற்றும் /v1/metrics ஆகியவற்றை வழங்குகிறது. இது உங்கள் project-ன் ingest key-ஐ x-api-key header அல்லது authorization: bearer header மூலம் சரிபார்க்கிறது. Port 4318 என்பது அதன் கீழ் இயங்கும் OpenTelemetry collector ஆகும்; நேரடியாக அங்கு தரவை அனுப்பினால் proxy-ஐத் தவிர்த்துவிடும், இது உங்கள் project id-ஐ தரவில் சேர்க்கும் முக்கிய அங்கமாகும். PORT அமைக்கப்படாதபோது proxy ஆனது port 4000-க்குத் திரும்பும், எனவே 4101 என்று கருதுவதற்கு முன் ss -lntp-ஐ இயக்கி அது எந்த port-ல் இயங்குகிறது என்பதை உறுதிப்படுத்தவும்.

Superlog-ஆல் Uptime Kuma அல்லது Zabbix-க்கு மாற்றாக முடியுமா?

முடியாது. உங்கள் network-க்கு வெளியே ஒரு endpoint பதிலளிக்கிறதா என்பதை Uptime Kuma சரிபார்க்கிறது; நீங்கள் அமைக்கும் வரம்புகளுக்கு ஏற்ப host மற்றும் service metrics-ஐ Zabbix கண்காணிக்கிறது. உங்கள் applications அனுப்பும் traces, logs மற்றும் metrics-ஐ Superlog பெற்று, மீண்டும் மீண்டும் நிகழும் பிழைகளை incidents-ஆக வகைப்படுத்துகிறது. உங்கள் telemetry pipeline இயங்கும் server செயலிழந்தாலும், அதைத் தெரிந்துகொள்ள வெளிப்புற uptime probe-ஐத் தொடர்ந்து பயன்படுத்துங்கள்.

Superlog agent எனது production அமைப்புகளை மாற்ற முடியுமா?

நீங்கள் வழங்கும் அனுமதிகளின் மூலம் மட்டுமே மாற்ற முடியும். இது ஒரு ஆய்வை மேற்கொண்டு, மனிதர்கள் சரிபார்க்கக்கூடிய மாற்றத்தை மட்டுமே பரிந்துரைக்கும். ஆரம்பத்தில் GitHub App-க்கு pull requests-ஐப் படிக்கும் அனுமதியை மட்டும் வழங்கவும், worker-க்குத் தேவையான credentials-ஐயும் படிக்கும் அனுமதியுடன் மட்டும் கட்டுப்படுத்தவும். Production-ல் எழுதும் (write) அனுமதியை வழங்குவது ஒரு தனிப்பட்ட முடிவாக இருக்க வேண்டும்; ஏனெனில், telemetry-ஐப் படித்து patch உருவாக்கும் agent-ஐ விட, services-ஐ restart செய்யும் திறன் கொண்ட agent அதிக ஆபத்துடையது.

நான் ஒரு commit-ஐ pin செய்ய வேண்டுமா அல்லது main branch-ஐத் தொடர வேண்டுமா?

ஒரு commit-ஐ pin செய்யுங்கள். ஆகஸ்ட் 2026 நிலவரப்படி, repository-ல் release tags எதுவும் இல்லை, எனவே main மட்டுமே தொடர்ந்து மாற்றங்களுக்கு உள்ளாகும் branch ஆகும்; இதில் வாரத்திற்குப் பல commits நிகழும். நீங்கள் சோதித்த SHA-வை குறித்து வைத்துக்கொண்டு, அதையே deploy செய்யுங்கள்; அடுத்த கட்டத்திற்குச் செல்லும் முன் diff-ஐப் படியுங்கள். git log --oneline <old-sha>..main என்பது மதிப்பாய்வுக்கான இடமாகும், மேலும் ஏதேனும் மாற்றங்களுக்குப் பிறகு புதிதாகத் தேவைப்படும் variables-ஐக் கண்டறிய ஒவ்வொரு app-க்குமான .env.example கோப்புகளை முதலில் பார்க்கவும்.