OpenTelemetry อยู่ระหว่างดำเนินการ: หยุดการแก้ไขข้อบกพร่องในความมืด

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

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

ประเด็นไม่ใช่ trace แต่เป็นเรื่องราว

trace คือลำดับของ span พูดแบบนี้ก็ฟังดูเย็นชานะ ในทางปฏิบัติ span แต่ละอันเป็นเพียงส่วนหนึ่งของเรื่องราว: POST /checkout, SELECT inventory, call payment provider, publish order.created

คุณค่าจะเกิดขึ้นเมื่อคุณเริ่มตอบคำถามจริง:

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

คำถามเหล่านี้ไม่สามารถแก้ไขได้ด้วยการรีบเร่ง console.log แท้จริงแล้วบันทึกที่เพิ่มไว้ในกรณีฉุกเฉินมักจะช่วยคุณได้ในวันนี้และจะกลายเป็นเสียงรบกวนในวันพรุ่งนี้

ฉันจะใส่สิ่งนี้ลงในแอปได้อย่างไร Node.js

การตั้งค่าที่ดีต่อสุขภาพที่สุดนั้นง่ายดาย: แอปจะสร้างการวัดและส่งข้อมูลทางไกล ส่วน Collector จะตัดสินใจว่าจะส่งไปที่ใด

Node.js app -> OpenTelemetry Collector -> backend di observability

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

Collector น่าเบื่อในรูปแบบที่ถูกต้อง ได้รับ OTLP, ทำการแบทช์, สามารถกรอง, ทำการสุ่มตัวอย่าง, สามารถเพิ่มคุณสมบัติทั่วไป และสามารถส่งออกไปยังหลายระบบได้

การพึ่งพาตนเอง: ดีแต่ยังไม่เพียงพอ

ใน Node.js ฉันจะเริ่มด้วยเครื่องมือวัดอัตโนมัติ ช่วยให้คุณมองเห็น HTTP, เฟรมเวิร์กที่รองรับ, ฐานข้อมูล และไลบรารีทั่วไปได้ทันที

npm install @opentelemetry/sdk-node \
  @opentelemetry/auto-instrumentations-node \
  @opentelemetry/exporter-trace-otlp-http

จากนั้นคุณเริ่มต้น SDK ก่อนส่วนที่เหลือของแอป:

import { NodeSDK } from '@opentelemetry/sdk-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: process.env.OTEL_EXPORTER_OTLP_TRACES_ENDPOINT,
  }),
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();

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

const span = tracer.startSpan('checkout.create_order');

try {
  span.setAttribute('cart.items_count', input.items.length);
  const order = await createOrder(input);
  span.setAttribute('order.id', order.id);
  return order;
} catch (error) {
  span.recordException(error as Error);
  throw error;
} finally {
  span.end();
}

ฉันจะไม่ใส่คู่มือ span ไว้ที่ไหนเลย ฉันจะวางไว้ตรงไหนตอนตีสาม ฉันอยากจะเข้าใจสิ่งที่เกิดขึ้นโดยไม่ต้องอ่านโค้ดเพียงครึ่งเดียว

กฎสามข้อที่หลีกหนีความวุ่นวายมากมาย

กฎข้อแรก: แต่ละบริการต้องมี service.name สภาพแวดล้อม และเวอร์ชัน ดูเหมือนเล็กน้อย แต่หากไม่มีคุณลักษณะเหล่านี้ trace จะมีประโยชน์น้อยกว่ามาก เมื่อการปรับใช้เกิดความเสียหาย คุณต้องการกรองตามเวอร์ชันภายในสองวินาที

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

กฎข้อที่สาม: ให้ความสนใจกับจำนวนสมาชิก user.id เป็นคุณลักษณะของ trace สมเหตุสมผล เนื่องจากเป็นป้ายกำกับเมตริก จึงสามารถทำลายต้นทุนและประสิทธิภาพของคุณได้

ตัวชี้วัด: น้อยแต่ดี

ฉันจะเริ่มต้นด้วยตัวชี้วัดที่ใช้งานได้จริง:

• อัตรา ข้อผิดพลาด และระยะเวลาของคำขอ
• เวลาแฝงของการพึ่งพาภายนอก
• จำนวนการหมดเวลาและการลองใหม่
• ความลึกของหาง
• ระยะเวลางาน;
• เปอร์เซ็นต์ของข้อผิดพลาดต่อเวอร์ชัน

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

บันทึก: ยังคงมีประโยชน์ แต่มีการเชื่อมโยง

บันทึกไม่หายไป มันจะมีประโยชน์มากขึ้นเมื่อมี trace_id และ span_id ดังนั้นคุณจึงสามารถเริ่มจากบันทึกข้อผิดพลาดและเปิด trace หรือเริ่มจาก trace ที่ช้า และอ่านเฉพาะบันทึกที่สร้างขึ้นในเส้นทางนั้น

คุณกำลังมองหาเข็มโดยไม่มีความสัมพันธ์กัน ด้วยความสัมพันธ์กัน อย่างน้อยคุณก็รู้ว่าต้องดูลิ้นชักไหน

รายการตรวจสอบที่ฉันจะใช้ก่อนพูดว่า "เราครอบคลุมแล้ว"

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

บทสรุป

OpenTelemetry ไม่สามารถแก้ปัญหาการผลิตได้ด้วยตัวเอง แต่วิธีที่คุณจัดการกับพวกเขาเปลี่ยนไป แทนที่จะเพิ่มบันทึกแบบสุ่มสี่สุ่มห้า คุณเริ่มติดตามเส้นทางที่แท้จริงของคำขอ

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

แหล่งที่มา

• OpenTelemetry: Overview
• OpenTelemetry Collector: Configuration
• OpenTelemetry JavaScript: Node.js getting started
• OpenTelemetry Semantic Conventions