ผู้ที่อยู่ในวงการทำงานด้าน Infrastructure คงจะรู้จักเครื่องมือ Open Source หลายๆอย่างที่ช่วยทำให้งาน Operation ง่ายขึ้น และหนึ่งในนั้นคือ Elasticsearch ที่ KBTG เลือกใช้ทำงานหลากหลายประเภท โดยบทความนี้ผมจะมาอธิบายการใช้ในแง่ของงาน Operation คือการทำ Application Log ให้เป็นฟอร์แมตที่เหมาะสมกับการใช้ค้นหาและมอนิเตอร์ครับ
ทำไมต้อง Elasticsearch
หลายคนอาจจะเคยได้ยิน หรือเคยลองใช้งานกันมาบ้างแล้ว หลายคนอาจจะไม่เคยได้ยินเลยก็เป็นได้ ผมจึงต้องขอแนะนำฟีเจอร์หลักที่น่าสนใจของ Elasticsearch ก่อน นั่นคือตัวระบบที่ออกแบบมาเพื่อ “เสิร์ช” ตามชื่อ ดังนั้นการนำมาใช้เสิร์ชข้อมูลเกี่ยวกับ Log จึงเป็นงานที่เหมาะสมสำหรับเครื่องมือตัวนี้ครับ
แต่เดิมนั้น งานมอนิเตอร์ฝั่งแอพพลิเคชั่นของ KBTG จะเป็นการใช้ Tail เพื่อ Follow Log โดยเฉพาะในช่วงที่ Transaction เยอะ ๆ ซึ่งต้องมีหลุดแน่ ๆ ดังนั้นทีม Infra ของ KBTG จึงเริ่มคิดวิธีแก้ปัญหาที่จะทำให้ระบบมอนิเตอร์ฝั่งแอปพลิเคชันใช้งานได้ง่ายขึ้น และตรวจพบปัญหาต่าง ๆ ได้อย่างรวดเร็ว
ผลลัพธ์จึงออกมาลงที่ Elasticsearch เพื่อเก็บ Log จากระบบสำคัญ ๆ ที่ KBTG ดูแลอยู่ และเนื่องจาก Elasticsearch ไม่ได้ทำงานได้ด้วยตัวเอง แต่เป็นส่วนหนึ่งของ Elastic Stack ที่มีเครื่องมือน่าสนใจได้แก่ Elasticsearch, Logstash, Kibana และ Beats ดังนั้นเราจึงเริ่มนำทั้ง Stack เข้ามาช่วยในงานต่าง ๆ ของเรา โดยอุปกรณ์แต่ละอย่างใน Stack มีหน้าที่ดังนี้
- Elasticsearch มีหน้าที่เก็บข้อมูลไว้เพื่อทำการคิวรี
- Logstash มีหน้าที่ประมวลผลข้อมูลก่อนที่จะส่งเข้า Elasticsearch
- Kibana มีหน้าที่คิวรีข้อมูลและจัดการ Elasticsearch
- Beats เป็น Lightweight Data Shipper ที่จะคอยเก็บข้อมูลจาก Leaf Node และประมวลผลเบื้องต้นก่อนจะส่งเข้า Logstash หรือ Elasticsearch มีให้เลือกหลายรูปแบบตามลักษณะงานที่ใช้
สิ่งที่น่าสนใจอีกข้อของ Elasticsearch คือ ความง่ายในการใช้งาน เพราะแม้ว่า Elasticsearch จะใช้ภาษา Java ในการเขียนเป็นหลัก (เนื่องจากพื้นฐานของ Elasticsearch คือ Lucene ที่เป็นไลบรารีภาษา Java ของ Apache) แต่ตัว Elasticsearch ใช้ REST API ในการติดต่อกับไคลเอนท์ ดังนั้นเราจึงสามารถคิวรีข้อมูลออกมาได้โดยใช้เครื่องมือทั่วไป ไม่จำเป็นต้องใช้ไคลเอนท์เฉพาะทาง
ความท้าทายในการใช้ Elasticsearch
โดยปกติแล้ว บริษัทที่เริ่มต้นด้วยการพัฒนาแอพพลิเคชั่นยุคใหม่มักจะนิยมเขียน Log ออกมาเป็น JSON เพื่อเหมาะแก่การเก็บและนำไปวิเคราะห์ ระบบกลุ่มนั้นไม่ใช่เรื่องยาก แต่ที่ยากคือระบบเก่า ๆ ที่มักจะนิยมเขียน Log ขึ้นมาเป็นฟอร์แมตที่เหมาะกับให้คนอ่าน และเราต้องการจะ Extract ข้อมูลบางอย่างออกมาจาก Log นั้น ๆ ส่วนที่เหลือไม่ได้จำเป็น ทิ้งไปก็ได้
Elasticsearch ในตัวเองมีความสามารถในการตัด Log ระดับหนึ่ง แต่กับระบบเก่า ๆ เราต้องการมากกว่านั้น เราจึงต้องนำ Logstash ซึ่งเป็นเครื่องมืออีกชิ้นหนึ่งใน Elastic Stack เข้ามาช่วยตัด Log ให้เราได้ในสิ่งที่เราต้องการก่อนที่จะส่งเข้า Elasticsearch
สำหรับ Elasticsearch แล้ว เครื่องมือพื้นฐานที่จะนำมาใช้ต่อกับ Elasticsearch คือ Kibana ซึ่งก็เป็นหนึ่งในเครื่องมือ Elastic Stack
ช่วงแรก ๆ ที่เราเริ่มทดลองใช้ Elasticsearch ร่วมกับ Kibana ทั้งการเสิร์ชและมอนิเตอร์ ก็พบว่าสามารถทำงานได้ด้วยดี แต่พอถึงจุด ๆ หนึ่ง เราเริ่มพบกับข้อจำกัดของ Kibana เช่น
- Kibana ต่อกับ Elasticsearch ได้คลัสเตอร์เดียวเท่านั้น ถ้าจะเสิร์ช Log ข้ามคลัสเตอร์จะต้องนำ Elasticsearch ไปต่อกับ Elasticsearch คลัสเตอร์อื่น และใช้ความสามารถ Cross-Cluster Search
- ระบบกราฟของ Kibana ทำงานช้า ย้ายไปมาไม่ง่าย และถ้าจะเขียนปลั๊กอินเข้าไปด้วยค่อนข้างยาก
- Kibana เชื่อมต่อได้เฉพาะ Elasticsearch เท่านั้น
ช่วงหลัง เราจึงเริ่มค้นพบเครื่องมือชิ้นใหม่ที่ชื่อว่า Grafana ที่สามารถปิดจุดตายของ Kibana ได้ ตั้งแต่ระบบเชื่อมต่อ Data Source ที่หลากหลาย ไม่ว่าจะเป็น InfluxDB, Prometheus, StackDriver และอื่น ๆ อีกมากมาย แถมระบบกราฟก็ทำงานไวกว่า Kibana ที่สำคัญมี Panel ให้โหลดมากมาย ย้ายไปย้ายมาง่าย หรือจะเขียนปลั๊กอินเข้าไปเองก็ง่ายกว่าเยอะเลยครับ!
แต่ Grafana ก็ยังมีจุดตายสำคัญมาก คือระบบเสิร์ช Log ไม่สามารถสู้ Kibana ได้เลย และทำได้แค่คิวรี Elasticsearch และนำข้อมูลมาแสดง แต่ไม่สามารถจัดการอะไร Elasticsearch ได้
ในช่วงหลัง KBTG จึงเริ่มใช้ Grafana คู่กับ Kibana โดย Grafana จะเน้นการใช้งานประเภทมอนิเตอร์ ซึ่งเราจะนำข้อมูลจาก Elasticsearch ขึ้นมาแสดงร่วมกับข้อมูลจาก Data Source อื่น ๆ ส่วน Kibana จะใช้เพื่อการเสิร์ช Log และจัดการ Elasticsearch
ผลลัพธ์จากการใช้ Elasticsearch เป็นอย่างไร ?
เมื่อ KBTG เริ่มใช้ Elasticsearch แล้ว ทำให้งาน Operation ของเราง่ายขึ้นมาก แทนที่จะเป็นการ Tail Log ที่จะพ่น Log ออกมาบนหน้าจอแป๊ปเดียวแล้วก็โดนกลบหายไป กลายเป็น Log ที่เราสามารถมอนิเตอร์ได้นานนับชั่วโมง และเมื่อมีปัญหาก็จะโดดเด่นออกมา
ในช่วงแรก การใช้ Elasticsearch จะเน้นไปที่งานด้านการมอนิเตอร์เป็นหลัก แต่เมื่อเราเริ่มใช้ Elasticsearch มากขึ้น ช่วงหลังจึงเริ่มขยายออกไปใช้งานประเภท Capacity Planning ในบางส่วนด้วยเช่นกัน
งานแบบไหนที่ไม่ควรใช้ Elasticsearch ?
จุดอ่อนอย่างหนึ่งที่สำคัญของ Elasticsearch คือตัวระบบออกแบบมาเน้นการทำงานประเภท Full-Text Search ดังนั้นการทำงานประเภท metric จึงด้อยกว่า Database ที่ถูกสร้างมาให้ทำงานเฉพาะด้านอย่างมีนัยสำคัญ แต่ก็มีเหตุผลที่เรายังคงเลือกใช้ Elasticsearch มาทำ Dashboard ที่ต้องเกี่ยวข้องกับ Metric เพราะว่าง่ายต่อการจัดการ คือเก็บ Application Log ที่ Extract ข้อมูล Metric จากใน Log ออกมา พร้อมทั้งเสิร์ชและทำ Metric ภายใน Elasticsearch ได้ในตัวเดียว
แต่ถ้าคิดจะทำ Elasticsearch เพื่อเอาไปมอนิเตอร์ Metric อย่างเช่น RAM, CPU, Disk หรืออื่น ๆ การไปใช้ เครื่องมืออื่น ๆ อย่าง Zabbix, InfluxDB หรือ Prometheus ดูจะเหมาะสมกว่าครับ ผมแนะนำ^^
สรุป
ในบทความนี้เน้นแนะนำการใช้งาน Elasticsearch กับการคิวรีข้อมูลเบื้องต้นเป็นหลัก ซึ่งจุดที่น่าสนใจของ Elasticsearch คือใช้งานง่ายและสะดวก รวมถึงอธิบายข้อดีข้อเสีย และข้อจำกัดที่เราพบ
แต่เนื่องจาก Elasticsearch ไม่ใช่อุปกรณ์ที่ทำงานได้ด้วยตัวเอง และมีเครื่องมือที่น่าสนใจอีกมากใน Elastic Stack ซึ่งในอนาคตอาจมีบทความที่อธิบายประสบการณ์ใช้งานเครื่องมือแต่ละอย่างให้มากยิ่งขึ้น ฝากติดตามกันด้วยครับ
