Mulai menggunakan koleksi yang di-deploy sendiri

Dokumen ini menjelaskan cara menyiapkan Google Cloud Managed Service for Prometheus dengan koleksi yang di-deploy sendiri. Contoh aplikasi 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.
  • Konfigurasikan akun layanan untuk Workload Identity Federation untuk cluster yang mengaktifkan 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.
  • Mengompilasi dan menjalankan biner Prometheus secara manual.

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

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

Layanan Terkelola untuk Prometheus tidak mendukung ekspor metrik dari server federasi atau dari server yang digunakan sebagai penerima operasi tulis jarak jauh. Anda dapat mereplikasi semua fungsi server federasi, termasuk mengurangi volume penyerapan dengan menggabungkan data sebelum mengirim ke Monarch, menggunakan filter dan agregasi lokal.

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

Untuk 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 project Google Cloud, lakukan hal berikut:

      1. Di konsol Google Cloud, buka New Project:

        Membuat Project Baru

      2. Di kolom Project Name, masukkan nama untuk 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 baru.

      Monitoring API diaktifkan secara default untuk project baru.

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

      1. Buka API & layanan:

        Buka API & layanan

      2. Pilih project Anda.

      3. Klik Aktifkan API dan Layanan.

      4. Telusuri "Pemantauan".

      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 Memulai 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:

  • Konfigurasikan alat command line sebagai berikut:

    • Konfigurasikan gcloud CLI untuk merujuk ke ID project Google Cloud Anda:

      gcloud config set project PROJECT_ID

    • Konfigurasikan kubectl CLI untuk menggunakan cluster Anda:

      kubectl config set-cluster CLUSTER_NAME

    Untuk informasi selengkapnya tentang alat ini, lihat referensi 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

Anda dapat melewati bagian ini jika cluster Kubernetes Anda telah mengaktifkan Workload Identity Federation for GKE.

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.

Jika Anda tidak menjalankannya di GKE, lihat Memberikan kredensial secara eksplisit.

Mengonfigurasi akun layanan untuk Workload Identity Federation for GKE

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

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

Membuat dan mengikat 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. Langsung ke Memberikan otorisasi ke 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 ke 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 telah memberikan peran tertentu kepada akun layanan Google Cloud 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 membuat Workload Identity Federation for GKE berfungsi, 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 error paling umum saat mengonfigurasi Workload Identity Federation untuk GKE, sebaiknya gunakan 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 memberi akun layanan Google Cloud semua izin yang diperlukan untuk 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 informasi selengkapnya tentang cara mengonfigurasi akun layanan untuk pengelolaan identitas beban kerja, lihat Menggunakan Workload Identity Federation untuk GKE.

Menyiapkan koleksi yang di-deploy sendiri

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

Men-deploy aplikasi contoh

Aplikasi contoh memunculkan metrik penghitung example_requests_total dan metrik histogram example_random_numbers (di antara yang lainnya) di port metrics-nya. 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.13.0/examples/example-app.yaml

Menjalankan biner Prometheus pengganti

Untuk menyerap data metrik yang dikeluarkan oleh aplikasi contoh, Anda men-deploy server Prometheus versi fork 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.13.0/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 datastore global, Monarch. Data tidak disimpan secara terus-menerus dalam salinan lokal. Untuk informasi tentang cara kerja konfigurasi yang telah ditentukan sebelumnya 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 build biner untuk Windows sendiri.

  2. Pastikan pod untuk server Prometheus dan aplikasi contoh 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 Anda menjalankannya di GKE, Anda dapat melakukan hal berikut:

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

Memberikan kredensial secara eksplisit

Saat berjalan di GKE, server Prometheus pengumpulan 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 pengumpulan dengan menggunakan flag atau variabel lingkungan GOOGLE_APPLICATION_CREDENTIALS.

  1. Tetapkan konteks ke project target Anda:

    gcloud config set project PROJECT_ID

  2. Buat akun layanan:

    gcloud iam service-accounts create gmp-test-sa

    Langkah ini akan membuat akun layanan yang mungkin sudah 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 cetak 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, daripada menggunakan tanda yang ditetapkan dalam contoh ini, Anda dapat menetapkan jalur file kunci menggunakan variabel lingkungan GOOGLE_APPLICATION_CREDENTIALS.

    Topik tambahan untuk koleksi yang di-deploy sendiri

    Bagian ini menjelaskan cara melakukan hal berikut:

    • Memfilter data yang Anda ekspor ke layanan terkelola.
    • Konversikan 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, sebaiknya hindari beberapa deret waktu yang 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 tanda --export.match.

    Flag ini menentukan satu atau beberapa pemilih deret PromQL, dan flag ini 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 di-ANDkan, sedangkan kondisi dalam tanda terpisah di-ORkan. Contoh berikut menggunakan dua instance flag:

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

    Perubahan ini menyebabkan hanya metrik untuk tugas "prometheus" serta metrik yang dihasilkan dengan merekam aturan yang digabungkan ke tingkat tugas (saat mengikuti praktik terbaik penamaan) yang diekspor. Contoh untuk semua serial lainnya akan 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 langsung sebagai flag di server Prometheus yang diambil oleh server Prometheus federasi Anda. Ekspor 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 penampung. Untuk informasi selengkapnya, lihat Menggunakan dengan prometheus-operator.

    Anda dapat menggabungkan tanda filter dengan aturan perekaman yang dijalankan secara lokal untuk "menggabungkan" data sebelum dikirim ke Monarch, sehingga mengurangi kardinalitas dan biaya. 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 visibilitas. Halaman Pengelolaan Metrik melaporkan informasi berikut:

    • Volume transfer 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 Pengelolaan Metrik untuk mengecualikan metrik yang tidak diperlukan, sehingga menghilangkan biaya penyerapannya. Untuk 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 dan 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.45.3-gmp.9-gke.0
    ...
    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 namespace dan akun layanan Kubernetes tambahan.

    Saat menjalankan di cluster Kubernetes non-GKE, Anda harus 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: gmp-test
    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 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.

    Menggunakan dengan kube-prometheus

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

    Kube-prometheus memiliki beberapa dependensi internal yang ketat pada namespace dan akun layanan default-nya, 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.45.3-gmp.9-gke.0
      ...
      replicas: 1
      version: v2.35.0
      ...

    Jika Anda menjalankan di GKE dan belum mengubah akun layanan default di node, menerapkan manifes yang diubah akan segera mulai mengirim 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 memberikan otorisasi ke akun layanan prometheus-k8s dalam namespace monitoring. Saat menjalankan 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 agar hanya mengambil metrik yang Anda minati 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 menggunakan pemilihan pemimpin. Server Prometheus yang direplikasi dalam mode ketersediaan tinggi mengumpulkan metrik dan mengevaluasi aturan seperti biasa, tetapi hanya satu server yang mengirim data ke Google Cloud Managed Service for Prometheus.

    Replika server Prometheus yang sama harus selalu memiliki konfigurasi yang sama, termasuk external_labels yang sama. Persyaratan ini berbeda dengan 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 menetapkan 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 resource Lease tempat pemilihan pemimpin berlangsung. 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 dengan 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 project Google Cloud yang terkait dengan metrik Anda. Wajib.
    • location: Lokasi fisik (region Google Cloud) tempat data disimpan. Nilai ini biasanya merupakan region cluster GKE Anda. Jika data dikumpulkan dari deployment AWS atau lokal, nilainya mungkin 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 subgrup instance. Opsional, tetapi sangat direkomendasikan.
    • job: Label tugas target Prometheus, jika diketahui; mungkin kosong untuk hasil evaluasi aturan. Wajib dan biasanya ditambahkan secara otomatis oleh Prometheus.
    • instance: Label instance target Prometheus, jika diketahui; mungkin kosong untuk hasil evaluasi aturan. Wajib dan biasanya ditambahkan secara otomatis oleh Prometheus. Jika ditetapkan atau diberi label ulang secara manual, jangan gunakan nilai hardcode seperti localhost, karena tindakan tersebut akan menyebabkan konflik deret waktu.

    Saat berjalan di Google Cloud, label project_id, location, dan cluster 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. Untuk mengetahui informasi selengkapnya, lihat Menjalankan pengumpulan yang di-deploy sendiri di luar Google Cloud.

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

    Deployment biner

    Jika ingin menjalankan di lingkungan non-container, Anda dapat mem-build biner Prometheus pengganti secara langsung.

    Mem-build sumber

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

    Untuk mem-build biner biasa, toolchain Go dan NPM/Yarn versi terbaru harus diinstal di komputer. Untuk 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.45.3-gmp.9

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

      make build && make tarball

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

    Batas untuk membuat dan memperbarui metrik dan label

    Managed Service for Prometheus menerapkan batas kapasitas per menit saat membuat metrik baru dan menambahkan label metrik baru ke metrik yang ada. Batas kapasitas 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 kapasitas untuk menyerap titik data. Batas kapasitas ini hanya berlaku saat membuat metrik yang belum pernah ada atau saat menambahkan label baru ke metrik yang sudah ada.

    Kuota ini bersifat tetap, tetapi masalah apa pun akan otomatis teratasi saat metrik baru dan label metrik 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 cukup diotorisasi, 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 (region Google Cloud) untuk menyimpan metrik. Anda juga harus menetapkan label cluster dan namespace, meskipun berjalan di lingkungan non-Kubernetes.

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

    Sebaiknya pilih project_id berdasarkan model kepemilikan yang Anda rencanakan untuk pembacaan. 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. Makin jauh region Google Cloud yang dipilih dari deployment Anda, makin besar latensi tulis yang akan Anda miliki dan makin besar kemungkinan Anda terpengaruh oleh masalah jaringan. Anda dapat melihat daftar region di beberapa cloud ini. Jika tidak masalah, Anda dapat menempatkan semuanya ke dalam satu region Google Cloud. Anda tidak dapat menggunakan global sebagai lokasi.

    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 pemberian label 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 dalam 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 dengan flag --export.compression=gzip.

    Langkah selanjutnya