Pembagian batas log, indikator dan Tracing

Reaksi pertama banyak tim ketika mencoba melengkapi observabilitas adalah “menghubungkan log, indikator, dan penelusuran”.

Kalimat ini kedengarannya benar, tetapi masalah sebenarnya adalah langkah berikutnya: ketiga hal tersebut terhubung, namun batasannya tidak ditentukan, sehingga masing-masing metode menghapus dua metode lainnya.

Hasilnya biasanya sangat familiar: label indikator meledak, pengambilan sampel penelusuran terus meningkat, volume log berlipat ganda setiap bulan, alarm masih tidak akurat, dan pemecahan masalah masih bergantung pada pemahaman manusia. Tidak ada kekurangan alat, namun sistemnya belum menjadi lebih mudah diamati.

Penilaian saya adalah: **Batas-batas log, indikator, dan penelusuran tidak boleh ditentukan oleh “seperti apa datanya” tetapi oleh “keputusan apa yang harus diambil selanjutnya”. **

• Indikatornya menjawab: apakah harus segera ditangani, dan apakah cakupan dampaknya besar;
• Menelusuri jawaban: Di bagian tautan mana masalahnya mungkin tersangkut?
• Log menjawab: Apa yang sebenarnya terjadi pada potongan kode dalam permintaan itu.

Ketiganya berada dalam hubungan peningkatan biaya pengambilan keputusan. Indikatornya adalah yang termurah dan cocok untuk pemantauan pasar secara terus menerus; Penelusuran lebih mahal dan cocok untuk mempersempit jangkauan; log adalah yang terberat dan cocok untuk restorasi akhir pemandangan.

Jika log bertanggung jawab untuk mengkhawatirkan, Tracing bertanggung jawab untuk audit, dan indikator bertanggung jawab untuk setiap pengguna, setiap pesanan, dan setiap dimensi SQL, sistem pasti akan dapat berjalan, tetapi harganya akan sangat jujur ​​dalam penyimpanan, kueri, pengambilan sampel, kontrol kardinalitas, dan pemecahan masalah manusia.

Keputusan pertama yang sebenarnya harus menjadi indikatornya.

Ketika ada kesalahan pada saluran, langkah pertama biasanya adalah “menilai apakah kesalahan tersebut layak untuk segera ditangani”.

Langkah ini paling cocok untuk indikator. Di permukaan, tampaknya indikator ini lebih maju, namun sebenarnya lebih dekat dan paling murah.

Sistem indikator yang baik harus menjawab pertanyaan-pertanyaan berikut dalam waktu sepuluh detik:

• Apakah tingkat kesalahan meningkat, atau hanya kebisingan sesekali?
• Apakah variasi penundaan bersifat global atau terkonsentrasi pada antarmuka tertentu?
• Dampaknya terhadap mesin, ruang komputer, atau seluruh rantai panggilan;
• Apakah masalahnya baru saja terjadi, atau sudah berlangsung setengah jam?

Masalah-masalah ini pada dasarnya melakukan hal yang sama: **Menggunakan agregasi informasi berbiaya rendah sebagai imbalan atas penilaian tindakan yang bernilai tinggi. **

Oleh karena itu, prinsip desain indikator yang paling penting adalah “dapat juga mendukung pengambilan keputusan setelah agregasi”.

Banyak tim membuat indikator buruk dengan menggunakan bidang berkardinalitas tinggi yang tidak boleh disertakan dalam indikator, seperti user_id, order_id, trace_id, URL lengkap, dan pesan kesalahan dinamis. Hal ini sangat memuaskan dalam jangka pendek dan rasanya semuanya bisa dilakukan; dalam jangka menengah, perluasan penyimpanan, perlambatan kueri, dan dimensi alarm akan mulai tidak terkendali; akibat jangka panjangnya biasanya tim itu sendiri takut menggunakan platform indikator.

Indikator cocok untuk mengekspresikan tren dan distribusi dalam dimensi stabil, seperti nama antarmuka, kode status, ruang komputer, layanan dependen, dan cache hits. Nilai dari dimensi ini bukan untuk “memulihkan permintaan tertentu”, namun untuk membantu dengan cepat menentukan apakah masalah terjadi di cluster.

Ketika pertanyaan yang ingin Anda tanyakan adalah “Order mana yang gagal?”, maka ini bukan lagi pertanyaan yang harus dijawab oleh indikator saja.

Nilai Tracing terletak pada memperpendek jalur penentuan posisi

Penelusuran sering disalahartikan sebagai “logging yang lebih canggih daripada logging”. Ini akan langsung menghabiskannya.

Keunggulan Tracing adalah mendeskripsikan jalur dan hubungan permintaan yang memakan waktu di seluruh layanan dan komponen. Tentu saja cocok untuk menjawab pertanyaan seperti ini:

• Apakah kelambatan disebabkan oleh gateway, aplikasi, database, atau ketergantungan eksternal?
• Percobaan ulang, yang hopnya diperkuat;
• Jika P99 pada antarmuka tertentu sangat tinggi, apakah ini terkait dengan layanan hilir tertentu?
• Permintaan abnormal mulai menyimpang dari jalur normal setelah melewati layanan mana.

Dengan kata lain, **Tracing menyediakan struktur tautan, bukan adegan lengkap. **

Oleh karena itu, yang paling harus dibawa adalah informasi jalur, tahap kunci yang memakan waktu, dan sejumlah kecil tag yang dapat membantu memfilter, daripada memasukkan objek bisnis sepenuhnya ke dalamnya, apalagi mengubah setiap variabel lokal menjadi atribut span.

Saya telah melihat banyak tim mencoba menjadikannya sumber kebenaran terpadu segera setelah mereka mulai menelusuri: teks SQL asli harus digantung, masukan pengguna harus digantung, isi respons lengkap harus digantung, dan semua parameter percobaan ulang harus digantung. Hasil akhirnya adalah:

• Ukuran bentang meningkat dengan cepat, dan laju pengambilan sampel terpaksa diturunkan;
• Saat menanyakan tautan, noise jauh lebih besar daripada sinyal;
• Saat kami benar-benar sampai di lokasi kecelakaan, permintaan kunci tidak tertinggal karena pengambilan sampel;
• Tata kelola data sensitif mulai menjadi biaya pemeliharaan baru.

Waktu yang paling berharga untuk Penelusuran adalah saat Anda dapat menggunakan tautan untuk dengan cepat menentukan layanan, rentang, dan bagian log mana yang harus dilihat pada lompatan berikutnya.

Jika hal tersebut terlalu berat sehingga tidak dapat dipertahankan secara stabil secara global, atau terlalu berat sehingga menanyakannya sekali pun terasa menyakitkan, maka batasan tersebut telah terlampaui.

Log bukanlah sistem indikator kedua, melainkan bahan pengumpulan bukti akhir

Log adalah yang paling mudah untuk salah menilai karena sepertinya dapat menampung apa saja.

Memang, log tersebut paling dekat dengan lokasi kejadian. Bagaimana cabang diambil, seperti apa parameternya, berapa kali dicoba ulang, jalur downgrade mana yang dilakukan, dan mengapa hasil yang tampaknya berhasil namun salah secara semantik yang dikembalikan kali ini sering kali hanya dapat dilihat dari log.

Namun justru karena ia memiliki entropi informasi tertinggi, maka ia paling tidak cocok untuk “pengamatan berkelanjutan global”.

Penggunaan log sebagai sumber pemantauan utama mempunyai tiga konsekuensi umum.

Pertama, biaya kueri yang tinggi. **Setiap saat, kesimpulan sementara diambil dari fakta awal, yang lambat dan stabilitasnya buruk.

Kedua, suaranya sangat bising. ** Jika volume log besar, tim secara alami akan mengurangi pencetakan; setelah pencetakan dikurangi, cabang-cabang utama sering kali kekurangan bukti; pada akhirnya, semua orang akan bolak-balik antara “terlalu banyak untuk dilihat” dan “terlalu sedikit untuk dilihat”.

Ketiga, hal ini dapat menimbulkan kebiasaan rekayasa yang buruk. ** Banyak pengembang membuat lapisan logging tambahan ketika mereka menemui masalah, dan akibatnya, sistem menjadi lebih berisik. Yang benar-benar perlu dilengkapi adalah event log dengan batasan yang jelas, error log dengan konteks, dan id permintaan yang dapat dikaitkan, daripada lebih banyak “metode masuk”, “metode keluar”, “mulai pemrosesan” dan “pemrosesan selesai”.

Tempat yang paling tepat untuk log adalah dengan menggunakan indikator untuk menentukan “benar-benar ada masalah di sini” dan menggunakan penelusuran untuk mengetahui “masalahnya mungkin terletak di sini”, dan kemudian menggunakannya untuk memulihkan permintaan tertentu.

Dengan kata lain, kayu gelondongan harus digunakan untuk tujuan forensik, bukan untuk patroli.

Pembagian kerja yang sederhana lebih efektif daripada “ketiga hal tersebut”

Pendekatan yang saya rekomendasikan sederhana: tentukan urutan pemecahan masalah terlebih dahulu, lalu tentukan batas pengumpulannya.

Pemecahan masalah online dapat dipecah menjadi tiga langkah.

1. Pertama-tama gunakan indikator untuk mengetahui ada tidaknya permasalahan sistemik;
2. Kemudian gunakan penelusuran untuk menyatukan masalah ke tahap layanan dan tautan;
3. Terakhir, gunakan log untuk menjelaskan mengapa permintaannya seperti ini.

Jika desain yang tertanam tidak dapat mendukung urutan ini, biasanya karena tanggung jawab yang diberikan salah.

Berikut ini adalah cara penulisan yang relatif terkendali:

func CreateOrder(ctx context.Context, req CreateOrderReq) error {
  start := time.Now()
  defer metrics.OrderCreateLatency.Observe(time.Since(start).Seconds())

  ctx, span := tracer.Start(ctx, "order.create")
  defer span.End()
  span.SetAttributes(
    attribute.String("payment_provider", req.Provider),
    attribute.Bool("has_coupon", req.CouponID != ""),
  )

  err := service.Create(ctx, req)
  if err != nil {
    metrics.OrderCreateErrors.WithLabelValues(classify(err)).Inc()
    logger.Error("create order failed",
      "request_id", requestid.FromContext(ctx),
      "provider", req.Provider,
      "err", err,
    )
    return err
  }
  return nil
}

Ada tiga batasan di sini yang sengaja dibatasi.

• Indikator hanya mempertahankan dimensi yang masih memiliki nilai pengambilan keputusan setelah agregasi, seperti kesalahan klasifikasi;
• Penelusuran hanya menggantung beberapa atribut yang dapat membantu memfilter jalur, bukan keseluruhan isi permintaan;
• Log hanya mencatat konteks kunci pada jalur yang gagal dan dijamin dikaitkan dengan tautan melalui request_id.

Desain ini tidak mewah, namun memecahkan masalah yang sangat nyata: setelah kecelakaan terjadi, dapatkah tim melakukan pendekatan terhadap jawaban dari biaya rendah ke biaya tinggi, daripada langsung terjun ke data yang paling mahal sejak awal. **

Kesalahpahaman umum: memahami “observabilitas terpadu” sebagai “mengumpulkan semua data”

Sekarang banyak platform yang membicarakan tentang observasi terpadu. Tidak ada yang salah dengan hal ini, masalahnya terletak pada cara penerapannya.

Beberapa tim memahami penyatuan sebagai “semua data masuk ke satu platform, semua bidang terhubung satu sama lain, dan yang terbaik adalah menyelesaikan semua masalah dengan satu kueri.” Ide ini menggiurkan karena sepertinya menghilangkan batasan alat; namun dalam bidang teknik, hal ini sering kali menghilangkan batasan biaya.

Arah penyatuan yang benar adalah menghubungkannya dengan gesekan rendah.

Misalnya:

• Alarm indikator dapat melompat langsung ke layanan dan jendela waktu yang relevan;
• penelusuran dapat menemukan log yang sesuai menurut request_id atau kode kesalahan;
• Log dapat membawa konteks jejak alih-alih bekerja secara mandiri.

Ini disebut China Unicom, bukan penggunaan campuran.

Bahaya sebenarnya adalah semua pertanyaan hanya dapat dijawab oleh lapisan data terberat.

Contoh tandingan dan batasan: tidak semua sistem memerlukan tiga set lengkap

Akui juga bahwa dalam beberapa adegan, batasan tidak perlu dijelaskan secara lengkap.

Untuk alat internal QPS rendah, skrip batch yang berdiri sendiri, dan tugas offline yang sangat stabil, log mungkin cukup; untuk layanan dengan tautan permintaan pendek dan ketergantungan sederhana, manfaat penelusuran mungkin tidak setinggi yang diharapkan; untuk skenario audit tertentu yang tunduk pada batasan kepatuhan, Anda tidak boleh mengharapkan penelusuran atau log aplikasi biasa berfungsi sebagai catatan audit formal.

Jadi artikel ini mengatakan: **Selama Anda memutuskan untuk melakukan tiga hal, jangan biarkan ketiga hal tersebut saling menggantikan. **

Semakin kompleks sistemnya, semakin banyak tanggung jawab yang perlu dipersempit. Jika tidak, yang dihilangkan hari ini adalah batasan desain, dan yang ditambahkan besok adalah tagihan platform, waktu pemecahan masalah, dan beban kognitif tim.

Ringkasan

Hal yang paling menakutkan tentang kemampuan observasi adalah setiap lapisan ingin menjawab semua pertanyaan.

Indikator akan memungkinkan Anda memutuskan apakah akan bertindak secepat mungkin, Penelusuran akan memungkinkan Anda memutuskan di mana harus mencari sesegera mungkin, dan log akan memberi tahu Anda apa yang terjadi sesegera mungkin.

Jika urutan ketiga tindakan ini kacau, tidak peduli seberapa lengkapnya, hal itu hanya akan mengubur biaya pemecahan masalah lebih dalam.