โดย วิธีติดตั้ง Superlog แบบ Self-host บน VPS ด้วย Docker
เรียนรู้วิธีติดตั้ง Superlog ด้วย Docker Compose เพื่อจัดการ OTLP traces และ logs พร้อมระบบ AI คัดกรอง incident อัตโนมัติ โดยต้องระบุ commit เองเนื่องจากยังไม่มี release tags
สิ่งที่การ self-host Superlog ติดตั้งลงในระบบจริง
ในการ self-host Superlog คุณต้อง clone repository ขึ้นมา จากนั้นรัน Postgres, ClickHouse และ OpenTelemetry collector ด้วย Docker Compose ทำการ migration ฐานข้อมูลหนึ่งครั้ง แล้วจึงเริ่มรัน Node services สี่รายการจากซอร์สโค้ด แอปพลิเคชันของคุณจะส่ง traces, logs และ metrics ผ่านโปรโตคอล OTLP (OpenTelemetry protocol) ไปยังพอร์ตรับข้อมูล จากนั้น Superlog จะทำ fingerprint ข้อมูลเหล่านั้น จัดกลุ่มรายการที่ซ้ำกันให้เป็น incident เดียวกัน และมี agent คอยเขียนสรุปการคัดกรองเบื้องต้นให้ การติดตั้งนี้ใช้เวลาประมาณหนึ่งช่วงบ่าย สิ่งที่ควรศึกษาให้เข้าใจก่อนเริ่มคือขนาดการใช้งาน (footprint) และข้อจำกัดที่แท้จริงของระบบ
Superlog ใช้สัญญาอนุญาตแบบ Apache 2.0 และอยู่ที่ github.com/superloglabs/superlog ณ เดือนสิงหาคม 2026 โปรเจกต์นี้มีดาวประมาณ 1.2k ดวง มีการ commit บน main ประมาณ 460 ครั้ง และยังไม่มีการทำ release tags เลย ประเด็นหลังนี้ส่งผลต่อวิธีการติดตั้ง เนื่องจาก git checkout v1.0.0 ไม่มีเวอร์ชันให้เลือก checkout คุณจึงต้องระบุ commit เอง หรือไม่ก็ต้องรันตามสถานะของ main ณ เช้าวันที่คุณ clone มาใช้งาน
สิ่งที่ Superlog ตอบโจทย์ได้แต่ Uptime Kuma และ Langfuse ทำไม่ได้
เครื่องมือตรวจสอบสถานะแบบ self-hosted อาจดูเหมือนใช้งานแทนกันได้เมื่อมองจากภายนอก แต่ในความเป็นจริงนั้นไม่ใช่ และการเลือกใช้เครื่องมือที่ไม่เหมาะสมอาจทำให้คุณเสียทรัพยากรเซิร์ฟเวอร์ไปโดยเปล่าประโยชน์
- Uptime Kuma ทำการตรวจสอบ endpoint ของคุณจากภายนอก และตอบคำถามเพียงข้อเดียวคือ บริการนั้นยังทำงานอยู่หรือไม่
- Zabbix เฝ้าดูโฮสต์และบริการบน Ubuntu 24.04 โดยตรวจสอบ CPU, หน่วยความจำ, ดิสก์ และสถานะของบริการเทียบกับเกณฑ์ที่คุณกำหนดไว้
- Langfuse ติดตามการเรียกใช้งาน LLM โดยบันทึก prompt, โมเดล, จำนวน token, latency และค่าใช้จ่ายของการเรียกใช้งานแต่ละครั้ง
- Superlog นำข้อมูล telemetry ที่บริการทั่วไปของคุณส่งออกมาอยู่แล้ว มาเปลี่ยนความล้มเหลวที่เกิดขึ้นซ้ำๆ ให้กลายเป็นเหตุการณ์ (incident)
Superlog ตอบคำถามในมุมที่ต่างออกไป คือเมื่อมีบางอย่างพัง อะไรคือสิ่งที่พัง และพังเพราะเหตุใด เครื่องมือนี้ไม่มีส่วนเกี่ยวข้องกับการเรียกใช้งาน LLM และไม่ได้ทำการตรวจสอบคุณจากภายนอก แต่จะรับข้อมูล OTLP จากโค้ดแอปพลิเคชันปกติของคุณ และวาง agent ไว้ในขั้นตอนการคัดกรอง (triage) ซึ่งเป็นขั้นตอนแรกที่เจ้าหน้าที่ on-call ต้องทำอยู่แล้ว
ความแตกต่างที่สำคัญสำหรับงบประมาณ VPS คือเรื่องพื้นที่จัดเก็บข้อมูล Uptime Kuma สามารถทำงานได้ดีบน RAM ขนาด 1 GB เพราะจัดเก็บเพียงผลการตรวจสอบไม่กี่พันรายการ แต่ Superlog ต้องใช้ column store เนื่องจากข้อมูล telemetry จะถูกเขียนเพียงครั้งเดียวและถูกสืบค้นตามช่วงเวลาจากข้อมูลนับล้านแถว นั่นคือหน้าที่ของ ClickHouse ซึ่งไม่ใช่สิ่งที่ Postgres ออกแบบมาเพื่อรองรับ อย่างไรก็ตาม Postgres ยังคงอยู่ใน stack เพื่อเก็บข้อมูลเชิงสัมพันธ์ขนาดเล็ก เช่น โปรเจกต์, ผู้ใช้งาน, เหตุการณ์ และ ingest keys
คำสั่ง docker compose up -d เริ่มการทำงานของอะไรบ้าง
มีคอนเทนเนอร์ 3 ตัวที่ถูกเริ่มทำงาน และไม่มีตัวใดที่เป็น Superlog ซึ่งเป็นเรื่องที่น่าประหลาดใจสำหรับผู้ที่คาดหวังว่าการติดตั้งจะเสร็จสิ้นด้วยคำสั่งเดียว
postgres:16ซึ่งเปิดใช้งานบนพอร์ต 5434 ของโฮสต์clickhouse/clickhouse-server:26.1บนพอร์ต 8123 สำหรับ HTTP และ 9000 สำหรับ native protocolotel/opentelemetry-collector-contrib:0.150.1บนพอร์ต 4317 สำหรับ gRPC และ 4318 สำหรับ OTLP ผ่าน HTTP
แอปพลิเคชัน Superlog ทำงานบนโฮสต์โดยตรงจากซอร์สโค้ด ซึ่งเริ่มทำงานด้วย pnpm dev ณ เดือนสิงหาคม 2026 ยังไม่มีไฟล์ compose สำหรับใช้งานจริง (production) ใน repository ดังนั้นการติดตั้งแบบถาวรจึงหมายถึงการที่คุณต้องสร้าง systemd unit ของคุณเองเพื่อครอบสคริปต์ start ของแต่ละแอป หรือใช้ Dockerfile ที่มีมาให้ในแต่ละโฟลเดอร์ของแอป
โปรดจดจำเส้นทางที่ข้อมูลเดินทางไว้ให้ดี เพราะความล้มเหลวทุกอย่างที่ระบุไว้ด้านล่างนี้คือจุดที่เส้นทางดังกล่าวขาดช่วง แอปของคุณส่งข้อมูล OTLP ไปยัง intake proxy ของ Superlog ตัว proxy จะตรวจสอบความถูกต้องของคำขอด้วย ingest key ของคุณ ประทับ project id ลงไป แล้วส่งต่อไปยัง collector ตัว collector จะลบ attribute superlog.* ใดๆ ที่ไคลเอนต์พยายามกำหนดเอง เพิ่ม superlog.project_id จาก header ที่ proxy ระบุมา จากนั้นทำการรวมกลุ่มข้อมูล (batch) และเขียนลงใน ClickHouse จากนั้น web app และ API จะอ่านข้อมูล telemetry กลับมาจาก ClickHouse และอ่านข้อมูลส่วนอื่นจาก Postgres
การลบ attribute ดังกล่าวเป็นการควบคุมแบบ multi-tenancy ที่แท้จริง ไม่ใช่เพียงแค่การตกแต่ง หากไม่มีการควบคุมนี้ ใครก็ตามที่มี ingest key ที่ถูกต้องเพียงหนึ่งชุดจะสามารถกำหนด superlog.project_id ได้ด้วยตนเองและเขียนข้อมูลลงในโปรเจกต์ของผู้อื่นได้
VPS ต้องมีขนาดเท่าใด
ควรวางแผนใช้ 4 vCPU, 8 GB RAM และ 40 GB SSD สำหรับการติดตั้งแบบ single node ที่มีปริมาณข้อมูลขาเข้าต่ำ นี่เป็นเพียงขนาดเริ่มต้นสำหรับการวางแผน ไม่ใช่ค่าที่วัดผลได้จริง ดังนั้นให้ถือว่าเป็นขนาดเริ่มต้นและตรวจสอบกับปริมาณ traffic ของคุณเอง
หน่วยความจำจะถูกแบ่งไปใช้ใน 4 ส่วนหลัก ClickHouse ถูกออกแบบมาสำหรับเครื่องที่มี RAM จำนวนมากและค่าเริ่มต้นก็ตั้งไว้ตามนั้น ส่วน Postgres 16 ใช้ทรัพยากรน้อยกว่าเนื่องจากเก็บเพียง metadata ไม่ใช่ telemetry ตัว collector เองก็ใช้ทรัพยากรไม่มาก แต่กระบวนการ Node ทั้ง 4 ตัวนั้นใช้ทรัพยากรสูง โดย Vite development server และกระบวนการ tsx watch อีก 3 ตัว ต่างก็ใช้หน่วยความจำหลายร้อยเมกะไบต์ ซึ่งเป็นเหตุผลว่าทำไมการรัน pnpm dev บนเครื่องที่มี RAM 2 GB จึงเป็นเรื่องยาก
พื้นที่จัดเก็บข้อมูลเป็นปัญหาที่มักถูกมองข้าม pnpm install ใน monorepo นี้จะดึง AWS SDK, ClickHouse client, OpenTelemetry SDK และ React toolchain มาก่อนที่คุณจะเริ่มรับข้อมูล span แรกเสียอีก จากนั้น 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"ในกรณีที่มีปริมาณข้อมูลต่ำ โดยมีบริการจำนวนหนึ่งส่งข้อมูลไม่กี่ร้อย span ต่อนาที เครื่องจะทำงานเบาและ ClickHouse จะอยู่ในสถานะว่างงานเกือบตลอดเวลา ภาระงานที่ส่งผลกระทบคือช่วงที่มีข้อมูลเข้ามาเป็นจำนวนมาก (burst) เช่น การ deploy ที่ผิดพลาดจนทำให้เกิดข้อผิดพลาดซ้ำๆ นับพันรายการต่อนาที ระบบ Fingerprinting จะยุบรวมข้อผิดพลาดเหล่านั้นให้เป็นเหตุการณ์เดียวสำหรับผู้ใช้งาน แต่ ClickHouse ยังคงต้องเขียนข้อมูลทุกแถวลงในฐานข้อมูล
คุณเป็นผู้กำหนดระยะเวลาการเก็บรักษาข้อมูล (retention) ตัว ClickHouse exporter ของ collector จะสร้างตารางต่างๆ ขึ้นมา ได้แก่ otel_traces, otel_logs และตารางแยกตามประเภท metric อีกหนึ่งตาราง โดยจะมีการกำหนดระยะเวลาการจัดเก็บ (time to live) ก็ต่อเมื่อมีการตั้งค่าไว้ใน infra/collector/config.yaml เท่านั้น ข้อมูลจะไม่ถูกลบออกโดยอัตโนมัติ ดังนั้นหากมีข้อมูลเข้ามามากในแต่ละเดือน พื้นที่จัดเก็บข้อมูลจะเต็มอย่างรวดเร็วหากคุณไม่ได้วางแผนรองรับไว้
การติดตั้งจาก 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 ที่คุณทดสอบแล้วและใช้งาน commit นั้นต่อไป:
git checkout 0d3a6c8bb63eda3493e6ba0003e7c2a70750bc1eถัดไปคือ toolchain:
node -v
corepack enable
corepack prepare pnpm@9.12.0 --activate
pnpm -vpackage.json ประกาศให้ engines.node เป็น >=20.0.0 และ packageManager เป็น pnpm@9.12.0 หากรันการติดตั้งบน Node เวอร์ชันเก่า pnpm จะหยุดทำงานพร้อมกับ ERR_PNPM_UNSUPPORTED_ENGINE โดยระบุเวอร์ชันที่ต้องการ แพ็กเกจ nodejs ในคลังซอฟต์แวร์ของ Ubuntu 24.04 มีเวอร์ชันเก่ากว่า 20 ดังนั้นให้ติดตั้ง Node 20 หรือใหม่กว่าจาก NodeSource หรือ nvm ตัว repository มีไฟล์ .nvmrc อยู่ ดังนั้น nvm use จะเลือกเวอร์ชันที่กำหนดไว้ให้โดยอัตโนมัติหากคุณใช้ nvm
pnpm install
docker compose up -d
docker compose psให้รอจนกว่า health check จะผ่าน แทนที่จะเชื่อว่า up -d หมายความว่าพร้อมใช้งานแล้ว ทั้ง Postgres และ ClickHouse ต่างประกาศ health check ไว้ในไฟล์ compose:
curl -sS http://127.0.0.1:8123/ping
pg_isready -h 127.0.0.1 -p 5434 -U postgresClickHouse จะตอบกลับด้วย Ok. และ pg_isready จะตอบกลับด้วย accepting connections หากพบข้อผิดพลาด Connection refused บนพอร์ต 8123 แสดงว่า container กำลังเริ่มทำงานหรือหยุดทำงานไปแล้ว docker compose logs clickhouse จะแสดงสถานะที่แท้จริง และ docker inspect $(docker compose ps -q clickhouse) | grep -i oomkilled จะรายงาน true หาก kernel สั่งปิดกระบวนการเนื่องจากหน่วยความจำไม่เพียงพอ ซึ่งบ่งชี้ว่าขนาดของเซิร์ฟเวอร์เล็กเกินไป ไม่ใช่ปัญหาที่การตั้งค่าของคุณ
จากนั้นจึงดำเนินการ migration และรันแอปพลิเคชัน:
pnpm --filter @superlog/db db:migrate
pnpm devโปรดสังเกตพอร์ต: 5434 ไม่ใช่ 5432 ไฟล์ compose เผยแพร่ Postgres บนพอร์ต 5434 เพื่อไม่ให้ทับซ้อนกับ Postgres ที่ติดตั้งอยู่บน host เดิม และไฟล์ .env.example ของแอปพลิเคชันต้องตรงกันด้วย DATABASE_URL=postgres://postgres:postgres@localhost:5434/superlog หากคุณชี้การ migration ไปที่พอร์ต 5432 บนเครื่องที่มี Postgres รันอยู่แล้ว คุณจะพบกับข้อผิดพลาดการเชื่อมต่อถูกปฏิเสธ หรือที่แย่กว่านั้นคือการ migration จะไปมีผลกับฐานข้อมูลผิดตัว
pnpm dev จะเริ่มกระบวนการทั้งสี่ที่ระบุไว้ใน Procfile ของ repository ได้แก่ api, web, worker และ proxy แต่ละกระบวนการจะส่ง output ไปยัง tmp/logs/ ดังนั้น tail -f tmp/logs/proxy.log จึงเป็นจุดที่คุณใช้ตรวจสอบการนำเข้าข้อมูล ไฟล์ README ระบุให้เว็บแอปทำงานบน http://localhost:5173, API บน http://localhost:4100 และ OTLP intake บน http://localhost:4101
ตรวจสอบว่าพอร์ตใดถูกใช้งานจริงก่อนที่จะชี้บริการใดๆ ไปที่พอร์ตนั้น:
ss -lntp | grep -E '4100|4101|5173'
curl -sS http://127.0.0.1:4101/healthเรื่องนี้มีความสำคัญในภายหลัง ตัว proxy จะอ่านพอร์ตของตัวเองจากตัวแปรสภาพแวดล้อม PORT และจะใช้ค่าเริ่มต้นเป็น 4000 หาก PORT ไม่ได้ถูกตั้งค่าไว้ ชุดเครื่องมือสำหรับการพัฒนาจะตั้งค่านี้ให้คุณโดยอัตโนมัติ แต่หากคุณเขียน systemd unit ขึ้นมาเอง ตัวแปรนี้จะไม่มีอยู่ ดังนั้นหากคุณชี้ exporter ไปที่พอร์ต 4101 ในขณะที่ proxy ฟังอยู่ที่พอร์ต 4000 การเชื่อมต่อจะล้มเหลวด้วยข้อผิดพลาด connection refused โดยไม่มีเบาะแสอื่นเพิ่มเติม
ส่งหนึ่ง trace, สร้างหนึ่ง error, พบหนึ่ง incident
สร้างโปรเจกต์ในเว็บแอปพลิเคชันแล้วคัดลอก ingest key ของโปรเจกต์นั้น ระบบ intake จะตรวจสอบสิทธิ์ทุกคำขอด้วย key นี้ ดังนั้น telemetry ที่ส่งมาโดยไม่มี key จะไม่ถูกบันทึกลงใน ClickHouse
กำหนดให้ OpenTelemetry SDK ชี้มาที่ intake โดยใช้ environment variable มาตรฐาน:
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 จะอ่าน key จาก header x-api-key และยังรองรับ authorization: bearer YOUR_INGEST_KEY หาก exporter ของคุณตั้งค่าด้วยวิธีนั้นได้ง่ายกว่า ระบบรองรับ OTLP path มาตรฐาน 3 รายการคือ /v1/traces, /v1/logs และ /v1/metrics รวมถึง /health
มีข้อควรระวังที่สำคัญประการหนึ่งคือ OTEL_EXPORTER_OTLP_ENDPOINT เป็น base URL ซึ่ง SDK จะต่อท้ายด้วย signal path โดยอัตโนมัติ ส่วนตัวแปรเฉพาะของ signal เช่น OTEL_EXPORTER_OTLP_TRACES_ENDPOINT จะถูกใช้งานตามที่ระบุไว้โดยไม่มีการต่อท้าย path หากคุณตั้งค่าตัวแปรเฉพาะของ signal เป็น http://127.0.0.1:4101 ข้อมูลทั้งหมดจะถูกส่งไปยัง / ซึ่งไม่ใช่ route ที่ถูกต้อง ส่งผลให้ไม่มีข้อมูลใดมาถึง และ SDK จะบันทึก log ว่าการส่งข้อมูลล้มเหลวในขณะที่แอปพลิเคชันของคุณยังทำงานปกติ
สำหรับบริการ Node การใช้ zero code path ก็เพียงพอที่จะพิสูจน์การทำงานของ pipeline:
npm install @opentelemetry/api @opentelemetry/auto-instrumentations-node
node --require @opentelemetry/auto-instrumentations-node/register server.jsจากนั้นให้ลองทำให้ระบบเกิดข้อผิดพลาดโดยเจตนา โดยใช้ route ใดก็ได้ที่ทำให้เกิด exception:
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'หากจำนวนใน otel_traces เพิ่มขึ้นแต่ในเว็บแอปพลิเคชันกลับว่างเปล่า แสดงว่าโปรเจกต์ไม่ตรงกัน ให้ตรวจสอบว่า ingest key นั้นเป็นของโปรเจกต์ใด หากจำนวนคงที่แต่มีกิจกรรมใน log ของ proxy แสดงว่าปัญหาอยู่ที่ collector หรือการเขียนข้อมูลลง ClickHouse ให้ตรวจสอบ docker compose logs collector หากไม่มีกิจกรรมใดใน log ของ proxy เลย แสดงว่า exporter ไม่สามารถเข้าถึง intake ได้ อาจเกิดจากพอร์ตผิด, path ผิด หรือ key ถูกปฏิเสธ
ในเว็บแอปพลิเคชัน ความล้มเหลวที่เกิดขึ้นซ้ำๆ จะถูกรวมเป็นหนึ่ง incident แทนที่จะแสดงแยกทีละแถวต่อหนึ่งคำขอ ระบบ Superlog จะทำ fingerprint ให้กับสัญญาณที่เข้ามาและจัดกลุ่มสัญญาณที่ตรงกัน ซึ่งช่วยลดปัญหาจาก inbox ที่เต็มไปด้วย error ซ้ำๆ 4,000 รายการ ให้เหลือเพียงหน้าเดียว จากนั้น agent จะเขียนสรุปการตรวจสอบไว้บนกลุ่ม incident นั้น
ขั้นตอนการตรวจสอบจะเรียกใช้งานโมเดล ดังนั้น worker จำเป็นต้องมีการตั้งค่า model provider ให้เรียบร้อย ให้นำชื่อตัวแปรมาจากไฟล์ .env.example ภายในไดเรกทอรีของแต่ละแอปใน commit ที่คุณเลือกไว้ แทนที่จะอ้างอิงจากเอกสารภายนอก เนื่องจากตัวแปรเหล่านี้จะเปลี่ยนแปลงไปตาม main เช่นเดียวกับการเชื่อมต่อกับ GitHub และ Sentry ซึ่งมีเอกสารการตั้งค่าของตนเองอยู่ที่ docs/github-app-setup.md และ docs/sentry-app-setup.md โดยมีรายละเอียด webhook payload อยู่ใน docs/webhooks.md
รักษาความเป็นส่วนตัวของข้อมูลขาเข้าและจำกัดสิทธิ์ของ agent
โดยปกติแล้ว Docker จะเผยแพร่พอร์ตของคอนเทนเนอร์บน 0.0.0.0 ซึ่งพอร์ตเหล่านี้จะข้ามการทำงานของ ufw เนื่องจาก Docker เขียนกฎของตัวเองลงใน chain DOCKER-USER ซึ่งจะถูกประเมินก่อนที่ ufw จะเห็นแพ็กเก็ต บน VPS ที่มี public IP ไฟล์ compose ที่มาพร้อมกับซอฟต์แวร์จะตั้งค่า ClickHouse HTTP ไว้ที่พอร์ต 8123 และ Postgres ที่พอร์ต 5434 ซึ่งทำให้เข้าถึงได้จากอินเทอร์เน็ต ข้อมูลประจำตัวในไฟล์ดังกล่าวเป็นค่าเริ่มต้นสำหรับการพัฒนา คือผู้ใช้ ClickHouse default ที่ไม่มีรหัสผ่าน และ Postgres ที่ใช้ postgres เป็นทั้งชื่อผู้ใช้และรหัสผ่าน
ให้ผูกพอร์ตเหล่านี้ไว้กับ loopback พอร์ตที่เผยแพร่ทุกรายการในไฟล์ compose จะดึงค่าฝั่ง host มาจาก environment variable ดังนั้นการตั้งค่า .env ไว้ที่ root ของ repository จึงเพียงพอแล้ว:
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ตรวจสอบผลลัพธ์ให้แน่ใจก่อนใช้งานจริง จากนั้นสร้างคอนเทนเนอร์ขึ้นใหม่:
docker compose config
docker compose up -d
ss -lntp | grep -E '5434|8123|9000|4317|4318'docker compose config จะแสดงไฟล์ที่รวมค่าแล้ว คุณจึงสามารถอ่าน 127.0.0.1:5434:5432 ได้โดยไม่ต้องคาดเดา ss ควรแสดงผลเป็น 127.0.0.1:5434 และต้องไม่แสดง 0.0.0.0:5434 อย่าพยายามแก้ไขปัญหานี้ด้วยไฟล์ compose override ที่ประกาศ ports ซ้ำ เพราะ Compose จะนำรายการพอร์ตจากหลายไฟล์มาต่อกันแทนที่จะแทนที่ค่าเดิม ส่งผลให้พอร์ตถูกผูกไว้ทั้งสองแบบและยังคงเปิดรับการเชื่อมต่อจากสาธารณะอยู่
ข้อมูลขาเข้า (intake) ต้องการการดูแลเช่นเดียวกัน ingest key ของคุณจะถูกส่งผ่าน header จึงจำเป็นต้องใช้ TLS (transport layer security) กำกับไว้ด้านหน้า: ให้ทำ TLS termination ที่ nginx หรือ Caddy ก่อนถึง proxy หรือเก็บ ingest ไว้ภายใน private network หรือผ่าน WireGuard tunnel เท่านั้น ส่วนเว็บแอปบนพอร์ต 5173 เป็น Vite development server ซึ่งไม่ควรเปิดให้เข้าถึงจากอินเทอร์เน็ตโดยเด็ดขาด
สำหรับตัว agent เอง จุดเด่นของ Superlog คือการที่ agent ทำการตรวจสอบและเสนอวิธีแก้ไข ซึ่งคำสำคัญคือ "เสนอ" ให้จำกัดสิทธิ์เป็นแบบอ่านอย่างเดียว (read only) กับระบบ production จนกว่าคุณจะมั่นใจจากการเฝ้าดูการทำงานของมันในเหตุการณ์จริง ให้สิทธิ์ GitHub App ในระดับอ่านข้อมูลและอนุญาตให้เปิด pull request เพื่อให้คุณตรวจสอบก่อน Agent ที่อ่าน telemetry และเขียน patch นั้นมีประโยชน์ แต่ agent ที่สามารถรีสตาร์ทบริการของคุณได้นั้นมีความเสี่ยงในระดับที่ต่างออกไป ซึ่งควรเป็นการตัดสินใจที่คุณเลือกเองโดยเจตนา ไม่ใช่ค่าเริ่มต้นที่ได้รับมาโดยไม่รู้ตัว ด้านค่าใช้จ่ายก็ควรให้ความสำคัญเช่นกัน เนื่องจากการตรวจสอบแต่ละครั้งคือการเรียกใช้งานโมเดล: กำหนดงบประมาณสำหรับค่าใช้จ่ายของ agent บน VPS ก่อนที่จะให้มันทำงานกับระบบ production ที่มีข้อมูลหนาแน่น และเก็บ บันทึกสิ่งที่ agent ได้ทำไปจริง เพื่อให้ pull request ที่ไม่คาดคิดมีร่องรอยการตรวจสอบรองรับอยู่เสมอ
ข้อผิดพลาดที่คุณจะพบและสตริงที่ระบุข้อผิดพลาดเหล่านั้น
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หรือไม่ - Exporter ที่รายงานว่าสำเร็จในขณะที่เว็บแอปยังว่างเปล่า มักหมายความว่าข้อมูลถูกส่งตรงไปยัง collector ที่พอร์ต 4318 ซึ่งข้ามขั้นตอนการประทับตราข้อมูลของโปรเจกต์ที่ proxy ทำไว้
- Connection refused ที่พอร์ต 4101 ในการติดตั้งแบบ production หมายความว่า proxy ได้ถอยกลับไปใช้
PORT=4000ให้กำหนดค่าPORTลงใน unit file ให้ชัดเจน docker compose psที่แสดง0.0.0.0:8123หมายความว่าการผูกค่า loopback ของคุณไม่มีผล ให้รันdocker compose configแล้วอ่านค่าพอร์ตที่ถูก resolve ออกมา
Flawless, HyperProbe และตำแหน่งของ Superlog
หมวดหมู่นี้ยังถือว่าใหม่ และเครื่องมือแต่ละตัวมีแนวทางที่แตกต่างกันในเรื่องขอบเขตการเข้าถึงของ agent ตัว Flawless เป็นเครื่องมือ AI SRE (site reliability engineering) แบบโอเพนซอร์สที่มุ่งเน้นการใช้งานบน Kubernetes โดยใช้วิธีอ่านข้อมูลจาก stack ของ Prometheus, Loki และ Grafana ที่มีอยู่เดิม แทนที่จะเป็นเจ้าของ pipeline เอง ส่วน HyperProbe เลือกแนวทางที่ตรงกันข้าม โดยเป็นผลิตภัณฑ์แบบ hosted ซึ่งเป็นซอฟต์แวร์ปิด (closed source) ณ เดือนสิงหาคม 2026 โดยจะติดตั้ง probe แบบอ่านอย่างเดียว (read only) ไว้ภายใน process ที่กำลังทำงานอยู่เพื่อดักจับสถานะของตัวแปร และส่งข้อมูลสถานะนั้นไปยังผู้ช่วยผ่านโปรโตคอล MCP (model context protocol)
Superlog มีตำแหน่งอยู่กึ่งกลางระหว่างเครื่องมือทั้งสองตัวนี้ โดยเป็นเจ้าของ pipeline แบบ end to end ตั้งแต่การรับข้อมูลผ่าน OTLP ไปจนถึงการจัดเก็บใน ClickHouse และวาง agent ไว้ในขั้นตอนการคัดกรอง (triage) แทนที่จะเป็นขั้นตอนการแก้ไข การออกแบบเช่นนี้เองที่ทำให้การ self-host Superlog เป็นการตัดสินใจเชิงโครงสร้างพื้นฐาน ไม่ใช่แค่การรัน container แล้วปล่อยทิ้งไว้ เมื่อคุณรัน Superlog เท่ากับว่าคุณกำลังรัน column store ซึ่งจำเป็นต้องได้รับการดูแลเช่นเดียวกับฐานข้อมูลอื่นๆ ที่คุณเป็นเจ้าของ
FAQ
Superlog ที่โฮสต์เองต้องใช้ RAM เท่าไร?
ควรวางแผนใช้ RAM 8 GB, 4 vCPU และพื้นที่ดิสก์ 40 GB สำหรับโหนดเดี่ยวที่มีปริมาณการนำเข้าข้อมูลต่ำ สแต็กประกอบด้วย Postgres, ClickHouse, OpenTelemetry collector และ Node process อีก 4 รายการ ซึ่ง ClickHouse ต้องการพื้นที่หน่วยความจำสำรอง VPS ขนาด 1 GB หรือ 2 GB ไม่เพียงพอ เนื่องจาก pnpm install เพียงอย่างเดียวก็ใช้ทรัพยากรสูง และ ClickHouse จะถูก kernel สั่ง kill ด้วย OOM killer หากมีโหลดใช้งาน ให้วัดค่าด้วยตนเองโดยใช้ docker stats --no-stream และ free -m แทนการเชื่อตัวเลขที่ประกาศไว้ รวมถึงตัวเลขนี้ด้วย
ฉันควรชี้ OTLP exporter ไปที่พอร์ตใด?
ให้ชี้ไปที่ Superlog intake proxy ซึ่ง README ระบุไว้ที่พอร์ต http://localhost:4101 โดย proxy นี้ให้บริการ /v1/traces, /v1/logs และ /v1/metrics และจะตรวจสอบสิทธิ์ด้วย ingest key ของโปรเจกต์คุณที่ดึงมาจาก header x-api-key หรือ header authorization: bearer ส่วนพอร์ต 4318 คือ OpenTelemetry collector ที่อยู่เบื้องหลัง หากส่งข้อมูลไปที่นั่นโดยตรงจะเป็นการข้าม proxy ซึ่งเป็นส่วนประกอบที่ทำหน้าที่ระบุ project id ลงในข้อมูลของคุณ Proxy จะย้อนกลับไปใช้พอร์ต 4000 หากไม่ได้ตั้งค่า PORT ไว้ ดังนั้นให้รันคำสั่ง ss -lntp เพื่อตรวจสอบว่ามีการ bind พอร์ตใดก่อนที่จะสรุปว่าเป็น 4101
Superlog สามารถแทนที่ Uptime Kuma หรือ Zabbix ได้หรือไม่?
ไม่ได้ Uptime Kuma ทำหน้าที่ตรวจสอบว่า endpoint ตอบสนองจากภายนอกเครือข่ายหรือไม่ ส่วน Zabbix ทำหน้าที่เฝ้าระวัง metric ของโฮสต์และบริการตามเกณฑ์ที่คุณกำหนด Superlog ทำหน้าที่ประมวลผล trace, log และ metric ที่แอปพลิเคชันของคุณส่งออกมา และจัดกลุ่มความล้มเหลวที่เกิดขึ้นซ้ำๆ ให้เป็น incident ควรใช้งาน uptime probe จากภายนอกควบคู่ไปด้วย เพราะ probe ที่ทำงานจากที่อื่นจะยังคงรายงานผลได้หากเซิร์ฟเวอร์ที่เก็บ telemetry pipeline ของคุณเกิดล่มขึ้นมา
Superlog agent สามารถเปลี่ยนแปลงระบบ production ของฉันได้หรือไม่?
ทำได้เฉพาะผ่านสิทธิ์ที่คุณอนุญาตเท่านั้น ผลลัพธ์ที่ได้คือการตรวจสอบและข้อเสนอแนะการเปลี่ยนแปลงเพื่อให้มนุษย์ตรวจสอบอีกครั้ง ในช่วงแรกให้ตั้งค่า GitHub App เป็นแบบอ่านอย่างเดียว (read scopes) สำหรับ pull request และจำกัดสิทธิ์ credential ของ worker ให้เป็นแบบอ่านเท่านั้น การให้สิทธิ์เขียน (write access) แก่ระบบ production ควรเป็นการตัดสินใจที่รอบคอบ เพราะ agent ที่สามารถรีสตาร์ทบริการได้นั้นมีความเสี่ยงสูงกว่า agent ที่ทำหน้าที่เพียงอ่าน telemetry และเขียน patch เพื่อรอการตรวจสอบ
ฉันควรล็อก commit หรือติดตาม branch main?
ควรล็อก commit เนื่องจากไม่มี release tag ใน repository ณ เดือนสิงหาคม 2026 ดังนั้น main จึงเป็นเป้าหมายเดียวที่มีการเปลี่ยนแปลงอยู่ตลอดและมีการ commit หลายครั้งต่อสัปดาห์ ให้บันทึก SHA ที่คุณทดสอบแล้ว deploy เวอร์ชันนั้น และอ่าน diff ก่อนที่จะอัปเดตเวอร์ชันถัดไป git log --oneline <old-sha>..main คือส่วนที่ใช้ตรวจสอบ และไฟล์ .env.example ของแต่ละแอปคือจุดแรกที่ควรตรวจสอบหาตัวแปรที่จำเป็นต้องใช้ใหม่หลังจากมีการอัปเดตเวอร์ชัน