Mulai menggunakan koleksi yang di-deploy sendiri

Dokumen ini menjelaskan cara menyiapkan Google Cloud Managed Service for Prometheus dengan pengumpulan yang di-deploy sendiri. Aplikasi contoh di-deploy ke cluster Kubernetes dan dipantau oleh server Prometheus yang menyimpan metrik yang dikumpulkan di Monarch.

Dokumen ini menunjukkan cara melakukan hal berikut:

  • Siapkan lingkungan dan alat command line Anda.
  • Konfigurasi akun layanan untuk cluster yang mendukung Workload Identity Federation untuk GKE.
  • Jalankan biner Prometheus drop-in di Kubernetes.
  • Mengontrol metrik yang diserap ke Managed Service for Prometheus.
  • Mengintegrasikan Managed Service for Prometheus dengan penyiapan prometheus-operator.
  • Kompilasi dan jalankan biner Prometheus secara manual.

Dengan pengumpulan data yang di-deploy sendiri, Anda mengelola penginstalan Prometheus seperti biasa. Satu-satunya perbedaan adalah Anda menjalankan biner pengganti langsung Managed Service for Prometheus, gke.gcr.io/prometheus-engine/prometheus:v2.53.4-gmp.0-gke.1, bukan biner Prometheus upstream.

Biner drop-in menyediakan opsi konfigurasi tambahan dengan tanda --export.*. Untuk informasi selengkapnya, lihat output opsi --help. Dokumen ini menunjukkan opsi yang paling penting.

Managed Service for Prometheus tidak mendukung ekspor metrik dari server gabungan atau dari server yang digunakan sebagai penerima tulis jarak jauh. Anda dapat mereplikasi semua fungsi server federasi, termasuk mengurangi volume penyerapan dengan menggabungkan data sebelum mengirim ke Monarch, menggunakan filter dan penggabungan lokal.

Streaming data ke Managed Service for Prometheus menggunakan resource tambahan. Jika Anda men-deploy pengumpul data sendiri, sebaiknya tingkatkan batas CPU dan memori hingga 5x dan sesuaikan berdasarkan penggunaan sebenarnya.

Untuk mengetahui informasi selengkapnya tentang pengumpulan data terkelola dan yang di-deploy sendiri, lihat Pengumpulan data dengan Managed Service for Prometheus.

Sebelum memulai

Bagian ini menjelaskan konfigurasi yang diperlukan untuk tugas yang dijelaskan dalam dokumen ini.

Menyiapkan project dan alat

Untuk menggunakan Google Cloud Managed Service for Prometheus, Anda memerlukan resource berikut:

  • Project Google Cloud dengan Cloud Monitoring API diaktifkan.

    • Jika Anda tidak memiliki Google Cloud project, lakukan hal berikut:

      1. Di Google Cloud console, buka New Project:

        Membuat Project Baru

      2. Di kolom Project Name, masukkan nama project Anda, lalu klik Create.

      3. Buka Penagihan:

        Buka Penagihan

      4. Pilih project yang baru saja Anda buat jika belum dipilih di bagian atas halaman.

      5. Anda akan diminta untuk memilih profil pembayaran yang sudah ada atau membuat profil pembayaran baru.

      Monitoring API diaktifkan secara default untuk project baru.

    • Jika Anda sudah memiliki Google Cloud project, pastikan Monitoring API diaktifkan:

      1. Buka APIs & services:

        Buka APIs & services

      2. Pilih project Anda.

      3. Klik Aktifkan API dan Layanan.

      4. Telusuri "Monitoring".

      5. Di hasil penelusuran, klik "Cloud Monitoring API".

      6. Jika "API enabled" tidak ditampilkan, klik tombol Enable.

  • Cluster Kubernetes. Jika Anda tidak memiliki cluster Kubernetes, ikuti petunjuk di Mulai Cepat untuk GKE.

Anda juga memerlukan alat command line berikut:

  • gcloud
  • kubectl

Alat gcloud dan kubectl adalah bagian dari Google Cloud CLI. Untuk mengetahui informasi tentang cara menginstalnya, lihat Mengelola komponen Google Cloud CLI. Untuk melihat komponen gcloud CLI yang telah Anda instal, jalankan perintah berikut:

gcloud components list

Mengonfigurasi lingkungan Anda

Agar tidak perlu memasukkan project ID atau nama cluster berulang kali, lakukan konfigurasi berikut:

  • Konfigurasi alat command line sebagai berikut:

    • Konfigurasi gcloud CLI untuk merujuk ke ID projectGoogle Cloud Anda:

      gcloud config set project PROJECT_ID

    • Konfigurasi CLI kubectl untuk menggunakan cluster Anda:

      kubectl config set-cluster CLUSTER_NAME

    Untuk mengetahui informasi selengkapnya tentang alat ini, lihat artikel berikut:

Menyiapkan namespace

Buat namespace Kubernetes NAMESPACE_NAME untuk resource yang Anda buat sebagai bagian dari aplikasi contoh:

kubectl create ns NAMESPACE_NAME

Memverifikasi kredensial akun layanan

Jika cluster Kubernetes Anda telah mengaktifkan Workload Identity Federation untuk GKE, Anda dapat melewati bagian ini.

Saat berjalan di GKE, Managed Service for Prometheus akan otomatis mengambil kredensial dari lingkungan berdasarkan akun layanan default Compute Engine. Akun layanan default memiliki izin yang diperlukan, monitoring.metricWriter dan monitoring.viewer, secara default. Jika Anda tidak menggunakan Workload Identity Federation untuk GKE, dan sebelumnya telah menghapus salah satu peran tersebut dari akun layanan node default, Anda harus menambahkan kembali izin yang hilang tersebut sebelum melanjutkan.

Mengonfigurasi akun layanan untuk Workload Identity Federation for GKE

Jika cluster Kubernetes Anda tidak mengaktifkan Workload Identity Federation untuk GKE, Anda dapat melewati bagian ini.

Managed Service for Prometheus merekam data metrik menggunakan Cloud Monitoring API. Jika cluster Anda menggunakan Workload Identity Federation for GKE, Anda harus memberikan izin akun layanan Kubernetes Anda ke Monitoring API. Bagian ini menjelaskan hal berikut:

Buat dan ikat akun layanan

Langkah ini muncul di beberapa tempat dalam dokumentasi Managed Service for Prometheus. Jika Anda telah melakukan langkah ini sebagai bagian dari tugas sebelumnya, Anda tidak perlu mengulanginya. Lanjutkan ke Melakukan otorisasi akun layanan.

Urutan perintah berikut membuat akun layanan gmp-test-sa dan mengikatnya ke akun layanan Kubernetes default di namespace NAMESPACE_NAME:

gcloud config set project PROJECT_ID \
&&
gcloud iam service-accounts create gmp-test-sa \
&&
gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE_NAME/default]" \
  gmp-test-sa@PROJECT_ID. \
&&
kubectl annotate serviceaccount \
  --namespace NAMESPACE_NAME \
  default \
  iam.gke.io/gcp-service-account=gmp-test-sa@PROJECT_ID.

Jika Anda menggunakan namespace atau akun layanan GKE yang berbeda, sesuaikan perintah dengan tepat.

Memberikan otorisasi akun layanan

Grup izin terkait dikumpulkan ke dalam peran, dan Anda memberikan peran tersebut kepada akun utama, dalam contoh ini, akun layanan Google Cloud. Untuk mengetahui informasi selengkapnya tentang peran Monitoring, lihat Kontrol akses.

Perintah berikut memberikan peran Monitoring API yang diperlukan akun layanan Google Cloud ,gmp-test-sa, untuk menulis data metrik.

Jika Anda telah memberikan peran tertentu kepada Google Cloud akun layanan sebagai bagian dari tugas sebelumnya, Anda tidak perlu melakukannya lagi.

gcloud projects add-iam-policy-binding PROJECT_ID\
  --member=serviceAccount:gmp-test-sa@PROJECT_ID. \
  --role=roles/monitoring.metricWriter

Men-debug konfigurasi Workload Identity Federation for GKE

Jika Anda mengalami masalah saat mengaktifkan Workload Identity Federation for GKE, lihat dokumentasi untuk memverifikasi penyiapan Workload Identity Federation for GKE dan panduan pemecahan masalah Workload Identity Federation for GKE.

Karena kesalahan ketik dan penyalinan sebagian adalah sumber kesalahan paling umum saat mengonfigurasi Workload Identity Federation untuk GKE, kami sangat merekomendasikan penggunaan variabel yang dapat diedit dan ikon salin tempel yang dapat diklik yang disematkan dalam contoh kode dalam petunjuk ini.

Workload Identity Federation for GKE di lingkungan produksi

Contoh yang dijelaskan dalam dokumen ini mengikat akun layanan Google Cloud ke akun layanan Kubernetes default dan memberikan semua izin yang diperlukan kepada akun layanan Google Clouduntuk menggunakan Monitoring API.

Dalam lingkungan produksi, Anda mungkin ingin menggunakan pendekatan yang lebih terperinci, dengan akun layanan untuk setiap komponen, masing-masing dengan izin minimal. Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi akun layanan untuk pengelolaan workload identity, lihat Menggunakan Workload Identity Federation untuk GKE.

Menyiapkan pengumpulan data yang di-deploy sendiri

Bagian ini menjelaskan cara menyiapkan dan menjalankan contoh aplikasi yang menggunakan pengumpulan data yang di-deploy sendiri.

Men-deploy aplikasi contoh

Aplikasi contoh memancarkan metrik penghitung example_requests_total dan metrik histogram example_random_numbers (di antara metrik lainnya) di port metrics. Manifes untuk aplikasi menentukan tiga replika.

Untuk men-deploy aplikasi contoh, jalankan perintah berikut:

kubectl -n NAMESPACE_NAME apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.15.3/examples/example-app.yaml

Jalankan biner Prometheus pengganti

Untuk menyerap data metrik yang dikeluarkan oleh contoh aplikasi, Anda men-deploy versi server Prometheus yang di-forking oleh Google, yang dikonfigurasi untuk meng-scrape metrik workload serta endpoint metriknya sendiri.

  1. Untuk men-deploy server yang di-fork, jalankan perintah berikut:

    kubectl -n NAMESPACE_NAME apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.15.3/examples/prometheus.yaml

    Server Prometheus yang di-deploy ini adalah fork tipis dari biner Prometheus upstream. Server ini berperilaku seperti server Prometheus standar, tetapi juga menyerap data ke Managed Service for Prometheus.

    Manifes di atas memberikan contoh kerja dasar yang mengirim data ke Monarch, yaitu datastore global. Aplikasi ini tidak menyimpan salinan data lokal secara persisten. Untuk mengetahui informasi tentang cara kerja konfigurasi yang telah ditentukan sebelumnya ini dan cara memperluasnya, lihat dokumentasi konfigurasi Prometheus open source.

    Image bawaan hanya berfungsi di node Linux. Untuk meng-scrape target yang berjalan di node Windows, deploy server di node Linux dan konfigurasikan untuk meng-scrape endpoint di node Windows atau bangun sendiri biner untuk Windows.

  2. Pastikan bahwa pod untuk server Prometheus dan contoh aplikasi berhasil di-deploy:

    kubectl -n NAMESPACE_NAME get pod

    Jika deployment berhasil, Anda akan melihat output yang mirip dengan berikut:

    NAME                            READY   STATUS    RESTARTS   AGE
prom-example-84c6f547f5-fglbr   1/1     Running   0          5m
prom-example-84c6f547f5-jnjp4   1/1     Running   0          5m
prom-example-84c6f547f5-sqdww   1/1     Running   0          5m
prometheus-test-0               2/2     Running   1          3m

Jika berjalan di GKE, Anda dapat melakukan hal berikut:

Jika Anda menjalankan di luar GKE, Anda perlu membuat akun layanan dan memberi otorisasi untuk menulis data metrik Anda, seperti yang dijelaskan di bagian berikut.

Memberikan kredensial secara eksplisit

Saat berjalan di GKE, server Prometheus yang mengumpulkan data akan otomatis mengambil kredensial dari lingkungan berdasarkan akun layanan node atau penyiapan Workload Identity Federation untuk GKE. Di cluster Kubernetes non-GKE, kredensial harus diberikan secara eksplisit ke server Prometheus pengumpul menggunakan flag atau variabel lingkungan GOOGLE_APPLICATION_CREDENTIALS.

  1. Tetapkan konteks ke project target Anda:

    gcloud config set project PROJECT_ID

  2. Membuat akun layanan:

    gcloud iam service-accounts create gmp-test-sa

    Langkah ini membuat akun layanan yang mungkin telah Anda buat di petunjuk Workload Identity Federation untuk GKE.

  3. Berikan izin yang diperlukan ke akun layanan:

    gcloud projects add-iam-policy-binding PROJECT_ID\
  --member=serviceAccount:gmp-test-sa@PROJECT_ID. \
  --role=roles/monitoring.metricWriter

  4. Buat dan download kunci untuk akun layanan:

    gcloud iam service-accounts keys create gmp-test-sa-key.json \
  --iam-account=gmp-test-sa@PROJECT_ID.

  5. Tambahkan file kunci sebagai secret ke cluster non-GKE Anda:

    kubectl -n NAMESPACE_NAME create secret generic gmp-test-sa \
  --from-file=key.json=gmp-test-sa-key.json

  6. Buka resource StatefulSet Prometheus untuk mengedit:

    kubectl -n NAMESPACE_NAME edit statefulset prometheus-test

    1. Tambahkan teks yang ditampilkan dalam huruf tebal ke resource:

      apiVersion: apps/v1
kind: StatefulSet
metadata:
  namespace: NAMESPACE_NAME
  name: example
spec:
  template
    containers:
    - name: prometheus
      args:
      - --export.credentials-file=/gmp/key.json
...
      volumeMounts:
      - name: gmp-sa
        mountPath: /gmp
        readOnly: true
...
    volumes:
    - name: gmp-sa
      secret:
        secretName: gmp-test-sa
...

    2. Simpan file dan tutup editor. Setelah perubahan diterapkan, pod akan dibuat ulang dan mulai mengautentikasi ke backend metrik dengan akun layanan yang diberikan.

    Atau, alih-alih menggunakan tanda yang ditetapkan dalam contoh ini, Anda dapat menetapkan jalur file kunci menggunakan variabel lingkungan GOOGLE_APPLICATION_CREDENTIALS.

    Topik tambahan untuk pengumpulan data yang di-deploy sendiri

    Bagian ini menjelaskan cara melakukan hal berikut:

    • Memfilter data yang Anda ekspor ke layanan terkelola.
    • Konversi konfigurasi deployment yang ada.
    • Jalankan biner Prometheus dalam mode ketersediaan tinggi.
    • Build dan jalankan biner Prometheus pengganti.
    • Menjalankan Managed Service for Prometheus di luar Google Cloud.

    Memfilter metrik yang diekspor

    Jika Anda mengumpulkan banyak data, Anda mungkin ingin mencegah beberapa deret waktu dikirim ke Managed Service for Prometheus untuk menekan biaya.

    Anda dapat menggunakan konfigurasi pelabelan ulang metrik reguler dalam konfigurasi scraping Prometheus. Dengan konfigurasi pelabelan ulang, Anda dapat menghapus metrik berdasarkan kecocokan label pada waktu penyerapan.

    Terkadang, Anda mungkin ingin menyerap data secara lokal, tetapi tidak mengekspornya ke Managed Service for Prometheus. Untuk memfilter metrik yang diekspor, Anda dapat menggunakan flag --export.match.

    Flag menentukan satu atau beberapa pemilih deret PromQL, dan flag dapat digunakan beberapa kali. Deret waktu diekspor ke Managed Service for Prometheus jika memenuhi semua pemilih di setidaknya salah satu tanda; yaitu, saat menentukan kelayakan, kondisi dalam satu tanda akan di-AND-kan, sedangkan kondisi dalam tanda terpisah akan di-OR-kan. Contoh berikut menggunakan dua instance tanda:

    ./prometheus \
  --export.match='{job="prometheus"}' \
  --export.match='{__name__=~"job:.+"}' \
  ...

    Perubahan ini hanya menyebabkan metrik untuk tugas "prometheus" serta metrik yang dihasilkan oleh aturan perekaman yang digabungkan ke tingkat tugas (saat mengikuti praktik terbaik penamaan) diekspor. Sampel untuk semua seri lainnya difilter. Secara default, tidak ada pemilih yang ditentukan dan semua deret waktu diekspor.

    Flag --export.match memiliki semantik yang sama dengan parameter match[] untuk federasi Prometheus. Oleh karena itu, Anda dapat memigrasikan penyiapan federasi ke Managed Service for Prometheus dengan menggunakan pemilih dari server federasi secara langsung sebagai tanda pada server Prometheus yang di-scrape oleh server Prometheus federasi Anda. Mengekspor metrik dari server federasi ke layanan terkelola tidak didukung.

    Untuk menyertakan metrik jenis histogram dalam filter, Anda harus menentukan metrik _count, _sum, dan _bucket. Anda juga dapat melakukannya dengan pencocok karakter pengganti, misalnya pemilih {__name__=~"histogram_metric_.+"}.

    Jika Anda menggunakan library prometheus-operator, tetapkan flag --export.match menggunakan variabel lingkungan EXTRA_ARGS dari container. Untuk mengetahui informasi selengkapnya, lihat Penggunaan dengan prometheus-operator.

    Anda dapat menggabungkan tanda filter dengan aturan perekaman yang dijalankan secara lokal untuk "menggabungkan" data sebelum mengirim ke Monarch, sehingga mengurangi kardinalitas dan biaya Anda. Untuk mengetahui informasi selengkapnya, lihat Kontrol dan atribusi biaya.

    Halaman Pengelolaan Metrik Cloud Monitoring memberikan informasi yang dapat membantu Anda mengontrol jumlah yang Anda belanjakan untuk metrik yang dapat ditagih tanpa memengaruhi kemampuan pengamatan. Halaman Pengelolaan Metrik melaporkan informasi berikut:

    • Volume penyerapan untuk penagihan berbasis byte dan sampel, di seluruh domain metrik dan untuk setiap metrik.
    • Data tentang label dan kardinalitas metrik.
    • Jumlah pembacaan untuk setiap metrik.
    • Penggunaan metrik dalam kebijakan pemberitahuan dan dasbor kustom.
    • Rasio error penulisan metrik.

    Anda juga dapat menggunakan halaman Pengelolaan Metrik untuk mengecualikan metrik yang tidak diperlukan, sehingga menghilangkan biaya penyerapan metrik tersebut. Untuk mengetahui informasi selengkapnya tentang halaman Pengelolaan Metrik, lihat Melihat dan mengelola penggunaan metrik.

    Penggunaan dengan prometheus-operator

    Biner Prometheus Managed Service for Prometheus juga dapat digunakan dengan deployment Prometheus GKE yang ada yang dikelola oleh prometheus-operator.

    Untuk menggunakan biner layanan terkelola, ganti spesifikasi image di resource Prometheus:

      apiVersion: monitoring.coreos.com/v1
  kind: Prometheus
  metadata:
    name: NAMESPACE_NAME
    namespace: gmp-system
  spec:
    image: gke.gcr.io/prometheus-engine/prometheus:v2.53.4-gmp.0-gke.1
    ...
    replicas: 1
    serviceAccountName: default
    version: v2.35.0
    ...

    Jika Anda berada di cluster Workload Identity Federation untuk GKE dan namespace atau akun layanan di resource Anda berbeda, ulangi petunjuk Workload Identity Federation untuk GKE untuk pasangan akun layanan Kubernetes dan namespace tambahan.

    Saat berjalan di cluster Kubernetes non-GKE, Anda perlu memberikan kredensial secara manual. Untuk memberikan kredensial, lakukan hal berikut:

    1. Tambahkan file kunci akun layanan yang sesuai sebagai secret, seperti yang dijelaskan dalam Memberikan kredensial secara eksplisit.

    2. Ubah resource Prometheus untuk menambahkan teks yang ditampilkan dalam huruf tebal:

        apiVersion: monitoring.coreos.com/v1
  kind: Prometheus
  metadata:
    namespace: NAMESPACE_NAME
    name: example
  spec:
    ...
    secrets:
    - gmp-test-sa
    containers:
    - name: prometheus
      env:
      - name: GOOGLE_APPLICATION_CREDENTIALS
        value: /gmp/key.json
      volumeMounts:
      - name: secret-gmp-test-sa
        mountPath: /gmp
        readOnly: true

    Anda dapat menetapkan variabel lingkungan EXTRA_ARGS dari penampung untuk menambahkan flag tambahan, seperti flag pemfilteran metrik. Hal ini dilakukan melalui variabel lingkungan karena bagian args dari spesifikasi penampung dikelola oleh Prometheus Operator.

    Penggunaan dengan kube-prometheus

    Anda dapat mengonfigurasi deployment yang dibuat menggunakan library kube-prometheus yang populer untuk menggunakan Managed Service for Prometheus.

    Kube-prometheus memiliki beberapa dependensi internal yang ketat pada namespace dan akun layanan defaultnya, jadi sebaiknya hanya ubah jumlah minimum kolom yang diperlukan untuk mengirim data ke Managed Service for Prometheus.

    Dalam manifests/prometheus-prometheus.yaml, ganti spesifikasi gambar dan nonaktifkan pengumpulan ketersediaan tinggi dengan mengurangi replicas menjadi 1:

        apiVersion: monitoring.coreos.com/v1
    kind: Prometheus
    ...
    spec:
      image: gke.gcr.io/prometheus-engine/prometheus:v2.53.4-gmp.0-gke.1
      ...
      replicas: 1
      version: v2.35.0
      ...

    Jika Anda menjalankan di GKE dan belum mengubah akun layanan default di node, penerapan manifes yang diubah akan segera mulai mengirimkan data ke Managed Service for Prometheus. Jika tidak, Anda mungkin harus mengonfigurasi dan menerapkan akun layanan. Saat berjalan di GKE dan menggunakan workload identity, Anda mungkin harus membuat dan memberi otorisasi akun layanan prometheus-k8s dalam namespace prometheus-k8s.monitoring Saat berjalan di cluster Kubernetes non-GKE, ikuti petunjuk di bagian prometheus-operator.

    Perhatikan bahwa kube-prometheus mengumpulkan banyak metrik secara default, yang sebagian besar sering kali tidak diperlukan di lingkungan Kubernetes terkelola seperti GKE. Untuk menghemat biaya penyerapan, Anda dapat menyesuaikan kube-prometheus sehingga hanya meng-scrape metrik yang penting bagi Anda dan memfilter metrik yang diekspor secara agresif.

    Untuk saran lainnya, lihat Kontrol biaya dan atribusi.

    Deployment ketersediaan tinggi

    Biner Prometheus pengganti dilengkapi dengan dukungan bawaan untuk pengumpulan yang sangat tersedia dengan menggunakan pemilihan pemimpin. Server Prometheus yang direplikasi dalam mode ketersediaan tinggi mengumpulkan metrik dan mengevaluasi aturan seperti biasa, tetapi hanya salah satunya yang mengirim data ke Google Cloud Managed Service for Prometheus.

    Replika server Prometheus yang sama harus selalu memiliki konfigurasi yang identik, termasuk external_labels yang sama. Persyaratan ini berbeda dari sistem lain, yang mengandalkan label eksternal khusus, seperti __replica__, untuk membuat replika secara eksplisit berbeda.

    Server Kubernetes API adalah backend pemilihan pemimpin yang didukung dan dapat diaktifkan dengan menyetel flag berikut:

    ./prometheus
  ...
  --export.ha.backend=kube \
  --export.ha.kube.namespace=LEASE_NAMESPACE \
  --export.ha.kube.name=LEASE_NAME

    Nilai LEASE_NAMESPACE dan LEASE_NAME mengidentifikasi Lease resource yang digunakan untuk pemilihan pemimpin. Semua server Prometheus yang mengarah ke resource yang sama termasuk dalam set replika yang sama. Akun layanan Kubernetes dari deployment Prometheus memerlukan izin untuk membaca dan menulis resource Lease masing-masing. Saat menjalankan server Prometheus di luar cluster Kubernetes, Anda dapat memberikan konfigurasi eksplisit menggunakan flag --export.ha.kube.config.

    Setelah melakukannya, Anda dapat meningkatkan nilai replicas menjadi 2 atau lebih.

    Label yang dicadangkan

    Managed Service for Prometheus menggunakan enam label yang dicadangkan untuk mengidentifikasi resource secara unik di Monarch:

    • project_id: ID Google Cloud project yang terkait dengan metrik Anda. Wajib.
    • location: Lokasi fisik (regionGoogle Cloud ) tempat data disimpan. Nilai ini biasanya adalah region cluster GKE Anda. Jika data dikumpulkan dari deployment AWS atau lokal, maka nilainya mungkin merupakan region Google Cloud terdekat. Wajib.
    • cluster: Nama cluster Kubernetes yang terkait dengan metrik Anda. Jika tidak berjalan di Kubernetes, ini dapat digunakan sebagai tingkat hierarki arbitrer seperti grup instance. Opsional, tetapi sangat direkomendasikan.
    • namespace: Nama namespace Kubernetes yang terkait dengan metrik Anda. Jika tidak berjalan di Kubernetes, ini dapat digunakan sebagai tingkat hierarki arbitrer seperti sub-grup instance. Opsional, tetapi sangat direkomendasikan.
    • job: Label tugas target Prometheus, jika diketahui; mungkin kosong untuk hasil evaluasi aturan. Diperlukan dan biasanya ditambahkan secara otomatis oleh Prometheus.
    • instance: Label instance target Prometheus, jika diketahui; mungkin kosong untuk hasil evaluasi aturan. Diperlukan dan biasanya ditambahkan secara otomatis oleh Prometheus. Jika disetel atau diberi label ulang secara manual, jangan gunakan nilai hardcode seperti localhost, karena tindakan ini akan menyebabkan bentrokan deret waktu.

    Saat berjalan di Google Cloud, label project_id, location, dan cluster akan otomatis ditambahkan ke setiap metrik.

    Meskipun tidak direkomendasikan saat berjalan di Google Cloud, Anda dapat mengganti label project_id, location, cluster, dan namespace menggunakan bagian global.external_labels dari konfigurasi Prometheus Anda. Untuk mengetahui informasi selengkapnya, lihat Menjalankan pengumpulan yang di-deploy sendiri di luar Google Cloud.

    Jika Anda menggunakan label yang dicadangkan sebagai label metrik, pengumpulan yang di-deploy sendiri akan menggunakan label metrik sebagai nilai untuk label yang dicadangkan. Hal ini dapat memberikan fleksibilitas, tetapi juga dapat menyebabkan error jika, misalnya, Anda menggunakan label location untuk merujuk ke sesuatu selainGoogle Cloud wilayah.

    Mengonfigurasi statsd_exporter dan pengekspor lain yang melaporkan metrik secara terpusat

    Jika Anda menggunakan statsd_exporter untuk Prometheus, Envoy untuk Istio, SNMP exporter, Prometheus Pushgateway, kube-state-metrics, atau Anda memiliki pengekspor serupa yang memediasi dan melaporkan metrik atas nama resource lain yang berjalan di lingkungan Anda, maka Anda perlu melakukan beberapa perubahan kecil agar pengekspor Anda dapat berfungsi dengan Managed Service for Prometheus.

    Untuk mengetahui petunjuk tentang cara mengonfigurasi eksportir ini, lihat catatan ini di bagian Pemecahan masalah.

    Deployment biner

    Jika ingin menjalankan di lingkungan yang tidak di-container, Anda dapat membuat biner Prometheus pengganti secara langsung.

    Membangun sumber

    Jika Anda memiliki proses yang sudah ada untuk mengompilasi Prometheus sendiri, Anda dapat mengganti repositori GitHub kami secara transparan ke dalam proses Anda. Managed Service for Prometheus memiliki ekstensi tag versi sendiri untuk membedakan rilisnya dari rilis upstream.

    Untuk membuat biner biasa, toolchain Go dan NPM/Yarn versi terbaru harus diinstal di komputer. Untuk mengetahui informasi selengkapnya, lihat petunjuk build upstream.

    1. Meng-cloning repository

      git clone https://github.com/GoogleCloudPlatform/prometheus &&
cd prometheus

    2. Periksa tag versi yang diinginkan:

      git checkout v2.53.4-gmp.0

    3. Untuk membuat tarball Managed Service for Prometheus, jalankan perintah berikut:

      make build && make tarball

    Tarball dan biner yang dihasilkan sepenuhnya kompatibel dengan varian upstream-nya dalam hal struktur direktori dan fungsi.

    Batas untuk membuat dan memperbarui metrik dan label

    Managed Service for Prometheus menerapkan batas frekuensi per menit untuk pembuatan metrik baru dan penambahan label metrik baru ke metrik yang ada. Batas frekuensi ini biasanya hanya tercapai saat pertama kali berintegrasi dengan Managed Service for Prometheus, misalnya saat Anda memigrasikan deployment Prometheus yang sudah ada dan matang untuk menggunakan pengumpulan yang di-deploy sendiri. Ini bukan batas kecepatan untuk memproses titik data. Batas frekuensi ini hanya berlaku saat membuat metrik yang belum pernah dilihat sebelumnya atau saat menambahkan label baru ke metrik yang ada.

    Kuota ini tetap, tetapi masalah apa pun akan otomatis diselesaikan saat metrik dan label metrik baru dibuat hingga batas per menit.

    Untuk mengetahui informasi selengkapnya, lihat Pemecahan masalah.

    Menjalankan pengumpulan yang di-deploy sendiri di luar Google Cloud

    Di lingkungan Compute Engine, lingkungan GKE, atau di mesin tempat Anda menjalankan gcloud login dengan akun yang memiliki otorisasi yang memadai, Anda dapat menjalankan pengumpulan yang di-deploy sendiri tanpa konfigurasi lebih lanjut. Di luar Google Cloud, Anda harus memberikan kredensial secara eksplisit, project_id untuk memuat metrik, dan location (regionGoogle Cloud ) untuk menyimpan metrik Anda. Anda juga harus menetapkan label cluster dan namespace, meskipun berjalan di lingkungan non-Kubernetes.

    Anda dapat memberikan kunci akun layanan menggunakan flag --export.credentials-file atau variabel lingkungan GOOGLE_APPLICATION_CREDENTIALS seperti yang dijelaskan dalam Memberikan kredensial secara eksplisit.

    Sebaiknya pilih project_id berdasarkan model sewa yang Anda rencanakan untuk bacaan. Pilih project untuk menyimpan metrik berdasarkan cara Anda berencana mengatur pembacaan nanti dengan cakupan metrik. Jika tidak peduli, Anda dapat memasukkan semuanya ke dalam satu project.

    Untuk location, sebaiknya pilih region Google Cloud terdekat dengan deployment Anda. Semakin jauh Google Cloud wilayah yang dipilih dari deployment Anda, semakin besar latensi penulisan yang akan Anda alami dan semakin besar pula pengaruh yang akan Anda rasakan akibat potensi masalah jaringan. Anda mungkin ingin melihat daftar region di beberapa cloud ini. Jika tidak masalah, Anda dapat menempatkan semuanya ke dalam satu Google Cloud region. Anda tidak dapat menggunakan global sebagai lokasi Anda.

    Jika berjalan di lingkungan Kubernetes, tetapkan nilai cluster dan namespace ke cluster dan namespace lokal. Jika berjalan di luar Kubernetes, tetapkan ke nilai yang masuk akal secara hierarkis. Misalnya, di lingkungan berbasis VM yang berjalan di AWS, tetapkan nilai cluster ke __aws__ dan nilai namespace ke ID instance. Anda dapat mengisi ID instance secara dinamis menggunakan aturan pelabelan ulang yang memanggil server metadata lokal.

    Untuk contoh kerja minimal, Anda dapat menjalankan biner Prometheus pemantauan mandiri lokal dengan perintah berikut:

    ./prometheus \
  --config.file=documentation/examples/prometheus.yaml \
  --export.label.project-id=PROJECT_ID \
  --export.label.location=REGION \
  --export.label.cluster=CLUSTER_NAME \

    Contoh ini mengasumsikan bahwa Anda telah menetapkan variabel REGION ke nilai seperti us-central1, misalnya.

    Namun, sebaiknya tetapkan label target export untuk layanan terkelola di bagian global.external_labels konfigurasi Prometheus Anda. Misalnya, di lingkungan Kubernetes, Anda dapat menggunakan konfigurasi berikut:

    global:
  external_labels:
    project_id: PROJECT_ID
    location: REGION
    cluster: CLUSTER_NAME
    namespace: local-testing

scrape_configs:
  ...

    Menjalankan Managed Service for Prometheus di luar Google Cloud akan dikenai biaya transfer data. Ada biaya untuk mentransfer data ke Google Cloud, dan Anda mungkin dikenai biaya untuk mentransfer data keluar dari cloud lain. Anda dapat meminimalkan biaya ini dengan mengaktifkan kompresi menggunakan tanda --export.compression=gzip.

    Langkah berikutnya