Docker Multi-stage Build Log Management ELK — คู่มือฉบับสมบูรณ์ 2026 | SiamCafe Blog

Docker Multi-stage Build และ ELK Stack คืออะไร — ทำความเข้าใจให้ตรงจุดก่อนลงมือ

หลายคนอ่านหัวข้อนี้แล้วสับสนว่ามันคือเรื่องเดียวกันหรือคนละเรื่อง ตอบตรง ๆ คือมันคือสองเทคโนโลยีที่ทำงานร่วมกันอย่างลงตัว Docker Multi-stage Build

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

ส่วน ELK Stack คือชุดเครื่องมือจัดการบันทึกเหตุการณ์ ประกอบด้วย Elasticsearch ที่ทำหน้าที่ค้นหาและจัดเก็บ, Logstash ที่รับและแปลงข้อมูล, และ Kibana ที่แสดงผลเป็นแดชบอร์ดสวยงาม บางคนเพิ่ม Beats เข้าไปอีกชั้นเพื่อส่งข้อมูลจากเครื่องปลายทาง ก็จะกลายเป็นกลุ่มที่เรียกว่า Elastic Stack

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

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

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

หัวใจของมัลติสเตจบิลด์คือการแยกสภาพแวดล้อมของ "การสร้าง" ออกจาก "การรัน" ให้ขาดจากกัน ยกตัวอย่างแอปพลิเคชันภาษาโก

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

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

โครงสร้าง Dockerfile แบบพื้นฐานจะเป็นแบบนี้ ขั้นแรกตั้งชื่อสเตจว่า บิลเดอร์ ใช้รูปภาพที่มีคอมไพเลอร์ สั่งคัดลอกซอร์สโค้ดเข้าไปแล้วรันคำสั่งสร้างไฟล์ปฏิบัติการ ขั้นที่สองเริ่มจากรูปภาพเปล่าที่เล็กมาก เช่น อัลไพน์ แล้วใช้คำสั่งคัดลอกจากสเตจแรกเฉพาะไฟล์ที่รันได้เท่านั้น ตัวอย่างโค้ด

FROM golang:1.22 AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 go build -o myapp

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

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

เมื่อพูดถึงการติดตั้ง ELK บนเซิร์ฟเวอร์อูบุนตู วิธีที่ผมแนะนำสำหรับปี 2026 คือรันผ่านดอกเกอร์คอมโพสทั้งหมด เพราะจัดการง่าย ย้ายเครื่องได้

และไม่เปื้อนระบบปฏิบัติการหลัก ก่อนเริ่มต้องปรับค่าของเคอร์เนลก่อนหนึ่งข้อ เพราะ Elasticsearch ต้องการค่าการจับคู่หน่วยความจำเสมือนที่สูงกว่าค่าเริ่มต้น ให้รันคำสั่งปรับค่า แล้วเพิ่มบรรทัดลงในไฟล์การตั้งค่าเพื่อให้คงอยู่หลังรีบูต

ติดตั้ง ELK Stack บนเซิร์ฟเวอร์จริงด้วย Docker Compose

เมื่อพูดถึงการติดตั้ง ELK บนเซิร์ฟเวอร์อูบุนตู วิธีที่ผมแนะนำสำหรับปี 2026 คือรันผ่านดอกเกอร์คอมโพสทั้งหมด เพราะจัดการง่าย ย้ายเครื่องได้ และไม่เปื้อนระบบปฏิบัติการหลัก ก่อนเริ่มต้องปรับค่าของเคอร์เนลก่อนหนึ่งข้อ เพราะ Elasticsearch ต้องการค่าการจับคู่หน่วยความจำเสมือนที่สูงกว่าค่าเริ่มต้น ให้รันคำสั่งปรับค่า แล้วเพิ่มบรรทัดลงในไฟล์การตั้งค่าเพื่อให้คงอยู่หลังรีบูต

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

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

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

องค์ประกอบ	หน้าที่หลัก	พอร์ตเริ่มต้น	ทรัพยากรแนะนำ
Elasticsearch	จัดเก็บและค้นหาบันทึก	9200	4 GB หน่วยความจำขึ้นไป
Logstash	รับ แปลง และส่งต่อข้อมูล	5044	2 GB หน่วยความจำ
Kibana	แดชบอร์ดและภาพข้อมูล	5601	1 GB หน่วยความจำ

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

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

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

เชื่อมบันทึกเหตุการณ์จากคอนเทนเนอร์เข้าสู่ ELK แบบรวมศูนย์

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

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

ระบบบันทึกรวมศูนย์คือกล่องสมบัติที่มีข้อมูลเชิงลึกขององค์กรทั้งหมด ถ้าถูกเจาะ ผู้ไม่หวังดีจะรู้ทุกอย่างเกี่ยวกับระบบเรา

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

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

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

Security Hardening และการปรับแต่งเพื่อโปรดักชัน

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

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

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

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

ตัวอย่างการใช้งานจริง — ไล่ปัญหาและเฝ้าระวังระบบเทรดแบบเรียลไทม์

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

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

Docker Multi-stage Build คืออะไร และช่วยลดขนาดอิมเมจได้อย่างไร?

Docker Multi-stage Build คือเทคนิคการเขียน Dockerfile ที่แบ่งกระบวนการสร้างอิมเมจออกเป็นหลายขั้นตอน ขั้นแรกเรียกว่า builder ใช้รูปภาพที่มีเครื่องมือคอมไพล์ครบครัน ส่วนขั้นสุดท้ายจะคัดลอกเฉพาะไฟล์ที่จำเป็นไปวางในอิมเมจขนาดเล็ก เช่น Alpine ยกตัวอย่างแอปพลิเคชันภาษาโก อิมเมจที่ใช้คอมไพล์อาจมีขนาดกว่าหนึ่งกิกะไบต์ แต่ไฟล์ที่รันได้จริงหลังคอมไพล์เสร็จมีขนาดแค่สิบกว่าเมกะไบต์เท่านั้น ถ้าไม่ใช้มัลติสเตจ เราต้องแบกอิมเมจใหญ่ขึ้นโปรดักชันโดยไม่จำเป็น ผลลัพธ์ของการใช้เทคนิคนี้คืออิมเมจเล็กลงหลายเท่า พื้นที่โจมตีน้อยลง และกระบวนการส่งมอบงานเร็วขึ้นอย่างชัดเจน

เมื่อใช้ Alpine ในคอนเทนเนอร์ ควรจัดการบันทึกเหตุการณ์ (logs) อย่างไรให้ถูกต้อง?

แนวปฏิบัติที่ถูกต้องคือให้แอปพลิเคชันเขียนบันทึกออกทางเอาต์พุตมาตรฐาน (stdout) และข้อผิดพลาดมาตรฐาน (stderr) เท่านั้น แล้วให้ตัว Docker Engine เป็นผู้จัดการเก็บสตรีมเหล่านี้ไว้เป็นไฟล์บันทึกของคอนเทนเนอร์โดยอัตโนมัติ วิธีนี้เรียกว่าการบันทึกแบบสิบสองปัจจัย (12-factor logging) เหตุผลสำคัญคือเมื่อใช้อิมเมจเล็กอย่าง Alpine ระบบบันทึกมาตรฐานอย่าง syslog อาจไม่มีในคอนเทนเนอร์เลย และถ้าเขียนบันทึกลงไฟล์ภายในคอนเทนเนอร์ เมื่อคอนเทนเนอร์ถูกลบ บันทึกก็จะหายไปด้วย นอกจากนี้ยังเสียทั้งการหมุนเวียนไฟล์อัตโนมัติและการรวมศูนย์ข้อมูลเข้าสู่ ELK ในขั้นตอนถัดไป

ELK Stack ประกอบด้วยอะไรบ้าง และแต่ละส่วนทำหน้าที่อะไร?

ELK Stack คือชุดเครื่องมือจัดการบันทึกเหตุการณ์ที่ประกอบด้วยสามส่วนหลัก ได้แก่ Elasticsearch ที่ทำหน้าที่ค้นหาและจัดเก็บข้อมูล, Logstash ที่รับและแปลงข้อมูลจากแหล่งต่าง ๆ ให้อยู่ในรูปแบบที่ใช้งานได้ และ Kibana ที่แสดงผลข้อมูลเป็นแดชบอร์ดสวยงาม วิเคราะห์และสร้างกราฟได้ นอกจากนี้บางองค์กรยังเพิ่ม Beats เข้าไปอีกชั้นหนึ่งเพื่อทำหน้าที่ส่งข้อมูลจากเครื่องปลายทางเข้าสู่ระบบกลาง เมื่อรวม Beats เข้ามาด้วยแล้วกลุ่มเครื่องมือทั้งหมดจะเรียกว่า Elastic Stack ข้อดีคือบันทึกจากทุกคอนเทนเนอร์จะมารวมกันที่เดียว ค้นหาได้ในไม่กี่วินาที และตั้งการแจ้งเตือนอัตโนมัติได้

การติดตั้ง ELK บนเซิร์ฟเวอร์ Ubuntu ควรเตรียมอะไรก่อนเริ่มต้น?

สำหรับปี 2026 วิธีที่แนะนำคือรัน ELK ผ่าน Docker Compose ทั้งหมด เพราะจัดการง่าย ย้ายเครื่องได้สะดวก และไม่เปื้อนระบบปฏิบัติการหลัก ก่อนเริ่มติดตั้งมีสิ่งหนึ่งที่ต้องเตรียมคือการปรับค่าของเคอร์เนล เนื่องจาก Elasticsearch ต้องการค่าการจับคู่หน่วยความจำเสมือน (virtual memory mapping) ที่สูงกว่าค่าเริ่มต้นของระบบ จึงต้องรันคำสั่งปรับค่าก่อน มิฉะนั้น Elasticsearch อาจไม่สามารถเริ่มทำงานได้ นอกจากนี้ควรวางแผนเรื่องทรัพยากรเครื่องด้วย เพราะ ELK ทั้งชุดใช้หน่วยความจำค่อนข้างมาก การรันผ่าน Docker Compose ยังทำให้อัปเดตและย้ายเซิร์ฟเวอร์ได

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

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

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

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

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

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