Grafana Loki LogQL Distributed System — คู่มือฉบับสมบูรณ์ 2026 | SiamCafe Blog

Grafana Loki กับ LogQL ในระบบแบบกระจายคืออะไร — ทำความเข้าใจจากพื้นฐาน

Grafana Loki คือระบบจัดเก็บและค้นหาบันทึกเหตุการณ์ (log) แบบโอเพนซอร์สที่พัฒนาโดยทีม Grafana Labs จุดขายหลักของมันคือการออกแบบให้

"จัดเก็บเฉพาะสิ่งที่จำเป็น" — Loki ไม่ทำการจัดทำดัชนีเนื้อหาข้อความของ log ทั้งหมดเหมือน Elasticsearch แต่จะจัดทำดัชนีเฉพาะชุดป้ายกำกับ (labels) เท่านั้น ทำให้ประหยัดพื้นที่จัดเก็บได้มหาศาล บางระบบที่ผมดูแลอยู่ลดพื้นที่เก็บ log ลงได้ถึงสิบเท่าเมื่อเทียบกับการใช้แบบเดิม

แนวคิดนี้ฟังดูง่ายแต่มีนัยสำคัญมากในทางปฏิบัติ เพราะต้นทุนที่แพงที่สุดของระบบรวมศูนย์ log ในปัจจุบันไม่ใช่ซีพียูหรือหน่วยความจำ แต่คือพื้นที่จัดเก็บและดัชนีที่โตเร็วกว่าข้อมูลตัวเองหลายเท่า เมื่อ Loki จัดดัชนีเฉพาะป้ายกำกับ ขนาดดัชนีจึงเล็กกว่าตัวข้อมูลหลายสิบเท่า ทำให้คุณเก็บ log ย้อนหลังได้นานขึ้นด้วยงบเท่าเดิม หรือลดงบลงได้โดยไม่ต้องลดช่วงเวลาเก็บรักษา ข้อแลกเปลี่ยนคือการค้นหาข้อความจะต้องสแกนข้อมูลจริง จึงต้องเขียนคำค้นหาอย่างมีวินัย ซึ่งเราจะลงลึกในหัวข้อ LogQL ด้านล่าง

LogQL คือภาษาค้นหาของ Loki ซึ่งเขียนขึ้นให้คุ้นเคยกับผู้ที่ใช้ PromQL ของ Prometheus อยู่แล้ว คุณสามารถกรอง log ด้วยตัวเลือกป้ายกำกับ ใช้ตัวกรองข้อความ และแปลง log เป็นตัวเลขเมตริกเพื่อสร้างกราฟบน Grafana ได้ในบรรทัดเดียว เช่น การนับจำนวนข้อผิดพลาดต่อนาทีของแต่ละบริการ จุดนี้คือสิ่งที่ทำให้ Loki ต่างจากระบบเก็บ log รุ่นเก่าที่เอาไว้ "เขียนไว้ก่อนแล้วค่อยหา" — Loki เปลี่ยน log ให้เป็นแหล่งข้อมูลเชิงวิเคราะห์ที่ใช้ตอบคำถามธุรกิจได้เลย เช่น อัตราคำสั่งซื้อที่ล้มเหลวรายชั่วโมง หรือประเทศที่มีอัตราข้อผิดพลาดการชำระเงินสูงสุด

เมื่อพูดถึง "ระบบแบบกระจาย" หมายถึงการติดตั้ง Loki ในโหมด Microservices โดยแยกส่วนประกอบออกจากกัน เช่น ตัวรับข้อมูล (Distributor), ตัวเขียน (Ingester), ตัวค้นหา (Querier), ตัวเชื่อมคำถาม (Query Frontend) และที่เก็บข้อมูลแบบวัตถุ เช่น S3 หรือ MinIO ซึ่งแต่ละส่วนสามารถขยายจำนวนได้อิสระตามภาระงาน แตกต่างจากโหมด Single Binary ที่รวมทุกอย่างไว้ในกระบวนการเดียวซึ่งเหมาะกับระบบขนาดเล็กเท่านั้น ข้อดีของโหมดกระจายคือเมื่อการค้นหาหนักก็ขยายเฉพาะฝั่งค้นหา เมื่อข้อมูลเข้าหนาแน่นก็ขยายเฉพาะฝั่งรับข้อมูล ไม่ต้องขยายทั้งระบบ

จากประสบการณ์ของผมซึ่งทำงานด้านโครงสร้างพื้นฐานมากว่าสิบสามปี ควบคู่กับการเทรดฟอเร็กซ์และวิเคราะห์ข้อมูลผ่านระบบอัตโนมัติ ผมมองว่าการรวม Loki, LogQL และสถาปัตยกรรมแบบกระจายเข้าด้วยกัน คือทักษะที่ผู้ดูแลระบบและวิศวกรในไทยควรมีติดตัวในปี 2026 เพราะระบบปัจจุบันถูกแยกออกเป็นคอนเทนเนอร์นับร้อย การหา log แบบเข้าไปไล่ไฟล์บนเซิร์ฟเวอร์ทีละเครื่องนั้นไม่มีทางรอดแล้ว ผมเคยใช้เวลาเกือบสองชั่วโมงในการไล่ข้อผิดพลาดหนึ่งจุดที่กระจายอยู่ในคอนเทนเนอร์ห้าตัวบนเครื่องสามเครื่อง — ถ้ามีระบบรวมศูนย์ตั้งแต่แรก ใช้เวลาไม่ถึงห้านาที

อย่างไรก็ตาม สถาปัตยกรรมแบบกระจายมาพร้อมความซับซ้อน — ต้องคิดเรื่องการกู้คืนข้อมูล การควบคุมการทำงานระหว่างส่วนประกอบ และการตรวจสอบสุขภาพของแต่ละโหนด ซึ่งเป็นเนื้อหาหลักที่บทความนี้จะพาไปลงมือทำจริงทีละขั้น ตั้งแต่การวางแผนฮาร์ดแวร์ การติดตั้ง การเขียนคำสั่งค้นหา ไปจนถึงการเฝ้าดูและกู้คืนระบบเมื่อเกิดเหตุ

สถาปัตยกรรมแบบกระจายของ Loki แบ่งการทำงานออกเป็นส่วนประกอบที่ชัดเจน ซึ่งแต่ละส่วนสื่อสารกันผ่านเกตเวย์และที่เก็บข้อมูลกลาง

การเข้าใจบทบาทของแต่ละส่วนจะช่วยให้คุณวางแผนขนาดระบบและแก้ปัญหาได้อย่างถูกจุด เพราะเมื่อเกิดปัญหาขึ้น อาการที่เห็นจากภายนอกมักกว้าง แต่ต้นเหตุจริงมักอยู่ที่ส่วนประกอบใดส่วนประกอบหนึ่งเท่านั้น

สถาปัตยกรรมแบบกระจายของ Loki แบ่งการทำงานออกเป็นส่วนประกอบที่ชัดเจน ซึ่งแต่ละส่วนสื่อสารกันผ่านเกตเวย์และที่เก็บข้อมูลกลาง การเข้าใจบทบาทของแต่ละส่วนจะช่วยให้คุณวางแผนขนาดระบบและแก้ปัญหาได้อย่างถูกจุด เพราะเมื่อเกิดปัญหาขึ้น อาการที่เห็นจากภายนอกมักกว้าง แต่ต้นเหตุจริงมักอยู่ที่ส่วนประกอบใดส่วนประกอบหนึ่งเท่านั้น

ส่วนประกอบหลักและหน้าที่

Distributor เป็นด่านหน้ารับข้อมูล log จากตัวเก็บรวมเช่น Promtail หรือ Alloy มันตรวจสอบความถูกต้อง คำนวณค่าแฮชของสตรีม log แล้วกระจายข้อมูลไปยัง Ingester อย่างสม่ำเสมอด้วยวิธีแฮชวงแหวน เพื่อให้ภาระงานเท่ากันและข้อมูลชุดเดียวกันไปอยู่ที่โหนดเดียวกัน จุดสำคัญที่มักถูกมองข้ามคือ Distributor เป็นตัวบังคับใช้ขีดจำกัดอัตราการรับข้อมูลด้วย หากคุณส่งข้อมูลเกินขีดที่ตั้งไว้ Distributor จะตอบกลับด้วยรหัสข้อผิดพลาด ทำให้ตัวเก็บรวมด้านหน้าต้องทำซ้ำ ถ้าเห็นอาการ log หายเป็นช่วง ๆ ให้เช็กจุดนี้ก่อน

Ingester เก็บข้อมูลไว้ในหน่วยความจำชั่วคราวก่อนบีบอัดเป็นเซกเมนต์แล้วเขียนลงที่เก็บข้อมูลถาวร ช่วงเวลาระหว่างที่ข้อมูลยังอยู่ในหน่วยความจำเป็นช่วงที่เสี่ยงที่สุดของระบบทั้งหมด ปัจจัยทำซ้ำ (Replication Factor) คือกุญแจสำคัญ — หากตั้งค่าเป็นสาม ข้อมูลจะถูกคัดลอกไปยัง Ingester สามโหนด ทำให้ระบบยังไม่สูญเสียข้อมูลแม้โหนดหนึ่งล่ม นอกจากนี้ Ingester ยังต้องบริหารหน่วยความจำอย่างระมัดระวัง เพราะจำนวนสตรีมที่มีชีวิตอยู่พร้อมกัน (active streams) คือตัวกำหนดความต้องการหน่วยความจำโดยตรง ระบบที่มีป้ายกำกับเยอะเกินไปจะทำให้จำนวนสตรีมระเบิดจนหน่วยความจำหมด ซึ่งเป็นปัญหาที่ผมเจอบ่อยที่สุดในการให้คำปรึกษา

Querier ทำหน้าที่รันคำสั่ง LogQL โดยดึงข้อมูลทั้งจาก Ingester (ข้อมูลล่าสุดที่ยังอยู่ในหน่วยความจำ) และจากที่เก็บข้อมูลถาวร ส่วน Query Frontend ช่วยแบ่งคำถามที่ครอบคลุมช่วงเวลายาวออกเป็นชิ้นเล็ก ๆ รันขนานกัน แล้วรวมผลลัพธ์ พร้อมแคชผลลัพธ์เพื่อลดภาระซ้ำซ้อน ในทีมที่หลายคนเปิดแดชบอร์ดเดียวกันในตอนเช้า การแคชผลลัพธ์ช่วยลดภาระฝั่งค้นหาได้ชัดเจนมาก

ที่เก็บข้อมูลยืนยันได้เช่น S3, GCS, Azure Blob หรือ MinIO คือจุดจบของข้อมูล เมื่อข้อมูลเป็นระเบียบแบบข้อมูลวัตถุแล้ว Loki ยังใช้ Compactor มาจัดการลบข้อมูลตามช่วงเวลาเก็บรักษา และใช้ Index Gateway เพื่อไม่ให้ Querier ทุกตัวต้องโหลดดัชนีเอง ซึ่งช่วยลดการใช้หน่วยความจำฝั่งค้นหาลงอย่างมากในกลุ่มที่มี Querier จำนวนมาก

ส่วนประกอบ	หน้าที่หลัก	ปัจจัยขนาดที่ต้องพิจารณา
Distributor	รับและกระจายข้อมูล log	จำนวนสตรีม log ต่อวินาที
Ingester	เขียนข้อมูลลงที่เก็บถาวร	จำนวนสตรีม × ปัจจัยทำซ้ำ, หน่วยความจำ
Querier	ค้นหาและประมวลผล LogQL	ปริมาณการค้นหา, ช่วงเวลาค้นหา
Query Frontend	แบ่งคำถามและแคชผลลัพธ์	ความยาวช่วงเวลาค้นหาเฉลี่ย
Compactor	ลบข้อมูลตามช่วงเก็บรักษา	ปริมาณข้อมูลสะสม
ที่เก็บข้อมูลวัตถุ	เก็บข้อมูลและดัชนีถาวร	ขนาดข้อมูลรวม, ต้นทุนต่อกิกะไบต์

ก่อนลงมือติดตั้ง การประเมินขนาดระบบให้ถูกต้องคือสิ่งที่ช่วยประหยัดเวลาและงบประมาณได้มากที่สุด

ข้อผิดพลาดที่ผมเห็นบ่อยที่สุดคือการประเมินหน่วยความจำของ Ingester ต่ำเกินไป ทำให้เกิดการหยุดทำงานเมื่อข้อมูลเข้าหนาแน่น อีกประเด็นที่มักถูกลืมคือความเร็วดิสก์ของเครื่องที่รัน Ingester เพราะแม้ข้อมูลจะถูกเขียนลงที่เก็บวัตถุในท้ายที่สุด แต่การเขียนไฟล์ชั่วคราวและการกู้คืนหลังรีสตาร์ตต้องใช้ดิสก์ที่เร็วจริง ๆ ไม่ใช่ดิสก์กลไกที่อ่านเขียนต่ำกว่าร้อยเมกะไบต์ต่อวินาที

การวางแผนฮาร์ดแวร์และการติดตั้งบนเซิร์ฟเวอร์จริง

ก่อนลงมือติดตั้ง การประเมินขนาดระบบให้ถูกต้องคือสิ่งที่ช่วยประหยัดเวลาและงบประมาณได้มากที่สุด ข้อผิดพลาดที่ผมเห็นบ่อยที่สุดคือการประเมินหน่วยความจำของ Ingester ต่ำเกินไป ทำให้เกิดการหยุดทำงานเมื่อข้อมูลเข้าหนาแน่น อีกประเด็นที่มักถูกลืมคือความเร็วดิสก์ของเครื่องที่รัน Ingester เพราะแม้ข้อมูลจะถูกเขียนลงที่เก็บวัตถุในท้ายที่สุด แต่การเขียนไฟล์ชั่วคราวและการกู้คืนหลังรีสตาร์ตต้องใช้ดิสก์ที่เร็วจริง ๆ ไม่ใช่ดิสก์กลไกที่อ่านเขียนต่ำกว่าร้อยเมกะไบต์ต่อวินาที

สเปกแนะนำตามขนาดระบบ

ระดับ	การใช้งาน	สเปกขั้นต่ำ	สเปกแนะนำสำหรับงานจริง
ทดลอง	เรียนรู้, ระบบเล็ก	2 คอร์, 4 กิกะไบต์, ดิสก์ 50 กิกะไบต์	4 คอร์, 8 กิกะไบต์
ระดับกลาง	องค์กรร้อยเครื่อง	4 คอร์, 16 กิกะไบต์	8 คอร์, 32 กิกะไบต์, ดิสก์เอ็นวีเม 200 กิกะไบต์
ขนาดใหญ่	ระบบกระจายเต็มรูปแบบ	8 คอร์, 32 กิกะไบต์ต่อโหนด	16 คอร์, 64 กิกะไบต์ต่อโหนด, ดิสก์เอ็นวีเม

สำหรับการติดตั้งบนอุบุนตู ให้เริ่มจากการอัปเดตระบบและติดตั้งเครื่องมือพื้นฐาน:

sudo apt update && sudo apt upgrade -y sudo apt install -y curl wget unzip jq

จากนั้นดาวน์โหลดไบนารีของ Loki เวอร์ชันล่าสุด สร้างผู้ใช้เฉพาะสำหรับรันบริการ และกำหนดโฟลเดอร์เก็บข้อมูล:

wget https://github.com/grafana/loki/releases/latest/download/loki-linux-amd64.zip unzip loki-linux-amd64.zip sudo mv loki-linux-amd64 /usr/local/bin/loki sudo useradd --no-create-home --shell /bin/false loki sudo mkdir -p /var/lib/loki /etc/loki sudo chown -R loki:loki /var/lib/loki

จากนั้นสร้างไฟล์การตั้งค่าพื้นฐานแบบโหมด Single Binary ก่อนเพื่อทดสอบ:

auth_enabled: false

server: httplistenport: 3100

common: path_prefix: /var/lib/loki replication_factor: 1 ring: kvstore: store: inmemory

schema_config: configs:

• from: 2026-01-01

store: tsdb object_store: filesystem schema: v13 index: prefix: index_ period: 24h

สร้างไฟล์หน่วยสำหรับ Systemd เพื่อให้บริการเริ่มอัตโนมัติเมื่อเครื่องรีสตาร์ต และเปิดใช้งาน:

[Unit] Description=Loki Log Aggregation After=network.target

[Service] User=loki ExecStart=/usr/local/bin/loki -config.file=/etc/loki/loki-config.yml Restart=on-failure LimitNOFILE=65536

[Install] WantedBy=multi-user.target

LogQL คือหัวใจที่ทำให้ Loki มีค่ากว่าการเก็บ log อย่างเดียว โครงสร้างของมันแบ่งเป็นสองส่วนคือตัวเลือกสตรีม ตามด้วยตัวกรองและตัวแปลง

ตัวเลือกสตรีมใช้ป้ายกำกับที่เป็นดัชนี จึงเร็วมาก ส่วนตัวกรองข้อความทำงานหลังจากนั้น เข้าใจง่าย ๆ คือ ยิ่งคัดแคบด้วยป้ายกำกับได้มากเท่าไร ปริมาณข้อมูลที่ระบบต้องสแกนก็ยิ่งน้อยลงเท่านั้น ความเร็วของคำค้นหาใน Loki จึงขึ้นอยู่กับวินัยการเขียนคำค้นหาของผู้ใช้มากกว่าฮาร์ดแวร์อย่างที่หลายคนคิด

แนวปฏิบัติที่ผมยึดมาตลอดคือ "เริ่มเล็ก ขยายเมื่อมีตัวเลขจริง" ระบบจำนวนมากที่คิดว่าต้องใช้โหมดกระจายตั้งแต่วันแรก จริง ๆ แล้ว Single Binary ที่ปรับตั้งดีรองรับได้สบายจนถึงปริมาณหลักสิบกิกะไบต์ต่อวัน การกระโดดไปโหมดกระจายโดยไม่มีความจำเป็นเพิ่มทั้งต้นทุน จุดล้มเหลว และภาระการดูแล ให้ตั้งเกณฑ์ชัดเจน เช่น เมื่อปริมาณข้อมูลเข้าเกินสามสิบกิกะไบต์ต่อวัน หรือเมื่อเวลาค้นหาเริ่มเกินที่ทีมยอมรับได้ จึงค่อยแยกส่วนประกอบออกทีละบทบาท โดยเริ่มจากแยกฝั่งค้นหาออกก่อน เพราะเป็นส่วนที่แยกง่ายและเห็นผลเร็วที่สุด

การเขียนคำสั่ง LogQL — จากการค้นหาพื้นฐานถึงการวิเคราะห์ขั้นสูง

LogQL คือหัวใจที่ทำให้ Loki มีค่ากว่าการเก็บ log อย่างเดียว โครงสร้างของมันแบ่งเป็นสองส่วนคือตัวเลือกสตรีม ตามด้วยตัวกรองและตัวแปลง ตัวเลือกสตรีมใช้ป้ายกำกับที่เป็นดัชนี จึงเร็วมาก ส่วนตัวกรองข้อความทำงานหลังจากนั้น เข้าใจง่าย ๆ คือ ยิ่งคัดแคบด้วยป้ายกำกับได้มากเท่าไร ปริมาณข้อมูลที่ระบบต้องสแกนก็ยิ่งน้อยลงเท่านั้น ความเร็วของคำค้นหาใน Loki จึงขึ้นอยู่กับวินัยการเขียนคำค้นหาของผู้ใช้มากกว่าฮาร์ดแวร์อย่างที่หลายคนคิด

รูปแบบคำสั่งที่ใช้บ่อย

ค้นหา log ทั้งหมดของบริการหนึ่ง:

{service="payment-api"}

กรองเฉพาะบรรทัดที่มีข้อผิดพลาด โดยตัวกรองทำงานหลังการเลือกสตรีม:

{service="payment-api", env="production"} |= "timeout"

ใช้นิพจน์ทั่วไปเพื่อความยืดหยุ่น และใช้ตัวกรองลบเพื่อตัดเสียงรบกวน:

{job="nginx"} |~ "status=(5..)" != "healthcheck"

แปลง log เป็นตัวเลขเมตริกเพื่อสร้างกราฟอัตราข้อผิดพลาดต่อนาที:

sum(rate({service="payment-api"} |= "ERROR" [5m])) / sum(rate({service="payment-api"} [5m]))

การแยกค่าด้วยตัวแยกวิเคราะห์

จุดที่ทำให้ LogQL ทรงพลังคือตัวแยกวิเคราะห์ เช่น ตัวแยกรูปแบบเจซัน, ตัวแยกรูปแบบล็อกเอฟเอ็มที และตัวแยกรูปแบบข้อความคงที่ ตัวอย่างเช่น log ของแอปเป็นรูปแบบเจซัน:

{service="payment-api"} | json | status >= 500 | lineformat "{{.method}} {{.path}} took {{.durationms}}ms"

สำหรับ log แบบข้อความที่มีโครงสร้างคงที่ ใช้ตัวแยกแบบรูปแบบ:

{job="nginx"} | pattern " - - "

จากนั้นสามารถจับกลุ่มตามฟิลด์ที่แยกออกมาได้ เช่น นับจำนวนคำขอตามรหัสสถานะ:

sum by (status) (countovertime({job="nginx"} | pattern " - -

คำถามที่พบบ่อย

Grafana Loki ต่างจาก Elasticsearch อย่างไร และทำไมจึงประหยัดพื้นที่จัดเก็บกว่า?

ความแตกต่างสำคัญที่สุดอยู่ที่วิธีการจัดทำดัชนี (indexing) ครับ Elasticsearch จะจัดทำดัชนีเนื้อหาข้อความของ log ทั้งหมด ทำให้การค้นหาข้อความเร็วแต่ดัชนีโตเร็วกว่าตัวข้อมูลจริงหลายเท่า ส่วน Loki จะจัดทำดัชนีเฉพาะชุดป้ายกำกับ (labels) เท่านั้น ทำให้ขนาดดัชนีเล็กกว่าตัวข้อมูลหลายสิบเท่า จากประสบการณ์ตรง บางระบบที่ดูแลอยู่สามารถลดพื้นที่เก็บ log ลงได้ถึงสิบเท่าเมื่อเทียบกับวิธีเดิม ข้อแลกเปลี่ยนคือการค้นหาข้อความจะต้องสแกนข้อมูลจริง จึงต้องเขียนคำค้นหาด้วย LogQL อย่างมีวินัย ใช้ตัวเลือกป้ายกำกับให้แคบที่สุดก่อน แล้วค่อยกรองข้อความทีหลัง ผลลัพธ์คือคุณเก็บ log ย้อนหลังได้นานขึ้นด้วยงบเท่าเดิม เพราะต้นทุนที่แพงที่สุดของระบบรวมศูนย์ log ในปัจจุบันไม่ใช่ซีพียูหรือหน่วยความจำ แต่เป็นพื้นที่จัดเก็บและดัชนีที่โตเร็วกว่าข้อมูลตัวเองหลายเท่า

ส่วนประกอบหลักในสถาปัตยกรรมแบบกระจายของ Loki มีอะไรบ้าง และแต่ละส่วนทำหน้าที่อะไร?

โหมด Microservices ของ Loki แบ่งการทำงานออกเป็นส่วนประกอบที่ชัดเจน ได้แก่ Distributor ที่ทำหน้าที่เป็นด่านหน้ารับข้อมูล log จากตัวเก็บรวมเช่น Promtail หรือ Alloy โดยตรวจสอบความถูกต้อง คำนวณค่าแฮชของสตรีม log แล้วกระจายข้อมูลไปยัง Ingester ด้วยวิธีแฮชวงแหวนเพื่อให้ภาระงานเท่ากัน และยังเป็นตัวบังคับใช้ขีดจำกัดอัตราการรับข้อมูลอีกด้วย ต่อมาคือ Ingester ที่เก็บข้อมูลไว้ในหน่วยความจำชั่วคราวก่อนบีบอัดเป็นเซกเมนต์แล้วเขียนลงที่เก็บข้อมูลถาวร ซึ่งช่วงเวลานี้เป็นช่วงที่เสี่ยงที่สุดของระบบทั้งหมด จึงต้องตั้งค่า Replication Factor ให้เหมาะสม เช่น ตั้งเป็นสามเพื่อคัดลอกข้อมูลไปยัง Ingester สามโหนด ส่วน Querier ทำหน้าที่ค้นหาข้อมูล และ Query Frontend ช่วยเชื่อมและจัดคิวคำถาม ทั้งหมดทำงานร่วมกับที่เก็บข้อมูลแบบวัตถุ เช่น S3 หรือ MinIO โดยแต่ละส่วนขยายจำนวนได้อิสระตามภาระงาน

เมื่อไรควรใช้โหมด Microservices แทนโหมด Single Binary ของ Loki?

โหมด Single Binary รวมทุกส่วนประกอบไว้ในกระบวนการเดียว เหมาะกับระบบขนาดเล็กเท่านั้น เพราะติดตั้งง่ายและดูแลสะดวก แต่เมื่อระบบของคุณโตขึ้นและมีคอนเทนเนอร์นับร้อยที่ส่ง log เข้ามาตลอดเวลา โหมดเดียวจะกลายเป็นคอขวดและแก้ปัญหาได้ยากเพราะทุกอย่างติดกันหมด โหมด Microservices เหมาะกับกรณีที่ภาระงานไม่สม่ำเสมอ เช่น เมื่อการค้นหาหนักก็ขยายเฉพาะฝั่ง Querier แต่เมื่อข้อมูลเข้าหนาแน่นก็ขยายเฉพาะฝั่ง Distributor และ Ingester โดยไม่ต้องขยายทั้งระบบ ช่วยประหยัดทรัพยากรและค่าใช้จ่าย อย่างไรก็ตามต้องยอมรับว่าสถาปัตยกรรมแบบกระจายมาพร้อมความซับซ้อนเพิ่มขึ้น คุณต้องคิดเรื่องการกู้คืนข้อมูล การควบคุมการทำงานระหว่างส่วนประกอบ และการตรวจสอบสุขภาพของแต่ละโหนดอย่างจริงจัง จึงควรเริ่มจาก Single Binary ถ้าปริมาณยังน้อย แล้วค่อยย้ายไป Microservices เมื่อจำเป

แนะนำเพิ่มเติม

🎯 เปิดบัญชี XM Forex → สมัคร

📱 แอป iCafeFX → ดาวน์โหลด

📊 สัญญาณฟรี → รับสัญญาณ

📚 คู่มือเทรด → SiamCafeBook

🤝 สมัคร Partner XM → pipaffiliates.com/c?c=72816&l=th&p=6