Memantau pesan

Panduan ini menjelaskan cara memantau pesan yang dikirim ke Manufacturing Data Engine (MDE), cara pesan tersebut mengalir melalui pipeline pemrosesan, dan mendiagnosis masalah apa pun yang mungkin terjadi karena konfigurasi atau potensi masalah sistem.

Untuk memantau pesan yang mengalir melalui MDE, Anda harus menggunakan tabel BigQuery operations-log. Setiap kali langkah pipeline MDE gagal memproses pesan, pesan tersebut akan dikirim ke tabel operations-log yang menunjukkan langkah dan alasan kegagalan.

Semua pesan yang gagal ditulis ke tabel ini, tetapi Anda dapat mengonfigurasi MDE agar juga menulis pesan yang berhasil ke tabel operations-log. Hal ini berguna saat men-debug masalah, tetapi tidak boleh dibiarkan aktif karena dapat menghasilkan banyak traffic tambahan dalam sistem dan dapat menurunkan performa dalam produksi.

REST

Jalankan permintaan REST API berikut untuk mengonfigurasi tabel operations-log:

POST /configuration/v1/environment

{
  "operationsLogLevel": "ALL"
}

Dengan:

  • ALL: Semua pesan akan dikirim ke tabel operations-log untuk setiap langkah dalam pipeline pemrosesan.
  • ERROR: Hanya pesan yang gagal dalam salah satu langkah pemrosesan yang akan dikirim ke operations-logtabel.

Langkah pemrosesan

Untuk mendiagnosis alasan penolakan pesan saat melewati pipeline pemrosesan, sebaiknya ketahui berbagai langkah pemrosesan dan pahami fungsinya. Untuk mengetahui informasi selengkapnya, lihat Arsitektur MDE.

  1. message-mapper: Membaca JSON asli, mencocokkannya dengan message-class yang sesuai, dan memprosesnya menggunakan Whistle untuk memancarkan satu atau beberapa rekaman.
  2. configuration-manager: Membuat tag baru dalam sistem jika belum ada dan menambahkan semua properti yang ditentukan ke rekaman dalam jenis yang sesuai (bucket metadata, sink ,dan transformasi).
  3. metadata-manager: Menyelesaikan semua referensi metadata dari rekaman ini, memperbarui instance metadata sistem jika ada yang baru diterima, menambahkan metadata yang diwujudkan ke rekaman jika dikonfigurasi untuk melakukannya.
  4. bigquery-sink: Memetakan rekaman ke struktur jenis yang sesuai dan mengirimkannya ke topik PubSub yang sesuai untuk ditulis ke BigQuery.
  5. pubsub-sink: Memetakan rekaman ke struktur Proto atau JSON pubsub dan mengirimkannya ke topik yang sesuai.
  6. GCSWriter: Menulis data mentah saat diterima dari topik input-messages, serta data yang diproses setelah melalui metadata-manager.
  7. BigtableWriter: Menulis data ke Bigtable.
  8. GCSReader: Membaca file dari Cloud Storage dan mengirim pesan ke input-messages.

Mendiagnosis pesan yang tidak ditampilkan di sink yang dikonfigurasi

Jika Anda mengirim pesan ke MDE dan pesan tersebut tidak ada di sink yang dikonfigurasi, pertama-tama pastikan bahwa jenis telah mengonfigurasi sink dengan benar (seperti yang dijelaskan di bagian Jenis) dan Anda membuat kueri tabel yang benar di BigQuery. Ingatlah bahwa tabel diberi nama sesuai jenisnya.

Jika dikonfigurasi dengan benar, Anda harus menggunakan tabel operations-log untuk mendiagnosis masalah. Anda dapat memulai dengan kueri umum, baik mengurutkannya berdasarkan event_timestamp atau memfilternya ke saat pesan dikirim, seperti yang ditunjukkan dalam contoh berikut:

SELECT
  *
FROM
  `mde_system.operations-log`
WHERE
  DATE(event_timestamp) = CURRENT_DATE()
ORDER BY
  event_timestamp desc
LIMIT 100;

Anda juga dapat menggunakan source_message_id untuk memfilter pesan tertentu. ID ini ditetapkan oleh Pub/Sub saat memublikasikan pesan. Jika Anda menggunakan gcloud CLI untuk memublikasikan pesan dari command line, messageId pesan yang dipublikasikan akan ditampilkan.

SELECT
  *
FROM
  `mde_system.operations-log`
WHERE
  DATE(event_timestamp) <= CURRENT_DATE()
  AND source_message_id = 'PubSubMessageId';

Jika Anda tidak dapat menemukan pesan atau ada terlalu banyak pesan, Anda dapat memfilter berdasarkan atribut pesan asli. Pesan selalu dicatat dalam kolom payload dengan status yang ditinggalkan oleh langkah terakhir, dan disimpan dalam kolom JSON, sehingga lebih mudah menggunakan TO_JSON_STRING dan % untuk mencari pesan yang berisi teks yang Anda inginkan.

SELECT
  *
FROM
  `mde_system.operations-log`
WHERE
  DATE(event_timestamp) = CURRENT_DATE()
  AND TO_JSON_STRING(payload) LIKE "%TEXT-TO-FIND%"
ORDER BY
  event_timestamp DESC;

Setelah Anda menemukan pesan di tabel operations-log, lihat kolom error-message untuk menemukan alasan pesan ditolak. Kesalahan yang paling umum adalah sebagai berikut:

  • Tidak dapat mencocokkan pesan masuk dengan salah satu class pesan terdaftar di pengelola konfigurasi.
  • Tidak ada parser yang ditemukan untuk class pesan <MESSAGE_CLASS_NAME>.
  • Melewati pemrosesan pesan karena tidak dapat dideserialisasi (pesan bukan JSON yang valid).
  • Tidak dapat membuat pesan yang valid dengan parser <PARSER_NAME>. Message tidak memiliki kolom stempel waktu.
  • Tidak dapat membuat pesan yang valid dengan parser <PARSER_NAME>. Message tidak memiliki kolom tagName atau kosong.
  • Tidak dapat membuat pesan yang valid dengan parser <PARSER_NAME>. Stempel waktu pesan berada di luar batas yang didukung.

Setelah Anda menemukan dan memperbaiki error yang menyebabkan pesan gagal, pesan akan mulai masuk ke sink masing-masing.