Metrik tugas Dataflow

Dataflow mengumpulkan metrik untuk tugas Anda, yang dapat membantu Anda men-debug error, memecahkan masalah performa, atau mengoptimalkan pipeline. Antarmuka pemantauan Dataflow menampilkan visualisasi untuk metrik ini. Anda juga dapat menggunakan Cloud Monitoring untuk membuat pemberitahuan atau membuat kueri Metrics Explorer.

Mengakses metrik tugas

Untuk melihat metrik tugas, lakukan langkah-langkah berikut:

1. Di konsol Google Cloud , buka halaman Dataflow > Jobs.

   Buka Tugas

2. Pilih tugas.

3. Klik tab Metrik tugas.

4. Pilih metrik yang akan dilihat.

5. Untuk mengakses informasi tambahan dalam diagram metrik tugas, klik query_stats Jelajahi data.

Setiap metrik disusun dalam dasbor berikut:

• Metrik penskalaan otomatis
• Metrik ringkasan
• Metrik streaming
• Metrik resource
• Metrik input/output

Untuk mengetahui daftar lengkap metrik Dataflow, lihat metrikGoogle Cloud .

Dukungan dan batasan

Saat menggunakan metrik Dataflow, perhatikan detail berikut.

• Terkadang data pekerjaan tidak tersedia secara berkala. Jika data tidak ada, celah akan muncul di diagram pemantauan tugas.

• Beberapa diagram ini khusus untuk pipeline streaming.

• Untuk menulis data metrik, akun layanan yang dikelola pengguna harus memiliki izin IAM API monitoring.timeSeries.create. Izin ini disertakan dengan peran pekerja Dataflow.

• Layanan Dataflow melaporkan waktu CPU yang dicadangkan setelah tugas selesai. Untuk tugas tanpa batas (streaming), waktu CPU yang dicadangkan hanya dilaporkan setelah tugas dibatalkan atau gagal. Oleh karena itu, metrik tugas tidak mencakup waktu CPU yang dicadangkan untuk tugas streaming.

Metrik penskalaan otomatis

Penskalaan Otomatis Horizontal memungkinkan Dataflow memilih jumlah instance pekerja yang sesuai untuk tugas Anda, dengan menambahkan atau menghapus pekerja sesuai kebutuhan.

Bagian Penskalaan otomatis di tab Metrik tugas menampilkan jumlah worker dan jumlah worker target dari waktu ke waktu. Jika tugas Anda menggunakan Streaming Engine, diagram ini juga menampilkan jumlah minimum dan maksimum pekerja.

Untuk melihat histori perubahan penskalaan otomatis, klik Histori lainnya. Tabel dengan informasi tentang histori worker tugas Anda akan ditampilkan.

Untuk melihat informasi penskalaan otomatis tambahan untuk tugas streaming, klik tab Penskalaan otomatis. Untuk mengetahui informasi selengkapnya, lihat Memantau penskalaan otomatis Dataflow.

Metrik ringkasan

Metrik berikut muncul di bagian Metrik ringkasan.

Keaktualan data

Metrik ini hanya berlaku untuk tugas streaming.

Keaktualan data adalah perbedaan antara waktu saat elemen data diproses (waktu pemrosesan) dan stempel waktu elemen data (waktu peristiwa). Nilai yang lebih tinggi berarti ada penundaan yang lebih lama antara waktu peristiwa dan waktu pemrosesan.

Diagram keaktualan data menampilkan nilai keaktualan data maksimum pada titik waktu tertentu. Dataflow memproses beberapa elemen secara paralel, sehingga grafik mencerminkan elemen dengan penundaan terbesar relatif terhadap waktu peristiwanya.

Jika beberapa data input belum diproses, watermark output mungkin tertunda, yang memengaruhi keaktualan data. Perbedaan yang signifikan antara waktu stempel air dan waktu peristiwa dapat menunjukkan operasi yang lambat atau macet. Untuk mengetahui informasi selengkapnya, lihat Watermark dan data terlambat dalam dokumentasi Apache Beam.

Dasbor ini mencakup dua diagram berikut:

• Keaktualan data menurut tahap
• Keaktualan data

Pada gambar berikut, area yang ditandai menunjukkan perbedaan besar antara waktu peristiwa dan waktu watermark output, yang menunjukkan operasi yang lambat.

Masalah berikut dapat menyebabkan nilai tinggi untuk metrik ini:

• Bottleneck performa: Jika pipeline Anda memiliki tahap dengan latensi sistem yang tinggi atau log yang menunjukkan transformasi yang macet, pipeline mungkin mengalami masalah performa yang dapat meningkatkan keaktualan data. Untuk menyelidiki lebih lanjut, lihat Memecahkan masalah tugas streaming yang lambat atau macet.
• Hambatan sumber data: Jika backlog sumber data Anda terus bertambah, stempel waktu peristiwa elemen Anda mungkin berbeda dari tanda air saat menunggu diproses. Penumpukan yang besar sering kali disebabkan oleh bottleneck performa, atau masalah sumber data yang paling baik dideteksi dengan memantau sumber yang digunakan oleh pipeline Anda.
  • Sumber yang tidak berurutan seperti Pub/Sub dapat menghasilkan tanda air yang macet meskipun menghasilkan output dengan kecepatan tinggi. Situasi ini terjadi karena elemen tidak ditampilkan dalam urutan stempel waktu, dan watermark didasarkan pada stempel waktu minimum yang belum diproses.
• Pencobaan ulang yang sering: Jika Anda melihat error yang menunjukkan bahwa elemen gagal diproses dan dicoba ulang, stempel waktu yang lebih lama dari elemen yang dicoba ulang tersebut mungkin meningkatkan keaktualan data. Daftar error Dataflow umum dapat membantu Anda memecahkan masalah.

Untuk tugas streaming yang baru saja diperbarui, informasi tentang status tugas dan tanda air mungkin tidak tersedia. Operasi update membuat beberapa perubahan yang memerlukan waktu beberapa menit untuk diterapkan ke antarmuka pemantauan Dataflow. Coba muat ulang antarmuka pemantauan lima menit setelah memperbarui tugas.

Latensi sistem

Metrik ini hanya berlaku untuk tugas streaming.

Latensi sistem adalah jumlah detik maksimum saat ini yang telah digunakan item data untuk diproses atau menunggu pemrosesan. Metrik ini mencakup berapa lama elemen menunggu di dalam sumber. Misalnya, jika tujuan output berhenti menerima permintaan tulis selama jangka waktu tertentu, data dapat terakumulasi di sumber, sehingga menyebabkan latensi sistem meningkat. Jika operasi tulis dilanjutkan dan pipeline dapat mengejar, latensi sistem akan kembali ke tingkat dasarnya.

Kasus berikut adalah pertimbangan tambahan:

• Untuk beberapa sumber dan tujuan, latensi sistem adalah jumlah waktu maksimum yang ditunggu elemen di dalam sumber sebelum ditulis ke semua tujuan.
• Terkadang, sumber tidak memberikan nilai untuk jangka waktu saat elemen menunggu di dalam sumber. Selain itu, elemen mungkin tidak memiliki metadata untuk menentukan waktu acaranya. Dalam skenario ini, latensi sistem dihitung dari saat pipeline pertama kali menerima elemen.

Dasbor ini mencakup dua diagram berikut:

• Latensi sistem menurut tahap
• Latensi sistem

Throughput

Throughput adalah volume data yang diproses pada waktu tertentu. Dasbor mencakup diagram berikut:

• Throughput per langkah dalam elemen per detik
• Throughput per langkah dalam byte per detik

Jumlah log error pekerja

Jumlah log error pekerja menunjukkan rasio error yang diamati di semua pekerja pada waktu tertentu.

Metrik streaming

Metrik berikut muncul di bagian Metrik streaming.

Backlog

Metrik ini hanya berlaku untuk tugas streaming.

Dasbor Backlog memberikan informasi tentang elemen yang menunggu untuk diproses. Dasbor ini mencakup dua diagram berikut:

• Detik backlog (khusus Streaming Engine)
• Byte backlog (dengan dan tanpa Streaming Engine)

Diagram Detik backlog menunjukkan perkiraan jumlah waktu dalam detik yang diperlukan untuk menggunakan backlog saat ini jika tidak ada data baru yang masuk dan throughput tidak berubah. Perkiraan waktu backlog dihitung dari throughput dan byte backlog dari sumber input yang masih perlu diproses. Metrik ini digunakan oleh fitur penskalaan otomatis streaming untuk menentukan kapan harus meningkatkan atau menurunkan skala.

Diagram Backlog bytes menunjukkan jumlah input yang diketahui belum diproses untuk suatu tahap dalam byte. Metrik ini membandingkan byte yang tersisa untuk digunakan oleh setiap tahap dengan tahap upstream. Agar metrik ini dapat melaporkan secara akurat, setiap sumber yang diproses oleh pipeline harus dikonfigurasi dengan benar. Sumber bawaan seperti Pub/Sub dan BigQuery sudah didukung secara langsung, tetapi sumber kustom memerlukan penerapan tambahan. Untuk mengetahui detail selengkapnya, lihat penskalaan otomatis untuk sumber tanpa batas kustom.

Memproses

Metrik ini hanya berlaku untuk tugas streaming.

Saat Anda menjalankan pipeline Apache Beam di layanan Dataflow, tugas pipeline akan berjalan di VM pekerja. Dasbor Pemrosesan memberikan informasi tentang durasi pemrosesan tugas di VM pekerja. Dasbor ini mencakup dua diagram berikut:

• Peta panas latensi pemrosesan pengguna
• Latensi pemrosesan pengguna menurut tahap

Peta panas latensi pemrosesan pengguna menampilkan latensi operasi maksimum di atas distribusi persentil ke-50, ke-95, dan ke-99. Gunakan peta panas untuk melihat apakah ada operasi long-tail yang menyebabkan latensi sistem secara keseluruhan tinggi atau berdampak negatif pada keaktualan data secara keseluruhan.

Untuk memperbaiki masalah di upstream sebelum menjadi masalah di downstream, tetapkan kebijakan pemberitahuan untuk latensi tinggi pada persentil ke-50.

Diagram Latensi pemrosesan pengguna menurut tahap menampilkan persentil ke-99 untuk semua tugas yang diproses pekerja yang dikelompokkan menurut tahap. Jika kode pengguna menyebabkan keterbatasan, diagram ini menunjukkan tahap mana yang berisi keterbatasan. Anda dapat menggunakan langkah-langkah berikut untuk men-debug pipeline:

1. Gunakan diagram untuk menemukan tahap dengan latensi yang sangat tinggi.

2. Di halaman detail tugas, di tab Execution details, untuk Graph view, pilih Stage workflow. Dalam grafik Stage workflow, temukan tahap yang memiliki latensi sangat tinggi.

3. Untuk menemukan operasi pengguna terkait, di grafik, klik node untuk tahap tersebut.

4. Untuk menemukan detail tambahan, buka Cloud Profiler, dan gunakan Cloud Profiler untuk men-debug stack trace pada rentang waktu yang tepat. Cari operasi pengguna yang Anda identifikasi di langkah sebelumnya.

Waktu per status item tugas aktif

Metrik ini hanya berlaku untuk tugas streaming.

Metrik Time per active work item state (worker/time_per_active_work_item_state) memberikan informasi latensi tentang fase utama siklus proses item kerja. Tidak seperti metrik gabungan tingkat tinggi, penilaian ini memungkinkan Anda mengatribusikan latensi secara tepat dengan mengelompokkan latensi tingkat tahap ke dalam fase yang berbeda. Misalnya, Anda dapat memeriksa latensi berdasarkan fase seperti pengambilan data (READ), eksekusi kode pengguna (ACTIVE), dan persistensi status (COMMIT).

Dukungan versi pelari

Meskipun metrik ini didukung sepenuhnya di Dataflow Runner v1, metrik ini didukung sebagian di Dataflow Runner v2.

Tabel ini merangkum status latensi dan dukungannya menurut pelari.

Status latensi	Dukungan Runner v1	Dukungan Runner v2
GET_WORK	Didukung	Tidak didukung
QUEUED	Didukung	Didukung
ACTIVE	Didukung	Didukung
READ	Didukung	Didukung
COMMIT	Didukung	Didukung

Definisi status latensi dan pemecahan masalah

Bagian berikut menentukan setiap status latensi dan menyertakan informasi pemecahan masalah.

GET_WORK

• Ini adalah waktu yang dibutuhkan pekerja pengguna untuk meminta item kerja, dan bagi backend Dataflow untuk menetapkan dan mengirimkannya.
• Untuk tahap ETL umum, waktu 0-1 detik yang stabil menunjukkan koneksi yang baik. Nilai sebenarnya bervariasi, bergantung pada kompleksitas workload dan volume data Anda.

QUEUED

• Ini adalah waktu yang dihabiskan item kerja di buffer lokal pekerja sebelum thread tersedia untuk diproses.
• Jika latensi QUEUED melebihi 1 detik, berarti tugas tiba lebih cepat daripada yang dapat diproses oleh thread. Untuk tahap ETL umum, latensi di bawah 1 detik dianggap baik. Nilai sebenarnya bervariasi, bergantung pada kompleksitas workload dan volume data Anda.

ACTIVE

• Ini adalah waktu yang dihabiskan untuk mengeksekusi kode DoFn.
• Latensi ACTIVE merujuk pada waktu yang dihabiskan untuk memproses sekumpulan elemen, bukan satu elemen.
• Peningkatan tiba-tiba pada nilai latensi ini dapat menunjukkan pembatasan oleh panggilan RPC eksternal atau kasus ekstrem yang mahal secara komputasi. Gunakan metrik untuk mengidentifikasi DoFns tertentu yang menyebabkan penundaan.DoFn

READ

• Ini adalah waktu yang dihabiskan untuk mengambil data, termasuk pembacaan status eksplisit dan pembacaan implisit selama operasi GroupByKey.
• Waktu READ yang tinggi sering disebabkan oleh pembacaan besar pada satu kunci. Selidiki pola akses status atau gunakan status dan timer untuk menghindari pemblokiran thread.

COMMIT

• Ini adalah waktu yang diperlukan untuk mengirim hasil (pembaruan status dan elemen output) ke backend Dataflow dan menerima konfirmasi.
• Waktu COMMIT yang tinggi sering kali disebabkan oleh penulisan payload besar atau pembaruan objek status besar. Periksa tombol pintas menggunakan status hambatan.

Keparalelan

Metrik ini hanya berlaku untuk tugas Streaming Engine.

Diagram Pemrosesan paralel menampilkan perkiraan jumlah kunci yang digunakan untuk pemrosesan data pada setiap tahap. Dataflow melakukan penskalaan berdasarkan paralelisme pipeline.

Saat menjalankan pipeline, pemrosesan Dataflow didistribusikan di beberapa virtual machine (VM) Compute Engine, yang juga dikenal sebagai pekerja. Layanan Dataflow secara otomatis memparalelkan dan mendistribusikan logika pemrosesan di pipeline Anda ke worker. Pemrosesan untuk setiap kunci tertentu diserialkan, sehingga jumlah total kunci untuk tahap mewakili paralelisme maksimum yang tersedia pada tahap tersebut.

Metrik paralelisme dapat berguna untuk menemukan tombol hot key atau hambatan untuk pipeline yang lambat atau macet.

Persistensi

Metrik ini hanya berlaku untuk tugas streaming.

Dasbor Persistensi memberikan informasi tentang kecepatan penulisan dan pembacaan penyimpanan persisten oleh tahap pipeline tertentu dalam byte per detik. Byte yang dibaca dan ditulis mencakup operasi status pengguna dan status untuk pengacakan persisten, penghapusan duplikat, input samping, dan pelacakan watermark. Pengodean pipeline dan caching memengaruhi byte yang dibaca dan ditulis. Byte penyimpanan mungkin berbeda dengan byte yang diproses karena penggunaan dan caching penyimpanan internal.

Dasbor ini mencakup dua diagram berikut:

• Penulisan penyimpanan
• Baca penyimpanan

Duplikat

Metrik ini hanya berlaku untuk tugas streaming.

Diagram Duplikat menampilkan jumlah pesan yang diproses oleh tahap tertentu yang telah difilter sebagai duplikat. Dataflow mendukung banyak sumber dan sink yang menjamin pengiriman at least once. Kelemahan pengiriman at least once adalah dapat menghasilkan duplikat. Dataflow menjamin pengiriman exactly once, yang berarti duplikat akan otomatis difilter. Tahap hilir disimpan dari pemrosesan ulang elemen yang sama, yang memastikan bahwa status dan output tidak terpengaruh. Pipeline dapat dioptimalkan untuk resource dan performa dengan mengurangi jumlah duplikat yang dihasilkan di setiap tahap.

Timer

Metrik ini hanya berlaku untuk tugas streaming.

Dasbor Timer memberikan informasi tentang jumlah timer yang tertunda dan jumlah timer yang sudah diproses dalam tahap pipeline tertentu. Karena jendela mengandalkan timer, metrik ini memungkinkan Anda melacak progres jendela.

Dasbor ini mencakup dua diagram berikut:

• Timer tertunda menurut tahap
• Pemrosesan timer menurut tahap

Diagram ini menunjukkan kecepatan jendela yang tertunda atau diproses pada titik waktu tertentu. Diagram Timers pending by stage menunjukkan jumlah jendela yang tertunda karena hambatan. Diagram Pemrosesan timer menurut tahap menunjukkan jumlah jendela yang mengumpulkan elemen.

Diagram ini menampilkan semua timer tugas, jadi jika timer digunakan di tempat lain dalam kode Anda, timer tersebut juga akan muncul dalam diagram ini.

Metrik resource

Metrik berikut muncul di bagian Metrik resource.

Pemakaian CPU

Pemakaian CPU adalah jumlah CPU yang digunakan dibagi dengan jumlah CPU yang tersedia untuk pemrosesan. Metrik per pekerja ini ditampilkan sebagai persentase. Dasbor ini mencakup empat diagram berikut:

• Penggunaan CPU (Semua pekerja)
• Pemakaian CPU (Statistik)
• Pemakaian CPU (4 Teratas)
• Pemakaian CPU (4 Terbawah)

Pemakaian memori

Penggunaan memori adalah perkiraan jumlah memori yang digunakan oleh pekerja dalam byte per detik. Dasbor ini mencakup dua diagram berikut:

• Penggunaan memori pekerja maksimum (byte per detik yang diperkirakan)
• Penggunaan memori (estimasi byte per detik)

Diagram Penggunaan memori pekerja maks. memberikan informasi tentang pekerja yang menggunakan memori paling banyak dalam tugas Dataflow pada setiap titik waktu. Jika, pada berbagai titik selama tugas, pekerja yang menggunakan jumlah memori maksimum berubah, garis yang sama dalam diagram akan menampilkan data untuk beberapa pekerja. Setiap titik data dalam garis menampilkan data untuk pekerja yang menggunakan jumlah memori maksimum pada saat itu. Diagram ini membandingkan perkiraan memori yang digunakan oleh pekerja dengan batas memori dalam byte.

Anda dapat menggunakan diagram ini untuk memecahkan masalah kehabisan memori (OOM). Error kehabisan memori pekerja tidak ditampilkan dalam diagram ini.

Diagram Penggunaan memori menunjukkan perkiraan memori yang digunakan oleh semua pekerja dalam tugas Dataflow dibandingkan dengan batas memori dalam byte.

Metrik input dan output

Jika tugas Dataflow streaming Anda membaca atau menulis rekaman menggunakan Pub/Sub, tab Metrik tugas akan menampilkan metrik untuk pembacaan atau penulisan Pub/Sub.

Semua metrik input dengan jenis yang sama digabungkan, dan semua metrik output juga digabungkan. Misalnya, semua metrik Pub/Sub dikelompokkan dalam satu bagian. Setiap jenis metrik disusun dalam bagian terpisah. Untuk mengubah metrik yang ditampilkan, pilih bagian di sebelah kiri yang paling sesuai dengan metrik yang Anda cari. Gambar berikut menampilkan semua bagian yang tersedia.

Dua diagram berikut ditampilkan di bagian Metrik Input dan Metrik Output.

Permintaan per detik

Permintaan per detik adalah rasio permintaan API untuk membaca atau menulis data oleh sumber atau sink dari waktu ke waktu. Jika rasio ini turun menjadi nol, atau menurun secara signifikan dalam jangka waktu yang lama dibandingkan dengan perilaku yang diharapkan, maka pipeline mungkin diblokir untuk melakukan operasi tertentu. Selain itu, mungkin tidak ada data yang dapat dibaca. Dalam kasus seperti itu, tinjau langkah-langkah tugas yang memiliki watermark sistem tinggi. Selain itu, periksa log pekerja untuk mengetahui error atau indikasi tentang pemrosesan yang lambat.

Error respons per detik berdasarkan jenis error

Error respons per detik berdasarkan jenis error adalah tingkat permintaan API yang gagal untuk membaca atau menulis data berdasarkan sumber atau tujuan dari waktu ke waktu. Jika error tersebut sering terjadi, permintaan API ini dapat memperlambat pemrosesan. Permintaan API yang gagal tersebut harus diselidiki. Untuk membantu memecahkan masalah ini, tinjau Kode error input dan output umum. Tinjau juga dokumentasi kode error tertentu yang digunakan oleh sumber atau tujuan, seperti kode error Pub/Sub.

Untuk mengetahui informasi selengkapnya tentang skenario tempat Anda dapat menggunakan metrik ini untuk melakukan debug, lihat Alat untuk melakukan debug di "Memecahkan masalah tugas yang lambat atau macet".

Menggunakan Cloud Monitoring

Dataflow terintegrasi sepenuhnya dengan Cloud Monitoring. Gunakan Cloud Monitoring untuk tugas berikut:

• Buat pemberitahuan saat tugas Anda melebihi batas yang ditentukan pengguna.
• Gunakan Metrics Explorer untuk membuat kueri dan menyesuaikan rentang waktu metrik.
• Melihat metrik yang tidak muncul di antarmuka pemantauan Dataflow.

Untuk mengetahui petunjuk tentang cara membuat pemberitahuan dan menggunakan Metrics Explorer, lihat Menggunakan Cloud Monitoring untuk pipeline Dataflow.

Untuk mengetahui daftar lengkap metrik Dataflow, lihat dokumentasi metrikGoogle Cloud .

Membuat pemberitahuan Cloud Monitoring

Cloud Monitoring memungkinkan Anda membuat pemberitahuan saat tugas Dataflow Anda melebihi batas yang ditentukan pengguna. Untuk membuat pemberitahuan Cloud Monitoring dari diagram metrik, klik Buat kebijakan pemberitahuan.

Jika Anda tidak dapat melihat grafik pemantauan atau membuat pemberitahuan, Anda mungkin memerlukan izin Pemantauan tambahan.

Lihat di Metrics Explorer

Anda dapat melihat diagram metrik Dataflow di Metrics Explorer, tempat Anda dapat membuat kueri dan menyesuaikan rentang waktu metrik.

Untuk melihat diagram Dataflow di Metrics Explorer, di tampilan Metrik tugas, buka Opsi diagram lainnya, lalu klik Lihat di Metrics Explorer.more_vert

Saat menyesuaikan rentang waktu metrik, Anda dapat memilih durasi standar atau memilih interval waktu kustom untuk menganalisis tugas.

Secara default, untuk tugas streaming dan tugas batch dalam proses, tampilan menunjukkan metrik enam jam sebelumnya untuk tugas tersebut. Untuk tugas streaming yang dihentikan atau selesai, tampilan default menunjukkan seluruh durasi runtime tugas.

Metrik I/O Dataflow

Anda dapat melihat metrik I/O Dataflow berikut di Metrics Explorer:

• job/pubsub/write_count: Permintaan publikasi Pub/Sub dari PubsubIO.Write dalam tugas Dataflow.
• job/pubsub/read_count: Permintaan penarikan Pub/Sub dari PubsubIO.Read dalam tugas Dataflow.
• job/bigquery/write_count: Permintaan publikasi BigQuery dari BigQueryIO.Write dalam tugas Dataflow. Metrik job/bigquery/write_count tersedia di pipeline Python menggunakan transformasi WriteToBigQuery dengan method='STREAMING_INSERTS' diaktifkan di Apache Beam v2.28.0 atau yang lebih baru. Metrik ini tersedia untuk pipeline batch dan streaming.
• Jika pipeline Anda menggunakan sumber atau tujuan BigQuery, untuk memecahkan masalah kuota, gunakan metrik BigQuery Storage API.

Metrik DoFn

Untuk tugas streaming yang menggunakan Streaming Engine dan tidak menggunakan Runner v2, Anda dapat melihat metrik berikut untuk DoFns yang ditentukan pengguna secara individual:

• job/dofn_latency_average: Waktu pemrosesan pesan rata-rata untuk satu DoFn selama periode 3 menit terakhir, dalam milidetik.
• job/dofn_latency_max: Waktu pemrosesan pesan maksimum untuk satu DoFn selama 3 menit terakhir, dalam milidetik.
• job/dofn_latency_min: Waktu pemrosesan pesan minimum untuk satu DoFn selama periode 3 menit terakhir, dalam milidetik.
• job/dofn_latency_num_messages: Jumlah pesan yang diproses oleh satu DoFn selama 3 menit terakhir.
• job/dofn_latency_total: Total waktu pemrosesan pesan untuk semua pesan dalam satu DoFn selama periode 3 menit terakhir, dalam milidetik.
• job/oldest_active_message_age: Durasi pesan aktif terlama diproses dalam DoFn, dalam milidetik.

Metrik ini memerlukan Apache Beam SDK versi 2.53.0 atau yang lebih baru. Untuk melihat metrik ini, gunakan Metrics Explorer.

Anda dapat menggunakan metrik ini untuk menemukan DoFns yang paling berkontribusi terhadap latensi pemrosesan dalam tugas Anda. Misalnya, jika tugas macet, gunakan metrik job/oldest_active_message_age untuk menemukan DoFn dengan pesan aktif terlama. Gambar berikut menunjukkan DoFn dengan lonjakan besar dalam metrik ini:

Untuk melihat nama DoFn, arahkan kursor ke garis grafik.

Langkah berikutnya

• Memecahkan masalah tugas streaming yang lambat atau macet.
• Memecahkan masalah tugas batch yang lambat atau macet.
• Menyesuaikan Penskalaan Otomatis Horizontal untuk pipeline streaming
• Mengoptimalkan biaya