จากบทความของ Elastic เรื่อง Pruning incoming log volumes with Elasticอธิบายถึงการเก็บข้อมูลใน Elastic stack ว่าข้อมูลที่จัดเก็บนั้นมีจำนวนที่เยอะ รูปแบบที่หลากหลายส่งผลให้ระบบมีปัญหาในการจัดเก็บ การประมวลผล หรือ ใช้งานดังนั้น สิ่งหนึ่งที่เราควรทำก่อนคือรู้ว่าข้อมูลอะไรบ้างที่ใช้ และ ไม่ใช้งานบ้างเพื่อที่จะเก็บเท่าที่ใช้งานเท่านั้น มิใช่เก็บไปเสียทุกอย่าง
หัวข้อที่ 1 What new in Elastic 8.6 ว่าด้วยเรื่องของวิวัฒนาการของ Elastic ว่าเป็นอย่างไรบ้างซึ่งเริ่มจากระบบการค้นหาตามมาด้วย analyticจากนั้นเริ่มเข้าสู่ APM, logging, tracing, metric หรือ Observability นั่นเองและเข้าสู่เรื่องของ security, ทางการแพทย์นั่นคือ การเข้าสู่ Data Intelligence Platform นั่นเอง
ใน Elasticsearch 8.6.0 นั้น ได้เพิ่ม index ชนิดใหม่ขึ้นมาชื่อว่า time_series ซึ่งอยู่ในสถานะ tech previewเพื่อใช้สำหรับเก็บข้อมูลในลักษณะของ time seriesโดยจะทำการเรียงลำดับตามเวลาของข้อมูลหรือ document ที่สร้างด้วย timestampและจะทำการแยกเก็บตาม index ย่อย ๆ (backing index) ให้เองแบบอัตโนมัติ
จาก Elasticsearch 8.3 นั้น ทำการปรับปรุง performance การทำงานของ Ingest pipelineโดยลดการใช้ CPU ลงไปประมาณ 5-10% ขึ้นอยู่กับรูปแบบของข้อมูลและมีสิ่งที่น่าสนใจ ประกอบไปด้วย
เพิ่งกลับมา upgrade และใช้งาน Logstash อีกรอบพบว่า Elasticsearch output plugin มีการเปลี่ยนแปลงนิดหน่อยทั้งต้องเชื่อมต่อไปยัง Elasticsearch ที่เปิด security by defaultซึ่งการ configuration ใน output ก็ต้องเพิ่มอีก เช่น user/password ssl ssl verification mode cacert
ใน Elasticsearch 8 นั้น ถ้าใครลองทำการ download และมาติดตั้งจะพบว่ามีการ enable ระบบ security มาให้เลยโดย defaultโดยในการ start ครั้งแรกแบบอัตโนมัติ
หลังจากที่ทาง Elastic ปล่อย Elastic 8.0 ออกมาแน่นอนว่าก็ update กันทั้ง stack ประกอบไปด้วย Elasticsearch Kibana Beat Logstash
วันนี้เพิ่งเห็นว่า ใน Elasticsearch 8 จะมี feature หลาย ๆ อย่างที่อาจจะทำให้ระบบงานมีปัญหาขึ้นมาได้หนึ่งในนั้นคือ action.destructive_requires_name มีค่าเป็น trueนั่นคือ ไม่สามารถลบ index แบบ wildcard ได้อีกแล้ว โดย defaultยกตัวอย่างเช่น DELETE * เป็นต้น
ใน Elasticsearch 7.14 นั้นได้เพิ่ม field type ใหม่ขึ้นมาชื่อว่า match_only_textสร้างขึ้นมาเพื่อนำมาใช้เก็บข้อมูล log ต่าง ๆ โดยเฉพาะสามารถ query ได้เหมือนกับ type textเพียงแต่ไม่สนับสนุนการ sorting/scoringแต่ก็มีข้อจำกัดเช่นกัน ในการใช้บาง query เช่น span queryหรือใช้แล้วช้ากว่า type text เช่น phase และ interval queryในส่วนการ aggregation บางอย่าง ก็มีข้อจำกัด
วันนี้เจอปัญหาเรื่อง _id field ของ document ใน ElasticSearchพบว่าในการย้ายเอกสารจาก version ที่ต่ำกว่า 5.0 มายัง version เกิน 5.0อาจจะทำการ dump หรือ reindex ก็ได้จะเจอ error ที่น่าสนใจคือ “id is too long, must be no longer than 512 bytes but was: 513&#