Superlog को self-host कैसे करें: पूरी जानकारी

Superlog को self-host करने पर क्या-क्या install होता है

Superlog को self-host करने के लिए आप repository को clone करते हैं, Docker Compose के साथ Postgres, ClickHouse और एक OpenTelemetry collector को start करते हैं, एक database migration चलाते हैं, और फिर source से चार Node services शुरू करते हैं। आपके applications OTLP (OpenTelemetry protocol) traces, logs और metrics को एक intake port पर भेजते हैं, Superlog उन्हें fingerprint करता है, दोहराए गए logs को एक single incident में group करता है, और एक agent triage का पहला चरण लिखता है। इसे install करने में एक दोपहर का समय लगता है। शुरू करने से पहले इसके footprint और वास्तविक सीमाओं (honest limits) के बारे में पढ़ना उपयोगी है।

Superlog Apache 2.0 license के अंतर्गत आता है और github.com/superloglabs/superlog पर उपलब्ध है। अगस्त 2026 तक इसमें लगभग 1.2k stars हैं, main पर लगभग 460 commits हैं, और कोई भी release tag मौजूद नहीं है। यह अंतिम बिंदु install करने के तरीके को निर्धारित करता है: git checkout v1.0.0 में checkout करने के लिए कुछ भी नहीं है, इसलिए आप स्वयं किसी commit को pin करते हैं या जिस दिन आपने clone किया, उस दिन जो भी main मौजूद था, आप उसी को run करते हैं।

Superlog उन सवालों के क्या जवाब देता है जो Uptime Kuma और Langfuse नहीं देते

बाहर से देखने पर self-hosted monitoring tools एक जैसे लग सकते हैं। लेकिन वे ऐसे नहीं हैं, और गलत टूल चलाने से आपको बिना किसी लाभ के सर्वर का खर्च उठाना पड़ता है।

• Uptime Kuma आपके endpoints को बाहर से probe करता है और केवल एक सवाल का जवाब देता है: क्या यह up है।
• Zabbix Ubuntu 24.04 पर hosts और services की निगरानी करता है, जो आपके द्वारा सेट की गई सीमाओं के आधार पर CPU, memory, disk और service state की जाँच करता है।
• Langfuse LLM calls को trace करता है, जो हर call के prompt, model, tokens, latency और cost को रिकॉर्ड करता है।
• Superlog उन telemetry डेटा को लेता है जो आपकी सामान्य services पहले से ही emit कर रही हैं और बार-बार होने वाली विफलताओं को incidents में बदल देता है।

Superlog एक अलग सवाल का जवाब देता है: कुछ टूट गया है, तो क्या टूटा है और क्यों टूटा है। इसका LLM calls के बारे में कोई मत नहीं है और यह आपको बाहर से probe नहीं करता है। यह आपके सामान्य application code से OTLP ingest करता है और triage चरण पर एक agent लगाता है, जो कि वही पहला कदम है जो on-call पर मौजूद व्यक्ति वैसे भी उठाता।

VPS बजट के लिए जो अंतर मायने रखता है, वह storage है। Uptime Kuma 1 GB RAM पर आसानी से चल जाता है क्योंकि यह केवल कुछ हजार check results को store करता है। Superlog एक column store का उपयोग करता है, क्योंकि telemetry को एक बार लिखा जाता है और फिर लाखों rows में समय सीमा के आधार पर query किया जाता है। ClickHouse इसी काम के लिए है और Postgres इसके लिए नहीं है। Postgres अभी भी stack में मौजूद है, जो छोटे relational डेटा को संभालता है: projects, users, incidents और ingest keys।

docker compose up -d वास्तव में क्या शुरू करता है?

तीन containers, और उनमें से कोई भी Superlog नहीं है। यह उन लोगों को आश्चर्यचकित करता है जो एक ही command में install होने की उम्मीद करते हैं।

• postgres:16, host port 5434 पर प्रकाशित
• clickhouse/clickhouse-server:26.1, HTTP के लिए 8123 और native protocol के लिए 9000 पर
• otel/opentelemetry-collector-contrib:0.150.1, gRPC के लिए 4317 और HTTP पर OTLP के लिए 4318 पर

Superlog applications host पर source से चलती हैं, जिन्हें pnpm dev द्वारा शुरू किया जाता है। अगस्त 2026 तक repository में कोई production compose file नहीं है, इसलिए लंबे समय तक चलने वाले install का मतलब है कि प्रत्येक app की start script के लिए आपकी अपनी systemd units, या tree में दिए गए प्रति-app Dockerfiles का उपयोग करना।

एक span जिस रास्ते से गुजरता है उसे ध्यान में रखें, क्योंकि नीचे दी गई हर विफलता उस रास्ते के किसी एक चरण में रुकावट है। आपकी app Superlog intake proxy को OTLP भेजती है। Proxy आपके ingest key के साथ request को authenticate करती है, उस पर project id लगाती है, और उसे collector को forward कर देती है। Collector उन सभी superlog.* attributes को हटा देता है जिन्हें client ने सेट करने की कोशिश की थी, proxy द्वारा प्रदान किए गए header से superlog.project_id जोड़ता है, batch बनाता है, और ClickHouse में लिखता है। इसके बाद web app और API, ClickHouse से telemetry और बाकी सब कुछ Postgres से पढ़ते हैं।

वह attribute stripping एक वास्तविक multi-tenancy control है, न कि केवल सजावट। इसके बिना, कोई भी व्यक्ति जिसके पास एक वैध ingest key है, वह खुद superlog.project_id सेट कर सकता है और किसी अन्य project के डेटा में लिख सकता है।

VPS का आकार कितना होना चाहिए?

कम ingest volume वाले single node install के लिए 4 vCPU, 8 GB RAM और 40 GB SSD की योजना बनाएँ। यह एक न्यूनतम आधार है, कोई सटीक माप नहीं, इसलिए इसे शुरुआती आकार मानें और अपने traffic के अनुसार इसकी जाँच करें।

Memory चार जगहों पर खर्च होती है। ClickHouse को अधिक RAM वाले मशीनों के लिए बनाया गया है और इसके defaults इसी आधार पर सेट हैं। यहाँ Postgres 16 कम संसाधन लेता है, क्योंकि यह telemetry के बजाय metadata रखता है। Collector भी कम संसाधन लेता है। चारों Node processes अधिक संसाधन लेती हैं: एक Vite development server और तीन tsx watch processes में से प्रत्येक सैकड़ों megabytes RAM लेती हैं, यही कारण है कि 2 GB वाली मशीन पर pnpm dev चलाना कठिन होता है।

Disk एक शांत समस्या है। इस monorepo पर pnpm install चलाने से पहले ही AWS SDK, एक ClickHouse client, OpenTelemetry SDK और React toolchain download हो जाते हैं, इससे पहले कि आप एक भी span ingest करें। इसके बाद ClickHouse आपके traffic के साथ बढ़ता है। दोनों को मापें:

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"

कम volume पर, जहाँ कुछ services प्रति मिनट कुछ सौ spans भेज रही हों, मशीन शांत रहती है और ClickHouse अधिकतर समय idle रहता है। जो load नुकसान पहुँचाता है वह है burst: एक खराब deploy जो प्रति मिनट हजारों समान errors उत्पन्न करे। Fingerprinting उन्हें reader के लिए एक incident में बदल देता है, लेकिन ClickHouse फिर भी हर row को नीचे लिखता है।

Retention सेट करना आपकी जिम्मेदारी है। Collector का ClickHouse exporter tables, otel_traces, otel_logs और प्रति metric type एक table बनाता है, और यह केवल तभी time to live लागू करता है यदि infra/collector/config.yaml में config इसे सेट करे। अपने आप कुछ भी expire नहीं होता, इसलिए यदि आप योजना नहीं बनाते हैं, तो एक व्यस्त महीना disk को पूरा भर सकता है।

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 आर्काइव में मौजूद nodejs पैकेज 20 से पुराना है, इसलिए NodeSource या nvm से Node 20 या उससे नया वर्ज़न इंस्टॉल करें। रिपॉजिटरी में एक .nvmrc शामिल है, इसलिए यदि आपके पास nvm है तो nvm use इच्छित वर्ज़न को चुन लेता है।

pnpm install
docker compose up -d
docker compose ps

up -d को ready मानने के बजाय 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 पर connection refused का मतलब है कि कंटेनर अभी भी start हो रहा है या बंद हो गया है। docker compose logs clickhouse दिखाता है कि स्थिति क्या है, और यदि मेमोरी के कारण kernel ने इसे kill कर दिया है तो docker inspect $(docker compose ps -q clickhouse) | grep -i oomkilled, true रिपोर्ट करता है। यह इंगित करता है कि आपकी config के बजाय सर्वर का आकार बहुत छोटा है।

इसके बाद migration और applications:

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

पोर्ट पर ध्यान दें: 5434, न कि 5432। Compose file Postgres को 5434 पर पब्लिश करती है ताकि यह होस्ट पर पहले से इंस्टॉल Postgres के साथ न टकराए, और ऐप .env.example फाइलें DATABASE_URL=postgres://postgres:postgres@localhost:5434/superlog के साथ मेल खाती हैं। यदि आप किसी ऐसे सर्वर पर migration को 5432 पर पॉइंट करते हैं जहाँ पहले से Postgres चल रहा है, तो या तो connection refused होगा या, इससे भी बुरा, गलत डेटाबेस पर migration लागू हो जाएगा।

pnpm dev रिपॉजिटरी की Procfile में सूचीबद्ध चार प्रक्रियाओं को शुरू करता है: api, web, worker और proxy। प्रत्येक अपना आउटपुट tmp/logs/ में भेजता है, इसलिए ingest को मॉनिटर करने के लिए tail -f tmp/logs/proxy.log सही जगह है। README वेब ऐप को http://localhost:5173 पर, API को http://localhost:4100 पर और OTLP intake को http://localhost:4101 पर रखता है।

किसी भी चीज़ को पॉइंट करने से पहले पुष्टि करें कि वास्तव में क्या bind हुआ है:

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

यह बाद में महत्वपूर्ण होता है। Proxy अपना पोर्ट PORT environment variable से पढ़ता है और यदि PORT सेट नहीं है तो 4000 पर वापस आ जाता है। डेवलपमेंट स्टैक इसे आपके लिए सेट कर देता है। आपके द्वारा लिखी गई systemd unit ऐसा नहीं करती है, इसलिए 4000 पर listening proxy के खिलाफ 4101 पर लक्षित exporter, connection refused के साथ विफल हो जाता है और कोई अन्य संकेत नहीं देता है।

एक ट्रेस भेजें, एक त्रुटि उत्पन्न करें, एक घटना देखें

वेब ऐप में एक प्रोजेक्ट बनाएँ और उसकी ingest key कॉपी करें। intake हर अनुरोध को उस key के विरुद्ध प्रमाणित करता है, इसलिए बिना key के भेजी गई टेलीमेट्री कभी भी ClickHouse तक नहीं पहुँचती है।

मानक 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 हेडर से key को पढ़ता है, और यदि आपका exporter उस तरह से कॉन्फ़िगर करना आसान है, तो authorization: bearer YOUR_INGEST_KEY को भी स्वीकार करता है। यह तीन मानक OTLP पथों, /v1/traces, /v1/logs और /v1/metrics, के साथ-साथ /health को भी सर्व करता है।

एक जाल जिसका उल्लेख करना आवश्यक है: OTEL_EXPORTER_OTLP_ENDPOINT एक base URL है और SDK इसमें सिग्नल पथ जोड़ता है। OTEL_EXPORTER_OTLP_TRACES_ENDPOINT जैसे सिग्नल-विशिष्ट variables का उपयोग बिल्कुल वैसे ही किया जाता है जैसे वे लिखे गए हैं, बिना किसी अतिरिक्त पथ के। यदि आप सिग्नल-विशिष्ट variable को http://127.0.0.1:4101 पर सेट करते हैं, तो हर एक्सपोर्ट / पर पोस्ट होगा, जो कि एक रूट नहीं है। परिणामस्वरूप, कुछ भी प्राप्त नहीं होगा और SDK एक एक्सपोर्ट विफलता लॉग करेगा जबकि आपका ऐप सामान्य दिखाई देगा।

Node सर्विस के लिए, पाइपलाइन को सिद्ध करने हेतु zero code पथ पर्याप्त है:

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

अब जानबूझकर कुछ खराब करें। कोई भी रूट जो throw करता है, वह काम करेगा:

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

हॉप्स (hops) की क्रमवार जाँच करें, क्योंकि पहला गैप आपको बताता है कि कौन सा विफल हुआ है:

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

खाली वेब ऐप के साथ otel_traces में बढ़ती संख्या का मतलब प्रोजेक्ट बेमेल (mismatch) है, इसलिए जाँचें कि ingest key किस प्रोजेक्ट से संबंधित है। प्रॉक्सी लॉग में गतिविधि के साथ स्थिर संख्या का मतलब collector या ClickHouse राइट में समस्या है, इसलिए docker compose logs collector पढ़ें। प्रॉक्सी लॉग में कोई गतिविधि न होने का मतलब है कि exporter कभी intake तक पहुँचा ही नहीं: गलत पोर्ट, गलत पथ, या अस्वीकृत key।

वेब ऐप में, वे बार-बार होने वाली विफलताएँ प्रति अनुरोध एक पंक्ति के बजाय एक घटना (incident) के रूप में आती हैं। Superlog आने वाले सिग्नलों को फिंगरप्रिंट करता है और मेल खाने वाले सिग्नलों को समूहित (group) करता है। यही कारण है कि इनबॉक्स में 4,000 समान त्रुटियों के बजाय एक पेज पर केवल एक घटना दिखाई देती है। इसके बाद एजेंट उस समूह पर अपनी जाँच (investigation) लिखता है।

जाँच का चरण एक मॉडल को कॉल करता है, इसलिए वर्कर के पास एक कॉन्फ़िगर किया गया मॉडल प्रदाता होना चाहिए। उन variable नामों को किसी बाहरी लेख के बजाय उस कमिट (commit) की प्रत्येक ऐप निर्देशिका के अंदर स्थित .env.example फ़ाइल से लें जिसे आपने पिन किया है, क्योंकि वे main के साथ बदलते रहते हैं। यही बात GitHub और Sentry इंटीग्रेशन पर भी लागू होती है, जिनके अपने सेटअप दस्तावेज़ docs/github-app-setup.md और docs/sentry-app-setup.md पर उपलब्ध हैं, और webhook पेलोड docs/webhooks.md में प्रलेखित हैं।

Intake को निजी रखें और agent को read-only मोड में चलाएं

Docker डिफ़ॉल्ट रूप से container ports को 0.0.0.0 पर publish करता है। ये published ports ufw को bypass कर देते हैं, क्योंकि Docker अपने स्वयं के rules को DOCKER-USER chain में लिखता है, जिनका मूल्यांकन ufw द्वारा पैकेट देखने से पहले ही हो जाता है। Public IP वाले VPS पर, compose file जैसा कि ship किया गया है, ClickHouse HTTP को 8123 पर और Postgres को 5434 पर डालता है, जहाँ internet उन तक पहुँच सकता है। उस file में मौजूद credentials development defaults हैं: ClickHouse user default बिना password के, और Postgres में postgres user और password दोनों के रूप में।

उन्हें 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

परिणाम पर भरोसा करने से पहले उसे verify करें, फिर containers को recreate करें:

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

docker compose config resolved file को print करता है, ताकि आप अनुमान लगाने के बजाय 127.0.0.1:5434:5432 को पढ़ सकें। ss को तब 127.0.0.1:5434 दिखाना चाहिए, न कि 0.0.0.0:5434। इसे compose override file के साथ ठीक करने का प्रयास न करें जो ports को फिर से declare करती है, क्योंकि Compose files के बीच port lists को replace करने के बजाय concatenate करता है। परिणामस्वरूप, आपको दोनों bindings मिलेंगी और public port अभी भी open रहेगा।

Intake को भी उतनी ही सावधानी की आवश्यकता है। आपकी ingest key एक header में जाती है, इसलिए इसके आगे TLS (transport layer security) होना आवश्यक है: proxy के आगे nginx या Caddy में TLS terminate करें, या ingest को private network या WireGuard tunnel के भीतर रखें। 5173 पर चल रहा web app एक Vite development server है और इसे internet पर expose करने का कोई औचित्य नहीं है।

अब बात agent की। Superlog का मुख्य उद्देश्य यह है कि agent जांच करता है और सुधार का प्रस्ताव देता है, और यहाँ महत्वपूर्ण शब्द 'प्रस्ताव' है। इसे production पर तब तक read-only रखें जब तक आप इसे कुछ वास्तविक incidents पर काम करते हुए न देख लें। GitHub App को read scopes दें और उसे pull requests खोलने दें, जिनकी आप समीक्षा करें। एक ऐसा agent जो telemetry पढ़ता है और patch लिखता है, उपयोगी है। एक ऐसा agent जो आपकी services को restart कर सकता है, जोखिम का एक अलग स्तर है, और यह एक ऐसा निर्णय होना चाहिए जिसे आप सोच-समझकर लें, न कि कोई डिफ़ॉल्ट सेटिंग जिसे आप अपना लें। लागत (cost) पर भी उतना ही ध्यान देना चाहिए, क्योंकि हर जांच एक model call है: इसे किसी noisy production system पर लक्षित करने से पहले agent spend के लिए budget निर्धारित करें, और agent द्वारा किए गए कार्यों का रिकॉर्ड रखें ताकि किसी भी अप्रत्याशित pull request का एक audit trail मौजूद रहे।

ऐसी विफलताएं जिनका आप सामना करेंगे, और उन्हें दर्शाने वाली स्ट्रिंग्स

• ERR_PNPM_UNSUPPORTED_ENGINE के दौरान pnpm install का अर्थ है कि Node का संस्करण 20 से पुराना है। node -v इसे एक लाइन में स्पष्ट करता है।
• माइग्रेशन के दौरान ECONNREFUSED 127.0.0.1:5434 का अर्थ है कि compose stack चालू नहीं है, या DATABASE_URL गलत पोर्ट को दर्शाता है।
• ClickHouse का बार-बार रीस्टार्ट होना आमतौर पर मेमोरी की समस्या है। docker compose logs clickhouse पढ़ें, फिर कंटेनर में जाँचें कि क्या OOMKilled का मान true है।
• यदि कोई एक्सपोर्टर सफलता की रिपोर्ट देता है लेकिन वेब ऐप खाली रहता है, तो इसका आमतौर पर अर्थ है कि डेटा सीधे 4318 पोर्ट पर कलेक्टर के पास चला गया है, जिससे वह प्रोजेक्ट स्टैम्पिंग छूट गई है जो प्रॉक्सी द्वारा की जाती है।
• प्रोडक्शन इंस्टॉलेशन में 4101 पर Connection refused का अर्थ है कि प्रॉक्सी PORT=4000 पर वापस आ गई है। यूनिट फ़ाइल में PORT को स्पष्ट रूप से सेट करें।
• docker compose ps में 0.0.0.0:8123 दिखने का अर्थ है कि आपके लूपबैक बाइंडिंग प्रभावी नहीं हैं। docker compose config चलाएं और रिज़ॉल्व किए गए पोर्ट्स को पढ़ें।

Flawless, HyperProbe, और Superlog की स्थिति

यह श्रेणी अभी नई है और इसमें शामिल टूल्स इस बात पर विभाजित हैं कि एजेंट को किन चीजों को एक्सेस करने की अनुमति है। Flawless एक ओपन सोर्स AI SRE (साइट रिलायबिलिटी इंजीनियरिंग) टूल है जो Kubernetes के लिए बनाया गया है। यह पाइपलाइन का स्वामित्व लेने के बजाय मौजूदा Prometheus, Loki और Grafana स्टैक से डेटा पढ़ता है। HyperProbe इसके विपरीत काम करता है: यह एक होस्टेड प्रोडक्ट है (अगस्त 2026 तक क्लोज्ड सोर्स), जो वेरिएबल स्टेट को कैप्चर करने के लिए रनिंग प्रोसेस के अंदर रीड-ओनली प्रोब्स लगाता है और उस स्टेट को MCP (मॉडल कॉन्टेक्स्ट प्रोटोकॉल) के माध्यम से एक असिस्टेंट को उपलब्ध कराता है।

Superlog इन दोनों के बीच में स्थित है। यह OTLP इनटेक से लेकर ClickHouse स्टोरेज तक पूरी पाइपलाइन का स्वामित्व रखता है, और यह एजेंट को फिक्स स्टेप के बजाय ट्राइएज स्टेप पर रखता है। यही डिज़ाइन कारण है कि इसे सेल्फ-होस्ट करना एक इंफ्रास्ट्रक्चर संबंधी निर्णय है, न कि कोई ऐसा कंटेनर जिसे आप भूल सकें। एक बार जब आप Superlog रन करते हैं, तो आप एक कॉलम स्टोर रन कर रहे होते हैं, और इसे आपके द्वारा स्वामित्व वाले किसी भी अन्य डेटाबेस की तरह ही देखभाल की आवश्यकता होती है।

FAQ

एक self-hosted Superlog को कितनी RAM की आवश्यकता होती है?

कम ingest volume वाले सिंगल नोड के लिए 8 GB RAM, 4 vCPU और 40 GB डिस्क की योजना बनाएँ। इस स्टैक में 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 पर point करना चाहिए?

Superlog intake proxy पर, जिसे README में http://localhost:4101 पर रखा गया है। यह /v1/traces, /v1/logs और /v1/metrics को serve करता है, और यह x-api-key header या authorization: bearer header से लिए गए आपके प्रोजेक्ट के ingest key के साथ authenticate करता है। Port 4318 इसके नीचे स्थित OpenTelemetry collector है, और सीधे वहां export करने से proxy छूट जाता है, जो वह घटक है जो आपके डेटा पर प्रोजेक्ट id लगाता है। जब PORT unset होता है, तो proxy port 4000 पर वापस चला जाता है, इसलिए 4101 मानने से पहले ss -lntp चलाएं और पुष्टि करें कि यह किस पर bound है।

क्या Superlog, Uptime Kuma या Zabbix की जगह ले सकता है?

नहीं। Uptime Kuma यह बताता है कि क्या कोई endpoint आपके नेटवर्क के बाहर से response दे रहा है, और Zabbix आपके द्वारा सेट किए गए thresholds के आधार पर host और service metrics की निगरानी करता है। Superlog आपके applications द्वारा उत्सर्जित traces, logs और metrics को consume करता है और बार-बार होने वाली विफलताओं को incidents में समूहित करता है। इसके साथ एक बाहरी uptime probe रखें, क्योंकि कहीं और चल रहा probe तब भी रिपोर्ट करता है जब वह सर्वर ही बंद हो जाए जिस पर आपका telemetry pipeline चल रहा है।

क्या Superlog agent मेरे production systems को बदल सकता है?

केवल उन अनुमतियों के माध्यम से जो आप इसे देते हैं। इसका output एक जांच और प्रस्तावित बदलाव है जिसे एक इंसान review करता है। शुरुआत में GitHub App को केवल read scopes और pull requests तक सीमित रखें, और worker के पास मौजूद किसी भी credential को केवल reading तक सीमित रखें। production पर write access को एक अलग और सोच-समझकर लिया गया निर्णय मानें, क्योंकि जो agent services को restart कर सकता है, वह केवल telemetry पढ़ने और review के लिए patch लिखने वाले agent की तुलना में बहुत बड़ी जिम्मेदारी है।

क्या मुझे commit pin करना चाहिए या main को track करना चाहिए?

commit pin करें। अगस्त 2026 तक repository में कोई release tags नहीं हैं, इसलिए main ही एकमात्र उपलब्ध विकल्प है और इसमें प्रति सप्ताह कई commits होते हैं। जिस SHA को आपने टेस्ट किया है उसे रिकॉर्ड करें, उसे deploy करें, और आगे बढ़ने से पहले diff को पढ़ें। git log --oneline <old-sha>..main ही review है, और किसी भी बदलाव के बाद नई आवश्यक variables के लिए प्रति-app .env.example फाइलें सबसे पहले देखने वाली जगह हैं।