OpenTelemetry dalam produksi: Hentikan proses debug dalam kegelapan

Pertama kali Anda benar-benar membutuhkan kemampuan observasi bukanlah saat Anda dengan tenang melihat ke dasbor. Itu ketika pengguna menulis "checkout lambat", grafik kesalahan terlihat normal dan di log Anda hanya menemukan deretan pesan yang terputus.

OpenTelemetry diciptakan untuk menghindari momen itu: bukan untuk memiliki lebih banyak grafik, tetapi untuk menghubungkan bagian-bagiannya. Permintaan memasuki API, memanggil database, melewati penyedia eksternal, memposting pekerjaan yang antri, dan mungkin gagal pada tiga layanan kemudian. Tanpa penelusuran terdistribusi, Anda merekonstruksi cerita itu dengan tangan. Dengan OpenTelemetry setidaknya Anda memiliki peta.

Intinya bukan trace, tapi ceritanya

A trace adalah barisan span. Taruh seperti itu kedengarannya dingin. Dalam praktiknya, setiap span adalah bagian dari cerita: POST /checkout, SELECT inventory, call payment provider, publish order.created.

Nilainya muncul ketika Anda mulai menjawab pertanyaan nyata:

layanan eksternal mana yang melambat?
apakah kesalahan berasal dari versi tertentu?
apakah masalahnya berdampak pada semua orang atau hanya satu penyewa?
apakah percobaan ulang menyembunyikan batas waktu?
pekerjaan asinkron dimulai tetapi kemudian mati di tempat lain?

Pertanyaan-pertanyaan ini tidak dapat diselesaikan dengan console.log yang dilontarkan secara terburu-buru. Memang sering kali log yang ditambahkan dalam keadaan darurat membantu Anda hari ini dan menjadi kebisingan besok.

Bagaimana cara memasukkan ini ke dalam aplikasi Node.js

Penyiapan yang paling sehat adalah sederhana: aplikasi menghasilkan telemetri, Collector memutuskan ke mana akan mengirimkannya.

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

Mengapa tidak mengekspor langsung ke vendornya? Karena pada awalnya tampak lebih cepat, kemudian Anda menyadari bahwa setiap layanan memiliki konfigurasi yang berbeda, percobaan ulang yang berbeda, filter yang berbeda dan tidak ada titik pusat untuk menghapus data sensitif atau mengubah tujuan.

Collector membosankan dalam semua hal yang benar. Ia menerima OTLP, melakukan pengelompokan, dapat memfilter, dapat melakukan pengambilan sampel, dapat menambahkan atribut umum, dan dapat mengekspor ke beberapa sistem.

Instrumentasi diri: bagus, tapi tidak cukup

Di Node.js Saya akan mulai dengan instrumentasi otomatis. Ini memberi Anda visibilitas langsung ke HTTP, kerangka kerja yang didukung, database, dan perpustakaan umum.

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

Kemudian Anda menginisialisasi SDK sebelum aplikasi lainnya:

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

Namun, ini melihat kerangka kerjanya, bukan produk Anda. Ia mengetahui Anda membuat kueri, tetapi ia tidak mengetahui bahwa kueri tersebut berada dalam "buat pesanan" atau "perpanjang langganan". Untuk itu Anda memerlukan span manual pada titik-titik di mana dominasi diperhitungkan.

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 pun. Saya akan meletakkannya di tempat, pada jam tiga pagi, saya ingin memahami apa yang terjadi tanpa membaca setengah dari basis kode.

Tiga aturan yang menghindari banyak kekacauan

Aturan pertama: setiap layanan harus memiliki service.name, lingkungan dan versi. Tampaknya sepele, tetapi tanpa atribut ini, trace kurang berguna. Saat penerapan merusak sesuatu, Anda ingin memfilter berdasarkan versi dalam dua detik.

Aturan kedua: jangan memasukkan data sensitif ke dalam atribut. Email, token, muatan bilangan bulat, dan alamat tidak boleh berakhir di backend observabilitas secara tidak sengaja. Jika Anda perlu mengidentifikasi pengguna, pertimbangkan ID internal, hashing, atau kolom yang kurang sensitif.

Aturan ketiga: perhatikan kardinalitas. user.id sebagai atribut trace bisa masuk akal. Sebagai label metrik, hal ini dapat merusak biaya dan kinerja Anda.

Metrik: sedikit, tapi bagus

Saya akan mulai dengan metrik yang sangat praktis:

tarif, kesalahan dan durasi permintaan;
latensi ketergantungan eksternal;
jumlah batas waktu dan percobaan ulang;
kedalaman ekor;
durasi pekerjaan;
persentase kesalahan per versi.

Sisanya ditambahkan bila diperlukan. Dasbor yang penuh dengan grafik yang tidak dilihat oleh siapa pun hanyalah furnitur, bukan yang dapat diamati.

Log: Masih berguna, tetapi tertaut

Log tidak hilang. Mereka menjadi jauh lebih berguna ketika membawa trace_id dan span_id. Jadi Anda dapat memulai dari log kesalahan dan membuka trace, atau memulai dari trace yang lambat dan hanya membaca log yang dihasilkan di jalur tersebut.

Tanpa korelasi, Anda mencari jarum. Dengan korelasi, setidaknya Anda tahu laci mana yang harus dicari.

Daftar periksa yang akan saya gunakan sebelum mengatakan "kita terlindungi"

trace sebenarnya melintasi beberapa layanan.
Log termasuk trace_id dan span_id.
Collector dikonfigurasi dengan batching dan batas memori.
Kesalahan dicatat di span.
Ada kebijakan pengambilan sampel.
Metrik telah mengontrol kardinalitas.
Data sensitif disaring.
Peringatan dimulai dari gejala pengguna, bukan grafik acak.

Kesimpulan

OpenTelemetry tidak menyelesaikan masalah produksi dengan sendirinya. Namun cara Anda menghadapinya berubah. Daripada menambahkan log secara membabi buta, Anda mulai mengikuti jalur permintaan yang sebenarnya.

Bagi saya tanda bahwa ini berhasil adalah sederhana: ketika sesuatu terjadi, tim berhenti bertanya "di mana kita mencari?" dan mulai bertanya "mengapa lagu itu lambat?". Di sinilah observabilitas menjadi sebuah alat, bukan kumpulan dasbor.

Sumber