ClickStack – ทางเลือกโอเพนซอร์สแทน Datadog ที่สร้างด้วย ClickHouse และ HyperDX

 (clickhouse.com)
4 คะแนน โดย GN⁺ 2025-06-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ClickStack เป็นแพลตฟอร์ม Observability แบบโอเพนซอร์สที่สร้างบน ClickHouse และ HyperDX โดยรวมการจัดการล็อก เมตริก เทรซ และเซสชันรีเพลย์ไว้ในที่เดียวอย่างครบวงจร
  • รองรับ การค้นหาและการแสดงผลล็อกและเทรซ ได้อย่างง่ายดายและรวดเร็วบนคลัสเตอร์ ClickHouse และใช้ได้กับทุกสคีมาโดยไม่ต้องมีงานเพิ่มเติม
  • มี การค้นหาที่ใช้งานได้อย่างเป็นธรรมชาติ การแจ้งเตือนตามอีเวนต์ และฟีเจอร์แดชบอร์ด ช่วยให้วิศวกรระบุและตอบสนองต่อปัญหาได้อย่างรวดเร็ว
  • รองรับมาตรฐาน OpenTelemetry เป็นค่าเริ่มต้น พร้อมการผสานรวม SDK สำหรับ หลายภาษาและหลายแพลตฟอร์ม
  • เมื่อเทียบกับโซลูชันเชิงพาณิชย์เดิม มีต้นทุนต่ำกว่าและตั้งค่าได้ง่ายกว่า อีกทั้งไม่ต้องสลับไปมาระหว่างเครื่องมือ observability หลายตัว เพราะจัดการทั้งกระบวนการได้บนแพลตฟอร์มเดียว

ฟีเจอร์หลัก

  • วิเคราะห์ความสัมพันธ์และค้นหาข้อมูลจาก ล็อก เมตริก เซสชันรีเพลย์ และเทรซ ได้ในที่เดียว
  • ใช้สคีมาเดิมของ ClickHouse ได้ทันที พร้อม โครงสร้างที่ไม่ยึดติดกับสคีมา
  • เหมาะกับข้อมูลปริมาณมากด้วย ความเร็วในการค้นหาสูง และการแสดงผลที่ปรับแต่งมาอย่างเหมาะสม
  • รองรับทั้ง การค้นหาแบบฟูลเท็กซ์และตามแอตทริบิวต์ โดยการใช้ SQL เป็นทางเลือก
  • วิเคราะห์แนวโน้มการเปลี่ยนแปลงของอีเวนต์ พร้อม ตั้งค่าการแจ้งเตือนได้ง่ายและสร้างแดชบอร์ด ได้
  • รองรับ Native JSON string query
  • ตรวจสอบอีเวนต์ล่าสุดได้ด้วยฟีเจอร์ tail ของล็อกและเทรซแบบเรียลไทม์
  • รองรับการผสานรวม OpenTelemetry และสภาพแวดล้อม APM (การมอนิเตอร์ประสิทธิภาพ)

การดีพลอยและการเริ่มต้นใช้งาน

  • แพ็กเกจ ClickStack สามารถดีพลอยรวม ClickHouse, HyperDX, OpenTelemetry Collector และ MongoDB ได้
  • สามารถเข้าถึง UI ของ HyperDX ได้ผ่านเบราว์เซอร์
  • เชื่อมต่อกับสภาพแวดล้อม ClickHouse Cloud ได้เช่นกัน และดีพลอยลงหลายสภาพแวดล้อมได้อย่างง่ายดาย

การทำ Application Instrumentation และการผสานรวม

หากต้องการเก็บข้อมูลล็อก เมตริก เทรซ และเซสชันรีเพลย์ด้วย HyperDX แอปพลิเคชันต้องส่งข้อมูลเทเลเมทรีไปยัง HyperDX

  • มี ตัวเลือก SDK และการผสานรวม: มี SDK สำหรับภาษา/สภาพแวดล้อมหลากหลาย เช่น เบราว์เซอร์ Node.js และ Python ทำให้เชื่อมต่อได้ง่าย
  • รองรับมาตรฐาน OpenTelemetry: ใช้งานร่วมกับภาษาและรันไทม์หลากหลาย เช่น Kubernetes, JavaScript, Python, Java, Go, Ruby, PHP, .NET, Elixir และ Rust
  • ตัวเก็บข้อมูล OpenTelemetry สามารถเชื่อมต่อได้โดยค่าเริ่มต้นที่ http://localhost:4318

วิธีมีส่วนร่วม

  • ยินดีต้อนรับการมีส่วนร่วมจากชุมชนในหลายรูปแบบ เช่น การส่ง PR การเปิด issue การปรับปรุงเอกสาร การโหวต issue ที่เปิดอยู่ และการเสนอกรณีการใช้งานใหม่

แรงจูงใจและแนวคิดในการพัฒนา

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

ปัญหาหลักของโซลูชันเดิม:

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

เพื่อก้าวข้ามข้อจำกัดเหล่านี้ จึงมีการเปิดซอร์ส ClickStack และ HyperDX

  • HyperDX ถูก ClickHouse เข้าซื้อกิจการแล้ว

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-06-07
ความคิดเห็นจาก Hacker News

  • สงสัยว่าทำไมถึงทำฟรอนต์เอนด์แบบคัสตอม แทนที่จะใช้ Grafana ที่มีอยู่แล้ว

  • แชร์ว่าราคา DataDog แพงมาก เลยรู้สึกว่า HyperDX น่าสนใจมาก, LogLayer ของตัวเอง(https://loglayer.dev)เป็น structured logger สำหรับ TypeScript ที่รองรับการส่งล็อกไปยัง logger หลายประเภทและบริการคลาวด์ต่าง ๆ (รวมถึง DataDog), แชร์ว่ากำลังพัฒนาฟีเจอร์ integration สำหรับ HyperDX และจะปล่อยเร็ว ๆ นี้, บอกว่าอยากเพิ่มลิงก์เอกสารวิธีเชื่อมต่อ HyperDX กับ LogLayer ไว้ในส่วน "integrations" ของเว็บไซต์ตัวเอง, และแชร์ลิงก์ PR ที่เกี่ยวข้อง(https://github.com/hyperdxio/hyperdx-js/pull/184)

    • ขอให้เพิ่มความสามารถในการส่งล็อกไปยัง VictoriaLogs ด้วย พร้อมเสนอแนบลิงก์เอกสารโปรโตคอลการ ingest ข้อมูลหลายแบบ(https://docs.victoriametrics.com/victorialogs/data-ingestion/)
    • ให้ฟีดแบ็กเชิงบวกว่า integration ระหว่าง LogLayer กับ HyperDX ดูดีมากและจะลองไปดูด้วยตัวเอง

  • ใช้งาน HyperDX อยู่ในโปรดักชันจริง และพอใจกับการผสานกับ ClickHouse รวมถึงความคุ้มค่าด้านต้นทุนมาก, สงสัยว่าจำเป็นต้องเตรียม migration จาก HyperDX ไป ClickStack หรือไม่

    • บอกว่ายินดีมากที่ได้ฟีดแบ็กจากผู้ใช้โปรดักชัน, อธิบายว่า HyperDX จะไม่หายไปไหน และในหน้า marketing ก็ยังเน้นว่าเป็นแกนหลักของสแตก, ต่อไปจะโฟกัสกับ HyperDX v2 และแพตเทิร์นของ ClickStack มากขึ้น แต่ตัว HyperDX เองก็จะยังเน้นประสบการณ์ของผู้ใช้ปลายทางต่อไป, อธิบายเพิ่มเติมว่าเป้าหมายของ ClickStack คือใช้ประโยชน์จากความยืดหยุ่นและประสิทธิภาพของคอร์ที่ใช้ ClickHouse ให้มากขึ้น, แชร์ว่ากำลังโฟกัสด้านวิศวกรรมเพื่อให้การเปลี่ยนผ่านทั้งบนโอเพ่นซอร์สและคลาวด์ราบรื่น, และทิ้งท้ายว่าช่วงนี้ Wi‑Fi ไม่เสถียรเลยตอบช้า

  • แชร์ว่ามองว่า trace และ logging ของ OTel ใช้ได้ดี แต่ฟีเจอร์ metrics ของ OTel ออกแบบซับซ้อนเกินไป, ถามว่า ClickStack ingest ข้อมูล statsd ได้หรือไม่ (โดยเฉพาะส่วนขยาย tagging ของ Datadog), มีการทำ service tagging และการเชื่อมโยงระหว่าง trace/log/metric หรือไม่, ใน UI มีฟีเจอร์ลิงก์ข้อมูลที่เกี่ยวข้องหรือไม่, สงสัยว่าทำไม Elixir SDK ถึงใช้ไลบรารี hyperdx, และถามว่าฟีเจอร์ Notebooks อยู่ใน roadmap หรือไม่

    • ตอบรับว่าเป็นคำถามที่ดี พร้อมเห็นด้วยว่าเรื่องที่มาตรฐาน OTel metrics หลากหลายมากมีเหตุผลแต่ก็มีจุดน่าเสียดาย, อธิบายว่า OTel collector สามารถรับฟอร์แมตได้หลากหลายรวมถึง statsd และเขียนลง ClickHouse ได้โดยตรง จึงใช้ statsd ได้(ลิงก์เอกสาร statsdreceiver), บอกว่าล็อกและ trace เชื่อมโยงกันได้ด้วย trace/span id และ resource attributes และใน k8s workload ตอนนี้มีการเชื่อมโยงถึง metric ด้วย, ระบุว่ายังไม่รองรับ exemplars สำหรับ metrics correlation แต่มีแผนในอนาคต, อธิบายว่า Elixir SDK ถูกเลือกเพื่อรองรับตามสภาพแวดล้อมของผู้ใช้, ไลบรารีนี้พัฒนาแยกมาอย่างอิสระและกำลังพิจารณาว่าจะเปลี่ยนไปใช้ OTel SDK อย่างเป็นทางการหรือไม่, แชร์กรณีที่นำ OTel integration สำหรับ Deno เข้ามาได้อย่างรวดเร็วด้วยตัวเอง, และบอกว่า Notebooks จะเปิดให้ใช้ในสถานะ experimental เร็ว ๆ นี้เพื่อรองรับ workflow ที่หลากหลาย, พร้อมสื่อว่าอยากได้ฟีดแบ็กจากผู้ใช้เพิ่ม
    • ถามกลับว่าทำไมถึงรู้สึกว่า OTel metrics ซับซ้อน พร้อมชี้ว่าข้อดีคือไม่จำเป็นต้องแทนที่ metric pipeline เดิมอย่าง statsd หรือ DD agent ได้แบบง่าย ๆ

  • เห็นว่า HyperDX ดูคล้าย Signoz ตรงที่ใช้ ClickHouse เป็นฐาน และมีทั้งเวอร์ชันโอเพ่นซอร์สกับคลาวด์, เลยสงสัยว่าต่างกันอย่างไร และสังเกตว่า UI ก็คล้ายกันด้วย

    • เสริมว่าอยากฟังการเปรียบเทียบกับ Signoz แบบตรง ๆ มากขึ้น

  • กำลังมองหาโซลูชัน logging ใหม่มาแทน Kibana และมีประสบการณ์ที่ดีกับ ClickHouse จึงสนใจ UI ของ HyperDX, ตอนนี้ log pipeline คือ Vector บน Kubernetes และ Vector รองรับ OTel sink (เบตา) อยู่แล้ว เลยกำลังคิดว่าวิธีส่งล็อกที่ดีที่สุดคืออะไรในสถานการณ์ที่ข้อมูลเป็น JSON, เน้นว่าเป็นสภาพแวดล้อมทราฟฟิกหนักมากระดับ TB และต้องการประสิทธิภาพสูง

    • ตอบว่า ClickHouse เด่นเรื่องรองรับข้อมูลปริมาณมากและ throughput สูง, ยกตัวอย่างกรณีใช้งานที่เขียนจาก Vector ลง ClickHouse โดยตรง (เช่น งานนำเสนอของ Anthropic), และชวนให้ลองใช้จริงแล้วกลับมาแชร์ความเห็น ถ้าต้องการก็พร้อมช่วย
    • แสดงความคิดเห็นว่าการทำฟอร์แมตการส่งข้อมูลให้เป็นมาตรฐาน otel เป็นทางเลือกเชิงกลยุทธ์ที่ดีต่ออนาคต และรู้สึกว่าเหมือนลดความกังวลไปได้สองเรื่อง

  • สงสัยว่าความแตกต่างระหว่าง Signoz กับ HyperDX (หรือ ClickHouse) คืออะไร โดยสังเกตว่าทั้งคู่มาจาก YC และใช้ ClickHouse เหมือนกัน

    • ตอบว่าตามที่มีคนพูดไว้ด้านล่าง ความต่างที่ใหญ่ที่สุดคือเป็นผลิตภัณฑ์ 1st-party ที่ทีม ClickHouse พัฒนาอย่างเป็นทางการ, ทำงานได้อย่างยืดหยุ่นกับแทบทุก ClickHouse instance และรองรับ custom schema ด้วย ซึ่งสำคัญมากสำหรับการจูนประสิทธิภาพหรือสภาพแวดล้อมขนาดใหญ่เฉพาะทาง (เช่น Anthropic), ถ้ามีข้อมูลอยู่ใน ClickHouse แล้วก็เริ่มใช้งานได้ง่ายมาก, ไม่ได้บังคับให้ใช้ otel เสมอไป และรองรับ Vector, Cribl, S3, custom script ฯลฯ แบบ native, มีฟีเจอร์ telemetry wrangling (เช่น high-cardinality event deltas, การจัดกลุ่มล็อก/สแปนอัตโนมัติด้วย ML ฯลฯ) ที่ช่วยให้สำรวจข้อมูลได้ง่าย, มีฟีเจอร์ session replay ที่เชื่อมโยงได้ตั้งแต่การคลิกไปจนถึง metric ของ infrastructure แบบครบวงจร, ใช้งานภายในสำหรับการมอนิเตอร์ ClickHouse Cloud ที่สเกล 100PB+ และมีความยืดหยุ่นพอจะตามปัญหาเฉพาะของผู้ใช้แบบ end-to-end ได้, และในเชิงปรัชญาเชื่อว่าการทำเครื่องมือค้นหาเบาะแสแบบรวมศูนย์/เป็นหนึ่งเดียว เหมาะกับการดีบักในงานจริงมากกว่าการแยก "3 pillars" (logs/metrics/traces) แบบดั้งเดิม
    • ชี้แจงให้ชัดว่า “You” หมายถึง ClickHouse

  • แชร์ประสบการณ์ว่าหลังสมัครสมาชิกแล้ว ใน UI มีวิดเจ็ต "Was this search result helpful?" โผล่มาตั้งแต่ก่อนค้นหา ทำให้ UX ชวนสับสน, พบบั๊กว่าถ้ากด Hide จะกลายเป็นปุ่มฟีดแบ็ก แล้วกดฟีดแบ็กอีกครั้งก็กลับไปสภาพเดิม, โดยรวมมองว่าฟอนต์เป็น monospace เกือบทั้งหมดและขนาดตัวอักษรก็เล็ก อีกทั้งสีขาวหนาและสีเขียวสว่างบนพื้นหลังมืดก็เข้ากันไม่ดี, ต่อให้เปลี่ยนเป็น system font ก็ไม่ได้ดีขึ้นมากนัก เลยแนะนำให้ใช้สไตล์ UI แบบดั้งเดิมมากกว่า, และให้ฟีดแบ็กว่าดีไซน์ที่อ่านยากทำให้ลังเลจะใช้งาน

  • สงสัยว่า ClickHouse เป็นองค์ประกอบ stateful เพียงตัวเดียวของสแตกนี้หรือไม่, สนใจความเข้ากันได้กับ Rotel ซึ่งเป็น OTEL collector เขียนด้วย Rust(https://github.com/streamfold/rotel), และเสริมว่า Datadog มีตัวแทน OTEL collector ที่พัฒนาขึ้นเองซึ่งให้ประสิทธิภาพดีกว่า

    • ตอบว่า Rotel น่าจะเหมาะกับการเชื่อมต่อ OTel ในสภาพแวดล้อมเบา ๆ อย่าง lambda, และเนื่องจาก OTel ingest endpoint ของ HyperDX เป็นมาตรฐานอยู่แล้วจึงน่าจะใช้งานร่วมกันได้ทันที, บอกด้วยว่าได้คุยกับนักพัฒนา Rotel แล้ว และการที่เพิ่งเพิ่มการรองรับ ClickHouse ทำให้ภาพรวมของเรื่องนี้ยิ่งแข็งแรงขึ้น