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

spinny:~/writing $ less opentelemetry-nodejs-observability-guide.md

1 
2ครั้งแรกที่คุณต้องการความสามารถในการสังเกตจริงๆ ไม่ใช่เมื่อคุณดูแดชบอร์ดอย่างใจเย็น เมื่อผู้ใช้เขียนว่า "การชำระเงินช้า" กราฟข้อผิดพลาดจะดูเป็นปกติ และในบันทึกคุณจะพบเพียงแถวของข้อความที่ไม่ได้เชื่อมต่อเท่านั้น
3 
4OpenTelemetry ถูกสร้างขึ้นเพื่อหลีกเลี่ยงช่วงเวลานั้น: ไม่ใช่เพื่อให้มีกราฟิกมากขึ้น แต่เพื่อเชื่อมโยงชิ้นส่วนต่างๆ คำขอเข้าสู่ API เรียกฐานข้อมูล ผ่านผู้ให้บริการภายนอก โพสต์งานที่อยู่ในคิว และอาจล้มเหลวสามบริการในภายหลัง หากไม่มีการติดตามแบบกระจาย คุณจะสร้างเรื่องราวนั้นขึ้นมาใหม่ด้วยมือ ด้วย OpenTelemetry อย่างน้อยคุณก็จะมีแผนที่
5 
6## ประเด็นไม่ใช่ trace แต่เป็นเรื่องราว
7 
8trace คือลำดับของ span พูดแบบนี้ก็ฟังดูเย็นชานะ ในทางปฏิบัติ span แต่ละอันเป็นเพียงส่วนหนึ่งของเรื่องราว: `POST /checkout`, `SELECT inventory`, `call payment provider`, `publish order.created`
9 
10คุณค่าจะเกิดขึ้นเมื่อคุณเริ่มตอบคำถามจริง:
11 
12- บริการภายนอกใดที่ชะลอตัว?
13- ข้อผิดพลาดมาจากเวอร์ชันใดเวอร์ชันหนึ่งโดยเฉพาะหรือไม่
14- ปัญหาส่งผลกระทบต่อทุกคนหรือผู้เช่าเพียงรายเดียว?
15- การลองใหม่ซ่อนการหมดเวลาหรือไม่
16- งานอะซิงโครนัสเริ่มต้นแต่จากนั้นก็ไปตายที่อื่นใช่ไหม
17 
18คำถามเหล่านี้ไม่สามารถแก้ไขได้ด้วยการรีบเร่ง `console.log` แท้จริงแล้วบันทึกที่เพิ่มไว้ในกรณีฉุกเฉินมักจะช่วยคุณได้ในวันนี้และจะกลายเป็นเสียงรบกวนในวันพรุ่งนี้
19 
20## ฉันจะใส่สิ่งนี้ลงในแอปได้อย่างไร Node.js
21 
22การตั้งค่าที่ดีต่อสุขภาพที่สุดนั้นง่ายดาย: แอปจะสร้างการวัดและส่งข้อมูลทางไกล ส่วน Collector จะตัดสินใจว่าจะส่งไปที่ใด
23 
24```text
25Node.js app -> OpenTelemetry Collector -> backend di observability
26```
27 
28ทำไมไม่ส่งออกไปยังผู้ขายโดยตรง? เพราะในตอนแรกดูเหมือนว่าจะเร็วกว่า จากนั้นคุณจะรู้ว่าแต่ละบริการมีการกำหนดค่าที่แตกต่างกัน การลองใหม่ที่แตกต่างกัน ตัวกรองที่แตกต่างกัน และไม่มีจุดศูนย์กลางในการลบข้อมูลที่ละเอียดอ่อนหรือเปลี่ยนปลายทาง
29 
30Collector น่าเบื่อในรูปแบบที่ถูกต้อง ได้รับ OTLP, ทำการแบทช์, สามารถกรอง, ทำการสุ่มตัวอย่าง, สามารถเพิ่มคุณสมบัติทั่วไป และสามารถส่งออกไปยังหลายระบบได้
31 
32## การพึ่งพาตนเอง: ดีแต่ยังไม่เพียงพอ
33 
34ใน Node.js ฉันจะเริ่มด้วยเครื่องมือวัดอัตโนมัติ ช่วยให้คุณมองเห็น HTTP, เฟรมเวิร์กที่รองรับ, ฐานข้อมูล และไลบรารีทั่วไปได้ทันที
35 
36```bash
37npm install @opentelemetry/sdk-node \
38  @opentelemetry/auto-instrumentations-node \
39  @opentelemetry/exporter-trace-otlp-http
40```
41 
42จากนั้นคุณเริ่มต้น SDK ก่อนส่วนที่เหลือของแอป:
43 
44```typescript
45import { NodeSDK } from '@opentelemetry/sdk-node';
46import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
47import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';
48 
49const sdk = new NodeSDK({
50  traceExporter: new OTLPTraceExporter({
51    url: process.env.OTEL_EXPORTER_OTLP_TRACES_ENDPOINT,
52  }),
53  instrumentations: [getNodeAutoInstrumentations()],
54});
55 
56sdk.start();
57```
58 
59อย่างไรก็ตาม สิ่งนี้จะมองเห็นกรอบงาน ไม่ใช่ผลิตภัณฑ์ของคุณ ระบบรู้ว่าคุณได้ทำการสอบถาม แต่ไม่ทราบว่าแบบสอบถามอยู่ใน "สร้างคำสั่งซื้อ" หรือ "ต่ออายุการสมัคร" เพื่อสิ่งนั้นคุณจะต้องมีคู่มือ span ในจุดที่ความเหนือกว่ามีความสำคัญ
60 
61```typescript
62const span = tracer.startSpan('checkout.create_order');
63 
64try {
65  span.setAttribute('cart.items_count', input.items.length);
66  const order = await createOrder(input);
67  span.setAttribute('order.id', order.id);
68  return order;
69} catch (error) {
70  span.recordException(error as Error);
71  throw error;
72} finally {
73  span.end();
74}
75```
76 
77ฉันจะไม่ใส่คู่มือ span ไว้ที่ไหนเลย ฉันจะวางไว้ตรงไหนตอนตีสาม ฉันอยากจะเข้าใจสิ่งที่เกิดขึ้นโดยไม่ต้องอ่านโค้ดเพียงครึ่งเดียว
78 
79## กฎสามข้อที่หลีกหนีความวุ่นวายมากมาย
80 
81กฎข้อแรก: แต่ละบริการต้องมี `service.name` สภาพแวดล้อม และเวอร์ชัน ดูเหมือนเล็กน้อย แต่หากไม่มีคุณลักษณะเหล่านี้ trace จะมีประโยชน์น้อยกว่ามาก เมื่อการปรับใช้เกิดความเสียหาย คุณต้องการกรองตามเวอร์ชันภายในสองวินาที
82 
83กฎข้อที่สอง: อย่าใส่ข้อมูลที่ละเอียดอ่อนในแอตทริบิวต์ อีเมล โทเค็น เพย์โหลดจำนวนเต็ม และที่อยู่ไม่ควรจบลงที่แบ็กเอนด์ที่สามารถสังเกตได้โดยไม่ได้ตั้งใจ หากคุณต้องการระบุผู้ใช้ ให้พิจารณารหัสภายใน การแฮช หรือฟิลด์ที่ละเอียดอ่อนน้อยกว่า
84 
85กฎข้อที่สาม: ให้ความสนใจกับจำนวนสมาชิก `user.id` เป็นคุณลักษณะของ trace สมเหตุสมผล เนื่องจากเป็นป้ายกำกับเมตริก จึงสามารถทำลายต้นทุนและประสิทธิภาพของคุณได้
86 
87## ตัวชี้วัด: น้อยแต่ดี
88 
89ฉันจะเริ่มต้นด้วยตัวชี้วัดที่ใช้งานได้จริง:
90 
91- อัตรา ข้อผิดพลาด และระยะเวลาของคำขอ
92- เวลาแฝงของการพึ่งพาภายนอก
93- จำนวนการหมดเวลาและการลองใหม่
94- ความลึกของหาง
95- ระยะเวลางาน;
96- เปอร์เซ็นต์ของข้อผิดพลาดต่อเวอร์ชัน
97 
98ส่วนที่เหลือจะถูกเพิ่มเมื่อจำเป็น แดชบอร์ดที่เต็มไปด้วยกราฟที่ไม่มีใครมองคือเฟอร์นิเจอร์ ไม่ใช่สิ่งที่สังเกตได้
99 
100## บันทึก: ยังคงมีประโยชน์ แต่มีการเชื่อมโยง
101 
102บันทึกไม่หายไป มันจะมีประโยชน์มากขึ้นเมื่อมี `trace_id` และ `span_id` ดังนั้นคุณจึงสามารถเริ่มจากบันทึกข้อผิดพลาดและเปิด trace หรือเริ่มจาก trace ที่ช้า และอ่านเฉพาะบันทึกที่สร้างขึ้นในเส้นทางนั้น
103 
104คุณกำลังมองหาเข็มโดยไม่มีความสัมพันธ์กัน ด้วยความสัมพันธ์กัน อย่างน้อยคุณก็รู้ว่าต้องดูลิ้นชักไหน
105 
106## รายการตรวจสอบที่ฉันจะใช้ก่อนพูดว่า "เราครอบคลุมแล้ว"
107 
108- trace ข้ามหลายบริการจริงๆ
109- บันทึกประกอบด้วย `trace_id` และ `span_id`
110- Collector ได้รับการกำหนดค่าด้วยขีดจำกัดแบตช์และหน่วยความจำ
111- ข้อผิดพลาดจะถูกบันทึกใน span
112- มีนโยบายการสุ่มตัวอย่าง
113- ตัวชี้วัดมีการควบคุมจำนวนสมาชิก
114- ข้อมูลที่ละเอียดอ่อนจะถูกกรอง
115- การแจ้งเตือนเริ่มจากอาการของผู้ใช้ ไม่ใช่กราฟสุ่ม
116 
117## บทสรุป
118 
119OpenTelemetry ไม่สามารถแก้ปัญหาการผลิตได้ด้วยตัวเอง แต่วิธีที่คุณจัดการกับพวกเขาเปลี่ยนไป แทนที่จะเพิ่มบันทึกแบบสุ่มสี่สุ่มห้า คุณเริ่มติดตามเส้นทางที่แท้จริงของคำขอ
120 
121สำหรับฉัน สัญญาณที่บอกว่ามันใช้งานได้นั้นเรียบง่าย: เมื่อมีอะไรเกิดขึ้น ทีมงานจะหยุดถามว่า "เรากำลังมองอยู่ที่ไหน" และเริ่มถามว่า "ทำไมชิ้นนั้นถึงช้า" นั่นคือจุดที่ความสามารถในการสังเกตกลายเป็นเครื่องมือ ไม่ใช่ชุดของแดชบอร์ด
122 
123## แหล่งที่มา
124 
125- [OpenTelemetry: Overview](https://opentelemetry.io/docs/specs/otel/overview/)
126- [OpenTelemetry Collector: Configuration](https://opentelemetry.io/docs/collector/configuration/)
127- [OpenTelemetry JavaScript: Node.js getting started](https://opentelemetry.io/docs/languages/js/getting-started/nodejs/)
128- [OpenTelemetry Semantic Conventions](https://opentelemetry.io/docs/concepts/semantic-conventions/)
129

:OpenTelemetry อยู่ระหว่างดำเนินการ: หยุดการแก้ไขข้อบกพร่องในความมืดlines 1-129 (END) — press q to close

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

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

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

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

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

12- บริการภายนอกใดที่ชะลอตัว?

13- ข้อผิดพลาดมาจากเวอร์ชันใดเวอร์ชันหนึ่งโดยเฉพาะหรือไม่

14- ปัญหาส่งผลกระทบต่อทุกคนหรือผู้เช่าเพียงรายเดียว?

15- การลองใหม่ซ่อนการหมดเวลาหรือไม่

16- งานอะซิงโครนัสเริ่มต้นแต่จากนั้นก็ไปตายที่อื่นใช่ไหม

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

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

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

24```text

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

26```

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

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

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

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

36```bash

37npm install @opentelemetry/sdk-node \

38 @opentelemetry/auto-instrumentations-node \

39 @opentelemetry/exporter-trace-otlp-http

40```

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

44```typescript

45import { NodeSDK } from '@opentelemetry/sdk-node';

46import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';

47import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';

49const sdk = new NodeSDK({

50 traceExporter: new OTLPTraceExporter({

51 url: process.env.OTEL_EXPORTER_OTLP_TRACES_ENDPOINT,

52 }),

53 instrumentations: [getNodeAutoInstrumentations()],

54});

56sdk.start();

57```

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

61```typescript

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

64try {

65 span.setAttribute('cart.items_count', input.items.length);

66 const order = await createOrder(input);

67 span.setAttribute('order.id', order.id);

68 return order;

69} catch (error) {

70 span.recordException(error as Error);

71 throw error;

72} finally {

73 span.end();

74}

75```

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

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

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

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

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

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

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

91- อัตรา ข้อผิดพลาด และระยะเวลาของคำขอ

92- เวลาแฝงของการพึ่งพาภายนอก

93- จำนวนการหมดเวลาและการลองใหม่

94- ความลึกของหาง

95- ระยะเวลางาน;

96- เปอร์เซ็นต์ของข้อผิดพลาดต่อเวอร์ชัน

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

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

101

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

103

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

105

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

107

108- trace ข้ามหลายบริการจริงๆ

109- บันทึกประกอบด้วย `trace_id` และ `span_id`

110- Collector ได้รับการกำหนดค่าด้วยขีดจำกัดแบตช์และหน่วยความจำ

111- ข้อผิดพลาดจะถูกบันทึกใน span

112- มีนโยบายการสุ่มตัวอย่าง

113- ตัวชี้วัดมีการควบคุมจำนวนสมาชิก

114- ข้อมูลที่ละเอียดอ่อนจะถูกกรอง

115- การแจ้งเตือนเริ่มจากอาการของผู้ใช้ ไม่ใช่กราฟสุ่ม

116

117## บทสรุป

118

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

120

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

122

123## แหล่งที่มา

124

125- [OpenTelemetry: Overview](https://opentelemetry.io/docs/specs/otel/overview/)

126- [OpenTelemetry Collector: Configuration](https://opentelemetry.io/docs/collector/configuration/)

127- [OpenTelemetry JavaScript: Node.js getting started](https://opentelemetry.io/docs/languages/js/getting-started/nodejs/)

128- [OpenTelemetry Semantic Conventions](https://opentelemetry.io/docs/concepts/semantic-conventions/)

129