OpenTelemetry ในปี 2023

 (bit.kevinslin.com)
2 คะแนน โดย GN⁺ 2023-08-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • OpenTelemetry ซึ่งเริ่มต้นจากการควบรวม OpenTracing และ OpenCensus ในปี 2019 ได้กลายเป็นมาตรฐาน observability ที่ครอบคลุม trace, metric และ log ภายในเวลา 4 ปี
  • โครงสร้างหลักแบ่งเป็น ข้อกำหนด และ implementation โดยให้ทั้งเกณฑ์สำหรับความเข้ากันได้กับ vendor และเครื่องมือจริงสำหรับ instrumentation และการรวบรวมข้อมูล
  • ข้อกำหนดของ OTEL ทำให้ tracing เสถียรในปี 2020, metric ในปี 2021 และ log ในปี 2023 จน ทุก signal อยู่ในสถานะ stable แล้ว แต่การรองรับ log ยังแตกต่างกันไปในแต่ละ SDK
  • OTLP และ Collector เป็นฐานสำหรับส่งและประมวลผลข้อมูล observability ในรูปแบบร่วมกัน และ agent ของ vendor อย่าง Grafana และ Datadog ก็ implement สิ่งนี้ด้วย
  • OTEL ขยายขอบเขตไปถึง Collector, Semantic Conventions, OpAMP, OTTL และ Demo จนกลายเป็นฐานร่วมของ observability แบบเป็นกลางต่อ vendor

ตำแหน่งปัจจุบันของ OpenTelemetry

  • OpenTelemetry หรือเรียกสั้น ๆ ว่า OTEL เริ่มต้นขึ้นในปี 2019 จากการรวม OpenTracing และ OpenCensus เข้าด้วยกัน
  • เดิมทีเป็นโปรเจกต์ที่เน้น tracing แต่หลังจากการควบรวม ขอบเขตก็ขยายไปสู่ observability ทั้งหมด
  • เป้าหมายคือช่วยให้องค์กรสามารถมอบ telemetry คุณภาพสูง เป็นสากล และพกพาได้
  • หลังผ่านไป 4 ปี OTEL มีรากฐานดังต่อไปนี้
    • มาตรฐานที่เสถียรสำหรับ metric, log และ trace
    • Collector ที่สามารถรับ ประมวลผล และส่งออก telemetry ได้ในทุกสภาพแวดล้อม
    • SDK ที่รองรับการทำ instrumentation ในโค้ดสำหรับภาษาหลัก ๆ
    • มาตรฐานเพิ่มเติมเกี่ยวกับ Semantic Conventions และการจัดการ agent
  • ปัจจุบัน OTEL เป็นโปรเจกต์ใน CNCF ที่มีความเคลื่อนไหวสูงเป็นอันดับถัดจาก Kubernetes โดยมีผู้มีส่วนร่วมกระจายอยู่ทั่ว vendor ด้าน observability รายใหญ่ และ protocol ก็ถูกนำไปใช้เกือบเป็นสากลในหมู่ผู้ให้บริการ observability

โครงสร้าง OTEL ที่แบ่งเป็นข้อกำหนดและ implementation

  • OTEL ประกอบด้วยส่วนใหญ่ ๆ คือ ข้อกำหนด (specification) และ implementation
  • ข้อกำหนดนิยามวิธีการจับ รวบรวม ประมวลผล และส่งออก telemetry
    • ใกล้เคียงกับมาตรฐานร่วมที่ vendor ต้องปฏิบัติตามเพื่อให้เข้ากันได้กับ OTEL
  • implementation คือ client library และเครื่องมือที่จัดการข้อมูล telemetry
    • เป็นส่วนที่ผู้ใช้ปลายทางสัมผัสโดยตรงเมื่อทำ instrumentation กับโค้ด
  • ความเสถียรของโปรเจกต์มักแสดงแยกตาม signal
    • ใน OTEL คำว่า signal หมายถึงประเภทข้อมูล telemetry เช่น metric, log และ trace
  • โปรเจกต์ย่อยหลักมีดังนี้
    • OpenTelemetry Specification
    • OpenTelemetry SDKs
    • OpenTelemetry Protocol
    • OpenTelemetry Collector
    • Open Agent Management Protocol
    • OpenTelemetry Semantic Conventions

OpenTelemetry Specification 1.24.0

  • OpenTelemetry Specification เป็นรากฐานของ OTEL และให้ API, SDK และ data model ที่เป็นพื้นฐานให้มาตรฐาน OTEL อื่น ๆ
  • การทำให้เสถียรดำเนินไปแยกตาม signal
    • กันยายน 2020: tracing stable
    • พฤศจิกายน 2021: metric stable
    • เมษายน 2023: log stable
  • ปัจจุบันข้อกำหนด OTEL อยู่ในสถานะ stable ในทุก signal
  • เนื่องจาก log signal เพิ่งเสถียรในปี 2023 ทำให้ OTEL SDK จำนวนมากยังไม่รองรับ log

OpenTelemetry SDK และ auto instrumentation

  • OTEL SDK ให้การทำ instrumentation ฝั่ง client ตามข้อกำหนด OTEL
  • SDK แต่ละภาษามีระดับความพร้อมแยกกันตาม signal อย่าง metric, log และ trace
  • SDK บางตัวรองรับ auto instrumentation ขึ้นอยู่กับภาษาโปรแกรม
    • auto instrumentation คือวิธีที่ SDK แทรก signal โดยอัตโนมัติในโค้ดแอปพลิเคชัน ซึ่งส่วนใหญ่เป็น trace เพื่อลดภาระการทำ instrumentation ด้วยตนเอง
  • ในภาษาที่ต้อง compile เช่น go และ rust auto instrumentation จะไม่ทำงาน
  • อย่างไรก็ตาม หากใช้เครื่องมือนอก SDK ที่อิง eBPF หรือ service mesh ก็สามารถได้การแทรก trace อัตโนมัติ

OTLP 1.0 และมาตรฐานการส่งข้อมูล

  • OTLP คือ wire protocol ร่วมกัน สำหรับส่งข้อมูล observability
  • วิธีส่งอย่างเป็นทางการมี 2 แบบ
  • ข้อกำหนดนี้ถือว่า stable และสามารถ implement ได้ในทุก service ที่รับ ประมวลผล และส่งออกข้อมูล OTEL
  • OTLP ถูก implement โดย OpenTelemetry Collector และ agent ของ vendor ด้าน observability อย่าง Grafana และ Datadog ก็ implement เช่นกัน

OpenTelemetry Collector 0.83.0

  • OTEL Collector คือ agent ที่เป็นกลางต่อ vendor สำหรับรวบรวม แปลง และส่งข้อมูล observability
  • Collector ประกอบด้วยคอมโพเนนต์ต่อไปนี้
    • receivers: รับข้อมูลจากหลาย source ด้วยวิธี push/pull
    • processors: แปลง กรอง เพิ่มข้อมูล และสร้างข้อมูลอนุพันธ์จากข้อมูลที่กำลังเคลื่อนที่
    • exporters: ส่งข้อมูลไปยังปลายทาง downstream
    • connectors: ทำงานเป็นทั้ง receiver และ exporter เพื่อเชื่อมหลาย pipeline เข้าด้วยกัน
    • pipelines: chain ที่ประกอบด้วย receiver, processor ตั้งแต่ 0 ตัวขึ้นไป และ exporter
    • extensions: ให้ฟังก์ชันนอกเหนือจากการประมวลผล telemetry เช่น basic auth และ health check
  • คอมโพเนนต์เหล่านี้ทำงานร่วมกันเป็น observability pipeline ที่สามารถรวบรวม telemetry จาก source ใดก็ได้ ประมวลผลระหว่างทาง แล้วส่งไปยังปลายทางที่ต้องการ
  • Collector แบ่งเป็น 2 โปรเจกต์
    • otel-collector: มีเฉพาะคอมโพเนนต์หลักของ Collector และส่วนใหญ่เป็น logic ที่เกี่ยวข้องโดยตรงกับการประมวลผลข้อมูล OTLP
    • otel-collector-contrib: ชุดรวม integration ที่มี exporter และ receiver สำหรับผู้ให้บริการ observability ส่วนใหญ่
  • ณ เวลาที่เขียน otel-collector-contrib มี receiver 91 ตัว, exporter 48 ตัว, processor 24 ตัว
  • แนะนำให้ผู้ใช้ปลายทางใช้ OpenTelemetry Collector Builder เพื่อสร้าง custom build ของ otel-collector-contrib ที่มีเฉพาะคอมโพเนนต์ที่ต้องการ
  • vendor อย่าง AWS และ Splunk ก็มี distribution ของ OTEL เป็นของตนเอง

OpAMP และการจัดการ agent จากระยะไกล

  • OpAMP คือ network protocol สำหรับการจัดการ agent จากระยะไกล
  • เป็นมาตรฐานค่อนข้างใหม่ที่เพิ่มเข้ามาใน OTEL ในปี 2022 และให้ วิธีที่เป็นกลางต่อ vendor สำหรับควบคุมกลุ่ม agent
  • เป้าหมายที่ถูกจัดการอาจเป็น instance ของ otel-collector หรืออาจเป็น agent เฉพาะของ vendor ที่ implement OpAMP ก็ได้
  • เมื่อใช้ OpAMP จะสามารถเปิดใช้ฟังก์ชันต่อไปนี้ได้
    • การ deploy การตั้งค่าแบบ dynamic
    • การอัปเดต agent
    • การจัดการ credential
  • ปัจจุบัน Go implementation ของข้อกำหนด OpAMP ยังอยู่ระหว่างดำเนินงาน

Semantic Conventions และโปรเจกต์เพิ่มเติม

  • OTEL Semantic Conventions นิยาม ชุด attribute ร่วมกัน ที่ใช้ในข้อมูล observability
  • ขอบเขตการใช้งานครอบคลุม cloud resource, database, exception, system และอื่น ๆ
  • Semantic Conventions ถูกใช้โดย OTEL SDK และจะถูกนำไปใช้โดยอัตโนมัติใน SDK ที่รองรับ auto instrumentation
  • semantic ร่วมกันทำให้สามารถเชื่อมความสัมพันธ์ระหว่าง signal ที่ต่างกันได้
  • ยังมีคอมโพเนนต์หลักอื่น ๆ ของ OTEL แยกต่างหากด้วย
    • OpenTelemetry Transformation Language (OTTL): ภาษาการแปลงร่วมกันสำหรับ telemetry มีทั้งประสิทธิภาพและความยืดหยุ่น และถูกออกแบบ/implement ใน otel-collector-contrib
    • OTEL Demo: เว็บไซต์ช้อปปิ้งแบบ microservices ที่แสดงความสามารถของ OTEL และ SDK ภาษาส่วนใหญ่

การเปลี่ยนแปลงตลอด 4 ปี

  • OTEL เริ่มจากการควบรวมข้อกำหนด tracing ที่แข่งขันกัน และพัฒนามาเป็น มาตรฐานอุตสาหกรรม ของ observability
  • 4 ปีที่ผ่านมาเป็นช่วงเวลาของการสร้างฐานร่วมกันครอบคลุม vendor และเครื่องมือต่าง ๆ

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

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

 
GN⁺ 2023-08-29
ความคิดเห็นบน Hacker News

  • OpenTelemetry มีปัญหาอยู่สองอย่าง

    1. ตัวตนไม่ชัดเจน คลุมเครือว่ามันเป็นมาตรฐานเชิงความหมาย โปรโตคอล ฟาซาด ไลบรารี หรือให้เลเยอร์นามธรรมแบบไหนกันแน่ แต่คำตอบใกล้เคียงกับว่า “เป็นทุกอย่าง”
    2. ดูเหมือนฝั่ง OpenTelemetry จะไม่มีใครที่เคยทำ instrumentation ให้ไลบรารีจริง ๆ เลย ไม่มีข้อเสนอว่าผู้ทำ instrumentation ควรใช้เมตริก เทรซ และล็อกอย่างไร ควรใช้ทั้งสามอย่างหรือแค่อย่างเดียว เคยถามไปเมื่อ 2 ปีก่อนแต่ไม่ได้คำตอบ: https://github.com/open-telemetry/opentelemetry-specificatio...
    • เห็นด้วย มันเหมือนให้ทั้งอ่างล้างจานพร้อมบ้านที่ติดมาด้วยในคราวเดียว ทำให้เอกสารบางและชวนสับสน
      คล้ายกันคือเคยอยากทำ heartbeat ง่าย ๆ เพื่อดูการใช้งานในแอปเดสก์ท็อป แต่ถ้าดูจากชื่อโปรเจกต์แล้ว น่าประหลาดที่แทบเป็นไปไม่ได้เลย ปฏิกิริยาต่อคำถามก็มีน้อย จึงล้มแผนใช้ OpenTelemetry ไปทั้งหมด: https://github.com/open-telemetry/community/discussions/1598, https://github.com/open-telemetry/semantic-conventions/issue...
    • เห็นด้วย บางอย่างที่ OpenTelemetry แนะนำทำไม่ได้จริงด้วย SDK
      ตัวอย่างเช่น ไม่สามารถกำหนดบัคเก็ตใกล้กับจุดที่นิยามฮิสโตแกรมได้ ต้องส่งรายการ “override” ที่แมปจากชื่อฮิสโตแกรมไปยังบัคเก็ตให้กับที่อย่าง global exporter ถ้ามีไลบรารีที่ส่งออกเมตริก เรื่องนี้จะยุ่งเหยิงมาก: https://github.com/open-telemetry/opentelemetry-go/issues/38...
    • เป็นคำถามที่ดี แต่ไม่คิดว่าสำคัญนัก คำถามพวกนี้ไม่ว่าจะเป็น OpenTelemetry หรือระบบกรรมสิทธิ์อื่น ๆ ก็ยากที่จะตอบให้ชัดเจนในสาย observability
      แม้ดูเว็บไซต์ของบริษัท observability ชั้นนำ บทความเกี่ยวกับ custom instrumentation ก็มีราว 4 หน้าและครอบคลุมแค่เรื่องพื้นฐานมาก ๆ OTel ไม่ได้ตามหลังเป็นพิเศษ และคำตอบโดยมากก็ใกล้เคียงกับ “แล้วแต่สถานการณ์” เมื่อสะสมประสบการณ์มากขึ้น ประเด็นแบบนี้ที่ทำให้มือใหม่สับสนก็น่าจะค่อย ๆ คลี่คลายได้
    • สิ่งที่ต้องการก็แค่การดูแล ไฟล์ JSON schema 3 ไฟล์ เท่านั้น
    • คำถามที่สามคือมันมี scalability หรือไม่

  • ชอบ OpenTelemetry มาก และอยากติดตามแทบทุก span ถ้าใช้เวนเดอร์สักรายคงล้มละลายเพราะค่าใช้จ่ายไปแล้ว
    ติด OpenTelemetry ด้วย Java auto instrumentation แทบไม่ต้องลงแรง และส่งไปยัง ClickHouse ที่โฮสต์เอง เก็บ span มากกว่า 700 ล้านรายการต่อวันบน EC2 ราคา 100 ดอลลาร์: https://clickhouse.com/blog/how-we-used-clickhouse-to-store-...

    • ในโปรเจกต์ส่วนตัวขนาดเล็ก ส่ง trace/log/metric ไปยัง ClickHouse ผ่าน SigNoz อยู่ ปริมาณราว 400,000–800,000 span ต่อวัน(https://i.imgur.com/s0J6Mzo.png) และบน t4g.small เครื่องเดียว CPU มักอยู่ที่ 11%, IOPS อยู่ระดับ 4%
      เมื่อเก็บ trace ไว้ 1 เดือน signoz_index_v2 มี 26.9 ล้านแถว ขนาด 17.06GiB, trace_log มี 123 ล้านแถว ขนาด 2.64GiB, samples_v2 มี 949 ล้านแถว ขนาด 345MiB ถือว่าบีบอัดได้ดี ถ้าใช้เครื่อง ClickHouse ตามสเปกที่แนะนำก็คงลดเวลาจูนได้ แต่ตอนนี้ก็ทำงานได้ดีอยู่
      ข้อเสียคือ IOPS ของดิสก์ sc1 ขนาดเล็กอยู่ราว 4 ทำให้ ClickHouse ใช้เวลาสตาร์ตประมาณ 5 นาที และแม้ UI ของ SigNoz จะมีฟีเจอร์เพียงพอ แต่ก็ยากจะคาดหวังความเนี้ยบระดับ Datadog
    • ควรตั้ง sampling rate ไว้ แต่ต้องแน่ใจว่าส่ง error ทั้งหมด
      ที่ทำงานเก่าเคยเก็บแค่ 5% ของ trace ที่ไม่ใช่ error
    • ในความเป็นจริง คนส่วนใหญ่ไม่อยากดูแล ClickHouse storage เอง และไม่ใช่วิศวกรทุกคนที่จะใช้ SQL ได้มีประสิทธิภาพเหมือนเขียนโค้ด ถึงอย่างนั้นก็เป็นคอนฟิกที่เจ๋งทีเดียว
    • ที่ยอดเยี่ยมอีกอย่างคือใช้แรงตั้งค่าน้อย เป็นชุด Java auto instrumentation + ClickHouse exporter + Grafana ClickHouse plugin

  • ผิดหวังกับ OpenTelemetry อย่างมาก จากประสบการณ์ มันเป็น ก้อนความสับสนที่ออกแบบเกินจำเป็น และประสบการณ์ใช้งานพื้นฐานก็เป็นปฏิปักษ์ต่อผู้ใช้มาก
    มันโฆษณาตัวเองว่าเป็นทั้งฟอร์แมต tracing/metrics/logging แบบทั่วไป และเป็นชุดไลบรารี plug-and-play ที่มี adapter สำหรับทุกอย่างที่จำเป็น แต่ในความเป็นจริง มันใกล้เคียงกับชุดไลบรารีครึ่ง ๆ กลาง ๆ ที่รายละเอียด implementation ภายในรั่วออกมาเยอะ คุณภาพ adapter ก็แย่ และฟีเจอร์ก็ไม่ได้มากนัก

    • เห็นด้วย ทุกครั้งที่ใช้ SDK จะรู้สึกเหมือนต้องคิดในแบบที่สวนทางกับสามัญสำนึก ไม่มีอะไรทำงานตามที่คาดไว้ ทุกอย่างมี abstraction ที่ไม่จำเป็นซ้อนกัน 3 ชั้น และต้องเข้าทางประตูหลัง
      ฟีเจอร์จำนวนมากมีเงื่อนไขแนบมาประมาณว่า มันจะทำงานเมื่อไร ที่ไหน มากแค่ไหน ตอนข้างขึ้นข้างแรมเป็นอย่างไร ตอนมองเห็นดาวพฤหัสบนท้องฟ้า และเมื่อความยาวสตริงอยู่ที่ระดับใด
      ถึงอย่างนั้น ถ้ามองข้าม API ของ SDK ที่รั่วไหลและฟีเจอร์ที่ทำมาแค่ครึ่งเดียวไป คำสัญญาเรื่อง การสลับแทนกันได้ ก็ถือว่าทำได้ในระดับหนึ่ง ก่อน OTel ทุกอย่างเป็นสแต็กเฉพาะของตัวเอง แต่ตอนนี้สามารถเสียบ backend สำหรับ logging ตัวอื่นเข้ากับ SDK มาตรฐานตัวเดียว และคาดหวังได้ว่ามันจะทำงานได้โดยรวม แม้จะด้อยกว่าสแต็กแบบบูรณาการแนวดิ่ง แต่จากมุมมองสถาปัตยกรรมก็นับเป็นชัยชนะบางส่วน เพราะทำให้เกิดการแข่งขันและวิวัฒนาการเป็นส่วน ๆ ได้โดยไม่ต้องรื้อทั้งสแต็ก observability
    • เคยเจอความเจ็บปวดแบบเดียวกัน แต่พอลองใช้ทางเลือกอื่นที่อ้างว่าดีกว่าเพราะมีสเปก OpenAPI ก็ไม่ได้ดีกว่ากันเท่าไร: https://github.com/openzipkin/zipkin-api-example
      ตัวอย่างแสดงเพียงวิธีใช้เครื่องมือ swagger เพื่อ parse สเปก OpenAPI (https://github.com/openzipkin/zipkin-api/blob/master/zipkin2...) สร้างโค้ดกาวใน Go อัตโนมัติ แล้วเรียกฟังก์ชันที่สร้างอัตโนมัติหนึ่งตัวเพื่อบันทึก trace
      ไม่มีเอกสารหรืออย่างอื่นเป็นตัวอย่างเลย จนสงสัยว่ามีใครใช้แนวทางนี้จริงหรือไม่ สุดท้ายจึงไปเรียก service API (https://zipkin.io/zipkin-api/#/) โดยตรงผ่าน REST แทน OTel นั้นเจ็บปวด แต่ทางเลือกอื่นก็ไม่ได้ดีไปกว่า หวังว่าจะมีคนให้ความสนใจกับด้านนี้มากขึ้น เพราะการวัด SLO และ SLI สำคัญขึ้นเรื่อย ๆ
    • ถ้าอย่างนั้นอยากรู้ว่ามีทางเลือกไหนแนะนำได้ไหม หรือแค่จำใจใช้ OTel ต่อไป
    • ถ้ายกประสบการณ์ที่เป็นรูปธรรมและข้อเสนอแนะในการปรับปรุงได้ก็คงดี

  • ไลบรารีทางการของ OTel ยังทำงานได้ไม่ดีบนเว็บฟรอนต์เอนด์ เช่น โดยค่าเริ่มต้นไม่มีวิธีเชื่อมโยง error กับ source map
    web browser collector ที่โปรเจกต์ OTel เผยแพร่ใช้ Zone.js เพื่อดักแทบทุกอย่างในเบราว์เซอร์เป็น context ถ้าเคยใช้ Angular รุ่นใหม่ ๆ ก็น่าจะรู้ว่า Zone.js บางครั้งค่อนข้างเจ็บปวด และการไปแตะ global อาจทำให้เกิดพฤติกรรมที่คาดเดายาก
    ก็ไม่รู้เหมือนกันว่ามีมาตรฐาน OTel สำหรับสิ่งอย่าง session replay หรือไม่ แพลตฟอร์ม telemetry หลายเจ้าอย่าง Sentry, Rollbar, DataDog รองรับสิ่งนี้ ทีม backend ดูเหมือนจะชอบมันพอสมควร และผมชอบคุณสมบัติของ span ที่ข้ามขอบเขตได้ ทำให้ตามทั้งระบบได้ด้วย tag เฉพาะตัว อย่างไรก็ตาม payload ที่สร้างขึ้นบางครั้งยืดยาวมาก และบางแพลตฟอร์ม logging ก็กะทัดรัดกว่า ในงานจริงไม่ได้รู้สึกว่าเป็นปัญหาใหญ่

    • ในสภาพแวดล้อม Promise แบบ native และ async/await ตอนนี้ดูเหมือนยังไม่มีวิธีทำสิ่งอย่าง Zone.js ให้ถูกต้องได้
      เคยลอง instrument เองแล้ว แต่เกิดข้อผิดพลาดง่ายและยืดยาว เบราว์เซอร์เองก็จำเป็นต้องมีอะไรแบบ https://nodejs.org/api/async_context.html#class-asynclocalst... จริง ๆ
    • บนแพลตฟอร์มส่วนใหญ่ Otel ใกล้เคียงกับการเป็นจุดเริ่มต้นสำหรับสร้างไลบรารี instrumentation ที่ดีมากกว่า
      ในแพ็กเกจของเรา เราเสริม session replay, การติดตาม exception ที่ดีขึ้น ฯลฯ ไว้บน implementation ของ Otel/Splunk browser SDK น่าเสียดายที่สิ่งเหล่านี้ยังห่างไกลจากการมีมาให้พร้อมใช้โดยพื้นฐาน ถึงอย่างนั้น การเชื่อมเซสชันฟรอนต์เอนด์เข้ากับ trace/log ฝั่ง backend ได้ ก็ถือว่าเปลี่ยนประสบการณ์นักพัฒนาไปมาก: https://www.hyperdx.io/blog/browser-based-distributed-tracin...
    • เอกสารนี้ของ Otel ก็น่าดู: https://opentelemetry.io/docs/instrumentation/js/getting-sta...
      มันไม่ได้แก้ปัญหาอย่างสมบูรณ์ แต่ก็เป็นจุดเริ่มต้นได้
    • Real User Monitoring ซึ่งเป็น frontend instrumentation ของ DataDog ก็ยังดูไม่ค่อยถูกขัดเกลาอย่างเห็นได้ชัด ระดับความละเอียดเหมือนกำลังจับบล็อก Duplo
      อยากรู้ว่ามีใครเริ่มทำ frontend tracing ไปบ้างแล้วหรือยัง
    • อยากรู้ว่าเคยดู Grafana Faro หรือยัง สามารถให้มันส่งไปที่ Grafana Agent ได้ และ Grafana Agent เป็นโอเพนซอร์ส รวมถึงสามารถเก็บ trace ไว้ที่ตำแหน่งอื่นได้

  • ผมกับเพื่อนร่วมงานสองสามคนเคยมีความคิดที่ค่อนข้างแปลกว่า ต่อไปอาจไม่ต้องมี log แล้วก็ได้ แทนที่จะใช้ข้อความ log ก็แค่ใส่ span event เข้าไป: https://opentelemetry.io/docs/instrumentation/ruby/manual/#a...
    จากนั้นก็เหลือ log ไว้แค่ชื่อ span กับลิงก์ไปยัง span นั้นใน Jaeger ประมาณนี้ เคยลองแค่ในโปรเจกต์ส่วนตัว แต่รู้สึกว่าค่อนข้างดี เพียงแต่น่าจะดีถ้า Jaeger UI รองรับรูปแบบการใช้งานแบบนี้ได้ดีกว่านี้
    จริง ๆ แล้วเพื่อนร่วมงานกลุ่มนั้นก็มี talk เรื่องนี้ด้วย ถ้าอยู่แถว ๆ Hannover เยอรมนี ลองหา “Nie wieder Log-Files!” ได้ที่ https://javaforumnord.de/2023/programm/

    • ขึ้นอยู่กับว่าโปรเจกต์เป็น greenfield แค่ไหน ถ้าไม่ใช่กรณีที่ต้องการแค่ timestamp ของงานบางอย่างและไม่ต้องการระยะเวลา ก็อาจไม่ต้องใช้แม้แต่ span event ด้วยซ้ำ
      การใช้ span กับงานที่มีความหมายทุกอย่างคล้ายกับการใช้ structured log ที่ทรงพลังกว่า สำหรับหลายระบบที่ยังต้องพก log เดิมไปด้วยอาจทำได้ยาก แต่ถ้าเป็น greenfield มากพอ ผมแนะนำ
    • ผมก็เคยคิดถึงวิธีนี้เหมือนกัน แต่ชอบตรงที่สามารถใช้เครื่องมือง่าย ๆ เพื่อพอเห็นภาพคร่าว ๆ ว่าเกิดอะไรขึ้นได้
      ถ้าจะใช้ trace มีหลายอย่างที่ต้องทำงานให้ถูกต้อง ไม่งั้นก็อาจเป็นเพราะผมยังประสบการณ์น้อย เลยรู้สึกกลัวเครื่องมือก็ได้
    • นี่คือไอเดียของโปรเจกต์ Veneur ของ Stripe เลย คือจัดการ span, log และ metric ในรูปแบบเดียวกัน และ “อัตโนมัติ” roll up cardinality ตามความจำเป็น
      ตอนดูงานนำเสนอเมื่อหลายปีก่อนผมคิดว่าเจ๋งมาก แต่คงยากมากที่จะโน้มน้าวนักพัฒนาที่ไม่ใช่ SRE: https://github.com/stripe/veneur
    • ไม่จำเป็นต้องส่ง trace ไปที่ไหนก็ได้ เก็บไว้ใน process แล้วสร้าง API บน ข้อมูล trace แบบ in-memory นั้นได้
    • ที่บริษัทก็พูดเรื่องเดียวกันอยู่ มันสมเหตุสมผลทีเดียว และผมคิดว่าอาจกำจัด log ได้แทบทั้งหมด

  • OpenTelemetry เป็น โปรเจกต์ที่ขับเคลื่อนด้วยการตลาด ออกแบบแบบคณะกรรมการและ implement อย่างไร้เดียงสาไม่มีประสิทธิภาพ ดูเหมือนมีเป้าหมายหลักเพื่อให้ CTO ของบริษัท Fortune X00 ได้ติ๊ก checkbox ในเอกสาร strategic roadmap
    ไม่ใช่ของที่คนซึ่งมีทางเลือกควรใช้

    • ความเห็นอื่น ๆ ใน thread นี้ส่วนใหญ่ค่อนข้างชอบหรือมองบวกมาก อยากฟังรายละเอียดมากกว่านี้ว่ามันแย่ตรงไหนโดยเฉพาะ
    • ในฐานะผู้ก่อตั้ง highlight.io จากมุมผู้บริโภค ผมเห็นคุณค่ามากจาก OTEL เราใช้มันเพื่อขยายการรองรับภาษาให้ลูกค้าหลายราย และ community ก็เปิดรับมาก
      ตัวอย่างการเปลี่ยนแปลงที่เราเสนออยู่ที่นี่: https://github.com/open-telemetry/opentelemetry-js/pull/4049
      ถ้าช่วยแชร์เหตุผลว่าทำไมถึงมองว่าไม่ควรมีใครใช้เลยก็ดีครับ
    • ผมว่า assessment นั้นไม่ถูกต้องนะ มันดูใกล้เคียงกับ “ซอฟต์แวร์ open source ต่าง ๆ export Prometheus metric กับ Jaeger trace อยู่ แต่เราต้องการขายผลิตภัณฑ์ proprietary ที่เป็นทางเลือกแทน และไม่อยากส่ง patch ไปทุกโปรเจกต์” มากกว่า
      Datadog เคยทุ่มคนจำนวนมากเข้าไปเพิ่มการรองรับ Datadog ในโปรเจกต์ OSS จริง ๆ การกระโดดเข้าไปใน codebase ที่ไม่คุ้นเคยเป็นความสามารถที่แข็งแกร่ง ดังนั้นในช่วงต้นอาชีพก็น่าจะค่อนข้างดี
      OTel ทำให้โปรเจกต์ open source ใช้ abstraction layer ได้ เพื่อให้ผู้ใช้ซื้อบริการแทนการ host เองได้ ผมไม่ได้ชอบมันสุด ๆ แต่ถ้าเป็นบริการที่คนภายนอกบริษัทเราเป็นคนรัน ตอนนี้ผมคงพิจารณา OTel เพราะมันทำให้เราไม่ไปขวางผู้ใช้บางคนที่อยากใช้ Datadog
      ตอนที่ผมใช้ OTel ช่วงแรกมาก ๆ Go API ไม่มีประสิทธิภาพมากจนผิดหวัง การเพิ่ม counter ต้องใช้ context.Context และ abstraction ก็รั่ว เช่น ไม่มีวิธีตั้ง histogram bucket ตอน export ไป Prometheus ตอนนี้คงแก้แล้วมั้ง
    • วิจารณ์แรงเกินไป data model ถือเป็นความก้าวหน้าไปในทิศทางที่ถูกต้อง
      processor ก็มีความสามารถพอตัว และชุด contrib ของ receiver กับ exporter โดยรวมก็โอเค ไม่ได้จะบอกว่าเป็นทางออกที่ดีที่สุด และขึ้นอยู่กับ use case แต่คำวิจารณ์แรงขนาดนี้ดูไม่สมเหตุสมผล อนึ่ง ผมอยู่ในทีม maintain fluent-bit
    • การทำให้ service พูด OTLP และทำให้การตั้งค่า application ง่ายขึ้นเป็นการส่งข้อมูลไปยัง OTEL collector นั้นยอดเยี่ยมมาก
      จากมุมการปฏิบัติการ ไม่ว่านักพัฒนาจะเพิ่ม observability แบบไหนใน code ก็สามารถบังคับ filtering จากศูนย์กลางได้ และ application ก็ต้องมีทางเข้ากลางที่มันคุยด้วยเพียงทางเดียว
      ทุกอย่าง export OTLP ดังนั้นถ้าอยากย้ายไป backend ใหม่ก็แค่เปลี่ยนไฟล์ YAML และไม่ต้องเขียน application ใหม่เพื่อรองรับ logging backend ใหม่ ต่อให้มีข้อบกพร่อง ผมก็จะใช้ OTEL ต่อ 10 ครั้งจาก 10 ครั้ง มากกว่าย้อนกลับไปใช้วิธีเก่าที่ใช้ logging library เฉพาะ vendor

  • ผมเกลียด popup สมัครรับข่าวสาร ของบล็อกนี้จริง ๆ ไม่มีปุ่ม x เลยไม่ชัดเจนเลยว่าสามารถปิดได้โดยไม่ต้องให้อีเมล
    ใต้ปุ่ม subscribe มีข้อความ “continue reading” ที่ไม่ intuitive อย่างมาก ผมไม่รู้ด้วยซ้ำว่ามันกดได้ และคลิกข้างนอกก็ไม่ปิด แบบนี้ควรทำให้ดีกว่านี้
    ส่วน OpenTelemetry ผมอยากลองมานานแล้วว่ามันมีฟีเจอร์ครบตามที่ต้องใช้ตอนส่งข้อมูลไป Datadog หรือไม่ แต่ถ้านอกเหนือจากฟีเจอร์พื้นฐานแล้วยังต้องใช้ Datadog agent อยู่ ก็เท่ากับมีอีกอย่างที่ต้องจัดการและสอนคน เลยลังเล
    อยากรู้ว่ามีใครเคยต่อเข้ากับ Datadog จริง ๆ ไหม เป้าหมายไม่จำเป็นต้องผูกกับ Datadog ต่อไป แต่ตอนนี้ alert กับ log จำนวนมากอยู่ที่นั่น ดังนั้นถ้าเปลี่ยนไปใช้ OpenTelemetry ก่อน ในทางทฤษฎีก็น่าจะย้ายไปอย่างอื่นภายหลังได้

    • popup นั้นเป็นฟีเจอร์ของ medium.com เห็นด้วยว่าน่ารำคาญมาก
    • ส่วนตัวแล้ว survey แย่กว่าอีก มันถามความเห็น ผมกดตัวเลือกหนึ่งไป แล้วก็ได้รับรางวัลเป็นหน้าต่าง สร้างบัญชี แบบเต็มจอ
      พอกด back ก็กลับไป HN เลย

  • สงสัยว่ายังมีฟรอนต์เอนด์ที่ไม่กัดกินกระแสรายได้อย่างหนัก ทั้งในแง่กำลังคน โครงสร้างพื้นฐาน และค่าไลเซนส์อยู่หรือเปล่า
    รับรีเควสต์มากกว่า 2,000 ครั้งต่อวินาที แค่เก็บ log ไว้ก็แพงแล้ว

    • ถ้ายังไม่ได้ทำ ขอแนะนำ trace sampling Datadog APM ไม่มีคอนฟิกแบบประหยัด เลยไม่น่าประทับใจนัก
      เราเดินสแต็ก Jaeger เองด้วย sampling 0.1% และเมื่อเทียบกับ Datadog APM แล้ว ต้นทุนแทบมองข้ามได้
      สำหรับ metrics กับ logs นั้น sampling ไม่ได้มีประโยชน์มากนัก จึงไม่มีคำตอบที่ดี ถ้า gross margin ของ Datadog อยู่ที่ 80% แปลว่าจากเงินที่จ่ายไป ต้นทุนโครงสร้างพื้นฐานอย่างมากก็ 20% และถ้าค่าแรงน้อยกว่า 80% นั้น การรันสแต็กโอเพนซอร์สเองก็ช่วยลดค่าใช้จ่ายได้มาก แม้จะใช้ Datadog อยู่ เราก็ยังทำโปรเจกต์ลดการใช้งานทุก 3 เดือนอยู่ดี สุดท้ายก็ต้องคอยดูแลต่อเนื่องเหมือนกัน
    • คำตอบคือ sampling เก็บ sample ของรีเควสต์ที่สำเร็จแค่ 1% และเก็บ error ทั้งหมดก็พอ
      ต้นทุนก็เป็นปัญหา แต่คุณอาจแปลกใจได้ว่า observability สร้างภาระให้บริการหนักกว่าที่คิด ใช้ CPU ค่อนข้างมาก
    • ต้องกำหนดก่อนว่า “อย่างหนัก” หมายถึงระดับไหน ที่บริษัทก่อน เรา route traces ไปยัง Cassandra และเก็บไว้ใน AWS Elasticsearch domain แล้ว visualize ด้วย Jaeger
      ผมยังเขียน Elasticsearch query ไว้สองสามตัวเพื่อทำรายงานพื้นฐานสำหรับหา query ที่ช้าด้วย ถ้าทำตาม tutorial ของ OTEL/Jaeger ก็ถือว่าเป็นคอนฟิกที่ค่อนข้างมาตรฐาน
      traces อยู่ที่ระดับหลายร้อยรายการต่อวินาที และเก็บทั้งหมดโดยไม่ downsample ตั้ง retention ได้ 7 วัน และตอนที่ออกมาแทบยังไม่มีการ optimize จริงจังเลย ค่าใช้จ่ายรายเดือนน่าจะอยู่ระดับหลายสิบถึงหลายร้อยดอลลาร์
      สามารถกำหนดพฤติกรรมของ tracing sampler ได้ด้วย environment variable ที่ตั้งในคอนเทนเนอร์ ดู OTEL_TRACES_SAMPLER ในเอกสาร: https://opentelemetry.io/docs/specs/otel/configuration/sdk-e...
    • observability vendors ส่วนใหญ่ตอนนี้รองรับ OTEL แล้ว โปรเจกต์ OSS ที่ผมมีส่วนร่วมก็รองรับการรับข้อมูล OTEL เช่นกัน: https://github.com/grafana/tempo/
    • ไม่รู้ว่าทำไมถึงโดน downvote เราก็เจ็บปวดแบบเดียวกัน เพียงแต่สเกลอยู่ที่ 500,000 รีเควสต์ต่อวินาที
      ตอนนี้ใช้ Datadog อยู่ แต่ทุกคนรู้ว่ามันแพงเกินไป

  • เธรดส่วนใหญ่พูดถึงการใช้ OpenTelemetry ส่ง metrics/logs ไปยังงาน collector ที่โฮสต์เอง
    การใช้ไลบรารีมาตรฐานที่เครื่องมือ collector หลายตัวอย่าง ClickHouse รองรับนั้นมีประโยชน์อยู่แล้ว แต่อีกข้อดีคือสเปกทำให้ส่งต่อ trace ID ข้ามขอบเขตของระบบได้
    ถ้าทั้งระบบของคุณและ dependencies ต่างก็ implement สเปก OpenTelemetry คุณจะได้ spans ที่แสดงรายละเอียดอย่างละเอียดว่าเกิดอะไรขึ้นระหว่างทาง เช่น รู้ได้ว่าสาเหตุที่หน้าโหลดนานคือการโหลด disk page ของฐานข้อมูล หรือ span ของ metadata plane ในบริการคลาวด์เป็นต้นเหตุของ latency สูงหรือไม่

  • พอใจกับความก้าวหน้าของ OpenTelemetry มาก ตอนที่ผลักดันให้เริ่มใช้เมื่อหลายปีก่อน นักพัฒนาลังเลเพราะมันใหม่และไม่เคยได้ยินชื่อ แต่พอกลับมาดูอีกครั้งเมื่อหนึ่งปีก่อน OpenTelemetry ก็อยู่ทั่วระบบของเราแล้ว และ vendor ด้าน logging/tracing ที่เราใช้ก็อยู่ระหว่างย้ายไปทางนั้นเช่นกัน