OpenTelemetry dalam pengeluaran: Hentikan penyahpepijatan dalam gelap

Kali pertama anda benar-benar memerlukan pemerhatian bukanlah apabila anda melihat papan pemuka dengan tenang. Ia adalah apabila pengguna menulis "checkout lambat", graf ralat kelihatan normal dan dalam log anda hanya menemui satu baris mesej yang terputus sambungan.

OpenTelemetry dicipta untuk mengelakkan detik itu: bukan untuk mempunyai lebih banyak grafik, tetapi untuk menyambung kepingan. Permintaan memasuki API, memanggil pangkalan data, melalui pembekal luaran, menyiarkan kerja beratur dan mungkin gagal tiga perkhidmatan kemudian. Tanpa pengesanan yang diedarkan, anda membina semula cerita itu dengan tangan. Dengan OpenTelemetry sekurang-kurangnya anda mempunyai peta.

Intinya bukan trace, tetapi ceritanya

A trace ialah urutan span. Letakkan seperti itu bunyinya sejuk. Dalam amalan, setiap span ialah secebis cerita: POST /checkout, SELECT inventory, call payment provider, publish order.created.

Nilai itu datang apabila anda mula menjawab soalan sebenar:

• perkhidmatan luaran manakah yang semakin perlahan?
• adakah ralat datang daripada versi tertentu?
• adakah masalah itu menjejaskan semua orang atau hanya seorang penyewa?
• adakah percubaan semula menyembunyikan tamat masa?
• kerja tak segerak bermula tetapi kemudian mati di tempat lain?

Soalan-soalan ini tidak dapat diselesaikan dengan console.log dilemparkan dengan tergesa-gesa. Memang, selalunya log yang ditambahkan dalam kecemasan membantu anda hari ini dan menjadi bising esok.

Bagaimanakah saya boleh meletakkan ini dalam apl Node.js

Persediaan paling sihat adalah mudah: apl menghasilkan telemetri, Collector menentukan tempat untuk menghantarnya.

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

Mengapa tidak mengeksport terus kepada vendor? Kerana pada mulanya ia kelihatan lebih pantas, kemudian anda menyedari bahawa setiap perkhidmatan mempunyai konfigurasi berbeza, percubaan semula berbeza, penapis berbeza dan tiada titik pusat untuk mengalih keluar data sensitif atau menukar destinasi.

Collector membosankan dengan cara yang betul. Ia menerima OTLP, melakukan pengumpulan, boleh menapis, boleh melakukan pensampelan, boleh menambah atribut biasa dan boleh mengeksport ke berbilang sistem.

Instrumen kendiri: baik, tetapi tidak mencukupi

Dalam Node.js saya akan mulakan dengan auto-instrumentasi. Ia memberi anda keterlihatan serta-merta ke dalam HTTP, rangka kerja yang disokong, pangkalan data dan perpustakaan biasa.

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

Kemudian anda memulakan SDK sebelum apl yang lain:

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();

Walau bagaimanapun, ini melihat rangka kerja, bukan produk anda. Ia mengetahui bahawa anda membuat pertanyaan, tetapi ia tidak mengetahui bahawa pertanyaan adalah dalam "buat pesanan" atau "perbaharui langganan". Untuk itu anda memerlukan span manual pada titik di mana penguasaan penting.

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();
}

Saya tidak akan meletakkan manual span di mana-mana sahaja. Saya akan meletakkannya di mana, pada pukul tiga pagi, saya ingin memahami apa yang berlaku tanpa membaca separuh asas kod.

Tiga peraturan yang mengelakkan banyak huru-hara

Peraturan pertama: setiap perkhidmatan mesti mempunyai service.name, persekitaran dan versi. Ia kelihatan remeh, tetapi tanpa atribut ini trace adalah kurang berguna. Apabila penggunaan memecahkan sesuatu, anda mahu menapis mengikut versi dalam masa dua saat.

Peraturan kedua: jangan letakkan data sensitif dalam atribut. E-mel, token, muatan integer dan alamat tidak sepatutnya berakhir di bahagian belakang yang boleh diperhatikan secara tidak sengaja. Jika anda perlu mengenal pasti pengguna, pertimbangkan ID dalaman, pencincangan atau medan yang kurang sensitif.

Peraturan ketiga: beri perhatian kepada kardinaliti. user.id sebagai atribut trace boleh masuk akal. Sebagai label metrik ia boleh memusnahkan kos dan prestasi anda.

Metrik: sedikit, tetapi bagus

Saya akan mulakan dengan metrik yang sangat praktikal:

• kadar, kesilapan dan tempoh permintaan;
• kependaman kebergantungan luar;
• bilangan tamat masa dan percubaan semula;
• kedalaman ekor;
• tempoh kerja;
• peratusan ralat setiap versi.

Selebihnya ditambah apabila diperlukan. Papan pemuka yang penuh dengan graf yang tiada siapa yang melihat adalah perabot, bukan kebolehmerhatian.

Log: Masih berguna, tetapi dipautkan

Log tidak hilang. Mereka menjadi lebih berguna apabila mereka membawa trace_id dan span_id. Jadi anda boleh bermula dari log ralat dan buka trace, atau mulakan dari trace perlahan dan baca hanya log yang dihasilkan dalam laluan itu.

Tanpa korelasi, anda sedang mencari jarum. Dengan korelasi, sekurang-kurangnya anda tahu laci mana yang hendak dilihat.

Senarai semak yang saya akan gunakan sebelum mengatakan "kami dilindungi"

• trace sebenarnya merentas pelbagai perkhidmatan.
• Log termasuk trace_id dan span_id.
• Collector dikonfigurasikan dengan batching dan had memori.
• Ralat direkodkan dalam span.
• Terdapat dasar pensampelan.
• Metrik mempunyai kardinaliti yang dikawal.
• Data sensitif ditapis.
• Makluman bermula daripada simptom pengguna, bukan graf rawak.

Kesimpulan

OpenTelemetry tidak menyelesaikan masalah pengeluaran dengan sendirinya. Tetapi cara anda berurusan dengan mereka berubah. Daripada menambah log secara membuta tuli, anda mula mengikut laluan sebenar permintaan.

Bagi saya tanda bahawa ia berfungsi adalah mudah: apabila sesuatu berlaku, pasukan berhenti bertanya "di mana kita mencari?" dan mula bertanya "kenapa sekeping itu lambat?". Di situlah kebolehmerhatian menjadi alat, bukan koleksi papan pemuka.

Sumber

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