DEV Community: Somprasong Damyos

แนะนำ Bash Command สำหรับ Developer มือใหม่

Somprasong Damyos — Mon, 21 Jul 2025 04:47:13 +0000

Originally published at https://somprasongd.work/blog/server/baisc-bash

แม้ว่า GUI จะช่วยให้การเขียนโค้ดง่ายขึ้น แต่เมื่อคุณเริ่มทำงานจริงโดยเฉพาะกับระบบ backend, deployment, หรือ CI/CD — การใช้ Terminal และ Bash Command กลายเป็นทักษะที่ขาดไม่ได้

บทความนี้ออกแบบมาสำหรับ developer มือใหม่ ที่ไม่คุ้นกับการใช้ command line โดยใช้โปรเจกต์ Go สมมติชื่อ myapp เป็นตัวอย่าง

รายชื่อคำสั่งที่ควรรู้จัก

พื้นฐานและจัดการไฟล์

pwd, ls, cd, touch, mkdir, rm, cat, less, head, tail, echo

ค้นหาและแก้ไข

grep, find, nano, vim

รันโปรเจกต์ / ดู process

go run, go build, ps, top, kill

จัดการ Git

git clone, git status, git log

ประมวลผลข้อความ

awk, sed, jq

การเรียก API และ Network เบื้องต้น

curl, ping, wget, netstat, lsof

จัดการ Environment Variable

export, .env, source, $VAR

เขียน Shell Script

#!/bin/bash, ตัวแปร, เงื่อนไข (if, loop)

สมมติฐาน: โปรเจกต์ Go ชื่อ `myapp`

git clone https://github.com/yourusername/myapp.git
cd myapp

1. พื้นฐานและจัดการไฟล์

`pwd` – แสดง path ปัจจุบัน

pwd

เช่น:

/Users/somprasong/projects/myapp

`ls` – แสดงรายการไฟล์

ls                        # แสดงรายการไฟล์และโฟลเดอร์ในไดเรกทอรีปัจจุบัน (แบบสั้น)
ls -lah                   # แสดงรายการไฟล์ทั้งหมด (รวมไฟล์ที่ขึ้นต้นด้วย .)
                          # -l : แสดงรายละเอียด เช่น permission, owner, size, date
                          # -a : แสดงไฟล์ทั้งหมด รวมถึงไฟล์ซ่อน (ที่ขึ้นต้นด้วย .)
                          # -h : แสดงขนาดไฟล์ให้อ่านง่าย (เช่น KB, MB)

`cd` – เปลี่ยนโฟลเดอร์

cd cmd         # เปลี่ยนไปยังโฟลเดอร์ย่อยชื่อ cmd (ภายใต้ไดเรกทอรีปัจจุบัน)

cd ..          # ย้อนกลับไปยังโฟลเดอร์แม่ (parent directory)

cd -           # กลับไปยังไดเรกทอรีก่อนหน้าที่เคยอยู่ (toggle ไป toggle มา)
               # ตัวอย่าง: อยู่ใน /project/cmd แล้ว cd .. ไป /project
               # หากรัน cd - จะกลับไป /project/cmd อีกครั้ง

`touch` – สร้างไฟล์เปล่า

touch config.yaml         # สร้างไฟล์เปล่าชื่อ config.yaml
                          # หากไฟล์นี้มีอยู่แล้ว จะไม่ทำอะไร (แต่จะอัปเดตเวลาการเข้าถึง)

`mkdir` – สร้างโฟลเดอร์

mkdir logs                   # สร้างโฟลเดอร์ชื่อ logs (ถ้ายังไม่มีอยู่)
mkdir -p logs/2025/july      # สร้างโฟลเดอร์ซ้อนกันหลายชั้นในครั้งเดียว
                             # -p คือให้สร้างโฟลเดอร์ parent (2025) โดยอัตโนมัติหากยังไม่มี

`rm` – ลบไฟล์หรือโฟลเดอร์

rm config.yaml          # ลบไฟล์ชื่อ config.yaml (เฉพาะไฟล์เดียว)
rm -rf logs/            # ลบโฟลเดอร์ logs และทุกไฟล์/โฟลเดอร์ย่อยภายใน
                        # -r คือ recursive (ลบทั้งโฟลเดอร์)
                        # -f คือ force (ไม่ถามยืนยัน)

คำสั่ง rm -rf ต้องใช้อย่างระมัดระวัง เพราะจะลบทุกอย่างโดยไม่ถาม

2. คำสั่งอ่าน / ค้น / แก้ไขไฟล์

`cat` – อ่านไฟล์ทั้งหมด

cat README.md

`less` – อ่านไฟล์แบบ scroll

less README.md

กด q เพื่อออก

`head` และ `tail` – ดูต้นหรือท้ายไฟล์

head main.go        # 10 บรรทัดแรก
tail main.go        # 10 บรรทัดสุดท้าย

`echo` – แสดงข้อความ / ตัวแปร

echo "Hello, Go Developer"         # แสดงข้อความ
echo $HOME                         # แสดงค่าตัวแปร environment
echo "Build status: $STATUS"       # แสดงค่าตัวแปรที่เรากำหนดเอง

บันทึกค่าไปไฟล์

echo "PORT=8080" > .env            # สร้างไฟล์ .env พร้อมกำหนดค่า
echo "DEBUG=true" >> .env          # เพิ่มบรรทัดใหม่ต่อท้าย

3. การค้นหาไฟล์ / ข้อความ

`grep` – ค้นหาคำในไฟล์

grep "func main" main.go
# ค้นหาข้อความ "func main" ในไฟล์ main.go
# ใช้เพื่อหา function entry point ในภาษา Go

grep -i "http" *.go
# ค้นคำว่า "http" (ไม่สนว่าเป็นตัวพิมพ์ใหญ่หรือเล็ก) ในทุกไฟล์ .go
# มีประโยชน์เวลาอยากหาว่าไฟล์ไหนเรียกใช้งาน HTTP client หรือ HTTP handler

`find` – ค้นหาไฟล์

find . -name "*.go"
# ค้นหาไฟล์ทั้งหมดที่ลงท้ายด้วย .go จาก path ปัจจุบันและทุกโฟลเดอร์ย่อย
# ใช้แทนการ grep ทั้ง project หรือเตรียมทำ build/check ทั่วโปรเจกต์

find . -type f -name "*.yaml"
# ค้นหาไฟล์ (`-type f`) ที่ชื่อจบด้วย .yaml เท่านั้น
# เหมาะสำหรับหา config ที่เก็บในหลายๆ โฟลเดอร์ เช่น `config/dev.yaml`, `config/test/app.yaml`

4. แก้ไขไฟล์จาก terminal

`nano` – editor แบบง่าย

nano config.yaml

เปิดไฟล์ config.yaml ขึ้นมาแก้ไขด้วย editor nano ซึ่งใช้งานง่าย เหมาะสำหรับมือใหม่

วิธีบันทึกและออกจาก nano:

กด Ctrl + O เพื่อบันทึกไฟล์ (O = Output)
- กด Enter ยืนยันชื่อไฟล์
กด Ctrl + X เพื่อออกจาก nano (X = Exit)

`vim` – editor แบบมืออาชีพ

vim main.go

เปิดไฟล์ main.go ด้วย vim ซึ่งเป็น editor ทรงพลังและเร็วมาก เหมาะกับผู้ที่ใช้ terminal เป็นประจำ

โหมดพื้นฐานใน vim:

Normal mode – สำหรับสั่งงาน (เปิดโปรแกรมจะเริ่มที่โหมดนี้)
Insert mode – สำหรับพิมพ์ข้อความ (i เพื่อเข้า insert)
Command mode – สำหรับรันคำสั่ง (: เพื่อเข้า)

วิธีบันทึกและออกจาก vim:

กด Esc เพื่อออกจากโหมด insert (กลับไปที่ normal mode)
พิมพ์ :w แล้วกด Enter → บันทึกไฟล์ (write)
พิมพ์ :q แล้วกด Enter → ออกจาก vim (quit)
หรือใช้รวมกัน :wq → บันทึกและออก
ถ้าไม่อยากบันทึกการเปลี่ยนแปลง: พิมพ์ :q! → ออกโดยไม่บันทึก

ถ้าคุณเพิ่งเริ่มใช้ terminal แนะนำเริ่มจาก nano ก่อน แล้วค่อยเรียนรู้ vim เมื่อเริ่มคุ้นเคยมากขึ้น

5. รันโปรเจกต์ Go และจัดการ process

`go run` – รันโปรแกรม

go run main.go

`go build` – คอมไพล์แอป

go build -o myapp          # คอมไพล์ไฟล์ Go ทั้งโปรเจกต์เป็นไฟล์ไบนารีชื่อ myapp
                          # -o ระบุชื่อไฟล์เอาต์พุตเอง (output)

./myapp                    # รันไฟล์ไบนารี myapp ที่เพิ่งคอมไพล์ออกมา

`ps`, `top`, `kill` – ดูและจัดการ process

ps aux | grep myapp
# ดูรายชื่อ process ทั้งหมดในระบบ (ps aux)
# และกรองแสดงเฉพาะบรรทัดที่มีคำว่า "myapp"
# เพื่อเช็คว่าโปรแกรมชื่อ myapp กำลังรันอยู่หรือไม่ พร้อมแสดง PID (Process ID)

top
# แสดงสถานะ process แบบ real-time
# แสดงการใช้งาน CPU, Memory และ process ที่กำลังทำงานมากที่สุด
# กด 'q' เพื่อออกจากหน้าจอ top

kill -9 <pid>
# สั่งให้ระบบหยุด process โดยใช้ PID ที่ต้องการ
# -9 คือส่งสัญญาณ SIGKILL เพื่อบังคับหยุด proce

6. ใช้ Git เบื้องต้น

git status
# แสดงสถานะปัจจุบันของ repository
# แจ้งไฟล์ที่มีการเปลี่ยนแปลง ยังไม่ได้ commit หรือไฟล์ที่ยังไม่ถูก track

git add <file>
# เพิ่มไฟล์เข้าสู่ staging area เพื่อเตรียม commit
# เช่น git add main.go

git commit -m "ข้อความบรรยาย"
# บันทึก snapshot ของไฟล์ที่อยู่ใน staging area พร้อมข้อความอธิบาย

git log --oneline
# แสดงประวัติ commit แบบย่อ สั้นๆ เหมาะสำหรับดูภาพรวม

git branch
# แสดงรายการสาขา (branches) ใน repository ปัจจุบัน

git checkout <branch-name>
# สลับไปยัง branch ที่ระบุ

git pull
# ดึงการเปลี่ยนแปลงล่าสุดจาก remote repository มารวมกับ branch ปัจจุบัน

git push
# ส่ง commit ที่ทำไปยัง remote repository

git clone <url>
# คัดลอก (clone) repository จาก remote มายังเครื่องเรา

7. การจัดการ Environment Variables

`export` – กำหนดตัวแปรใน session

export PORT=8080
# กำหนดตัวแปร PORT ให้มีค่าเป็น 8080 และ export ไปยัง environment
# ทำให้โปรแกรมหรือ shell อื่นสามารถเข้าถึงค่าตัวแปรนี้ได้

export DEBUG=true
# กำหนดตัวแปร DEBUG ให้มีค่า true

เรียกใช้ตัวแปร

echo $PORT
# แสดงค่าของตัวแปร PORT
# ผลลัพธ์: 8080

การโหลดค่าตัวแปรจากไฟล์ `.env`

source .env
# อ่านและโหลดค่าตัวแปรจากไฟล์ .env เข้าสู่ environment
# ไฟล์ .env มักใช้เก็บค่าคอนฟิก เช่น PORT=3000, DB_URL=...

หมายเหตุ: ไฟล์ .env ควรอยู่ในรูปแบบ KEY=value ต่อบรรทัด เช่น

PORT=3000
DEBUG=false

ใช้ตัวแปรร่วมกับคำสั่งอื่น

go run main.go
# ใช้งานโปรแกรม Go โดยอ้างอิงค่าจาก $PORT หรือ $DEBUG ภายในโค้ดได้
# เช่น os.Getenv("PORT") ในภาษา Go

ลบตัวแปรออกจาก environment

unset PORT
# ลบตัวแปร PORT ออกจาก environment

การใช้ environment variables เป็นเรื่องพื้นฐานที่สำคัญมากในงาน dev เพราะช่วยให้แยก config ออกจาก code และควบคุมการทำงานได้ง่ายในแต่ละ environment (dev, staging, prod)

8. คำสั่ง Network ที่ควรรู้

`ping` – ตรวจสอบว่า host online หรือไม่

ping google.com
# ส่ง ICMP request ไปยัง google.com แบบไม่จำกัดจำนวนครั้ง (ต้องกด Ctrl+C เพื่อหยุดเอง)

ตัวเลือก (`option`) ที่นิยมใช้บ่อย

ส่งจำนวนจำกัด (`c`)

ping -c 4 google.com
# ส่ง ping ไปยัง google.com จำนวน 4 ครั้ง แล้วหยุดอัตโนมัติ

กำหนดเวลาระหว่างการ ping (`i`)

ping -i 0.5 google.com
# ส่ง ping ทุก ๆ 0.5 วินาที (ค่า default คือ 1 วินาที)

แสดงเวลารวม (`D`)

ping -D -c 2 google.com
# แสดง timestamp ของแต่ละ reply (ใช้ดู latency แบบมีเวลาประกอบ)

ตรวจสอบด้วย IP โดยตรง

ping 8.8.8.8
# ใช้ ping ด้วย IP โดยไม่ผ่าน DNS lookup

ใช้ IPv6 (`6`)

ping -6 google.com
# ใช้ IPv6 แทน IPv4 ในการ ping

หมายเหตุสำหรับการใช้ในระบบ Linux/macOS:

ping บน macOS มี option บางตัวที่ต่างจาก Linux เล็กน้อย เช่น t บน macOS คือจำนวนครั้ง แต่บน Linux คือ TTL (time to live)
ควรตรวจสอบ man ping เพื่อดู option ทั้งหมดในระบบของคุณ

`curl` – เรียก API

curl http://localhost:8080/health
# ส่ง HTTP GET request ไปยัง endpoint /health บน localhost port 8080

ตัวเลือก (`option`) ที่นิยมใช้บ่อย

แสดง header ของ response (`i`)

curl -i http://localhost:8080/health
# แสดง HTTP response header ด้วย

แสดงเฉพาะ HTTP status code (`o /dev/null -w "%{http_code}" -s`)

curl -o /dev/null -s -w "%{http_code}\n" http://localhost:8080/health
# ใช้ตรวจสอบว่า endpoint ตอบกลับด้วย status code อะไร (เช่น 200, 404)

ส่งข้อมูลแบบ JSON (`X POST -H "Content-Type: application/json" -d`)

curl -X POST http://localhost:8080/api \
  -H "Content-Type: application/json" \
  -d '{"username": "admin", "password": "1234"}'
# ส่ง HTTP POST request พร้อม payload JSON

อ่านค่า header ที่ส่งกลับมา (`I`)

curl -I http://localhost:8080/
# ส่ง HTTP HEAD request (ไม่โหลดเนื้อหา) เพื่อดู header เท่านั้น

เก็บผลลัพธ์ลงไฟล์ (`o`)

curl -o response.json http://localhost:8080/api/data
# บันทึกผลลัพธ์ของ HTTP response ลงไฟล์ response.json

ใช้กับไฟล์ `.env` ที่มี token หรือ env var

curl -H "Authorization: Bearer $API_TOKEN" http://localhost:8080/api
# ส่ง header พร้อม token จากตัวแปร environment

ใช้ `curl` ทดสอบ REST API เบื้องต้น

curl -X GET http://localhost:8080/users
curl -X POST http://localhost:8080/users -d '{"name": "go dev"}' -H "Content-Type: application/json"

คำสั่ง curl เหมาะสำหรับ:

ทดสอบ health check
ตรวจสอบ endpoint ในระบบ microservices
Debug API เบื้องต้น
ใช้ร่วมกับ jq เพื่อจัดรูปแบบ JSON

`wget` – ดาวน์โหลดไฟล์

wget http://example.com/file.txt
# ดาวน์โหลดไฟล์จาก URL ไปยังไฟล์ในเครื่อง

ตัวเลือก (`option`) ที่ใช้บ่อย

1. `O <filename>` – เปลี่ยนชื่อไฟล์ที่บันทึก

wget -O myfile.txt http://example.com/file.txt
# ดาวน์โหลดแล้วเซฟเป็นชื่อ myfile.txt

2. `c` – ดาวน์โหลดต่อ (resume) หากไฟล์ยังไม่เสร็จ

wget -c http://example.com/largefile.zip
# หากหลุดระหว่างโหลด สามารถใช้ -c โหลดต่อจากจุดเดิมได้

3. `-limit-rate=200k` – จำกัดความเร็วในการดาวน์โหลด

wget --limit-rate=200k http://example.com/file.txt
# ดาวน์โหลดโดยจำกัดความเร็วที่ 200KB/s

4. `-no-check-certificate` – ข้ามการตรวจสอบ SSL (ใช้กับ HTTPS)

wget --no-check-certificate https://example.com/file.txt
# ใช้กรณี certificate ไม่ valid เช่น เซิร์ฟเวอร์ dev

5. `-user=<username> --password=<password>` – สำหรับเว็บไซต์ที่ต้อง login

wget --user=admin --password=secret http://example.com/protected.zip
# ใช้เมื่อจำเป็นต้องใส่ username/password

6. `r` – ดาวน์โหลดแบบ recursive (ทั้ง directory)

wget -r http://example.com/files/
# ดาวน์โหลดทั้ง directory และไฟล์ย่อยทั้งหมด

7. `-no-parent` – ไม่ขึ้นไปโหลด path ด้านบน

bash
Copy code
wget -r --no-parent http://example.com/files/
# ดาวน์โหลดเฉพาะไฟล์ภายใน path นั้น ไม่ย้อนกลับขึ้นไป directory ข้างบน

ตัวอย่างการใช้งานร่วมกัน

wget -c -O backup.zip http://example.com/backup.zip
# ดาวน์โหลดไฟล์ backup.zip และสามารถ resume ได้หากหลุด

`netstat` – ดูว่าโปรแกรมไหนเปิดพอร์ต

netstat -tulnp

ความหมายของแต่ละ option:

t = แสดงเฉพาะ TCP
u = แสดงเฉพาะ UDP
l = แสดงเฉพาะที่อยู่ในสถานะ “listening” (รอฟังการเชื่อมต่อ)
n = แสดง IP และพอร์ตเป็นตัวเลข (ไม่แปลงเป็นชื่อ)
p = แสดงโปรเซส (PID) และชื่อโปรแกรมที่ใช้พอร์ตนั้น (ต้องใช้ sudo ในบางระบบ)

ตัวอย่างผลลัพธ์:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      1234/nginx
udp        0      0 0.0.0.0:123             0.0.0.0:*

`lsof` – ดูว่าใครใช้พอร์ต

lsof -i :8080  
# i :8080 หมายถึงให้แสดงเฉพาะโปรเซสที่เปิดใช้งานพอร์ต 8080

ตัวอย่างผลลัพธ์:

COMMAND  PID  USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
myapp    1234 user   10u  IPv4  12345      0t0  TCP *:http-alt (LISTEN)

คุณสามารถดูว่าแอปอะไรใช้งานพอร์ต และจะนำ PID (1234 ในตัวอย่าง) ไปใช้กับ kill ได้เช่น

kill -9 1234

9. ประมวลผลข้อความ

`awk` – ดึง column จากข้อความ

awk '{print $1}' access.log     # ดึงข้อมูลคอลัมน์แรกจากไฟล์

# ดึงคอลัมน์ที่ 7 (เช่น URL ที่เรียก):
awk '{print $7}' access.log

# ดึงหลายคอลัมน์พร้อมกัน:
awk '{print $1, $7}' access.log

# ใช้กับ pipe (เช่น log จากคำสั่งอื่น):
cat access.log | awk '{print $1}'

ตัวอย่างเช่น

ไฟล์ access.log มีข้อมูล

192.168.1.1 - - [21/Jul/2025:12:00:00] "GET /index.html HTTP/1.1" 200 1234
127.0.0.1 - - [21/Jul/2025:12:01:00] "POST /login HTTP/1.1" 302 0

คำสั่ง awk '{print $1}' access.log จะได้ผลลัพธ์เป็น

192.168.1.1
127.0.0.1

`sed` – แก้ข้อความในไฟล์

sed 's/localhost/127.0.0.1/g' config.yaml

# แทนที่คำว่า localhost ด้วย 127.0.0.1
# 's/localhost/127.0.0.1/g' =
#   s = substitute (คำสั่งแทนที่)
#   localhost = คำที่ต้องการค้นหา
#   127.0.0.1 = คำที่ใช้แทน
#   g = global คือ แทนที่ทุกจุดที่เจอในแต่ละบรรทัด

# config.yaml = ชื่อไฟล์ต้นทาง

คำสั่งนี้จะแสดงผลลัพธ์ใหม่ที่มีการแทนที่ localhost ด้วย 127.0.0.1 ทุกแห่งในแต่ละบรรทัด แต่ยังไม่บันทึกลงไฟล์

ถ้าต้องการเขียนกลับลงไฟล์

ใช้ option -i เพื่อแก้ไขในไฟล์จริง:

sed -i 's/localhost/127.0.0.1/g' config.yaml

หมายเหตุ: บน macOS อาจต้องใช้ -i ''

sed -i '' 's/localhost/127.0.0.1/g' config.yaml

`jq` – แก้ไข JSON

curl -s http://localhost:8080/status | jq '.'

# jq '.'    แสดง JSON ทั้งก้อนแบบสวยงาม (pretty print)

# ตัวอย่างเพิ่มเติมของ jq
# jq '.status'  ดึงค่าจาก key status

# jq '.data.name'   ดึงค่าจาก nested key เช่น .data.name

# `jq '.items[].id'` ดึงค่าของฟิลด์ id จากทุก element ที่อยู่ใน array items ของ JSON

# jq '.users[] | select(.active == true)'
# .users[] วนลูปผ่านแต่ละ element ใน array ชื่อ users
# select(.active == true) กรอง (filter) เฉพาะ element ที่มี field active เท่ากับ true

10. เขียน Shell Script เบื้องต้น

ไฟล์: build.sh

#!/bin/bash

echo "Building myapp..."
go build -o myapp

if [ $? -eq 0 ]; then
  echo "✅ Build success"
else
  echo "❌ Build failed"
fi

ให้สิทธิ์รัน:

chmod +x build.sh
./build.sh

11. เสริม productivity

history                # ดูคำสั่งย้อนหลัง
!!                     # รันคำสั่งล่าสุด
alias gs="git status"  # สร้าง shortcut คำสั่ง

สรุป

Developer มือใหม่ไม่จำเป็นต้องจำคำสั่งทั้งหมดในคราวเดียว แต่ควรเริ่มจากคำสั่งที่ ใช้กับงานจริงในโปรเจกต์ตัวเอง เช่น แก้ config, รันแอป, แสดงค่าตัวแปร, แก้ .env, หรือดู log จาก production

เมื่อคุ้นมือแล้ว คุณจะเริ่มใช้ bash เป็นเครื่องมือสร้างระบบ build, deploy, หรือ monitoring script ที่ยืดหยุ่นและควบคุมได้เอง 100%

Observability Series ตอนที่ 4 — เก็บ Metrics ด้วย OpenTelemetry + OTLP Metric (gRPC)

Somprasong Damyos — Wed, 09 Jul 2025 07:47:03 +0000

ตอนนี้เราจะเริ่ม เก็บ Metrics ให้เห็นใน Grafana โดยใช้ Prometheus

Originally published at https://somprasongd.work/blog/go/observability-4

สิ่งที่จะได้ในตอนนี้

เก็บ Metrics ด้วย OpenTelemetry Metrics API
ใช้ OTLP gRPC Exporter
ให้ OTel Collector รับ OTLP Metric → แปลงเป็น Prometheus Format
ใช้ Middleware วัด Request Count + Latency อัตโนมัติ
Prometheus Scrape จาก OTel Collector
ดู Metrics ใน Grafana

ทำไมใช้ OTLP ดีกว่า Prometheus Exporter ตรง ๆ ?

แอปไม่ต้องเปิดพอร์ต /metrics เอง
ใช้ Protocol มาตรฐานเดียวกับ Traces (OTLP gRPC)
OTel Collector ทำหน้าที่ Gateway รวม Traces, Metrics
เปลี่ยน Destination ได้ง่าย เช่น ส่งไป Prometheus, Mimir หรือ Cloud

Architecture

[Fiber App]
   |
[OTLP Metric gRPC Exporter]
   |
[OTel Collector]
   |
[Prometheus]
   |
[Grafana]

โครงสร้างโปรเจ็กต์

โค้ดตั้งต้น: https://github.com/somprasongd/observability-demo-go/tree/feat/trace

project-root/
│
├── cmd/
│   └── main.go               # จุดเริ่มโปรแกรม, bootstrap Fiber, DI, middleware
│
├── internal/
│   ├── handler/
│   │   └── user_handler.go   # HTTP Handlers (Fiber routes)
│   │
│   ├── service/
│   │   └── user_service.go   # Business Logic Layer
│   │
│   └── repository/
│       └── user_repo.go      # Data Access Layer
│
├── pkg/
│   ├── ctxkey/
│   │   └── ctxkey.go         # Shared Lib: เก็บ context key
│   │
│   ├── logger/
│   │   └── logger.go         # Shared Lib: Logger setup (Zap)
│   │
│   ├── middleware/           # Shared Lib: Middleware
│   │    └── observability_middleware.go
│   │
│   └── observability/
│       └── observability.go  # Shared Lib: Trace + Metric
│
├── go.mod
└── go.sum

ขั้นตอน

1. ติดตั้ง Packages

go get go.opentelemetry.io/otel
go get go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc
go get go.opentelemetry.io/otel/sdk/metric
go get go.opentelemetry.io/otel/metric
go get go.opentelemetry.io/contrib/instrumentation/runtime

2. สร้าง Metrics Provider (OTLP gRPC)

/pkg/observability/observability.go

package observability

import (
    "context"
    "log"
    "time"

    "go.opentelemetry.io/otel"
    "go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc"
    "go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc"

    sdkmetric "go.opentelemetry.io/otel/sdk/metric"
    "go.opentelemetry.io/otel/sdk/resource"
    sdktrace "go.opentelemetry.io/otel/sdk/trace"
    semconv "go.opentelemetry.io/otel/semconv/v1.21.0"
)

type OTel struct {
    TracerProvider *sdktrace.TracerProvider
    MeterProvider  *sdkmetric.MeterProvider // เพิ่ม metric
}

func (c *OTel) Shutdown(ctx context.Context) {
    ctx, cancel := context.WithTimeout(ctx, 5*time.Second)
    defer cancel()

    if err := c.TracerProvider.Shutdown(ctx); err != nil {
        log.Println("failed to shutdown tracer:", err)
    }

    if err := c.MeterProvider.Shutdown(ctx); err != nil { // เพิ่ม metric
        log.Println("failed to shutdown meter:", err)
    }
}

func NewOTel(ctx context.Context, collectorAddr, serviceName string) (*OTel, error) {
    // ----- Resource -----
    res, err := resource.New(ctx,
        resource.WithAttributes(
            semconv.ServiceName(serviceName),
        ),
    )
    if err != nil {
        return nil, err
    }

    // ----- Tracer -----
    traceExp, err := otlptracegrpc.New(ctx,
        otlptracegrpc.WithEndpoint(collectorAddr),
        otlptracegrpc.WithInsecure(),
    )
    if err != nil {
        return nil, err
    }

    tp := sdktrace.NewTracerProvider(
        sdktrace.WithBatcher(traceExp),
        sdktrace.WithResource(res),
    )
    otel.SetTracerProvider(tp)

    // ----- Meter -----
    metricExp, err := otlpmetricgrpc.New(ctx,
        otlpmetricgrpc.WithEndpoint(collectorAddr),
        otlpmetricgrpc.WithInsecure(),
    )
    if err != nil {
        return nil, err
    }

    mp := sdkmetric.NewMeterProvider(
        sdkmetric.WithReader(
            sdkmetric.NewPeriodicReader(metricExp),
        ),
        sdkmetric.WithResource(res),
    )
    otel.SetMeterProvider(mp)

    return &OTel{
        TracerProvider: tp,
        MeterProvider:  mp,
    }, nil
}

3. Middleware วัด Metrics ทุก Request

ให้รับ meter เข้ามาเพื่อวัด Metrics ทุก Request

http_requests_total → Request Count
http_request_duration_seconds → Latency Histogram
http_requests_inflight → Inflight Count
http_request_size_bytes → Request Size Histogram
http_response_size_bytes → Response Size Histogram
http_requests_error_total → Errors Counter

/internal/middleware/obervability_middleware.go

package middleware

import (
    "context"
    "demo/pkg/ctxkey"
    "fmt"
    "runtime/debug"
    "strings"
    "time"

    "github.com/gofiber/fiber/v2"
    "github.com/google/uuid"
    "go.opentelemetry.io/otel/attribute"
    "go.opentelemetry.io/otel/metric"
    "go.opentelemetry.io/otel/trace"
    "go.uber.org/zap"
)

func NewObservabilityMiddleware(
    baseLogger *zap.Logger,
    tracer trace.Tracer,
    meter metric.Meter,
) fiber.Handler {

    // ----- OTel Instruments -----
    requestCounter, _ := meter.Int64Counter("http_requests_total")
    requestDuration, _ := meter.Float64Histogram("http_request_duration_ms")
    inflightCounter, _ := meter.Int64UpDownCounter("http_requests_inflight")
    requestSize, _ := meter.Float64Histogram("http_request_size_bytes")
    responseSize, _ := meter.Float64Histogram("http_response_size_bytes")
    errorCounter, _ := meter.Int64Counter("http_requests_error_total")

    // Skip Paths ที่ไม่ต้องการ trace
    skipPaths := map[string]bool{
        "/health":  true,
        "/metrics": true,
    }
    // กรณีมีการ serve SPA
    staticPrefixes := []string{"/static", "/assets", "/public", "/favicon", "/robots.txt"}

    return func(c *fiber.Ctx) error {
        start := time.Now()
        method := c.Method()
        path := c.Path()

        // ตรวจสอบ path ที่เรียกมา
        skip := skipPaths[path]
        for _, prefix := range staticPrefixes {
            if strings.HasPrefix(path, prefix) {
                skip = true
                break
            }
        }

        var (
            ctx     context.Context
            span    trace.Span
            traceID string
        )

        if skip {
            ctx = c.Context()
        } else {
            ctx, span = tracer.Start(c.Context(), "HTTP "+c.Method()+" "+path)
            defer span.End()
            traceID = span.SpanContext().TraceID().String()
        }

        requestID := c.Get("X-Request-ID")
        if requestID == "" {
            requestID = uuid.New().String()
        }

        // Bind Request ID ลง Response Header
        c.Set("X-Request-ID", requestID)

        // สร้าง child logger
        reqLogger := baseLogger.With(
            zap.String("trace_id", traceID), // เพิ่ม trace_id เพื่อเชื่อมโยง log กับ trace
            zap.String("request_id", requestID),
        )

        // สร้าง Context ใหม่ที่มี logger
        ctx = context.WithValue(ctx, ctxkey.Logger{}, reqLogger)
        // แทน Context เดิม
        c.SetUserContext(ctx)

        // ----- Record Inflight -----
        if !skip {
            inflightCounter.Add(ctx, 1)
        }

        err := c.Next()

        duration := time.Since(start).Milliseconds()
        status := c.Response().StatusCode()

        if !skip {
            labels := []attribute.KeyValue{
                attribute.String("method", method),
                attribute.String("path", path),
                attribute.Int("status", status),
            }

            requestCounter.Add(ctx, 1, metric.WithAttributes(labels...))
            requestDuration.Record(ctx, float64(duration), metric.WithAttributes(labels...))
            inflightCounter.Add(ctx, -1)

            // Request Size (Header Content-Length)
            if reqSize := c.Request().Header.ContentLength(); reqSize > 0 {
                requestSize.Record(ctx, float64(reqSize), metric.WithAttributes(labels...))
            }

            // Response Size (Body Length)
            if resSize := len(c.Response().Body()); resSize > 0 {
                responseSize.Record(ctx, float64(resSize), metric.WithAttributes(labels...))
            }

            if status >= 400 {
                errorCounter.Add(ctx, 1, metric.WithAttributes(labels...))
            }
        }

        // log unhandle error
        if err != nil {
            reqLogger.Error("an error occurred",
                zap.Any("error", err),
                zap.ByteString("stack", debug.Stack()),
            )
        }

        msg := fmt.Sprintf("%d - %s %s", status, method, path)
        reqLogger.Info(msg,
            zap.Int("status", status),
            zap.Int64("duration_ms", duration),
        )

        return err
    }
}

4. แก้ไข Main

/cmd/main.go

package main

import (
    "context"
    "os"
    "time"

    "go.opentelemetry.io/contrib/instrumentation/runtime"

    "github.com/gofiber/fiber/v2"
    "github.com/gofiber/fiber/v2/middleware/cors"
    "github.com/gofiber/fiber/v2/middleware/recover"

    "demo/internal/handler"
    "demo/internal/repository"
    "demo/internal/service"
    "demo/pkg/logger"
    "demo/pkg/middleware"
    "demo/pkg/observability"
)

func main() {
    // Init Logger
    logger.Init()

    // Init Observability via Opentelmetry
    otel, err := observability.NewOTel(
        context.Background(),
        os.Getenv("OTEL_EXPORTER_OTLP_ENDPOINT"),
        "demo-app")
    if err != nil {
        logger.Default().Fatal(err.Error())
    }
    defer otel.Shutdown(context.Background())

    // เก็บ Process Metrics: สร้าง Runtime Instrument → ผูกกับ MeterProvider
    runtime.Start(
        runtime.WithMinimumReadMemStatsInterval(time.Second * 10),
    )

    // Init Fiber
    app := fiber.New()

    // Middlewares
    app.Use(middleware.NewObservabilityMiddleware(
        logger.Default(),
        otel.TracerProvider.Tracer("demo-app"),
        otel.MeterProvider.Meter("demo-app"), // เพิ่มส่ง meter
    ))
    app.Use(cors.New())
    app.Use(recover.New())

    // Init DI
    repo := repository.NewUserRepository()
    svc := service.NewUserService(repo)
    h := handler.NewUserHandler(svc)

    // Routes
    app.Get("/users/:id", h.GetUser)

    // Start
    app.Listen(":8080")
}

runtime.WithMinimumReadMemStatsInterval() ใช้สำหรับเก็บ runtime metrics (Goroutines Count, GC Pauses, Heap Usage)

5. ส่ง Metric ไป Prometheus

ส่งผ่าน OTel Pipeline → Collector → Prometheus

สร้าง config ของ Prometheus prometheus.yml ****

  global:
    scrape_interval: 5s

  scrape_configs:
    - job_name: 'otel-collector'
      static_configs:
        - targets: ['otel-collector:9464']

แก้ config ของ exporters เพิ่ม Prometheus otel-collector-config.yaml

  receivers:
    otlp:
      protocols:
        grpc:
          endpoint: 0.0.0.0:4317
        http:
          endpoint: 0.0.0.0:4318

  exporters:
    otlp/tempo:
      endpoint: tempo:4317
      tls:
        insecure: true
    prometheus:
      endpoint: '0.0.0.0:9464'

  processors:
    batch:

  service:
    pipelines:
      traces:
        receivers: [otlp]
        processors: [batch]
        exporters: [otlp/tempo]
      metrics:
        receivers: [otlp]
        processors: [batch]
        exporters: [prometheus]

เพิ่ม service prometheus docker-compose.yml

  services:
    app:
      build: .
      container_name: backend-app
      ports:
        - '8080:8080'
      environment:
        - OTEL_EXPORTER_OTLP_ENDPOINT=otel-collector:4317
      depends_on:
        - otel-collector
      logging:
        driver: 'json-file'
        options:
          max-size: '10m'
          max-file: '5'
      # เพิ่ม label สำหรับ filtering logs
      labels:
        logging: 'promtail'
        logging_jobname: 'containerlogs'

    loki:
      image: grafana/loki:latest
      container_name: loki
      command: -config.file=/etc/loki/local-config.yaml
      volumes:
        - loki_data:/loki
      # ports:
      #   - "3100:3100"

    promtail:
      image: grafana/promtail:latest
      container_name: promtail
      volumes:
        - ./promtail-config.yml:/etc/promtail/promtail-config.yml
        - /var/lib/docker/containers:/var/lib/docker/containers:ro
        - /var/run/docker.sock:/var/run/docker.sock:ro
      command: -config.file=/etc/promtail/promtail-config.yml
      depends_on:
        - loki

    otel-collector:
      image: otel/opentelemetry-collector:latest
      container_name: otel-collector
      volumes:
        - ./otel-collector-config.yaml:/etc/otelcol/config.yaml
      command: ['--config=/etc/otelcol/config.yaml']
      ports:
        - '4317:4317' # gRPC
        - '4318:4318' # HTTP
        - '9464:9464'
      depends_on:
        - tempo

    tempo:
      image: grafana/tempo:latest
      container_name: tempo
      volumes:
        - ./tempo.yaml:/etc/tempo.yaml
      command: ['-config.file=/etc/tempo.yaml']
      # ports:
      #   - "3200" # tempo
      #   - "4317" # otlp grpc

    prometheus:
      image: prom/prometheus:latest
      container_name: prometheus
      command: ['--config.file=/etc/prometheus/prometheus.yml']
      volumes:
        - ./prometheus.yml:/etc/prometheus/prometheus.yml
        - prometheus-data:/prometheus
      # ports:
      #   - "9090:9090"

    grafana:
      image: grafana/grafana:latest
      container_name: grafana
      ports:
        - '3000:3000'
      environment:
        - GF_SECURITY_ADMIN_USER=admin
        - GF_SECURITY_ADMIN_PASSWORD=admin
      volumes:
        - grafana-data:/var/lib/grafana
      depends_on:
        - loki
        - tempo
        - prometheus

  volumes:
    loki_data:
    grafana-data:
    prometheus-data:

6. ดู Metric ใน Grafana

รัน App ด้วยคำสั่ง: docker compose up -d --build
ส่ง Request: curl http://localhost:8080/users/1
เปิด Grafana: http://localhost:3000 (User: admin, Password: admin)
Data Source → Add data source → Prometheus → URL: http://prometheus:9090 → Save & test
Explore → Prometheus → Metric: http_request_total → คุณจะเห็น Graph
หรือดูที่ Drilldiwn → Metrics

ผลลัพธ์

ทุก Request มี Metric Count + Duration และอื่นๆ
มีแสดง Go Process Metrics จาก Runtime
ใช้ Protocol มาตรฐาน OTLP → ต่อเข้ากับ OTel Collector
Prometheus Scrape ผ่าน Collector → ไม่ต้อง expose /metrics เองที่ฝั่ง App
ต่อยอดรวม Traces, Logs, Metrics ผ่าน Collector จุดเดียว

จุดเด่นแนวทางนี้

ง่ายต่อการจัดการ: Export ผ่าน OTLP Protocol เดียว
ยืดหยุ่น: Collector เปลี่ยน Destination ได้ง่าย
มาตรฐานเดียวกับ Tracing → ระบบเดียวกันจัดการหมด

สรุป

Middleware เก็บ Request Metrics
Rumtime เก็บ Process Metrics
Export ผ่าน OTLP gRPC → Collector → Prometheus

Observability Series ตอนที่ 3 — Tracing เชื่อม Logger ด้วย OpenTelemetry + Tempo

Somprasong Damyos — Wed, 09 Jul 2025 07:45:37 +0000

ตอนนี้เราจะเริ่ม เก็บ Trace ให้เห็นใน Grafana โดยใช้ Tempo

Originally published at https://somprasongd.work/blog/go/observability-3

สิ่งที่จะได้เรียนรู้ในตอนนี้

เพิ่ม Distributed Tracing ด้วย OpenTelemetry (OTel)
เก็บ Trace เข้า Tempo
ผูก Trace กับ Log เดียวกัน (ใช้ TraceID เป็น Field ใน Log)
Logger ตัวเดียว (Zap) + Tracer ตัวเดียว ใช้ผ่าน Context
เชื่อม Trace และ Log ใน Grafana → Click จาก Trace ไป Log ได้

Architecture เดิม + Tracing

ใช้โครงสร้างเดียวกับตอนที่ 2

[Fiber Middleware] -> [Fiber Handler] -> [Service] -> [Repo]

เพิ่ม:

Middleware สร้าง Tracer ใส่ใน Context
ใช้ otel.Tracer เปิด Span ทุก Layer
Logger ใส่ trace_id เพื่อเชื่อมโยง log กับ trace

โครงสร้างโปรเจ็กต์

โค้ดตั้งต้น: https://github.com/somprasongd/observability-demo-go/tree/feat/log

project-root/
│
├── cmd/
│   └── main.go               # จุดเริ่มโปรแกรม, bootstrap Fiber, DI, middleware
│
├── internal/
│   ├── handler/
│   │   └── user_handler.go   # HTTP Handlers (Fiber routes)
│   │
│   ├── service/
│   │   └── user_service.go   # Business Logic Layer
│   │
│   └── repository/
│       └── user_repo.go      # Data Access Layer
│
├── pkg/
│   ├── ctxkey/
│   │   └── ctxkey.go         # Shared Lib: เก็บ context key
│   │
│   ├── logger/
│   │   └── logger.go         # Shared Lib: Logger setup (Zap)
│   │
│   ├── middleware/           # Shared Lib: Middleware
│   │    └── observability_middleware.go
│   │
│   └── observability/
│       └── observability.go  # Shared Lib: Trace
│
├── go.mod
└── go.sum

ขั้นตอน

1. ติดตั้ง Package Tracing

go get go.opentelemetry.io/otel
go get go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc
go get go.opentelemetry.io/otel/sdk/trace
go get go.opentelemetry.io/otel/trace

2. สร้าง Tracer Provider (OTLP gRPC)

/pkg/observability/observability.go

package observability

import (
    "context"
    "log"
    "time"

    "go.opentelemetry.io/otel"
    "go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc"

    "go.opentelemetry.io/otel/sdk/resource"
    sdktrace "go.opentelemetry.io/otel/sdk/trace"
    semconv "go.opentelemetry.io/otel/semconv/v1.21.0"
)

type OTel struct {
    TracerProvider *sdktrace.TracerProvider
}

func (c *OTel) Shutdown(ctx context.Context) {
    ctx, cancel := context.WithTimeout(ctx, 5*time.Second)
    defer cancel()

    if err := c.TracerProvider.Shutdown(ctx); err != nil {
        log.Println("failed to shutdown tracer:", err)
    }
}

func NewOTel(ctx context.Context, collectorAddr, serviceName string) (*OTel, error) {
    // ----- Resource -----
    res, err := resource.New(ctx,
        resource.WithAttributes(
            semconv.ServiceName(serviceName),
        ),
    )
    if err != nil {
        return nil, err
    }

    // ----- Tracer -----
    traceExp, err := otlptracegrpc.New(ctx,
        otlptracegrpc.WithEndpoint(collectorAddr),
        otlptracegrpc.WithInsecure(),
    )
    if err != nil {
        return nil, err
    }

    tp := sdktrace.NewTracerProvider(
        sdktrace.WithBatcher(traceExp),
        sdktrace.WithResource(res),
    )
    otel.SetTracerProvider(tp)

    return &OTel{
        TracerProvider: tp,
    }, nil
}

3. ปรับ Middleware

ให้รับ trace เข้ามาเพื่อสร้าง span ใหม่ของแต่ละ request

/internal/middleware/obervability_middleware.go

package middleware

import (
    "context"
    "demo/pkg/ctxkey"
    "fmt"
    "runtime/debug"
    "strings"
    "time"

    "github.com/gofiber/fiber/v2"
    "github.com/google/uuid"
    "go.opentelemetry.io/otel/trace"
    "go.uber.org/zap"
)

func NewObservabilityMiddleware(
    baseLogger *zap.Logger,
    tracer trace.Tracer,
) fiber.Handler {

    // Skip Paths ที่ไม่ต้องการ trace
    skipPaths := map[string]bool{
        "/health": true,
    }
    // กรณีมีการ serve SPA
    staticPrefixes := []string{"/static", "/assets", "/public", "/favicon", "/robots.txt"}

    return func(c *fiber.Ctx) error {
        start := time.Now()
        method := c.Method()
        path := c.Path()

        // ตรวจสอบ path ที่เรียกมา
        skip := skipPaths[path]
        for _, prefix := range staticPrefixes {
            if strings.HasPrefix(path, prefix) {
                skip = true
                break
            }
        }

        var (
            ctx     context.Context
            span    trace.Span
            traceID string
        )

        if skip {
            ctx = c.Context()
        } else {
            ctx, span = tracer.Start(c.Context(), "HTTP "+c.Method()+" "+path)
            defer span.End()
            traceID = span.SpanContext().TraceID().String()
        }

        requestID := c.Get("X-Request-ID")
        if requestID == "" {
            requestID = uuid.New().String()
        }

        // Bind Request ID ลง Response Header
        c.Set("X-Request-ID", requestID)

        // สร้าง child logger
        reqLogger := baseLogger.With(
            zap.String("trace_id", traceID), // เพิ่ม trace_id เพื่อเชื่อมโยง log กับ trace
            zap.String("request_id", requestID),
        )

        // สร้าง Context ใหม่ที่มี logger
        ctx = context.WithValue(ctx, ctxkey.Logger{}, reqLogger)
        // แทน Context เดิม
        c.SetUserContext(ctx)

        err := c.Next()

        duration := time.Since(start).Milliseconds()
        status := c.Response().StatusCode()

        // log unhandle error
        if err != nil {
            reqLogger.Error("an error occurred",
                zap.Any("error", err),
                zap.ByteString("stack", debug.Stack()),
            )
        }

        msg := fmt.Sprintf("%d - %s %s", status, method, path)
        reqLogger.Info(msg,
            zap.Int("status", status),
            zap.Int64("duration_ms", duration),
        )

        return err
    }
}

4. แก้ไข Main

/cmd/main.go

package main

import (
    "context"
    "os"

    "github.com/gofiber/fiber/v2"
    "github.com/gofiber/fiber/v2/middleware/cors"
    "github.com/gofiber/fiber/v2/middleware/recover"

    "demo/internal/handler"
    "demo/internal/repository"
    "demo/internal/service"
    "demo/pkg/logger"
    "demo/pkg/middleware"
    "demo/pkg/observability"
)

func main() {
    // Init Logger
    logger.Init()

    // Init Observability via Opentelmetry
    otel, err := observability.NewOTel(
        context.Background(),
        os.Getenv("OTEL_EXPORTER_OTLP_ENDPOINT"),
        "demo-app")
    if err != nil {
        logger.Default().Fatal(err.Error())
    }
    defer otel.Shutdown(context.Background())

    // Init Fiber
    app := fiber.New()

    // Middlewares
    app.Use(middleware.NewObservabilityMiddleware(
        logger.Default(),
        otel.TracerProvider.Tracer("demo-app"), // เพิ่มส่ง tracer
    ))
    app.Use(cors.New())
    app.Use(recover.New())

    // Init DI
    repo := repository.NewUserRepository()
    svc := service.NewUserService(repo)
    h := handler.NewUserHandler(svc)

    // Routes
    app.Get("/users/:id", h.GetUser)

    // Start
    app.Listen(":8080")
}

5. Handler Layer → เปิด Span ต่อ

/internal/handler/user_handler.go

package handler

import (
    "demo/internal/service"
    "demo/pkg/logger"

    "github.com/gofiber/fiber/v2"
    "go.opentelemetry.io/otel/trace"
    "go.uber.org/zap"
)

type UserHandler struct {
    svc *service.UserService
}

func NewUserHandler(svc *service.UserService) *UserHandler {
    return &UserHandler{svc: svc}
}

func (h *UserHandler) GetUser(c *fiber.Ctx) error {
    ctx := c.UserContext()
    logger := logger.FromContext(ctx)

    tracer := trace.SpanFromContext(ctx).TracerProvider().Tracer("handler")
    ctx, span := tracer.Start(ctx, "Handler:GetUser")
    defer span.End()

    logger.Info("Handler: GetUser called")

    id := c.Params("id")

    user, err := h.svc.GetUser(ctx, id)
    if err != nil {
        logger.Error("Handler: Failed to get user", zap.Error(err))
        return c.Status(500).SendString("Internal Server Error")
    }

    return c.JSON(user)
}

6. Service Layer → Span + Logger จาก Context

/internal/service/user_service.go

package service

import (
    "context"
    "demo/internal/repository"
    "demo/pkg/logger"

    "go.opentelemetry.io/otel/trace"
    "go.uber.org/zap"
)

type UserService struct {
    repo *repository.UserRepository
}

func NewUserService(repo *repository.UserRepository) *UserService {
    return &UserService{repo: repo}
}

func (s *UserService) GetUser(ctx context.Context, id string) (map[string]string, error) {
    logger := logger.FromContext(ctx)
    tracer := trace.SpanFromContext(ctx).TracerProvider().Tracer("service")
    ctx, span := tracer.Start(ctx, "Service:GetUser")
    defer span.End()

    logger.Info("Service: GetUser called", zap.String("id", id))

    return s.repo.FindUser(ctx, id)
}

7. Repository Layer → Span + Logger จาก Context

/internal/repository/user_repo.go

package repository

import (
    "context"
    "demo/pkg/logger"

    "go.opentelemetry.io/otel/trace"
    "go.uber.org/zap"
)

type UserRepository struct{}

func NewUserRepository() *UserRepository {
    return &UserRepository{}
}

func (r *UserRepository) FindUser(ctx context.Context, id string) (map[string]string, error) {
    logger := logger.FromContext(ctx)
    tracer := trace.SpanFromContext(ctx).TracerProvider().Tracer("repository")
    ctx, span := tracer.Start(ctx, "Repository:FindUser")
    defer span.End()

    logger.Info("Repository: FindUser called", zap.String("id", id))

    // Mock DB
    user := map[string]string{
        "id":   id,
        "name": "John Doe",
    }
    return user, nil
}

8. ส่ง Trace ไป Tempo

สร้าง config ของ tempo tempo.yaml ****

  auth_enabled: false

  stream_over_http_enabled: true
  server:
    http_listen_port: 3200
    log_level: info

  distributor:
    receivers:
      otlp:
        protocols:
          grpc:
            endpoint: 'tempo:4317'

  ingester:
    trace_idle_period: 10s
    max_block_duration: 5m

  compactor:
    compaction:
      block_retention: 1h

  storage:
    trace:
      backend: local
      local:
        path: /tmp/tempo/blocks
      wal:
        path: /tmp/tempo/wal

สร้าง config ของ exporters otel-collector-config.yaml

  receivers:
    otlp:
      protocols:
        grpc:
          endpoint: 0.0.0.0:4317
        http:
          endpoint: 0.0.0.0:4318

  exporters:
    otlp/tempo:
      endpoint: tempo:4317
      tls:
        insecure: true

  processors:
    batch:

  service:
    pipelines:
      traces:
        receivers: [otlp]
        processors: [batch]
        exporters: [otlp/tempo]

แก้ให้ loki เพิ่ม label ชื่อ trace_id promtail-config.yml

  server:
    http_listen_port: 9080
    grpc_listen_port: 0

  positions:
    filename: /tmp/positions.yaml

  clients:
    - url: http://loki:3100/loki/api/v1/push

  scrape_configs:
    - job_name: docker-logs
      docker_sd_configs:
        - host: unix:///var/run/docker.sock
          refresh_interval: 5s
          filters:
            - name: label
              values: ['logging=promtail']

      relabel_configs:
        - source_labels: ['__meta_docker_container_name']
          regex: '/(.*)'
          target_label: 'container'
        - source_labels: ['__meta_docker_container_log_stream']
          target_label: 'logstream'
        - source_labels: ['__meta_docker_container_label_logging_jobname']
          target_label: 'job'

      pipeline_stages:
        - docker: {}
        - json:
            expressions:
              app_name:
              level:
              msg:
              request_id:
              trace_id:
        - labels:
            app_name:
            level:
            request_id:
            trace_id:

เพิ่ม service opentelemetry-collector กับ tempo docker-compose.yml

  services:
    app:
      build: .
      container_name: backend-app
      ports:
        - '8080:8080'
      environment:
        - OTEL_EXPORTER_OTLP_ENDPOINT=otel-collector:4317
      depends_on:
        - otel-collector
      logging:
        driver: 'json-file'
        options:
          max-size: '10m'
          max-file: '5'
      # เพิ่ม label สำหรับ filtering logs
      labels:
        logging: 'promtail'
        logging_jobname: 'containerlogs'

    loki:
      image: grafana/loki:latest
      container_name: loki
      command: -config.file=/etc/loki/local-config.yaml
      volumes:
        - loki_data:/loki
      # ports:
      #   - "3100:3100"

    promtail:
      image: grafana/promtail:latest
      container_name: promtail
      volumes:
        - ./promtail-config.yml:/etc/promtail/promtail-config.yml
        - /var/lib/docker/containers:/var/lib/docker/containers:ro
        - /var/run/docker.sock:/var/run/docker.sock:ro
      command: -config.file=/etc/promtail/promtail-config.yml
      depends_on:
        - loki

    otel-collector:
      image: otel/opentelemetry-collector:latest
      container_name: otel-collector
      volumes:
        - ./otel-collector-config.yaml:/etc/otelcol/config.yaml
      command: ['--config=/etc/otelcol/config.yaml']
      ports:
        - '4317:4317' # gRPC
        - '4318:4318' # HTTP
        - '9464:9464'
      depends_on:
        - tempo

    tempo:
      image: grafana/tempo:latest
      container_name: tempo
      volumes:
        - ./tempo.yaml:/etc/tempo.yaml
      command: ['-config.file=/etc/tempo.yaml']
      # ports:
      #   - "3200" # tempo
      #   - "4317" # otlp grpc

    grafana:
      image: grafana/grafana:latest
      container_name: grafana
      ports:
        - '3000:3000'
      environment:
        - GF_SECURITY_ADMIN_USER=admin
        - GF_SECURITY_ADMIN_PASSWORD=admin
      volumes:
        - grafana-data:/var/lib/grafana
      depends_on:
        - loki
        - tempo

  volumes:
    loki_data:
    grafana-data:

8. ดู Trace ใน Grafana

รัน App ด้วยคำสั่ง: docker compose up -d --build
ส่ง Request: curl http://localhost:8080/users/1
เปิด Grafana: http://localhost:3000 (User: admin, Password: admin)
Data Source → Add data source → Tempo → URL: http://tempo:3200 → Trace to logs: เลือก Loki และเปิด filter by trace id → Save & test
Explore → Trace → เลือก Query Type เป็น Search → คุณจะเห็น Trace ID และสามารถกดลิงค์ไปยัง log ผ่าน trace id ได้

จุดเด่นแนวทางนี้

TraceID ใส่ใน Log ทุกบรรทัด → เชื่อม Log + Trace ได้จริง
ใช้ otel แบบมาตรฐาน → ต่อเข้ากับ Tempo Collector หรือ Jaeger ได้หมด

สรุป

คุณมี Distributed Tracing ครบ
ทุก Layer มี Trace Span ของตัวเอง
ทุก Log ผูกกับ TraceID → กดไปกลับ Log ↔ Trace ใน Grafana ได้ทันที

Observability Series ตอนที่ 2 — ส่ง Log เข้า Grafana ด้วย Loki

Somprasong Damyos — Wed, 09 Jul 2025 07:44:33 +0000

ในตอนที่แล้ว เรารู้จัก Observability และ 3 เสาหลัก: Logs, Metrics, Traces

ตอนนี้เราจะเริ่ม เก็บ Log ให้เห็นใน Grafana โดยใช้ Loki

Originally published at https://somprasongd.work/blog/go/observability-2

สิ่งที่จะได้เรียนรู้ในตอนนี้

สร้าง API ด้วย Go + Fiber (Layered Architecture)
ใช้ Middleware ใส่ Request ID และ Logger ลงใน context.Context
ทุก Layer (Handler, Service, Repo) ดึง Logger จาก context
ใช้ Zap เป็น Logger
ต่อ Log ออก stdout → เก็บด้วย Promtail → ส่งเข้า Loki
ดู Log ใน Grafana Dashboard

ตัวอย่าง Architecture

ในโปรเจ็กต์นี้ เราจะใช้ Layered Architecture

[Fiber Middleware] -> [Fiber Handler] -> [Service Layer] -> [Repository Layer]

และเราจะ Log ทุกชั้น ด้วย Logger เดียวกัน

เพื่อเชื่อม Log ทั้งหมดเข้ากับ Request ID เดียว

โครงสร้างโปรเจ็กต์

โค้ดตั้งต้น: https://github.com/somprasongd/observability-demo-go

project-root/
│
├── cmd/
│   └── main.go               # จุดเริ่มโปรแกรม, bootstrap Fiber, DI, middleware
│
├── internal/
│   ├── handler/
│   │   └── user_handler.go   # HTTP Handlers (Fiber routes)
│   │
│   ├── service/
│   │   └── user_service.go   # Business Logic Layer
│   │
│   └── repository/
│       └── user_repo.go      # Data Access Layer
│
├── pkg/
│   ├── ctxkey/
│   │   └── ctxkey.go         # Shared Lib: เก็บ context key
│   │
│   ├── logger/
│   │   └── logger.go         # Shared Lib: Logger setup (Zap)
│   │
│   └── middleware/           # Shared Lib: Middleware
│       └── observability_middleware.go
│
├── go.mod
└── go.sum

ขั้นตอน

1. สร้าง Logger (Zap)

/pkg/ctxkey/ctxkey.go

package ctxkey

type Logger struct{}

/pkg/logger/logger.go

package logger

import (
    "context"
    "demo/pkg/ctxkey"

    "go.uber.org/zap"
)

var baseLogger *zap.Logger

func Init() {
    l, _ := zap.NewProduction()
    baseLogger = l.With(zap.String("app_name", "demo-app"))
}

func Default() *zap.Logger {
    return baseLogger
}

// FromContext extracts logger from context
func FromContext(ctx context.Context) *zap.Logger {
    logger, ok := ctx.Value(ctxkey.Logger{}).(*zap.Logger)
    if !ok {
        return baseLogger
    }
    return logger
}

2. Middleware สร้าง Logger ต่อ Request

/pkg/middleware/obervability_middleware.go

package middleware

import (
    "context"
    "demo/pkg/ctxkey"
    "fmt"
    "runtime/debug"
    "time"

    "github.com/gofiber/fiber/v2"
    "github.com/google/uuid"
    "go.uber.org/zap"
)

func NewObservabilityMiddleware(baseLogger *zap.Logger) fiber.Handler {
    return func(c *fiber.Ctx) error {
        start := time.Now()
        method := c.Method()
        path := c.Path()

        requestID := c.Get("X-Request-ID")
        if requestID == "" {
            requestID = uuid.New().String()
        }

        // Bind Request ID ลง Response Header
        c.Set("X-Request-ID", requestID)

        // สร้าง child logger
        reqLogger := baseLogger.With(
            zap.String("request_id", requestID),
        )

        // สร้าง Context ใหม่
        ctx := context.WithValue(c.Context(), ctxkey.Logger{}, reqLogger)
        // แทน Context เดิม
        c.SetUserContext(ctx)

        err := c.Next()

        duration := time.Since(start).Seconds()
        status := c.Response().StatusCode()

        // log unhandle error
        if err != nil {
            reqLogger.Error("an error occurred",
                zap.Any("error", err),
                zap.ByteString("stack", debug.Stack()),
            )
        }

        msg := fmt.Sprintf("%d - %s %s", status, method, path)
        reqLogger.Info(msg,
            zap.Int("status", status),
            zap.Float64("duration_sec", duration),
        )

        return err
    }
}

3. Handler Layer

เรียกใช้ logger จาก context

/internal/handler/user_handler.go

package handler

import (
    "demo/internal/service"
    "demo/pkg/logger"

    "github.com/gofiber/fiber/v2"
    "go.uber.org/zap"
)

type UserHandler struct {
    svc *service.UserService
}

func NewUserHandler(svc *service.UserService) *UserHandler {
    return &UserHandler{svc: svc}
}

func (h *UserHandler) GetUser(c *fiber.Ctx) error {
    ctx := c.UserContext()
    // ดึง logger จาก context
    logger := logger.FromContext(ctx)

    logger.Info("Handler: GetUser called")

    id := c.Params("id")

    user, err := h.svc.GetUser(ctx, id)
    if err != nil {
        logger.Error("Handler: Failed to get user", zap.Error(err))
        return c.Status(500).SendString("Internal Server Error")
    }

    return c.JSON(user)
}

4. Service Layer

เรียกใช้ logger จาก context

/internal/service/user_service.go

package service

import (
    "context"
    "demo/internal/repository"
    "demo/pkg/logger"

    "go.uber.org/zap"
)

type UserService struct {
    repo *repository.UserRepository
}

func NewUserService(repo *repository.UserRepository) *UserService {
    return &UserService{repo: repo}
}

func (s *UserService) GetUser(ctx context.Context, id string) (map[string]string, error) {
    logger := logger.FromContext(ctx)
    logger.Info("Service: GetUser called", zap.String("id", id))

    return s.repo.FindUser(ctx, id)
}

5. Repository Layer

/internal/repository/user_repo.go

package repository

import (
    "context"
    "demo/pkg/logger"

    "go.uber.org/zap"
)

type UserRepository struct{}

func NewUserRepository() *UserRepository {
    return &UserRepository{}
}

func (r *UserRepository) FindUser(ctx context.Context, id string) (map[string]string, error) {
    logger := logger.FromContext(ctx)
    logger.Info("Repository: FindUser called", zap.String("id", id))

    // Mock DB
    user := map[string]string{
        "id":   id,
        "name": "John Doe",
    }
    return user, nil
}

6. Main

/cmd/main.go

package main

import (
    "github.com/gofiber/fiber/v2"
    "github.com/gofiber/fiber/v2/middleware/cors"
    "github.com/gofiber/fiber/v2/middleware/recover"

    "demo/internal/handler"
    "demo/internal/repository"
    "demo/internal/service"
    "demo/pkg/logger"
    "demo/pkg/middleware"
)

func main() {
    // Init Logger
    logger.Init()

    // Init Fiber
    app := fiber.New()

    // Middlewares
    app.Use(middleware.NewObservabilityMiddleware(logger.Default()))
    app.Use(cors.New())
    app.Use(recover.New())

    // Init DI
    repo := repository.NewUserRepository()
    svc := service.NewUserService(repo)
    h := handler.NewUserHandler(svc)

    // Routes
    app.Get("/users/:id", h.GetUser)

    // Start
    app.Listen(":8080")
}

ให้ ObservabilityMiddleware อยู่ก่อนเพราะ

เก็บ log ทุก request ไม่ว่าผ่านหรือไม่ผ่าน CORS
ถ้าเกิด panic คืน HTTP 500 response → แล้ว Observability ก็เก็บ status 500 ได้พอดี

7. ส่ง Log ไปหา Loki

วิธีที่ง่ายสุด:

รัน Grafana Loki + Promtail

ตั้งค่าให้ Promtail อ่าน Log จาก stdout, stderr ของ Container

promtail-config.yml

# ตัวอย่าง promtail-config.yml
server:
  http_listen_port: 9080
  grpc_listen_port: 0

positions:
  filename: /tmp/positions.yaml

clients:
  - url: http://loki:3100/loki/api/v1/push

scrape_configs:
  - job_name: docker-logs
    docker_sd_configs:
      - host: unix:///var/run/docker.sock
        refresh_interval: 5s
        filters:
          - name: label
            values: ['logging=promtail']

    relabel_configs:
      - source_labels: ['__meta_docker_container_name']
        regex: '/(.*)'
        target_label: 'container'
      - source_labels: ['__meta_docker_container_log_stream']
        target_label: 'logstream'
      - source_labels: ['__meta_docker_container_label_logging_jobname']
        target_label: 'job'

    pipeline_stages:
      - docker: {}
      - json:
          expressions:
            app_name:
            level:
            msg:
            request_id:
      - labels:
          app_name:
          level:
          request_id:

pipeline_stages = ขั้นตอนการประมวลผล

- `docker: {}` → ดึง `log` จาก Docker log JSON
- `json` → Parse `log` เป็น JSON อีกชั้น และหา Field ตามที่ `expressions` กำหนด
- `labels` → สร้าง Loki label

ใช้ docker-compose หรือ k8s ตามสะดวก แต่ในบทความจะใช้ docker-compose

Dockerfile

FROM golang:1.24 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o app ./cmd/main.go

FROM alpine:latest
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=builder /app/app .
EXPOSE 8080
CMD ["./app"]

docker-compose.yml

services:
  app:
    build: .
    container_name: backend-app
    ports:
      - '8080:8080'
    logging:
      driver: 'json-file'
      options:
        max-size: '10m'
        max-file: '5'
    # เพิ่ม label สำหรับ filtering logs
    labels:
      logging: 'promtail'
      logging_jobname: 'containerlogs'

  loki:
    image: grafana/loki:latest
    container_name: loki
    volumes:
      - loki_data:/loki
    command: -config.file=/etc/loki/local-config.yaml
    # ports:
    #   - "3100:3100"

  promtail:
    image: grafana/promtail:latest
    container_name: promtail
    volumes:
      - ./promtail-config.yml:/etc/promtail/promtail-config.yml
      - /var/lib/docker/containers:/var/lib/docker/containers:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
    command: -config.file=/etc/promtail/promtail-config.yml
    depends_on:
      - loki

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - '3000:3000'
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=admin
    volumes:
      - grafana-data:/var/lib/grafana
    depends_on:
      - loki

volumes:
  loki_data:
  grafana-data:

  <aside>

💡

ใช้ labels เพื่อให้ promtail ใช้กรอง log จาก container ที่ต้องการ

  </aside>

7. ดู Log ใน Grafana

รัน App ด้วยคำสั่ง: docker compose up -d --build
ส่ง Request: curl http://localhost:8080/users/1
เปิด Grafana: http://localhost:3000 (User: admin, Password: admin)
Data Source → Add data source → Loki → URL: http://loki:3100 → Save & test
Explore → Filter ด้วย Label app=demo-app → คุณจะเห็น Log จากทุก Layer ใน Request เดียวกัน (request_id เดียวกัน)

จุดเด่นแนวทางนี้

ใช้ Middleware สร้าง Logger ต่อ Request พร้อม Request ID (Logger ถูกสร้าง 1 ครั้งต่อ Request)
เก็บใน context.Context → ดึงจากไหนก็ได้
แต่ละ Layer ไม่ต้องส่ง Logger เป็น argument
Logs จะโยงกันได้หมดใน Grafana Loki
ใช้ Zap ร่วมกับ OTel ได้ถ้าจะต่อ Tracing ในตอนต่อไป

Observability Series ตอนที่ 1 — Observability คืออะไร ทำไมต้องทำ?

Somprasong Damyos — Wed, 09 Jul 2025 07:42:20 +0000

ซีรีส์นี้: สอนทำ Observability ครบ 3 มิติ (Logs, Traces, Metrics) ด้วยภาษา Go, Framework Fiber, เครื่องมือ OpenTelemetry, และ Stack ยอดนิยมอย่าง Grafana, Loki, Tempo, Prometheus

Originally published at https://somprasongd.work/blog/go/observability-1

ทำไม Observability ถึงสำคัญ?

ทุกวันนี้ระบบ Software ไม่ได้รันอยู่บนเครื่องเดียวหรือ Server เดียวอีกต่อไป เรามี

ระบบกระจาย (Distributed System)
Microservices หลายตัว
Cloud Infrastructure ที่ Dynamic

คำถาม: ถ้า Service หนึ่งพัง หรือข้อมูลผิด จะหาต้นเหตุยังไง?

ถ้าไม่มี Observability คุณอาจต้อง ssh เข้าเครื่องไปไล่ดู log มือ หรือ debug โค้ดสด ๆ ซึ่งไม่ทันกินอีกต่อไป เพราะระบบสมัยนี้ซับซ้อนและเปลี่ยนแปลงตลอดเวลา

Monitoring vs Observability

ก่อนอื่นต้องแยกให้ออกระหว่าง Monitoring และ Observability

Monitoring	Observability
ตั้งค่าตรวจจับ (Alert) ว่ามีอะไรผิดปกติ เช่น CPU สูง	ตอบคำถามได้ ทำไม มันถึงสูง
รู้อย่างเดียวว่าเกิดเหตุผิดปกติ	รู้ว่าเกิดที่ไหน เกิดยังไง และต้องแก้ตรงไหน
ตัวอย่าง: มี Dashboard แสดง Error Rate	ตัวอย่าง: มี Trace และ Log เชื่อมโยงถึงกัน

พูดง่าย ๆ คือ Monitoring = What, Observability = Why

สามองค์ประกอบของ Observability

Observability ที่ดีต้องครอบคลุม 3 สิ่งนี้

Logs — ข้อความบันทึกเหตุการณ์ เช่น error, debug, info
Metrics — ตัวเลขที่สรุปสถานะ เช่น Request/sec, CPU, Memory
Traces — ร่องรอยการเดินทางของ Request ข้าม Services

เมื่อมีทั้งสาม คุณจะ

เห็นภาพรวม
เจาะลงไปดูรายละเอียดได้
หาสาเหตุได้เร็ว
แก้ไขปัญหาได้ไว

ทำไมต้องใช้ OpenTelemetry + Grafana Stack?

OpenTelemetry (OTel) เป็นมาตรฐานเปิดสำหรับเก็บ Logs, Metrics, Traces ในรูปแบบเดียวกัน

Grafana เป็น Visualization Tool ที่ครองตลาด

Loki เก็บ Logs
Tempo เก็บ Traces
Prometheus หรือ Mimir เก็บ Metrics

ทั้งหมด Integrate กันได้ดี ใช้ง่าย มี Community ใหญ่ และฟรี!

สรุป

Observability ช่วยให้เข้าใจ ทำไม ระบบทำงานผิดปกติ
ครอบคลุม Logs + Metrics + Traces
Stack ที่เราจะใช้ คือ Go + Fiber + OpenTelemetry + Loki + Tempo + Prometheus + Grafana
ตอนถัดไป เราจะเริ่ม เก็บ Logs ด้วย Loki และดูผ่าน Grafana
ตัวอย่างโค้ด: https://github.com/somprasongd/observability-demo-go

Correlation Logging: ตอนที่ 3 Promtail ดึง Log จาก Kubernetes

Somprasong Damyos — Fri, 04 Jul 2025 04:59:26 +0000

Originally published at https://somprasongd.work/blog/go/correlation-logging-3

จากตอนที่แล้ว รันด้วย Docker Compose ถ้าเปลี่ยนไปรันใน Kubernetes แล้วใช้ label-based log filtering ใน Promtail สำหรับดึง log ของเฉพาะ Pod/Container ที่ต้องการ จะต้องปรับแต่งหลักๆ ดังนี้

1. เปลี่ยนจาก `docker_sd_configs` เป็น `kubernetes_sd_configs`

ใน promtail-config.yml:

scrape_configs:
  - job_name: kubernetes-pods
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_label_logging]
        regex: promtail
        action: keep

      - source_labels: [__meta_kubernetes_pod_name]
        target_label: pod

      - source_labels: [__meta_kubernetes_namespace]
        target_label: namespace

      - source_labels: [__meta_kubernetes_pod_label_logging_jobname]
        target_label: job

ใช้ kubernetes_sd_configs เพื่อดึงข้อมูล Pod จาก Kubernetes API แทน docker_sd_configs
ฟิลด์ label จะเปลี่ยนไปเป็นแบบ __meta_kubernetes_pod_label_<labelname>
role: pod คือการค้นหา Pod ทั้งหมดใน cluster

2. เพิ่มสิทธิ์ให้ Promtail อ่าน Kubernetes API

Promtail ต้องรันใน Kubernetes เป็น DaemonSet (แนะนำ) และต้องมี RBAC สิทธิ์อ่าน Pod metadata
ตัวอย่าง ServiceAccount + Role + RoleBinding สำหรับ Promtail:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: promtail
  namespace: monitoring

---

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: promtail
rules:
  - apiGroups: [""]
    resources: ["pods", "namespaces"]
    verbs: ["get", "list", "watch"]

---

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: promtail
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: promtail
subjects:
  - kind: ServiceAccount
    name: promtail
    namespace: monitoring

3. กำหนด label บน Pod / Deployment ที่ต้องการ

เช่น ใน deployment.yaml ของแอป

metadata:
  labels:
    logging: promtail
    logging_jobname: containerlogs

เพื่อให้ Promtail กรอง log ได้ตาม label เหมือนกับใน docker-compose

4. Mount log path และ docker socket (ถ้าจำเป็น)

ใน Kubernetes ส่วนใหญ่ใช้ container runtime เช่น containerd หรือ CRI-O ที่เก็บ log ไว้ที่ /var/log/pods หรือ /var/log/containers
Promtail ควร mount log directory เหล่านี้ เช่น

volumeMounts:
  - name: varlog
    mountPath: /var/log
  - name: varlibdockercontainers
    mountPath: /var/lib/docker/containers
    readOnly: true
  - name: dockersocket
    mountPath: /var/run/docker.sock
    readOnly: true

volumes:
  - name: varlog
    hostPath:
      path: /var/log
  - name: varlibdockercontainers
    hostPath:
      path: /var/lib/docker/containers
  - name: dockersocket
    hostPath:
      path: /var/run/docker.sock

แต่ถ้าใช้ container runtime อื่นต้องเช็ค path log ที่ถูกต้อง

สรุป

ส่วน	Docker Compose	Kubernetes
Service Discovery	docker_sd_configs	kubernetes_sd_configs
Label Selector	`__meta_docker_container_label_<name>`	`__meta_kubernetes_pod_label_<name>`
Log Path	`/var/lib/docker/containers`	`/var/log/pods`, `/var/log/containers`
สิทธิ์	ไม่ต้องใช้ RBAC	ต้องมี RBAC เพื่ออ่าน metadata จาก API
Deployment	Compose service	DaemonSet

ตัวอย่างไฟล์ `promtail.yaml`

ตัวอย่าง ไฟล์ promtail.yaml (รวม Namespace, ServiceAccount, RBAC, ConfigMap และ DaemonSet) สำหรับรัน Promtail ใน Kubernetes แบบ best practice พร้อม Label filter อ่านเฉพาะ Pod ที่ติด logging: promtail เหมือนกรณี docker-compose

---
apiVersion: v1
kind: Namespace
metadata:
  name: monitoring

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: promtail
  namespace: monitoring

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: promtail
rules:
  - apiGroups: [""]
    resources: ["pods", "nodes", "namespaces"]
    verbs: ["get", "list", "watch"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: promtail
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: promtail
subjects:
  - kind: ServiceAccount
    name: promtail
    namespace: monitoring

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: promtail-config
  namespace: monitoring
  labels:
    name: promtail-config
data:
  promtail.yaml: |
    server:
      http_listen_port: 9080
      grpc_listen_port: 0

    positions:
      filename: /run/promtail/positions.yaml

    clients:
      - url: http://loki:3100/loki/api/v1/push

    scrape_configs:
      - job_name: kubernetes-pods
        pipeline_stages:
          - docker: {}
          - json:
              expressions:
                app_name: app_name
          - labels:
              app: app_name

        kubernetes_sd_configs:
          - role: pod

        relabel_configs:
          - source_labels: [__meta_kubernetes_pod_label_logging]
            regex: promtail
            action: keep

          - source_labels: [__meta_kubernetes_pod_name]
            target_label: pod

          - source_labels: [__meta_kubernetes_namespace]
            target_label: namespace

          - source_labels: [__meta_kubernetes_pod_label_logging_jobname]
            target_label: job

          - source_labels: [__meta_kubernetes_pod_node_name]
            target_label: node

        # ใช้ paths container log
        static_configs:
        - targets:
            - localhost
          labels:
            __path__: /var/log/pods/*/*/*.log

---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: promtail
  namespace: monitoring
  labels:
    app: promtail
spec:
  selector:
    matchLabels:
      app: promtail
  template:
    metadata:
      labels:
        app: promtail
    spec:
      serviceAccountName: promtail
      terminationGracePeriodSeconds: 30
      containers:
        - name: promtail
          image: grafana/promtail:latest
          args:
            - -config.file=/etc/promtail/promtail.yaml
          volumeMounts:
            - name: config
              mountPath: /etc/promtail
            - name: positions
              mountPath: /run/promtail
            - name: varlog
              mountPath: /var/log
            - name: varlibdockercontainers
              mountPath: /var/lib/docker/containers
              readOnly: true
      volumes:
        - name: config
          configMap:
            name: promtail-config
        - name: positions
          emptyDir: {}
        - name: varlog
          hostPath:
            path: /var/log
        - name: varlibdockercontainers
          hostPath:
            path: /var/lib/docker/containers

Correlation Logging: ตอนที่ 2 ส่ง Log จาก Go Fiber ไป Loki

Somprasong Damyos — Fri, 04 Jul 2025 04:58:04 +0000

Originally published at https://somprasongd.work/blog/go/correlation-logging-2

จากตอนที่แล้ว เราทำระบบ Log ที่มี Request ID เชื่อมโยงทุก Log ของ Request เดียวกันได้แล้ว

แต่เก็บ Log แค่ในไฟล์ หรือ stdout ไม่พอสำหรับ Production จริง เพราะถ้าเครื่องมีหลาย Node จะหา Log แต่ละครั้งวุ่นมาก

วิธีแก้คือใช้ Log Aggregation — รวม Log จากทุกเครื่อง ทุก Container ไว้ที่เดียว เช่น Grafana Loki

ในตอนนี้เราจะทำให้ Log จาก Go Fiber ถูกส่งไปที่ Loki แล้วดูผ่าน Grafana ได้แบบ Real-Time

Stack ที่ใช้

Go Fiber + Zap Logger (จากตอนที่แล้ว)
Promtail สำหรับดึง Log ไฟล์แล้วส่งไป Loki
Loki เป็น Log Aggregator
Grafana เป็นหน้าจอ Dashboard
Docker Compose สำหรับรันทุกตัวพร้อมกัน

เป้าหมาย

ทุก Request ใน Fiber → Log แบบ stdout
Docker Engine จะเก็บ stdout ลงไฟล์
Promtail อ่านไฟล์แล้ว Forward ไป Loki
Grafana อ่าน Loki แล้วแสดง Log ตาม request_id

โครงสร้างไฟล์โปรเจกต์

project/
 ├── cmd/
 │   └── main.go
 ├── middleware/
 │   └── request_context.go
 ├── handler/
 │   └── user_handler.go
 ├── service/
 │   └── user_service.go
 ├── repository/
 │   └── user_repository.go
 ├── Dockerfile
 ├── docker-compose.yml <-- แก้ไข
 ├── nginx.conf
 ├── promtail-config.yml <-- เพิ่ม
 ├── go.mod
 └── go.sum

1. ให้ Docker Engine จะเก็บ stdout/stderr ลงไฟล์แบบ JSON

แก้ไขไฟล์ docker-compose.yml

services:
  nginx:
    # ...

  app:
    build: .
    container_name: backend-app
    # เก็บ log เป็นไฟล์ JSON
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "5"

กำหนด Logging Driver

driver: "json-file" หมายความว่า container จะเก็บ log เป็นไฟล์ JSON บน disk (นี่คือ default ของ Docker)
ทุก log ที่ container พิมพ์ออกมาที่ stdout/stderr จะถูกเก็บเป็น JSON event ในไฟล์

กำหนดขนาดและจำนวนไฟล์ log (log rotation)

max-size: "10m" → เมื่อ log ไฟล์ใหญ่เกิน 10 MB Docker จะเริ่มหมุนไฟล์ (rotate)
max-file: "5" → Docker จะเก็บไฟล์ log ได้สูงสุด 5 ไฟล์ (ไฟล์หลัก + ไฟล์ rotate 4 ไฟล์) ถ้าเกินก็ลบทิ้งไฟล์เก่าสุด

2. Promtail Config: อ่านไฟล์แล้วส่งไป Loki

สร้างไฟล์ promtail-config.yml

server:
  http_listen_port: 9080
  grpc_listen_port: 0

positions:
  filename: /tmp/positions.yaml

clients:
  - url: http://loki:3100/loki/api/v1/push

scrape_configs:
  - job_name: docker-logs
    docker_sd_configs:
      - host: unix:///var/run/docker.sock
        refresh_interval: 5s
        filters:
          - name: label
            values: ["logging=promtail"]

    relabel_configs:
      - source_labels: ['__meta_docker_container_name']
        regex: '/(.*)'
        target_label: 'container'
      - source_labels: ['__meta_docker_container_log_stream']
        target_label: 'logstream'
      - source_labels: ['__meta_docker_container_label_logging_jobname']
        target_label: 'job'

    pipeline_stages:
      - docker: {}
      - json:
          expressions:
            app_name: app_name
      - labels:
          app: app_name

server

server:
  http_listen_port: 9080
  grpc_listen_port: 0

Promtail จะเปิด HTTP server ที่พอร์ต 9080 เพื่อใช้ health check, metrics, หรือ config reload.
ปิด gRPC listener (grpc_listen_port: 0) → ไม่ใช้ gRPC สำหรับรับ log จาก agent อื่น ๆ\

positions

positions:
  filename: /tmp/positions.yaml

Promtail จะเก็บไฟล์ positions.yaml ไว้เพื่อจำว่าอ่าน log ไฟล์/stream ไปถึงไหนแล้ว
ถ้า Promtail รีสตาร์ท จะไม่อ่าน log ซ้ำตั้งแต่ต้น แต่จะ resume ต่อจากตำแหน่งล่าสุด

clients

clients:
  - url: http://loki:3100/loki/api/v1/push

จุดหมายของ log → ส่ง log ทั้งหมดไปที่ Loki ซึ่งรันอยู่ที่ http://loki:3100
loki คือชื่อ container (เช่น ใน docker-compose มี service: loki)

scrape_configs

scrape_configs:
  - job_name: docker-logs

ตั้งชื่อ job ว่า docker-logs → เพื่อระบุว่า job นี้มีหน้าที่ scrape log จาก Docker containers

docker_sd_configs

docker_sd_configs:
  - host: unix:///var/run/docker.sock
    refresh_interval: 5s
    filters:
      - name: label
        values: ["logging=promtail"]

ใช้ Docker Service Discovery → ดึงรายการ containers ผ่าน Docker API (/var/run/docker.sock)
refresh_interval: 5s → เช็ค container ใหม่ทุก 5 วินาที
filters → จะ scrape เฉพาะ containers ที่มี label logging=promtail เท่านั้น ถ้าไม่มี label นี้จะไม่เก็บ log

relabel_configs

relabel_configs:
  - source_labels: ['__meta_docker_container_name']
    regex: '/(.*)'
    target_label: 'container'
  - source_labels: ['__meta_docker_container_log_stream']
    target_label: 'logstream'
  - source_labels: ['__meta_docker_container_label_logging_jobname']
    target_label: 'job'

ใช้ relabel_configs เพื่อสร้าง labels สำหรับ log event
- __meta_* → เป็น metadata จาก Docker discovery
- แปลงชื่อ container → เป็น label container
- แยก log stream (stdout / stderr) → เป็น label logstream
- ถ้า container มี label เช่น logging_jobname=myapp → จะ map เป็น label job

pipeline_stages

pipeline_stages:
  - docker: {}
  - json:
      expressions:
        app_name: app_name
  - labels:
      app: app_name

เป็น pipeline สำหรับแปลง log ก่อนส่งไป Loki:
1. docker: {} → แยก JSON จาก Docker log driver (json-file) ให้ออกมาเป็น field
2. json: → ดึงค่า app_name จาก payload JSON ใน log (ถ้ามี)
3. labels: → สร้าง label ชื่อ app โดยใช้ค่า app_name ที่ดึงมา

3. Docker Compose: Loki + Promtail + Grafana

แก้ไฟล์ docker-compose.yml

services:
  nginx:
    image: nginx:latest
    container_name: nginx-proxy
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    depends_on:
      - app

  app:
    build: .
    container_name: backend-app
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "5"
    # เพิ่ม label สำหรับ filtering logs
    labels:
      logging: "promtail"
      logging_jobname: "containerlogs"

  loki:
    image: grafana/loki:latest
    container_name: loki
    ports:
      - "3100:3100"

  promtail:
    image: grafana/promtail:latest
    container_name: promtail
    volumes:
      - ./promtail-config.yml:/etc/promtail/promtail-config.yml
      - /var/lib/docker/containers:/var/lib/docker/containers:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
    command: -config.file=/etc/promtail/promtail-config.yml
    depends_on:
      - loki

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=admin
    volumes:
      - grafana-data:/var/lib/grafana
    depends_on:
      - loki

volumes:
  grafana-data:

4. ตั้งค่า Grafana

เปิด Grafana http://localhost:3001
- Login: admin / admin
ไปที่ Configuration → Data Sources → Add data source
เลือก Loki, ตั้ง URL เป็น http://loki:3100
Save & Test
ไปที่ Explore → เลือก Data Source → เลือก {app="demo-logger"}
ลองยิง Request:
```
curl http://localhost/users/1
```
ดู Log ใน Grafana จะเห็นทุก Log พร้อม request_id

จุดสำคัญ

Promtail ทำงานแบบ Agent คอย tail ไฟล์ Log แล้ว Push ให้ Loki
Zap สร้าง Log ในรูปแบบ JSON → Loki ดึง label หรือ filter ได้ดีมาก
การค้น Log ตาม request_id ใน Grafana แค่ใช้ Loki Query เช่น:
```
{app="demo-logger"} |= "request_id"
```

สรุป

นี่คือ Stack Logging ขนาดย่อมแต่ใช้งานได้จริง:

Fiber + Zap → สร้าง Log เป็น JSON
Docker Engine → เขียน Log ไฟล์
Promtail → Agent ดึง Log ไฟล์
Loki → Aggregator เก็บ Log ทุก Container
Grafana → Query Log ตาม Request ID

ทั้งหมดนี้รันด้วย Docker Compose พร้อมใช้งานทันที

Correlation Logging: ตอนที่ 1 ให้ Log รู้ว่าเกิดจาก Request เดียวกัน

Somprasong Damyos — Fri, 04 Jul 2025 04:55:27 +0000

Originally published at https://somprasongd.work/blog/go/correlation-logging-1

เคยไหม? เปิด log ไฟล์มาแล้วต้องกวาดตาดู Stack Trace วนเป็นชั่วโมง กว่าจะเจอว่า Error อันนี้มาจาก Request ไหน แล้วถ้าเจอ Request หนึ่งกระจายยิงหลาย Service ยิ่งวุ่นเข้าไปใหญ่

นี่คือที่มาของ Request ID หรือบางคนเรียกว่า Correlation ID — ตัวช่วยเล็ก ๆ ที่ทำให้ Distributed Logging เป็นเรื่องง่ายขึ้น

บทความนี้จะพาไปดูวิธีทำ End-to-End Correlated Logging ตั้งแต่

Proxy ชั้นนอก (NGINX)
จนถึง Backend (Go Fiber)
และวิธีส่งต่อ ID นี้ไปทั้ง Layer: Handler → Service → Repository

พร้อมตัวอย่างโค้ดจริง เอาไปต่อยอดได้เลย

ทำไมต้องมี Request ID?

เวลามี Request เข้า Service, เราอยากรู้ว่า:

Log ไหนเป็นของ Request ไหน
ถ้า Request เดียวกันทำงานหลาย Layer หรือเรียกหลาย Service, ทุก Log ต้องมี ID เดียวกัน

พอมี ID เดียวกัน เราจะ Search, Filter, Trace ข้ามระบบได้ง่าย (โดยเฉพาะถ้าใช้ OpenTelemetry หรือ ELK, Loki, Jaeger)

ภาพรวม Architecture

NGINX: ทำหน้าที่ Proxy, inject X-Request-ID ถ้ายังไม่มี
Fiber Middleware รับ X-Request-ID แล้วสร้าง Logger ฝัง request_id ใส่ context.Context
Layered Architecture: แบ่ง Handler → Service → Repository ทุก Layer รับ Context และดึง Logger จาก Context เท่านั้น
Logger: ใช้ Uber Zap Logger ซึ่งเป็น Production-ready logger ที่นิยมใน Go

โครงสร้างไฟล์โปรเจกต์

project/
 ├── cmd/
 │   └── main.go
 ├── middleware/
 │   └── request_context.go
 ├── handler/
 │   └── user_handler.go
 ├── service/
 │   └── user_service.go
 ├── repository/
 │   └── user_repository.go
 ├── Dockerfile
 ├── docker-compose.yml
 ├── nginx.conf
 ├── go.mod
 └── go.sum

Config NGINX ให้ใส่ `X-Request-ID`

เริ่มที่ Proxy ก่อน สมมติคุณมี nginx.conf ประมาณนี้:

http {
  server {
    listen 80;

    location / {
      # ถ้ามี X-Request-ID แล้ว ให้ใช้ของเดิม
      # ถ้าไม่มี ให้ generate ใหม่จาก $request_id ของ NGINX
      proxy_set_header X-Request-ID $request_id;

      proxy_pass http://backend;
    }
  }

  # ตั้ง backend upstream
  upstream backend {
    server app:3000;
  }
}

Tip:

$request_id ของ NGINX คือ Unique ID ที่ NGINX generate ให้แต่ละ Request
ถ้าข้างหน้ามี Load Balancer ที่ generate ไว้แล้ว หรือ Client ส่ง X-Request-ID มาก่อนแล้ว $request_id ของ NGINX จะ preserve ให้โดยอัตโนมัติ

Fiber Middleware: สร้าง Request ID และ Logger

ต่อมาใน Go Fiber เราต้องทำ Middleware ดึง X-Request-ID ใส่ logger

สร้าง Context Key

// ctxkey/ctxkey.go
package ctxkey

type key int

const (
    Logger key = iota
    RequestID
)

สร้าง Logger

// logger/logger.go
package logger

import (
    "context"
    "demo-logger/ctxkey"

    "go.uber.org/zap"
)

var baseLogger *zap.Logger

func InitLogger() {
    l, _ := zap.NewProduction()
    baseLogger = l.With(zap.String("app_name", "demo-logger"))
}

func Default() *zap.Logger {
    return baseLogger
}

func Logger(ctx context.Context) *zap.Logger {
    log, ok := ctx.Value(ctxkey.Logger).(*zap.Logger)
    if ok {
        return log
    }
    return baseLogger
}

สร้าง Middleware

// middleware/request_context.go
package middleware

import (
    "context"
    "demo-logger/ctxkey"
    "demo-logger/logger"

    "github.com/gofiber/fiber/v2"
    "github.com/google/uuid"
    "go.uber.org/zap"
)

func RequestContext() fiber.Handler {
    return func(c *fiber.Ctx) error {
        reqID := c.Get("X-Request-ID")
        if reqID == "" {
            reqID = uuid.New().String()
        }

        // Bind Request ID ลง Response Header
        c.Set("X-Request-ID", reqID)

        // สร้าง child logger
        reqLogger := logger.Default().With(zap.String("request_id", reqID))

        // สร้าง Context ใหม่
        ctx := context.WithValue(c.Context(), ctxkey.RequestID, reqID)
        ctx = context.WithValue(ctx, ctxkey.Logger, reqLogger)

        // แทน Context เดิม
        c.SetUserContext(ctx)

        return c.Next()
    }
}

Handler → Service → Repository ใช้ Logger จาก Context

Handler

// handler/user_handler.go
package handler

import (
    "demo-logger/logger"
    "demo-logger/service"

    "github.com/gofiber/fiber/v2"
    "go.uber.org/zap"
)

type UserHandler struct {
    svc *service.UserService
}

func NewUserHandler(svc *service.UserService) *UserHandler {
    return &UserHandler{svc: svc}
}

func (h *UserHandler) GetUser(c *fiber.Ctx) error {
    userID := c.Params("id")

  // ใช้ UserContext() เพราะใส่ logger ไว้ที่นี่
    user, err := h.svc.GetUser(c.UserContext(), userID)
    if err != nil {
        // ดึง logger จาก context
        logger.FromContext(c.UserContext()).Error("failed to get user")
        return c.Status(fiber.StatusInternalServerError).SendString("error")
    }

  // ดึง logger จาก context
    logger.FromContext(c.UserContext()).Info("success get user", zap.String("user_id", userID))

    return c.JSON(user)
}

Service

// service/user_service.go
package service

import (
    "context"
    "demo-logger/logger"
    "demo-logger/repository"

    "go.uber.org/zap"
)

type UserService struct {
    repo *repository.UserRepository
}

func NewUserService(repo *repository.UserRepository) *UserService {
    return &UserService{repo: repo}
}

func (s *UserService) GetUser(ctx context.Context, userID string) (any, error) {
  // ดึง logger จาก context
    logger.FromContext(ctx).Info("calling repo", zap.String("user_id", userID))

    return s.repo.FindByID(ctx, userID)
}

Repository

// repository/user_repository.go
package repository

import (
    "context"
    "demo-logger/logger"

    "go.uber.org/zap"
)

type UserRepository struct {
    // DB connection
}

func NewUserRepository() *UserRepository {
    return &UserRepository{}
}

func (r *UserRepository) FindByID(ctx context.Context, userID string) (any, error) {
  // ดึง logger จาก context
    logger.FromContext(ctx).Info("querying database", zap.String("user_id", userID))

    // สมมติคืน mock user
    return map[string]string{"id": userID, "name": "ball"}, nil
}

Main

// cmd/main.go
package main

import (
    "demo-logger/handler"
    "demo-logger/logger"
    "demo-logger/middleware"
    "demo-logger/repository"
    "demo-logger/service"

    "github.com/gofiber/fiber/v2"
)

func main() {
    logger.InitLogger()

    app := fiber.New()
    app.Use(middleware.RequestContext())

    repo := repository.NewUserRepository()
    svc := service.NewUserService(repo)
    hdl := handler.NewUserHandler(svc)

    app.Get("/user/:id", hdl.GetUser)

    app.Listen(":3000")
}

Build: สร้าง Dockerfile และ docker-compose

Dockerfile

# ---------- STAGE 1: Build ----------
FROM golang:1.24 AS builder

# Set working dir
WORKDIR /app

# Copy go.mod and go.sum first for caching dependencies
COPY go.mod go.sum ./

# Download dependencies
RUN go mod download

# Copy the source code
COPY . .

# Build binary - youสามารถเปลี่ยนชื่อได้ตามต้องการ
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o app ./cmd/main.go

# ---------- STAGE 2: Run ----------
FROM alpine:latest

# ทำให้ binary ทำงานได้ (สำหรับบาง lib เช่น timezone)
RUN apk --no-cache add ca-certificates

# Set working dir
WORKDIR /root/

# Copy binary จาก builder stage
COPY --from=builder /app/app .

# Expose port (ถ้ามี)
EXPOSE 3000

# Command to run
CMD ["./app"]

docker-compose.yml

services:
  nginx:
    image: nginx:latest
    container_name: nginx-proxy
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    depends_on:
      - app

  app:
    build: .
    container_name: backend-app

Run

docker compose up -d --build

ทดสอบเรียก curl http://localhost/users/1

ผลลัพธ์

เรียกดู Log ด้วยคำสั่ง docker compose logs app

backend-app  | {"level":"info","ts":1751602673.5724216,"caller":"service/user_service.go:20","msg":"calling repo","app_name":"demo-logger","request_id":"29988fdef291b7afaadaa872cea0d5ba","user_id":"1"}
backend-app  | {"level":"info","ts":1751602673.5769289,"caller":"repository/user_repository.go:19","msg":"querying database","app_name":"demo-logger","request_id":"29988fdef291b7afaadaa872cea0d5ba","user_id":"1"}
backend-app  | {"level":"info","ts":1751602673.5770924,"caller":"handler/user_handler.go:28","msg":"success get user","app_name":"demo-logger","request_id":"29988fdef291b7afaadaa872cea0d5ba","user_id":"1"}

ทุก Log ที่เกิดใน Handler, Service, Repo จะมี request_id ติดไปด้วย ทำให้เรา grep หรือ trace cross-service ได้ง่าย

สรุป

Request ID หรือ Correlation ID คือวิธีง่าย ๆ ที่ช่วยให้การ Debug ระบบ Distributed หรือ Microservices เป็นเรื่องง่ายขึ้น

จุดสำคัญคือ generate ID ครั้งเดียวที่ Proxy แล้วส่งต่อทุกจุดใน Layer ด้วย context.Context

Logger ต้องสร้างครั้งเดียวใน Middleware แล้วใช้ Logger จาก Context ทั้งหมด

แค่นี้คุณจะมี Log ที่เชื่อมโยงได้ชัดเจน ลดเวลาหา Bug ได้มาก

การสร้าง Docker Image สำหรับ Go ให้เหมาะกับ Production

Somprasong Damyos — Mon, 30 Jun 2025 04:09:10 +0000

แนวทางสร้าง Go container image ที่ เล็ก ปลอดภัย deploy ง่าย และ maintain ได้ระยะยาว

Originally published at https://somprasongd.work/blog/docker/docker-image-for-go

เมื่อพัฒนาแอปพลิเคชันด้วยภาษา Go หนึ่งในจุดเด่นที่สำคัญคือการสร้างไฟล์ไบนารีแบบ static ทำให้เหมาะอย่างยิ่งสำหรับนำไปบรรจุใน Docker container ที่มีขนาดเล็กและปลอดภัย ซึ่ง Alpine Linux เป็นฐานที่คนนิยมใช้เพราะขนาดเล็กและมีแพ็กเกจพื้นฐานเพียงพอสำหรับงานส่วนใหญ่

แต่การจะทำให้ container ขนาดเล็กและพร้อมใช้จริงใน production ต้องเข้าใจประเด็นสำคัญทั้งในแง่ของ build, dependency, และการจัดการ image ให้มีความเสถียรและปลอดภัย

ปิด cgo (CGO_ENABLED=0) เพื่อสร้าง static binary

โดยปกติ Go จะเปิดใช้ cgo เป็นค่าเริ่มต้นหากโค้ดมีการเรียกไลบรารี C หรือใช้ฟังก์ชันมาตรฐานบางส่วนที่อ้างอิง libc ซึ่งอาจทำให้ไฟล์ไบนารีต้องพึ่งพา shared library ภายนอก เช่น glibc หรือ musl

เมื่อใช้ Alpine ซึ่งใช้ musl libc แทน glibc ปัญหาที่พบบ่อยคือไฟล์ไบนารีที่พึ่ง glibc จะรันไม่สำเร็จ หากต้องการความแน่นอนว่ารันได้ทุกที่บน Linux base image ควรตั้ง CGO_ENABLED=0 เพื่อให้ Go สร้างไฟล์ไบนารีที่ลิงก์แบบ static ทั้งหมด ลดปัญหา dependency ภายนอก

ตัวอย่างที่นิยมคือ

ENV CGO_ENABLED=0

ลดขนาดไฟล์ด้วย ldflags "-s -w"

ตัวเลือก -ldflags="-s -w" เป็นอีกเทคนิคที่ใช้กันทั่วไปเพื่อลดขนาดไฟล์ที่ได้จาก go build

s จะตัด symbol table ซึ่งไม่จำเป็นต่อการรันจริง
w จะตัดข้อมูลสำหรับการ debug (DWARF)

ผลคือขนาดไฟล์จะลดลงได้หลาย MB แต่ข้อควรระวังคือ หากต้องใช้เครื่องมือ debug เช่น Delve ข้อมูลเหล่านี้จะหายไป ทำให้ debug ได้ลำบากขึ้น เทคนิคนี้จึงเหมาะสำหรับ build ไบนารีที่ใช้จริงใน production เท่านั้น

ทำไมไม่ควรใช้ alpine:latest

หลายคนมักเขียน Dockerfile ว่า FROM alpine:latest เพราะง่าย แต่ในทางปฏิบัติ นี่เป็นสิ่งที่ควรหลีกเลี่ยง เนื่องจาก tag latest ไม่ได้ผูกกับ version ใด ๆ แบบตายตัว ภายใน repository อาจอัปเดตเมื่อใดก็ได้โดยไม่ประกาศล่วงหน้า ซึ่งทำให้ build ครั้งถัดไปอาจได้ base image ที่ไม่เหมือนเดิมและอาจเกิดปัญหาใหม่โดยไม่รู้ตัว

แนวทางที่ควรทำคือระบุเวอร์ชันให้ชัดเจน เช่น FROM alpine:3.22 เพื่อให้แน่ใจว่าผลลัพธ์ reproducible และ rollback ได้ง่ายหากเกิดปัญหา

ใช้ Multi-Stage Build เพื่อลดขนาดและจัดการได้ง่าย

Dockerfile สำหรับ Go ที่ดีควรแยกขั้นตอน build ออกจากขั้นตอน runtime โดยใช้ multi-stage build ขั้นแรกใช้ image golang:<version>-alpine สำหรับ compile โค้ด ขั้นถัดไปใช้ alpine:<version> หรือแม้แต่ scratch เพื่อลดขนาด image

ตัวอย่างโครงสร้าง

# Build Stage
FROM golang:1.24-alpine AS builder

WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .

ENV CGO_ENABLED=0 GOOS=linux GOARCH=amd64
ARG VERSION=latest

RUN go build -ldflags="-s -w -X 'main.Version=${VERSION}'" -o /app/app ./cmd/api/main.go

# Final Stage
FROM alpine:3.22

RUN apk add --no-cache ca-certificates tzdata \
    && addgroup -S appgroup \
    && adduser -S appuser -G appgroup

WORKDIR /app
COPY --from=builder /app/app .

USER appuser

EXPOSE 8080

ENTRYPOINT ["./app"]

ใช้ Non-Root User

อีกหนึ่งจุดที่หลายคนมองข้ามคือ user ที่ container ใช้รันโปรเซส เริ่มต้น container จะรันด้วย root ซึ่งถ้าเกิดช่องโหว่ ผู้โจมตีอาจใช้สิทธิ root ภายใน container เพื่อโจมตีต่อได้ง่าย

วิธีแก้คือสร้าง user สิทธิจำกัด แล้วสั่งให้ container รันด้วย user นี้แทน การเพิ่มบรรทัด adduser และ USER ใน Dockerfile เป็นวิธีปฏิบัติมาตรฐานที่ช่วยปิดความเสี่ยงนี้ได้ดี

ENTRYPOINT vs CMD

หลายคนสับสนระหว่าง ENTRYPOINT และ CMD ว่าควรใช้แบบไหน ต่างกันอย่างไร

ENTRYPOINT ใช้กำหนด คำสั่งหลัก ที่ container ต้องรันเสมอ ไม่ว่าผู้ใช้จะสั่ง docker run พร้อม argument อะไร คำสั่งนี้จะถูกเรียกเสมอ โดย argument ที่ตามมาจะถูกต่อท้าย
CMD ใช้กำหนด default arguments ถ้า docker run ไม่ได้ระบุ argument ใหม่ ระบบจะใช้ค่าใน CMD แทน แต่ถ้าผู้ใช้ระบุ argument ใหม่ทั้งหมด CMD จะถูกแทนที่ทันที

ตัวอย่างเช่น

ENTRYPOINT ["./app"]
CMD ["--port=8080"]

กรณีนี้ หากรัน docker run myapp จะได้ ./app --port=8080 ถ้ารัน docker run myapp --help จะได้ ./app --help

การใช้ ENTRYPOINT แบบ exec form (["./app"]) ยังช่วยให้โปรเซสของเราทำงานเป็น PID 1 โดยตรง ทำให้จัดการ signal ได้ถูกต้อง โดยเฉพาะ SIGTERM ซึ่งสำคัญต่อการทำ graceful shutdown ใน production

สรุปแนวทาง Production Docker Image สำหรับ Go

ปิด cgo (CGO_ENABLED=0) เพื่อสร้างไฟล์ static
ใช้ ldflags="-s -w" เพื่อลดขนาดไฟล์
ระบุ base image version ชัดเจน เช่น alpine:3.18 อย่าใช้ latest
แยกขั้น build ออกจากขั้น runtime ด้วย multi-stage build
สร้าง non-root user เพื่อลดความเสี่ยง
ใช้ ENTRYPOINT เพื่อกำหนด command หลัก และ CMD เพื่อกำหนด default arguments

แนวทางทั้งหมดนี้จะช่วยให้ได้ Docker Image ที่ขนาดเล็ก เสถียร ปลอดภัย และจัดการได้ง่ายจริงในงาน production

ทำไมต้องใช้ Database Transaction?

Somprasong Damyos — Fri, 27 Jun 2025 14:05:28 +0000

Originally published at https://somprasongd.work/blog/db/dbtx

ในการพัฒนาระบบที่เกี่ยวข้องกับข้อมูลสำคัญ เช่น การเงิน หนึ่งในสิ่งที่ขาดไม่ได้คือการใช้ Database Transaction เพื่อให้มั่นใจว่าข้อมูลจะถูกจัดการอย่างถูกต้องและปลอดภัย โดยเฉพาะในสถานการณ์ที่มีหลายคำสั่ง SQL ทำงานร่วมกัน เช่น "การโอนเงิน" ที่ต้องอัปเดตยอดเงินสองบัญชีพร้อมกัน

ในบทความนี้ เราจะพาคุณเข้าใจว่าเหตุใดการใช้ Transaction จึงสำคัญ ผ่านการเรียนรู้แนวคิด ACID, Lock, และ Deadlock ด้วยตัวอย่างจากการโอนเงินระหว่างบัญชีด้วย PostgreSQL

โครงสร้างฐานข้อมูล: `accounts` และ `transactions`

CREATE TABLE public.accounts (
    id serial4 NOT NULL,
    "name" text NOT NULL,
    balance numeric NOT NULL,
    CONSTRAINT accounts_pkey PRIMARY KEY (id)
);

CREATE TABLE public.transactions (
    id serial4 NOT NULL,
    from_account_id int4 NULL,
    to_account_id int4 NULL,
    amount numeric NOT NULL,
    created_at timestamp DEFAULT now() NULL,
    CONSTRAINT transactions_pkey PRIMARY KEY (id),
    CONSTRAINT transactions_from_account_id_fkey FOREIGN KEY (from_account_id) REFERENCES public.accounts(id),
    CONSTRAINT transactions_to_account_id_fkey FOREIGN KEY (to_account_id) REFERENCES public.accounts(id)
);

ปัญหา: การโอนเงินโดยไม่ใช้ Transaction

สมมุติว่าเราต้องโอนเงิน 500 บาทจากบัญชี A ไปยังบัญชี B โดยใช้คำสั่ง SQL ต่อไปน

UPDATE accounts SET balance = balance - 500 WHERE id = 1;
UPDATE accounts SET balance = balance + 500 WHERE id = 2;
INSERT INTO transactions (from_account_id, to_account_id, amount)
VALUES (1, 2, 500);

ถ้าเกิดเหตุขัดข้องหลังอัปเดตบัญชี A แล้ว (เช่น network error หรือ crash) แต่ยังไม่ทันเพิ่มเงินให้บัญชี B — เงิน 500 บาทจะ “หายไปจากระบบ” ซึ่งเป็นปัญหาหนักมากในระบบการเงิน

วิธีแก้: ใช้ Database Transaction

BEGIN;

UPDATE accounts SET balance = balance - 500 WHERE id = 1;
UPDATE accounts SET balance = balance + 500 WHERE id = 2;

INSERT INTO transactions (from_account_id, to_account_id, amount)
VALUES (1, 2, 500);

COMMIT;

หากคำสั่งใดล้มเหลว PostgreSQL จะไม่ COMMIT และเราสามารถ ROLLBACK เพื่อยกเลิกทุกคำสั่งที่ทำไปแล้ว ทำให้ข้อมูลไม่เสียหาย

เข้าใจ ACID: หัวใจของ Transaction

ACID คือคุณสมบัติหลักของ Database Transaction ที่ทำให้ข้อมูลเชื่อถือได้ ซึ่งย่อมาจาก

Atomicity – ทุกคำสั่งใน transaction ต้องสำเร็จทั้งหมด หรือไม่สำเร็จเลย
Consistency – หลัง transaction สำเร็จ ฐานข้อมูลยังคงถูกต้องตามกฎ เช่น balance ≥ 0
Isolation – แต่ละ transaction ไม่รบกวนกันระหว่างทำงานพร้อมกัน
Durability – เมื่อ COMMIT แล้ว ข้อมูลจะถูกบันทึกถาวร แม้ระบบดับ

ตัวอย่าง: หากมีคนโอนเงินจากบัญชีเดียวกันสองคนพร้อมกัน PostgreSQL ต้องมั่นใจว่าไม่มีการขัดแย้ง หรือข้อมูลผิดเพี้ยน เช่นเงินติดลบ

การล็อกข้อมูล (Database Lock)

PostgreSQL จะล็อก row-level อัตโนมัติเมื่อมี UPDATE:

UPDATE accounts SET balance = balance - 500 WHERE id = 1;

แถวของบัญชี id = 1 จะถูกล็อกไว้จนกว่า transaction จะจบ เพื่อป้องกันไม่ให้ transaction อื่นเข้ามาแก้ไขบัญชีเดียวกันพร้อมกัน

สถานการณ์: `select` ก่อน `update`

แต่ในกรณีที่ใน application logic มีการดึงข้อมูล (select) ขึ้นมาก่อน แล้วทำการแก้ไขค่า เสร็จแล้วบันทึกกลับไปในฐานข้อมูล (update) แล้วเกิด transaction เข้ามาแก้ไขบัญชีเดียวกันพร้อมกัน เช่น

-- Transaction A
BEGIN;
SELECT id, "name", balance FROM accounts WHERE id = 1;
id|name|balance|
--+----+-------+
 1|A   |   1000|

UPDATE accounts SET balance = 1000 - 500 WHERE id = 1;

COMMIT;

-- Transaction B (เกิดขึ้นพร้อมกัน)
BEGIN;
SELECT id, "name", balance FROM accounts WHERE id = 1;
id|name|balance|
--+----+-------+
 1|A   |   1000|

UPDATE accounts SET balance = 1000 - 500 WHERE id = 1;

COMMIT;

ในสถานการณ์นี้จะทำให้ค่า balance ผิด แทนที่จะเหลือ 0 แต่กลับเหลือ 500 แทน

วิธีแก้: ใช้ SELECT FOR UPDATE เพื่อล็อกก่อน

-- Transaction A
BEGIN;
SELECT id, "name", balance FROM accounts WHERE id = 1 FOR UPDATE;
id|name|balance|
--+----+-------+
 1|A   |   1000|

UPDATE accounts SET balance = 1000 - 500 WHERE id = 1;

COMMIT;

-- Transaction B (เกิดขึ้นพร้อมกัน)
BEGIN;
SELECT id, "name", balance FROM accounts WHERE id = 1 FOR UPDATE;
-- จะหยุดรอจนกว่า Transaction A จะ COMMIT หรือ ROLLBACK
id|name|balance|
--+----+-------+
 1|A   |   500|

UPDATE accounts SET balance = 500 - 500 WHERE id = 1;

COMMIT;

Deadlock: ล็อกขัดกันเอง

สถานการณ์ที่ 1:

Transaction A: โอน A ➜ B
Transaction B: โอน B ➜ A

-- Transaction A
BEGIN;
UPDATE accounts SET balance = balance - 500 WHERE id = 1;
UPDATE accounts SET balance = balance + 500 WHERE id = 2;
-- รอ เพราะ lock จาก Transaction B

-- Transaction B (เกิดขึ้นพร้อมกัน)
BEGIN;
UPDATE accounts SET balance = balance - 300 WHERE id = 2;
UPDATE accounts SET balance = balance + 300 WHERE id = 1;
-- ERROR: deadlock detected

สถานการณ์ที่ 2:

ถ้า INSERT ไปยัง transactions ซึ่งมี Foreign Key อ้างถึง accounts.id และหากมีอีก transaction กำลัง UPDATE accounts อยู่ อาจเกิด Deadlock ได้

เช่น สมมุติให้เปลี่ยนลำดับให้บันทึก transactions ก่อน แล้วมาดึงข้อมูลข้อมูล accounts ก่อน update

-- Transaction A
BEGIN;

INSERT INTO transactions (from_account_id, to_account_id, amount)
VALUES (1, 2, 500);

SELECT id, "name", balance FROM accounts WHERE id = 1 FOR UPDATE;
-- หยุดรอ เพราะ INSERT INTO transactions จาก Transaction B

-- Transaction B (เกิดขึ้นพร้อมกัน)
BEGIN;

INSERT INTO transactions (from_account_id, to_account_id, amount)
VALUES (1, 2, 500);

SELECT id, "name", balance FROM accounts WHERE id = 1 FOR UPDATE;
-- ERROR: deadlock detected

จากสถานการณ์ที่ยกตัวอย่างมา ทั้งสอง transaction จะล็อกบัญชีฝั่งของตนเองก่อน แล้วรอกันข้าม — ทำให้เกิด Deadlock PostgreSQL จะเลือก kill transaction ใด transaction หนึ่งเพื่อยกเลิก

วิธีป้องกัน Deadlock

ล็อก row ตามลำดับเสมอ
ใช้ ORDER BY id เพื่อให้ทุก transaction ล็อกบัญชีตามลำดับเดียวกัน เช่น id จากน้อยไปมาก
ล็อก row ก่อนอัปเดตด้วย FOR NO KEY UPDATE
หากไม่ล็อก row ล่วงหน้า PostgreSQL จะพยายามล็อกเองในตอนที่ INSERT ไปยัง transactions ซึ่งมี Foreign Key อ้างถึง accounts.id
หากอีก transaction กำลัง UPDATE accounts อยู่ อาจเกิด Deadlock ได้
FOR NO KEY UPDATE คือระดับ lock ที่
- ป้องกันการ update, delete หรือ insert ที่อ้าง foreign key
- เบากว่า FOR UPDATE แต่ปลอดภัยสำหรับกรณีแบบนี้
- เหมาะสำหรับ row ที่เราจะอัปเดต (แต่ไม่เปลี่ยนค่า primary key)
ควร UPDATE accounts ก่อน แล้วค่อย INSERT transactions

ช่วยลดความเสี่ยงในการเกิด Deadlock เพราะว่าหากคุณ INSERT ก่อน และมี Foreign Key ไปที่ accounts → PostgreSQL จะพยายามล็อก row เหล่านั้นก่อน ถ้าคำสั่ง UPDATE accounts มาทีหลัง อาจเกิด Deadlock ได้ (โดยเฉพาะถ้าอีก transaction ล็อกกลับกัน)

ตัวอย่าง

-- Transaction A
BEGIN;

-- 1. ล็อกบัญชีล่วงหน้าเพื่อลดโอกาส deadlock
SELECT id FROM accounts
WHERE id IN (1, 2)
ORDER BY id
FOR NO KEY UPDATE;

-- 2. อัปเดตยอดเงิน
UPDATE accounts SET balance = balance - 500 WHERE id = 1;
UPDATE accounts SET balance = balance + 500 WHERE id = 2;

-- 3. บันทึกธุรกรรม
INSERT INTO transactions (from_account_id, to_account_id, amount)
VALUES (1, 2, 500);

COMMIT;

-- Transaction B (เกิดขึ้นพร้อมกัน)
BEGIN;

SELECT id FROM accounts
WHERE id IN (1, 2)
ORDER BY id
FOR NO KEY UPDATE;
-- รอจนกว่า Transaction A จะถูก COMMIT หรือ ROLLBACK

UPDATE accounts SET balance = balance - 300 WHERE id = 2;
UPDATE accounts SET balance = balance + 300 WHERE id = 1;

INSERT INTO transactions (from_account_id, to_account_id, amount)
VALUES (2, 1, 300);

COMMIT;

ตารางเปรียบเทียบระดับ Lock (ใน SELECT ... FOR ...)

Lock Mode	ใช้ในกรณี	ป้องกันไม่ให้ใครทำอะไรได้บ้าง
`FOR UPDATE`	อัปเดต row	ห้ามใคร update/delete แถวนี้
`FOR NO KEY UPDATE`	อัปเดต row (ไม่แตะ key)	ห้าม insert ที่อ้างถึง row นี้ (FK)
`FOR SHARE`	อ่านอย่างเดียว	ห้ามใคร delete หรือ update แถวนี้
`FOR KEY SHARE`	อ่านพร้อมอ้าง FK	ห้ามใครเปลี่ยน primary key หรือ delete

สรุป

การใช้ Database Transaction เป็นสิ่งสำคัญอย่างยิ่งในระบบที่ต้องการความถูกต้องของข้อมูล โดยเฉพาะระบบการเงิน โดย PostgreSQL มีคุณสมบัติรองรับ ACID อย่างครบถ้วน พร้อมระบบ Lock และกลไกจัดการ Deadlock อัตโนมัติ

หากละเลยการใช้ Transaction อาจนำไปสู่ความเสียหายทางข้อมูล และความไม่ถูกต้องที่ยากจะแก้ไขภายหลัง

ลด Coupling และแยก Concern ด้วย Domain Event และ Integration Event

Somprasong Damyos — Fri, 06 Jun 2025 11:25:47 +0000

Originally published at https://somprasongd.work/blog/architecture/domain-event-vs-integration-event

ในระบบที่ออกแบบแบบ DDD (Domain-Driven Design) หรือ Modular Monolith หลายคนมักเริ่มต้นด้วยการเขียนโค้ดในรูปแบบ Imperative Style — ซึ่งตรงไปตรงมาแต่ coupling สูง และแยก concern ได้ไม่ชัดเจน

ยกตัวอย่างเช่น ใน CustomerService ที่รับผิดชอบสร้างลูกค้าใหม่ เราอาจเขียน logic ประมาณนี้

if err := h.custRepo.Create(ctx, customer); err != nil {
    return err
}

// ส่งอีเมลต้อนรับทันที
if err := h.notiSvc.SendEmail(customer.Email, "Welcome!", ...); err != nil {
    return err
}

แม้โค้ดนี้จะดูเรียบง่าย แต่จริงๆ แล้วมันแฝงปัญหาหลายอย่างไว้ เช่น

Coupling สูง: Command Handler รู้จัก Service สำหรับส่งอีเมลโดยตรง
ยากต่อการขยาย/ปรับปรุง: หากในอนาคตอยากส่ง SMS หรือบันทึก event log เพิ่มเติม ต้องแก้ handler ตรงนี้
ยากต่อการทดสอบ: การ mocking พฤติกรรมที่เกิด "หลัง" การสร้าง customer ทำได้ยาก

ย้าย Logic ที่ไม่ใช่ Core Concern ออกด้วย Event

ทางออกที่ดีกว่า คือการใช้แนวคิด Domain Events และ Integration Events เพื่อแยก concern ต่างๆ ออกจาก core business logic

Domain Event คืออะไร?

Domain Event คือสิ่งที่เกิดขึ้นใน domain ของเรา เช่น CustomerCreated, OrderCancelled เป็นต้น — โดย publish และ handle อยู่ภายใน module เดียวกัน

เช่น เมื่อสร้าง Customer สำเร็จ ก็สามารถเพิ่ม logic เช่นนี้

customer.AddDomainEvent(CustomerCreated{
    ID:    customer.ID,
    Email: customer.Email,
})

จากนั้น ระบบจะมี Domain Event Dispatcher ที่ทำหน้าที่ตามหา handler ที่เหมาะสมมาทำงานต่อ — โดยไม่กระทบ core logic

Integration Event คืออะไร?

เมื่อมีบาง domain event ที่เราต้อง "แจ้ง" ไปยัง ระบบอื่น หรือ module อื่น เช่นการส่งอีเมล, เขียน log audit, หรือแจ้งผ่าน Kafka — เราจะ แปลง Domain Event เป็น Integration Event แล้วค่อยส่งออกแบบ async

ตัวอย่าง

type CustomerCreatedDomainEventHandler struct {
    eventBus EventBus
}

func (h *CustomerCreatedDomainEventHandler) Handle(ctx context.Context, evt CustomerCreated) error {
    // แปลงเป็น Integration Event
    return h.eventBus.Publish(ctx, CustomerCreatedIntegrationEvent{
        CustomerID: evt.ID,
        Email:      evt.Email,
    })
}

สรุปข้อดีของการใช้ Event-Based Approach

แยก business logic ออกจาก infrastructure concern
ลด coupling ระหว่าง module และ service ต่างๆ
เปิดทางสู่ scalability และ async processing
ง่ายต่อการทดสอบ และรองรับ use-case ใหม่ๆ โดยไม่แก้ core logic

สุดท้าย

การเปลี่ยนจากแนวทาง imperative ที่ทำทุกอย่างตรงๆ ไปสู่ event-driven ไม่ได้หมายความว่าคุณต้องเปลี่ยนทั้งหมดในคราวเดียว — แต่การเริ่ม "แยก concern" ให้ชัดเจนมากขึ้น จะช่วยให้ระบบของคุณ flexible, maintainable และรองรับการเติบโตได้ดียิ่งขึ้น

N8N Credentials Setup: จัดให้ครบ จบทุกการเชื่อมต่อ

Somprasong Damyos — Fri, 25 Apr 2025 12:15:42 +0000

N8N Credentials Setup: จัดให้ครบ จบทุกการเชื่อมต่อ

การสร้าง Credentials คือกุญแจสำคัญที่จะเปิดประตูให้ N8N เชื่อมต่อกับโลกภายนอกได้อย่างมั่นใจ

บทความนี้จะพาคุณตั้งค่า Credentials สำหรับ Gemini API, Gmail, Google Drive และ PostgreSQL ผ่าน Supabase แบบทีละขั้นตอน ไม่ต้องเดา ไม่ต้องลองผิดลองถูกให้ปวดหัว พร้อมใช้งานได้จริงตั้งแต่ Workflow แรก

การเชื่อมต่อกับ Gmail และ Google Drive

ต้องเปิดใช้งาน API และสร้าง OAuth 2.0 Client ID ใน Google Cloud ก่อน ซึ่งมีขั้นตอน ดังนี้

Step 1: เลือก หรือสร้างโปรเจคใหม่

ไปที่ https://console.cloud.google.com/projectselector2
ถ้ายังไม่มี ให้เลือก Create Project เพื่อสร้างใหม่ โดยระบุ
- Project name: เช่น n8n-dev
- ถ้าเป็น Google Workspace จะมี Organization กับ Location มาให้เลือกเพิ่ม
- กดปุ่ม Create

Step 2: เปิดใช้งาน API

ให้พิมพ์ค้นหา และเลือก Gmail API

เปิดการใช้งาน เลือก Enable

ให้พิมพ์ค้นหา และเลือก Google Drive API

เปิดการใช้งาน เลือก Enable

Step 3: สร้าง OAuth consent screen

ก่อนจะสร้าง OAuth 2.0 Client ID ครั้งแรก จะต้องสร้าง OAuth consent screen ก่อน

ไปที่ APIs & Services > OAuth consent screen

เลือก Get started จะมีให้กรอก Project Information
- App Information
- ระบุ App name
- ระบุ Email
- กดปุ่ม Next

Audience
- ถ้าเลือก External จะเป็น testing mode ต้องเพิ่ม Test user ด้วย ไม่งั้น login ไม่ได้
- กดปุ่ม Next

Contact Information
- ใส่อีเมลตัวเอง
- กดปุ่ม Next

Finish
- เลือก I agree to …
- กดปุ่ม Continue

กดปุ่ม Create
- กรณีเลือก Audience เป็น External ให้เพิ่มอีเมลตัวเอง เป็น Test user ก่อน
โดยเลือกที่เมนู Audience
กดปุ่ม Add users

ใส่ระบุอีเมลของเรา และกดปุ่ม Save

เมื่อเสร็จแล้วจะมีชื่ออีเมลของเราเป็น Test user

Step 4: สร้าง OAuth 2.0 Client ID

เมื่อทุกอย่างพร้อมแล้ว ก็เริ่มสร้าง OAuth 2.0 Client ID เพื่อเอาไปใช้งานได้ n8n ได้

ไปที่ APIs & Services > Credentials

เลือก Create credentials และเลือก OAuth client ID

)

เลือก Application type เป็น Web application

ระบุชื่อ ที่ Name: เช่น n8n-gmail
กดปุ่ม Add URI

โดย URI นี้ ต้องเอามาจาก n8n ตัวอย่างการจะเป็นการเพิ่ม Credential ของ Gmail มีขั้นตอนดังนี้
- Login เข้า n8n ของเรา
- เลือก + แล้วเลือก Credential

พิมพ์ค้นหาว่า Gmail แล้วเลือก Gmail OAuth2 API

ให้ Copy ที่ OAuth Redirect URL

นำ URL มาใส่ที่ Authorized redirect URIs

กดปุ่ม Create ก็จะได้ Client ID และ Client secret

นำมาใส่ใน หน้าการเชื่อมต่อของ n8n

กดปุ่ม Sign in with Google เพื่อทำการ sign in โดยเลือกบัญชีให้ถูกต้อง

⚠️ ถ้าเลือกแบบ Audience แบบ External และไม่ได้เพิ่ม Test user จะไม่สามารถ sing in ได้ แบบนี้

หากเป็น Test mode ให้เลือก Continue (กรณี Audience เป็น Internal จะไม่มีหน้าจอนี้)

ให้สิทธิการใช้งานทั้งหมด (กรณี Audience เป็น Internal จะเลือกไม่ได้) และกดปุ่ม Continue

เมื่อสำเร็จจะได้แบบนี้

ในส่วนของ Google Drive สามารถใช้ Client ID และ Client Secret เดียวกันได้ หรือจะสร้างใหม่ก็ เสร็จให้กดสร้าง Credentials ที่ n8n โดยเลือกเป็น Google Drive OAuth2 API

และทำขั้นตอนซ้ำเหมือนการเชื่อมต่อ Gmail

การเชื่อมต่อกับ Gemini API

เพื่อเปิดใช้งาน AI Model โดยมีขั้นตอนดังนี้

Step 1: สร้าง API Key

ไปที่ https://aistudio.google.com/u/1/apikey
กดปุ่ม Create API Key

เลือกไปที่โปรเจคของเรา ในบทความใช้ n8n-dev

กดปุ่ม Create API Key in existing project

จะได้ API key ออกมา ให้ Copy เก็บไว้ก่อน

Step 2: สร้าง n8n credentials

กลับมาที่ n8n ให้เลือกสร้าง Credential ใหม่ โดยเลือกเป็น Google Gemini(PaLM) Api

ใส่ API Key และกดปุ่ม Save

ถ้าสำเร็จ จะมีข้อความบอกแบบนี้

การเชื่อมต่อกับ PostgreSQL

ในบทความนี้จะทำการเชื่อมต่อ PostgreSQL โดยจะใช้ตัวอย่างจาก PostgreSQL ใน supabase ซึ่งสามารถใช้ได้กับการติดตั้งเอง

Step 1: สร้างโปรเจคใหม่ใน Supabase

ใครมีอยู่แล้วสามารถข้ามไปขั้นตอนถัดไปได้เลย

ไปที่ https://supabase.com/dashboard/
กดปุ่ม New project

ทำการตั้งชื่อโปรเจค และกำหนดรหัสผ่าน แล้วกดปุ่ม Create new project

เสร็จแล้วก็จะได้โปรเจคใหม่ออกมา

Step 2: หาค่าเชื่อมต่อฐานข้อมูล

ที่หน้า Project overview ให้เลือกปุ่ม Connect

ให้เลื่อนลงมาที่ Transaction pooler

กดที่ View parameters โดยเราจะนำค่าตรงนี้ไปใช้งาน

Step 3: สร้าง PostgreSQL Credentials

กลับมาที่ n8n แล้วกดสร้าง Credential และเลือกเป็น Postgres

ให้ทำการแก้ไข ดังนี้
- Host: ตามค่าของ Transaction pooler
- Database: ตามค่าของ Transaction pooler
- User: ตามค่าของ Transaction pooler
- Password: รหัสผ่านที่ระบุตอนสร้างโปรเจค
- Port: ตามค่าของ Transaction pooler

กดปุ่ม Save
ถ้าสำเร็จ จะมีข้อความแจ้งแบบนี้

ทดสอบการเชื่อมต่อ Credentials

ลองทดสอบว่า credentials ที่เราสร้างไปสามารถใช้งานได้ หรือไม่โดย มีขั้นตอนดังนี้

ดาวน์โหลดไฟล์ Workflow สำหรับการทดสอบจากที่นี่ (คลิกขวา Save As)
ไปที่ n8n สร้าง Workflow ใหม่

เลือกที่ … แล้วเลือก Import from File และเลือกไฟล์ที่ดาวน์โหลดมา
Workflow ที่ได้มาจะขึ้นสีแดง

เราต้องทำการเลือก Credential ของตัวเอง (ชื่อตามที่ตัวเองตั้งไว้) ให้ถูกต้องก่อน โดยการ double click ที่ node แล้วเลือก credential ให้ถูกต้อง

ทดสอบโดยกดปุ่ม Open chat

ให้ลองพิมพ์ทดสอบ ตามนี้
- อีเมลของฉัน somprasong.damyos@gmail.com (ทดสอบ Gemini API, Postgres)
- แต่งเรื่องตลก 2 เรื่อง แล้วส่งอีเมลให้หน่อย (ทดสอบ Gmail API)

ถ้าทุกอย่างรันได้ แสดงว่าเราถูกต้องแล้ว 🎉

DEV Community: Somprasong Damyos

แนะนำ Bash Command สำหรับ Developer มือใหม่

รายชื่อคำสั่งที่ควรรู้จัก

พื้นฐานและจัดการไฟล์

ค้นหาและแก้ไข

รันโปรเจกต์ / ดู process

จัดการ Git

ประมวลผลข้อความ

การเรียก API และ Network เบื้องต้น

จัดการ Environment Variable

เขียน Shell Script

สมมติฐาน: โปรเจกต์ Go ชื่อ myapp

1. พื้นฐานและจัดการไฟล์

pwd – แสดง path ปัจจุบัน

ls – แสดงรายการไฟล์

cd – เปลี่ยนโฟลเดอร์

touch – สร้างไฟล์เปล่า

mkdir – สร้างโฟลเดอร์

rm – ลบไฟล์หรือโฟลเดอร์

2. คำสั่งอ่าน / ค้น / แก้ไขไฟล์

cat – อ่านไฟล์ทั้งหมด

less – อ่านไฟล์แบบ scroll

head และ tail – ดูต้นหรือท้ายไฟล์

echo – แสดงข้อความ / ตัวแปร

3. การค้นหาไฟล์ / ข้อความ

grep – ค้นหาคำในไฟล์

find – ค้นหาไฟล์

4. แก้ไขไฟล์จาก terminal

nano – editor แบบง่าย

vim – editor แบบมืออาชีพ

5. รันโปรเจกต์ Go และจัดการ process

go run – รันโปรแกรม

go build – คอมไพล์แอป

ps, top, kill – ดูและจัดการ process

6. ใช้ Git เบื้องต้น

7. การจัดการ Environment Variables

export – กำหนดตัวแปรใน session

เรียกใช้ตัวแปร

การโหลดค่าตัวแปรจากไฟล์ .env

ใช้ตัวแปรร่วมกับคำสั่งอื่น

ลบตัวแปรออกจาก environment

8. คำสั่ง Network ที่ควรรู้

ping – ตรวจสอบว่า host online หรือไม่

ตัวเลือก (option) ที่นิยมใช้บ่อย

ส่งจำนวนจำกัด (c)

กำหนดเวลาระหว่างการ ping (i)

แสดงเวลารวม (D)

ตรวจสอบด้วย IP โดยตรง

ใช้ IPv6 (6)

หมายเหตุสำหรับการใช้ในระบบ Linux/macOS:

curl – เรียก API

ตัวเลือก (option) ที่นิยมใช้บ่อย

แสดง header ของ response (i)

แสดงเฉพาะ HTTP status code (o /dev/null -w "%{http_code}" -s)

ส่งข้อมูลแบบ JSON (X POST -H "Content-Type: application/json" -d)

อ่านค่า header ที่ส่งกลับมา (I)

เก็บผลลัพธ์ลงไฟล์ (o)

ใช้กับไฟล์ .env ที่มี token หรือ env var

ใช้ curl ทดสอบ REST API เบื้องต้น

wget – ดาวน์โหลดไฟล์

ตัวเลือก (option) ที่ใช้บ่อย

1. O <filename> – เปลี่ยนชื่อไฟล์ที่บันทึก

2. c – ดาวน์โหลดต่อ (resume) หากไฟล์ยังไม่เสร็จ

3. -limit-rate=200k – จำกัดความเร็วในการดาวน์โหลด

4. -no-check-certificate – ข้ามการตรวจสอบ SSL (ใช้กับ HTTPS)

5. -user=<username> --password=<password> – สำหรับเว็บไซต์ที่ต้อง login

6. r – ดาวน์โหลดแบบ recursive (ทั้ง directory)

7. -no-parent – ไม่ขึ้นไปโหลด path ด้านบน

ตัวอย่างการใช้งานร่วมกัน

netstat – ดูว่าโปรแกรมไหนเปิดพอร์ต

ความหมายของแต่ละ option:

ตัวอย่างผลลัพธ์:

lsof – ดูว่าใครใช้พอร์ต

ตัวอย่างผลลัพธ์:

9. ประมวลผลข้อความ

awk – ดึง column จากข้อความ

sed – แก้ข้อความในไฟล์

jq – แก้ไข JSON

10. เขียน Shell Script เบื้องต้น

11. เสริม productivity

สมมติฐาน: โปรเจกต์ Go ชื่อ `myapp`

`pwd` – แสดง path ปัจจุบัน

`ls` – แสดงรายการไฟล์

`cd` – เปลี่ยนโฟลเดอร์

`touch` – สร้างไฟล์เปล่า

`mkdir` – สร้างโฟลเดอร์

`rm` – ลบไฟล์หรือโฟลเดอร์

`cat` – อ่านไฟล์ทั้งหมด

`less` – อ่านไฟล์แบบ scroll

`head` และ `tail` – ดูต้นหรือท้ายไฟล์

`echo` – แสดงข้อความ / ตัวแปร

`grep` – ค้นหาคำในไฟล์

`find` – ค้นหาไฟล์

`nano` – editor แบบง่าย

`vim` – editor แบบมืออาชีพ

`go run` – รันโปรแกรม

`go build` – คอมไพล์แอป

`ps`, `top`, `kill` – ดูและจัดการ process

`export` – กำหนดตัวแปรใน session

การโหลดค่าตัวแปรจากไฟล์ `.env`

`ping` – ตรวจสอบว่า host online หรือไม่

ตัวเลือก (`option`) ที่นิยมใช้บ่อย

ส่งจำนวนจำกัด (`c`)

กำหนดเวลาระหว่างการ ping (`i`)

แสดงเวลารวม (`D`)

ใช้ IPv6 (`6`)

`curl` – เรียก API

ตัวเลือก (`option`) ที่นิยมใช้บ่อย

แสดง header ของ response (`i`)

แสดงเฉพาะ HTTP status code (`o /dev/null -w "%{http_code}" -s`)

ส่งข้อมูลแบบ JSON (`X POST -H "Content-Type: application/json" -d`)

อ่านค่า header ที่ส่งกลับมา (`I`)

เก็บผลลัพธ์ลงไฟล์ (`o`)

ใช้กับไฟล์ `.env` ที่มี token หรือ env var

ใช้ `curl` ทดสอบ REST API เบื้องต้น

`wget` – ดาวน์โหลดไฟล์

ตัวเลือก (`option`) ที่ใช้บ่อย

1. `O <filename>` – เปลี่ยนชื่อไฟล์ที่บันทึก

2. `c` – ดาวน์โหลดต่อ (resume) หากไฟล์ยังไม่เสร็จ

3. `-limit-rate=200k` – จำกัดความเร็วในการดาวน์โหลด

4. `-no-check-certificate` – ข้ามการตรวจสอบ SSL (ใช้กับ HTTPS)

5. `-user=<username> --password=<password>` – สำหรับเว็บไซต์ที่ต้อง login

6. `r` – ดาวน์โหลดแบบ recursive (ทั้ง directory)

7. `-no-parent` – ไม่ขึ้นไปโหลด path ด้านบน

`netstat` – ดูว่าโปรแกรมไหนเปิดพอร์ต

`lsof` – ดูว่าใครใช้พอร์ต

`awk` – ดึง column จากข้อความ

`sed` – แก้ข้อความในไฟล์

`jq` – แก้ไข JSON

1. เปลี่ยนจาก `docker_sd_configs` เป็น `kubernetes_sd_configs`

ตัวอย่างไฟล์ `promtail.yaml`