Ekspor metrik Cloud Monitoring

Last reviewed 2024-08-14 UTC

Artikel ini menjelaskan solusi untuk mengekspor metrik Cloud Monitoring untuk analisis jangka panjang. Cloud Monitoring menyediakan solusi pemantauan untuk Google Cloud dan Amazon Web Services (AWS). Cloud Monitoring mempertahankan metrik selama enam minggu karena nilai dalam metrik pemantauan sering kali terikat waktu. Oleh karena itu, nilai metrik historis berkurang dari waktu ke waktu. Setelah periode enam minggu, metrik gabungan mungkin masih memiliki nilai untuk analisis tren jangka panjang yang mungkin tidak terlihat jelas dengan analisis jangka pendek.

Solusi ini memberikan panduan untuk memahami detail metrik untuk ekspor dan implementasi referensi serverless untuk ekspor metrik ke BigQuery.

Laporan State of DevOps mengidentifikasi kemampuan yang mendorong performa pengiriman software. Solusi ini akan membantu Anda dengan kemampuan berikut:

Mengekspor kasus penggunaan metrik

Cloud Monitoring mengumpulkan metrik dan metadata dari Google Cloud, AWS, dan instrumentasi aplikasi. Metrik pemantauan memberikan kemampuan observasi yang mendalam mengenai performa, waktu beroperasi, dan kondisi aplikasi cloud secara keseluruhan melalui API, dasbor, dan penjelajah metrik. Alat-alat ini memberikan cara untuk meninjau nilai metrik selama 6 minggu sebelumnya untuk dianalisis. Jika Anda memiliki persyaratan analisis metrik jangka panjang, gunakan Cloud Monitoring API untuk mengekspor metrik untuk penyimpanan jangka panjang.

Cloud Monitoring menyimpan metrik 6 minggu terakhir. Jenis ini sering digunakan untuk tujuan operasional, seperti memantau infrastruktur virtual machine (CPU, memori, metrik jaringan) dan metrik performa aplikasi (latensi permintaan atau respons). Saat metrik ini melebihi batas yang telah ditetapkan, proses operasional akan dipicu melalui pemberitahuan.

Metrik yang ditangkap mungkin juga berguna untuk analisis jangka panjang. Misalnya, Anda mungkin ingin membandingkan metrik performa aplikasi dari Cyber Monday atau peristiwa dengan traffic tinggi lainnya dengan metrik dari tahun sebelumnya untuk merencanakan peristiwa dengan traffic tinggi berikutnya. Kasus penggunaan lainnya adalah mengamati penggunaan layanan Google Cloud selama kuartal atau tahun untuk memperkirakan biaya dengan lebih baik. Mungkin juga ada metrik performa aplikasi yang ingin Anda lihat selama berbulan-bulan atau bertahun-tahun.

Dalam contoh ini, diperlukan pemeliharaan metrik untuk analisis dalam jangka waktu yang panjang. Mengekspor metrik ini ke BigQuery akan memberikan kemampuan analisis yang diperlukan untuk menangani contoh ini.

Persyaratan

Untuk melakukan analisis jangka panjang terhadap data metrik Monitoring, ada 3 persyaratan utama:

  1. Ekspor data dari Cloud Monitoring. Anda perlu mengekspor data metrik Cloud Monitoring sebagai nilai metrik gabungan. Agregasi metrik diperlukan karena menyimpan titik data timeseries mentah, meskipun secara teknis memungkinkan, tidak menambah nilai. Sebagian besar analisis jangka panjang dilakukan pada tingkat agregat dalam jangka waktu yang lebih lama. Perincian agregasi bersifat unik untuk kasus penggunaan Anda, tetapi sebaiknya agregasi minimal selama 1 jam.
  2. Serap data untuk dianalisis. Anda perlu mengimpor metrik Cloud Monitoring yang diekspor ke mesin analisis untuk dianalisis.
  3. Menulis kueri dan membuat dasbor berdasarkan data. Anda memerlukan dasbor dan akses SQL standar untuk membuat kueri, menganalisis, dan memvisualisasikan data.

Langkah fungsional

  1. Buat daftar metrik untuk disertakan dalam ekspor.
  2. Baca metrik dari Monitoring API.
  3. Petakan metrik dari output JSON yang diekspor dari Monitoring API ke format tabel BigQuery.
  4. Menulis metrik ke BigQuery.
  5. Buat jadwal terprogram untuk mengekspor metrik secara rutin.

Arsitektur

Desain arsitektur ini memanfaatkan layanan terkelola untuk menyederhanakan operasi dan upaya pengelolaan Anda, mengurangi biaya, serta memberikan kemampuan untuk melakukan penskalaan sesuai kebutuhan.

Diagram arsitektur produk yang digunakan dalam solusi

Teknologi berikut digunakan dalam arsitektur:

  • App Engine - Solusi platform as a service (PaaS) skalabel yang digunakan untuk memanggil Monitoring API dan menulis ke BigQuery.
  • BigQuery - Mesin analisis terkelola sepenuhnya yang digunakan untuk menyerap dan menganalisis data timeseries.
  • Pub/Sub - Layanan pesan real-time terkelola sepenuhnya yang digunakan untuk menyediakan pemrosesan asinkron yang skalabel.
  • Cloud Storage - Penyimpanan objek terpadu untuk developer dan perusahaan yang digunakan untuk menyimpan metadata tentang status ekspor.
  • Cloud Scheduler - Penjadwal bergaya cron yang digunakan untuk menjalankan proses ekspor.

Memahami detail metrik Cloud Monitoring

Untuk memahami cara terbaik mengekspor metrik dari Cloud Monitoring, Anda perlu memahami cara penyimpanan metrik.

Jenis metrik

Ada 4 jenis utama metrik di Cloud Monitoring yang dapat Anda ekspor.

Setiap jenis metrik ini memiliki deskripsi metrik, yang mencakup jenis metrik, serta metadata metrik lainnya. Metrik berikut adalah contoh listingan deskripsi metrik dari metode projects.metricDescriptors.list Monitoring API.

{
  "metricDescriptors": [
    {
      "name": "projects/sage-facet-201016/metricDescriptors/pubsub.googleapis.com/subscription/push_request_count",
      "labels": [
        {
          "key": "response_class",
          "description": "A classification group for the response code. It can be one of ['ack', 'deadline_exceeded', 'internal', 'invalid', 'remote_server_4xx', 'remote_server_5xx', 'unreachable']."
        },
        {
          "key": "response_code",
          "description": "Operation response code string, derived as a string representation of a status code (e.g., 'success', 'not_found', 'unavailable')."
        },
        {
          "key": "delivery_type",
          "description": "Push delivery mechanism."
        }
      ],
      "metricKind": "DELTA",
      "valueType": "INT64",
      "unit": "1",
      "description": "Cumulative count of push attempts, grouped by result. Unlike pulls, the push server implementation does not batch user messages. So each request only contains one user message. The push server retries on errors, so a given user message can appear multiple times.",
      "displayName": "Push requests",
      "type": "pubsub.googleapis.com/subscription/push_request_count",
      "metadata": {
        "launchStage": "GA",
        "samplePeriod": "60s",
        "ingestDelay": "120s"
      }
    }
  ]
}

Nilai penting yang perlu dipahami dari deskripsi metrik adalah kolom type, valueType, dan metricKind. Kolom ini mengidentifikasi metrik dan memengaruhi agregasi yang memungkinkan untuk deskripsi metrik.

Jenis metrik

Setiap metrik memiliki jenis metrik dan jenis nilai. Untuk informasi selengkapnya, baca Jenis nilai dan jenis metrik. Jenis metrik dan jenis nilai terkait penting karena kombinasinya memengaruhi cara metrik diagregasi.

Pada contoh sebelumnya, jenis metrik pubsub.googleapis.com/subscription/push_request_count metric memiliki jenis metrik DELTA dan jenis nilai INT64.

Permintaan push

Di Cloud Monitoring, jenis dan jenis nilai metrik disimpan di metricsDescriptors, yang tersedia di Monitoring API.

Deret waktu

timeseries adalah pengukuran reguler untuk setiap jenis metrik yang disimpan dari waktu ke waktu yang berisi jenis metrik, metadata, label, dan titik data pengukuran individual. Metrik yang dikumpulkan secara otomatis oleh Monitoring, seperti metrik Google Cloud dan AWS, dikumpulkan secara rutin. Misalnya, metrik appengine.googleapis.com/http/server/response_latencies dikumpulkan setiap 60 detik.

Kumpulan titik yang dikumpulkan untuk timeseries tertentu dapat berkembang seiring waktu, berdasarkan frekuensi data yang dilaporkan dan label apa pun yang terkait dengan jenis metrik. Jika Anda mengekspor titik data timeseries mentah, hal ini dapat menyebabkan ekspor yang besar. Untuk mengurangi jumlah titik data timeseries yang ditampilkan, Anda dapat menggabungkan metrik selama periode penyelarasan tertentu. Misalnya, dengan menggunakan agregasi, Anda dapat menampilkan satu titik data per jam untuk metrik timeseries tertentu yang memiliki satu titik data per menit. Hal ini mengurangi jumlah titik data yang diekspor dan mengurangi pemrosesan analisis yang diperlukan di mesin analisis. Dalam artikel ini, timeseries ditampilkan untuk setiap jenis metrik yang dipilih.

Agregasi metrik

Anda dapat menggunakan agregasi untuk menggabungkan data dari beberapa timeseries menjadi satu timeseries. Monitoring API memberikan fungsi perataan dan agregasi yang canggih sehingga Anda tidak perlu melakukan agregasi sendiri, dengan meneruskan parameter perataan dan agregasi ke panggilan API. Untuk mengetahui detail selengkapnya tentang cara kerja agregasi untuk Monitoring API, baca Pemfilteran dan agregasi dan postingan blog ini.

Anda memetakan metric type ke aggregation type untuk memastikan bahwa metrik diselaraskan dan timeseries dikurangi untuk memenuhi kebutuhan analisis Anda. Ada daftar perataan dan pengurangan, yang dapat Anda gunakan untuk menggabungkan timeseries. Perataan dan pengurangan memiliki sekumpulan metrik yang dapat Anda gunakan untuk meratakan atau mengurangi berdasarkan jenis metrik dan jenis nilai. Misalnya, jika Anda menggabungkan lebih dari 1 jam, hasil agregasi adalah 1 poin yang ditampilkan per jam untuk timeseries.

Cara lain untuk menyesuaikan agregasi adalah dengan menggunakan fungsi Group By, yang memungkinkan Anda mengelompokkan nilai gabungan ke dalam daftar agregat timeseries. Misalnya, Anda dapat memilih untuk mengelompokkan metrik App Engine berdasarkan modul App Engine. Pengelompokan menurut modul App Engine yang dikombinasikan dengan perataan dan pengurangan yang digabungkan menjadi 1 jam, akan menghasilkan 1 titik data per modul App Engine per jam.

Agregasi metrik menyeimbangkan peningkatan biaya pencatatan setiap poin data, daripada kebutuhan untuk menyimpan data yang cukup untuk analisis jangka panjang yang mendetail.

Detail penerapan referensi

Implementasi referensi berisi komponen yang sama seperti yang dijelaskan dalam Diagram desain arsitektur. Detail implementasi yang fungsional dan relevan di setiap langkah dijelaskan di bawah ini.

Membuat daftar metrik

Cloud Monitoring menentukan lebih dari seribu jenis metrik untuk membantu Anda memantau software Google Cloud, AWS, dan pihak ketiga. Monitoring API menyediakan metode projects.metricDescriptors.list, yang menampilkan daftar metrik yang tersedia untuk project Google Cloud. Monitoring API menyediakan mekanisme pemfilteran sehingga Anda dapat memfilter ke daftar metrik yang ingin diekspor untuk penyimpanan dan analisis jangka panjang.

Implementasi referensi di GitHub menggunakan aplikasi Python App Engine untuk mendapatkan daftar metrik, lalu menulis setiap pesan ke topik Pub/Sub secara terpisah. Ekspor dimulai oleh Cloud Scheduler yang menghasilkan notifikasi Pub/Sub untuk menjalankan aplikasi.

Ada banyak cara untuk memanggil Monitoring API, dan dalam hal ini, Cloud Monitoring dan Pub/Sub API dipanggil menggunakan Library Klien Google API untuk Python karena akses fleksibelnya ke Google API.

Dapatkan deret waktu

Anda mengekstrak timeseries untuk metrik, lalu menulis setiap timeseries ke Pub/Sub. Dengan Monitoring API, Anda dapat menggabungkan nilai metrik di seluruh periode penyelarasan tertentu menggunakan metode project.timeseries.list. Menggabungkan data akan mengurangi beban pemrosesan, persyaratan penyimpanan, waktu kueri, dan biaya analisis Anda. Agregasi data adalah praktik terbaik untuk melakukan analisis metrik jangka panjang secara efisien.

Implementasi referensi di GitHub menggunakan aplikasi Python App Engine untuk berlangganan topik, dengan setiap metrik untuk ekspor dikirim sebagai pesan terpisah. Untuk setiap pesan yang diterima, Pub/Sub akan mengirim pesan ke aplikasi App Engine. Aplikasi akan mendapatkan timeseries untuk metrik tertentu yang digabungkan berdasarkan konfigurasi input. Dalam hal ini, Cloud Monitoring dan Pub/Sub API dipanggil menggunakan Library Klien Google API.

Setiap metrik dapat menampilkan 1 atau beberapa timeseries.. Setiap metrik dikirim oleh pesan Pub/Sub terpisah untuk dimasukkan ke BigQuery. Pemetaan type-to-aligner dan metrik type-to-reducer metrik disertakan ke dalam implementasi referensi. Tabel berikut merekam pemetaan yang digunakan dalam implementasi referensi berdasarkan kelas jenis metrik dan jenis nilai yang didukung oleh aligner dan pengurangan.

Jenis nilai GAUGE Perata Pengurang DELTA Perata Pengurang CUMULATIVE2 Perata Pengurang
BOOL ya ALIGN_FRACTION_TRUE tidak ada tidak ada T/A T/A tidak ada T/A T/A
INT64 ya ALIGN_SUM tidak ada ya ALIGN_SUM tidak ada ya tidak ada tidak ada
DOUBLE ya ALIGN_SUM tidak ada ya ALIGN_SUM tidak ada ya tidak ada tidak ada
STRING ya dikecualikan dikecualikan tidak ada T/A T/A tidak ada T/A T/A
DISTRIBUTION ya ALIGN_SUM tidak ada ya ALIGN_SUM tidak ada ya tidak ada tidak ada
MONEY tidak ada T/A T/A tidak ada T/A T/A tidak ada T/A T/A

Penting untuk mempertimbangkan pemetaan valueType ke perataan dan pengurangan karena agregasi hanya dapat dilakukan untuk valueTypes dan metricKinds tertentu bagi setiap perata dan pengurang.

Misalnya, pertimbangkan jenis pubsub.googleapis.com/subscription/push_request_count metric. Berdasarkan jenis metrik DELTA dan jenis nilai INT64, salah satu cara untuk mengagregasi metrik tersebut adalah:

  • Periode Perataan - 3600 detik (1 jam)
  • Aligner = ALIGN_SUM - Titik data yang dihasilkan dalam periode perataan adalah jumlah semua titik data dalam periode perataan.
  • Reducer = REDUCE_SUM - Mengurangi dengan menghitung jumlah di seluruh timeseries untuk setiap periode perataan.

Seiring dengan nilai periode perataan, perata, dan pengurangan, metode project.timeseries.list memerlukan beberapa input lain:

  • filter - Pilih metrik yang akan ditampilkan.
  • startTime - Pilih titik awal waktu tempat timeseries akan ditampilkan.
  • endTime - Pilih titik waktu terakhir yang timeseries akan dikembalikan.
  • groupBy - Masukkan kolom untuk mengelompokkan respons timeseries.
  • alignmentPeriod - Masukkan periode waktu saat Anda ingin tiap metrik diselaraskan.
  • perSeriesAligner - Menyelaraskan titik menjadi interval waktu yang merata yang ditentukan oleh alignmentPeriod.
  • crossSeriesReducer - Menggabungkan beberapa titik dengan nilai label yang berbeda hingga satu titik per interval waktu.

Permintaan GET ke API mencakup semua parameter yang dijelaskan dalam daftar sebelumnya.

https://monitoring.googleapis.com/v3/projects/sage-facet-201016/timeSeries?
interval.startTime=START_TIME_VALUE&
interval.endTime=END_TIME_VALUE&
aggregation.alignmentPeriod=ALIGNMENT_VALUE&
aggregation.perSeriesAligner=ALIGNER_VALUE&
aggregation.crossSeriesReducer=REDUCER_VALUE&
filter=FILTER_VALUE&
aggregation.groupByFields=GROUP_BY_VALUE

HTTP GET berikut menyediakan contoh panggilan ke metode API projects.timeseries.list dengan menggunakan parameter input:

https://monitoring.googleapis.com/v3/projects/sage-facet-201016/timeSeries?
interval.startTime=2019-02-19T20%3A00%3A01.593641Z&
interval.endTime=2019-02-19T21%3A00%3A00.829121Z&
aggregation.alignmentPeriod=3600s&
aggregation.perSeriesAligner=ALIGN_SUM&
aggregation.crossSeriesReducer=REDUCE_SUM&
filter=metric.type%3D%22kubernetes.io%2Fnode_daemon%2Fmemory%2Fused_bytes%22+&
aggregation.groupByFields=metric.labels.key

Panggilan Monitoring API sebelumnya menyertakan crossSeriesReducer=REDUCE_SUM, yang berarti bahwa metrik diciutkan dan dikurangi menjadi satu jumlah seperti yang ditunjukkan dalam contoh berikut.

{
  "timeSeries": [
    {
      "metric": {
        "type": "pubsub.googleapis.com/subscription/push_request_count"
      },
      "resource": {
        "type": "pubsub_subscription",
        "labels": {
          "project_id": "sage-facet-201016"
        }
      },
      "metricKind": "DELTA",
      "valueType": "INT64",
      "points": [
        {
          "interval": {
            "startTime": "2019-02-08T14:00:00.311635Z",
            "endTime": "2019-02-08T15:00:00.311635Z"
          },
          "value": {
            "int64Value": "788"
          }
        }
      ]
    }
  ]
}

Tingkat agregasi ini menggabungkan data ke dalam satu titik data, sehingga menjadikannya metrik ideal untuk keseluruhan project Google Cloud Anda. Namun, hal ini tidak memungkinkan Anda melihat perincian resource yang berkontribusi pada metrik. Dalam contoh sebelumnya, Anda tidak dapat mengetahui langganan Pub/Sub mana yang paling banyak berkontribusi terhadap jumlah permintaan.

Jika ingin meninjau detail setiap komponen yang menghasilkan timeseries, Anda dapat menghapus parameter crossSeriesReducer. Tanpa crossSeriesReducer, Monitoring API tidak menggabungkan berbagai timeseries untuk membuat satu nilai.

HTTP GET berikut menyediakan contoh panggilan ke metode API projects.timeseries.list menggunakan parameter input. crossSeriesReducer tidak disertakan.

https://monitoring.googleapis.com/v3/projects/sage-facet-201016/timeSeries?
interval.startTime=2019-02-19T20%3A00%3A01.593641Z&
interval.endTime=2019-02-19T21%3A00%3A00.829121Z
aggregation.alignmentPeriod=3600s&
aggregation.perSeriesAligner=ALIGN_SUM&
filter=metric.type%3D%22kubernetes.io%2Fnode_daemon%2Fmemory%2Fused_bytes%22+

Dalam respons JSON berikut, metric.labels.keys sama di kedua hasil karena timeseries dikelompokkan. Titik terpisah ditampilkan untuk setiap nilai resource.labels.subscription_ids. Tinjau nilai metric_export_init_pub dan metrics_list dalam JSON berikut. Tingkat agregasi ini direkomendasikan karena Anda dapat menggunakan produk Google Cloud, yang disertakan sebagai label resource, dalam kueri BigQuery.

{
    "timeSeries": [
        {
            "metric": {
                "labels": {
                    "delivery_type": "gae",
                    "response_class": "ack",
                    "response_code": "success"
                },
                "type": "pubsub.googleapis.com/subscription/push_request_count"
            },
            "metricKind": "DELTA",
            "points": [
                {
                    "interval": {
                        "endTime": "2019-02-19T21:00:00.829121Z",
                        "startTime": "2019-02-19T20:00:00.829121Z"
                    },
                    "value": {
                        "int64Value": "1"
                    }
                }
            ],
            "resource": {
                "labels": {
                    "project_id": "sage-facet-201016",
                    "subscription_id": "metric_export_init_pub"
                },
                "type": "pubsub_subscription"
            },
            "valueType": "INT64"
        },
        {
            "metric": {
                "labels": {
                    "delivery_type": "gae",
                    "response_class": "ack",
                    "response_code": "success"
                },
                "type": "pubsub.googleapis.com/subscription/push_request_count"
            },
            "metricKind": "DELTA",
            "points": [
                {
                    "interval": {
                        "endTime": "2019-02-19T21:00:00.829121Z",
                        "startTime": "2019-02-19T20:00:00.829121Z"
                    },
                    "value": {
                        "int64Value": "803"
                    }
                }
            ],
            "resource": {
                "labels": {
                    "project_id": "sage-facet-201016",
                    "subscription_id": "metrics_list"
                },
                "type": "pubsub_subscription"
            },
            "valueType": "INT64"
        }
    ]
}

Setiap metrik dalam output JSON dari panggilan API projects.timeseries.list ditulis langsung ke Pub/Sub sebagai pesan terpisah. Ada potensi fan-out dengan 1 metrik input menghasilkan 1 atau beberapa timeseries. Pub/Sub memberikan kemampuan untuk menyerap fan-out yang berpotensi besar tanpa melebihi waktu tunggu.

Periode penyelarasan yang diberikan sebagai input berarti nilai-nilai selama jangka waktu tersebut digabungkan menjadi satu nilai seperti yang ditunjukkan dalam contoh respons sebelumnya. Periode penyelarasan juga menentukan seberapa sering ekspor harus dijalankan. Misalnya, jika periode penyelarasan adalah 3600 detik, atau 1 jam, ekspor akan berjalan setiap jam untuk mengekspor timeseries secara rutin.

Metrik penyimpanan

Implementasi referensi di GitHub menggunakan aplikasi Python App Engine untuk membaca setiap timeseries, lalu menyisipkan data ke tabel BigQuery. Untuk setiap pesan yang diterima, Pub/Sub mengirim pesan ke aplikasi App Engine. Pesan Pub/Sub berisi data metrik yang diekspor dari Monitoring API dalam format JSON dan perlu dipetakan ke struktur tabel di BigQuery. Dalam hal ini, BigQuery API dipanggil menggunakan Library Klien Google API.

Skema BigQuery dirancang untuk memetakan secara dekat dengan JSON yang diekspor dari Monitoring API. Saat membuat skema tabel BigQuery, salah satu pertimbangannya adalah skala ukuran data seiring perkembangannya dari waktu ke waktu.

Di BigQuery, sebaiknya Anda mempartisi tabel berdasarkan kolom tanggal karena dapat membuat kueri lebih efisien dengan memilih rentang tanggal tanpa menimbulkan pemindaian tabel lengkap. Jika berencana menjalankan ekspor secara rutin, Anda dapat menggunakan partisi default dengan aman berdasarkan tanggal penyerapan.

Screenshot pembuatan partisi di BigQuery

Jika Anda berencana untuk mengupload metrik secara massal atau tidak menjalankan ekspor secara berkala, partisi di end_time, yang mengharuskan perubahan pada skema BigQuery. Anda dapat memindahkan end_time ke kolom tingkat teratas dalam skema, tempat Anda dapat menggunakannya untuk membuat partisi, atau menambahkan kolom baru ke skema. Pemindahan kolom end_time diperlukan karena kolom tersebut terdapat dalam data BigQuery, dan partisi harus dilakukan di kolom tingkat teratas. Untuk informasi selengkapnya, baca dokumentasi partisi BigQuery.

BigQuery juga memberikan kemampuan untuk mengakhiri masa berlaku set data, tabel, dan partisi tabel setelah jangka waktu tertentu.

Screenshot setelan habis masa berlaku data di BigQuery

Menggunakan fitur ini adalah cara yang berguna untuk menghapus permanen data lama saat data tidak lagi berguna. Misalnya, jika analisis mencakup periode waktu 3 tahun, Anda dapat menambahkan kebijakan untuk menghapus data yang berusia lebih dari 3 tahun.

Ekspor jadwal

Cloud Scheduler adalah penjadwal cron job yang terkelola sepenuhnya. Dengan Cloud Scheduler, Anda dapat menggunakan format jadwal cron standar untuk memicu aplikasi App Engine, mengirim pesan menggunakan Pub/Sub, atau mengirim pesan ke endpoint HTTP arbitrer.

Dalam implementasi referensi di GitHub, Cloud Scheduler memicu aplikasi App Engine list-metrics setiap jam dengan mengirimkan pesan Pub/Sub berisi token yang cocok dengan konfigurasi App Engine. Periode agregasi default dalam konfigurasi aplikasi adalah 3600 detik, atau 1 jam, yang berkaitan dengan seberapa sering aplikasi dipicu. Agregasi minimal 1 jam direkomendasikan karena akan memberikan keseimbangan antara mengurangi volume data dan tetap mempertahankan data fidelitas tinggi. Jika Anda menggunakan periode perataan yang berbeda, ubah frekuensi ekspor agar sesuai dengan periode perataan. Implementasi referensi menyimpan nilai end_time terakhir di Cloud Storage dan menggunakan nilai tersebut sebagai start_time berikutnya kecuali jika start_time diteruskan sebagai parameter.

Screenshot dari Cloud Scheduler berikut menunjukkan cara menggunakan konsol Google Cloud untuk mengonfigurasi Cloud Scheduler untuk memanggil aplikasi App Engine list-metrics setiap jam.

Konfigurasi Cloud Scheduler

Kolom Frequency menggunakan sintaksis gaya cron untuk memberi tahu Cloud Scheduler seberapa sering menjalankan aplikasi. Target menentukan pesan Pub/Sub yang dihasilkan, dan kolom Payload berisi data yang dimuat dalam pesan Pub/Sub.

Menggunakan metrik yang diekspor

Dengan data yang diekspor di BigQuery, kini Anda dapat menggunakan SQL standar untuk membuat kueri data atau membuat dasbor guna memvisualisasikan tren dalam metrik dari waktu ke waktu.

Contoh kueri: Latensi App Engine

Kueri berikut menemukan nilai metrik latensi minimum, maksimum, dan rata-rata untuk aplikasi App Engine. metric.type mengidentifikasi metrik App Engine, dan label mengidentifikasi aplikasi App Engine berdasarkan nilai label project_id. point.value.distribution_value.mean digunakan karena metrik ini adalah nilai DISTRIBUTION di Monitoring API, yang dipetakan ke objek kolom distribution_value di BigQuery. Kolom end_time melihat kembali nilai selama 30 hari terakhir.

SELECT
  metric.type AS metric_type,
  EXTRACT(DATE  FROM point.INTERVAL.start_time) AS extract_date,
  MAX(point.value.distribution_value.mean) AS max_mean,
  MIN(point.value.distribution_value.mean) AS min_mean,
  AVG(point.value.distribution_value.mean) AS avg_mean
FROM
  `sage-facet-201016.metric_export.sd_metrics_export`
CROSS JOIN
  UNNEST(resource.labels) AS resource_labels
WHERE
   point.interval.end_time > TIMESTAMP(DATE_SUB(CURRENT_DATE, INTERVAL 30 DAY))
  AND  point.interval.end_time <= CURRENT_TIMESTAMP
  AND metric.type = 'appengine.googleapis.com/http/server/response_latencies'
  AND resource_labels.key = "project_id"
  AND resource_labels.value = "sage-facet-201016"
GROUP BY
  metric_type,
  extract_date
ORDER BY
  extract_date

Contoh kueri: Jumlah kueri BigQuery

Kueri berikut menampilkan jumlah kueri terhadap BigQuery per hari dalam sebuah project. Kolom int64_value digunakan karena metrik ini adalah nilai INT64 di Monitoring API, yang dipetakan ke kolom int64_value di BigQuery. metric.type mengidentifikasi metrik BigQuery, dan label mengidentifikasi project berdasarkan nilai label project_id. Kolom end_time melihat kembali nilai selama 30 hari terakhir.

SELECT
  EXTRACT(DATE  FROM point.interval.end_time) AS extract_date,
  sum(point.value.int64_value) as query_cnt
FROM
  `sage-facet-201016.metric_export.sd_metrics_export`
CROSS JOIN
  UNNEST(resource.labels) AS resource_labels
WHERE
   point.interval.end_time > TIMESTAMP(DATE_SUB(CURRENT_DATE, INTERVAL 30 DAY))
  AND  point.interval.end_time <= CURRENT_TIMESTAMP
  and metric.type = 'bigquery.googleapis.com/query/count'
  AND resource_labels.key = "project_id"
  AND resource_labels.value = "sage-facet-201016"
group by extract_date
order by extract_date

Contoh kueri: Instance Compute Engine

Kueri berikut menemukan nilai metrik penggunaan CPU minimum, maksimum, dan rata-rata mingguan untuk instance Compute Engine suatu project. metric.type mengidentifikasi metrik Compute Engine, dan label mengidentifikasi instance berdasarkan nilai label project_id. Kolom end_time melihat kembali nilai selama 30 hari terakhir.

SELECT
  EXTRACT(WEEK  FROM point.interval.end_time) AS extract_date,
  min(point.value.double_value) as min_cpu_util,
  max(point.value.double_value) as max_cpu_util,
  avg(point.value.double_value) as avg_cpu_util
FROM
  `sage-facet-201016.metric_export.sd_metrics_export`
WHERE
   point.interval.end_time > TIMESTAMP(DATE_SUB(CURRENT_DATE, INTERVAL 30 DAY))
  AND  point.interval.end_time <= CURRENT_TIMESTAMP
  AND metric.type = 'compute.googleapis.com/instance/cpu/utilization'
group by extract_date
order by extract_date

Visualisasi data

BigQuery terintegrasi dengan banyak alat yang dapat Anda gunakan untuk visualisasi data.

Looker Studio adalah alat gratis yang dibuat oleh Google tempat Anda dapat membuat diagram dan dasbor data untuk memvisualisasikan data metrik, lalu membagikannya kepada tim Anda. Contoh berikut menunjukkan diagram garis tren latensi dan jumlah untuk metrik appengine.googleapis.com/http/server/response_latencies dari waktu ke waktu.

Grafik tren App Engine dari waktu ke waktu

Colaboratory adalah alat riset untuk riset dan pendidikan machine learning. Ini adalah lingkungan notebook Jupyter yang dihosting dan tidak memerlukan penyiapan untuk menggunakan serta mengakses data di BigQuery. Dengan menggunakan notebook Colab, perintah Python, dan kueri SQL, Anda dapat mengembangkan analisis dan visualisasi yang mendetail.

Grafik penggunaan CPU

Memantau penerapan referensi ekspor

Saat ekspor berjalan, Anda perlu memantau ekspor. Salah satu cara untuk memutuskan metrik mana yang akan dipantau adalah dengan menetapkan Tujuan Tingkat Layanan (SLO). SLO adalah nilai target atau rentang nilai untuk tingkat layanan yang diukur dengan metrik. Buku Site reliability engineering menjelaskan 4 area utama untuk SLO: ketersediaan, throughput, tingkat error, dan latensi. Untuk ekspor data, throughput dan tingkat error adalah dua pertimbangan utama dan Anda dapat memantaunya melalui metrik berikut:

  • Throughput - appengine.googleapis.com/http/server/response_count
  • Tingkat error - logging.googleapis.com/log_entry_count

Misalnya, Anda dapat memantau tingkat error dengan menggunakan metrik log_entry_count dan memfilternya untuk aplikasi App Engine (list-metrics, get-timeseries, write-metrics) dengan tingkat keparahan dari ERROR. Kemudian, Anda dapat menggunakan Kebijakan pemberitahuan di Cloud Monitoring untuk memberi tahu Anda tentang error yang ditemukan dalam aplikasi ekspor.

Kebijakan pemberitahuan

UI Pemberitahuan menampilkan grafik metrik log_entry_count dibandingkan dengan ambang batas untuk membuat pemberitahuan.

Grafik kondisi

Langkah berikutnya