Evaluasi aturan dan pemberitahuan dengan koleksi terkelola
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Dokumen ini menjelaskan konfigurasi untuk evaluasi aturan dan pemberitahuan
dalam deployment Managed Service for Prometheus yang menggunakan
koleksi terkelola.
Diagram berikut mengilustrasikan deployment yang menggunakan beberapa cluster dalam dua project Google Cloud dan menggunakan evaluasi aturan dan pemberitahuan, serta resource GlobalRules opsional:
Untuk menyiapkan dan menggunakan deployment seperti yang ada dalam diagram, perhatikan hal berikut:
Evaluator aturan terkelola otomatis di-deploy di cluster tempat koleksi terkelola berjalan. Evaluator
ini dikonfigurasi sebagai berikut:
Gunakan resource Rules untuk menjalankan aturan pada data dalam namespace. Resource aturan harus diterapkan di setiap namespace tempat Anda ingin menjalankan aturan.
Gunakan resource ClusterRules untuk menjalankan
aturan pada data di seluruh cluster. Resource ClusterRules harus diterapkan
satu kali per cluster.
Semua evaluasi aturan dijalankan terhadap datastore global,
Monarch.
Resource aturan secara otomatis memfilter aturan ke project, lokasi,
cluster, dan namespace tempat aturan diinstal.
Resource ClusterRules secara otomatis memfilter aturan ke project,
lokasi, dan cluster tempat aturan diinstal.
Semua hasil aturan ditulis ke Monarch setelah evaluasi.
Instance Prometheus AlertManager di-deploy secara manual di setiap
cluster. Evaluator aturan terkelola dikonfigurasi dengan mengedit resource OperatorConfig untuk mengirim aturan pemberitahuan yang diaktifkan ke instance AlertManager lokal. Penonaktifan, konfirmasi, dan
alur kerja pengelolaan insiden biasanya ditangani di alat pihak ketiga
seperti PagerDuty.
Anda dapat memusatkan pengelolaan pemberitahuan di beberapa cluster ke dalam satu AlertManager menggunakan resource Endpoints Kubernetes.
Diagram sebelumnya juga menunjukkan resource
GlobalRules opsional.
Gunakan GlobalRules dengan sangat hemat, untuk tugas seperti
menghitung SLO global di seluruh project atau untuk mengevaluasi aturan di seluruh
cluster dalam satu project Google Cloud .
Sebaiknya gunakan Rules dan ClusterRules jika memungkinkan;
resource ini memberikan keandalan yang lebih baik dan lebih cocok untuk
mekanisme deployment dan model kepemilikan Kubernetes umum.
Jika Anda menggunakan resource GlobalRules, perhatikan hal berikut dari
diagram sebelumnya:
Satu cluster yang berjalan di dalam Google Cloud ditetapkan sebagai
cluster evaluasi aturan global untuk cakupan metrik. Evaluator aturan terkelola ini dikonfigurasi untuk menggunakan scoping_project_A, yang berisi Project 1 dan 2. Aturan yang dieksekusi terhadap scoping_project_A akan otomatis
diperluas ke Project 1 dan 2.
Seperti di semua cluster lainnya, evaluator aturan ini disiapkan dengan resource Rules
dan ClusterRules yang mengevaluasi aturan yang dicakup untuk namespace
atau cluster. Aturan ini otomatis difilter ke project lokal—Project 1, dalam hal ini. Karena scoping_project_A
berisi Project 1, aturan yang dikonfigurasi Rules dan ClusterRules hanya dijalankan
terhadap data dari project lokal seperti yang diharapkan.
Cluster ini juga memiliki resource GlobalRules yang mengeksekusi aturan terhadap
scoping_project_A. GlobalRules tidak difilter secara otomatis, sehingga
GlobalRules dijalankan persis seperti yang ditulis di semua project,
lokasi, cluster, dan namespace di scoping_project_A.
Aturan pemberitahuan yang diaktifkan akan dikirim ke AlertManager yang dihosting sendiri seperti yang diharapkan.
Penggunaan GlobalRules dapat memiliki efek yang tidak terduga, bergantung pada apakah Anda mempertahankan atau menggabungkan label project_id, location, cluster, dan namespace dalam aturan:
Jika aturan GlobalRules Anda mempertahankan label project_id (dengan menggunakan
klausa by(project_id)), hasil aturan akan ditulis kembali ke
Monarch menggunakan nilai project_id asli dari deret waktu
yang mendasarinya.
Dalam skenario ini, Anda harus memastikan akun layanan yang mendasarinya memiliki izin Monitoring Metric Writer untuk setiap project yang dipantau di scoping_project_A. Jika menambahkan project baru yang dipantau ke scoping_project_A, Anda juga harus menambahkan izin baru ke akun layanan secara manual.
Jika aturan GlobalRules Anda tidak mempertahankan label project_id (dengan
tidak menggunakan klausa by(project_id)), hasil aturan akan ditulis kembali
ke Monarch menggunakan nilai project_id cluster
tempat evaluator aturan global berjalan.
Dalam skenario ini, Anda tidak perlu mengubah akun layanan yang mendasarinya lebih lanjut.
Jika GlobalRules Anda mempertahankan label location (dengan menggunakan
klausa by(location)), hasil aturan akan ditulis kembali ke
Monarch menggunakan setiap region Google Cloud asli tempat
deret waktu yang mendasarinya berasal.
Jika GlobalRules Anda tidak mempertahankan label location, data akan ditulis kembali ke lokasi cluster tempat evaluator aturan global berjalan.
Sebaiknya pertahankan label cluster dan namespace dalam
hasil evaluasi aturan, kecuali jika tujuan aturannya adalah untuk menggabungkan
label tersebut. Jika tidak, performa kueri mungkin menurun dan Anda mungkin
mengalami batas kardinalitas. Sebaiknya jangan hapus kedua label tersebut.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-04 UTC."],[],[],null,["# Evaluation of rules and alerts with managed collection\n\nThis document describes a configuration for rule and alert evaluation\nin a Managed Service for Prometheus deployment that uses\n[managed collection](/stackdriver/docs/managed-prometheus/setup-managed).\n\nThe following diagram illustrates a deployment that uses multiple clusters\nin two Google Cloud projects and uses both rule and alert evaluation, as well\nas the optional GlobalRules resource:\n\nTo set up and use a deployment like the one in the diagram, note the\nfollowing:\n\n- The [managed rule evaluator](/stackdriver/docs/managed-prometheus/rules-managed) is automatically\n deployed in any cluster where managed collection is running. These\n evaluators are configured as follows:\n\n - Use [Rules](https://github.com/GoogleCloudPlatform/prometheus-engine/blob/v0.15.3/doc/api.md#rules) resources to run rules on data\n within a namespace. Rules resources must be applied in every namespace\n in which you want to execute the rule.\n\n - Use [ClusterRules](https://github.com/GoogleCloudPlatform/prometheus-engine/blob/v0.15.3/doc/api.md#clusterrules) resources to run\n rules on data across a cluster. ClusterRules resources should be applied\n once per cluster.\n\n- All rule evaluation executes against the global datastore,\n Monarch.\n\n - Rules resources automatically filter rules to the project, location, cluster, and namespace in which they are installed.\n - ClusterRules resources automatically filter rules to the project, location, and cluster in which they are installed.\n - All rule results are written to Monarch after evaluation.\n- A Prometheus AlertManager instance is manually deployed in every single\n cluster. Managed rule evaluators are configured by [editing the\n OperatorConfig resource](/stackdriver/docs/managed-prometheus/rules-managed#am-config-managed) to send fired alerting\n rules to their local AlertManager instance. Silences, acknowledgements, and\n incident management workflows are typically handled in a third-party tool\n such as PagerDuty.\n\n You can centralize alert management across multiple clusters into a\n single AlertManager by using a Kubernetes\n [Endpoints resource](/stackdriver/docs/managed-prometheus/rules-managed#am-config-managed).\n\nThe preceding diagram also shows the optional\n[GlobalRules](https://github.com/GoogleCloudPlatform/prometheus-engine/blob/v0.15.3/doc/api.md#globalrules) resource.\nUse GlobalRules very sparingly, for tasks like\ncalculating global SLOs across projects or for evaluating rules across\nclusters within a single Google Cloud project.\n**We strongly recommend using Rules and ClusterRules whenever possible**;\nthese resources provide superior reliability and are better fits for\ncommon Kubernetes deployment mechanisms and tenancy models.\n\nIf you use the GlobalRules resource, note the following from the\npreceding diagram:\n\n- One single cluster running inside Google Cloud is designated as the\n global rule-evaluation cluster for a metrics scope. This managed rule\n evaluator is configured to use scoping_project_A, which contains\n Projects 1 and 2. Rules executed against scoping_project_A automatically\n fan out to Projects 1 and 2.\n\n The underlying service account must be given the [Monitoring\n Viewer](/monitoring/access-control#mon_roles_desc) permissions for scoping_project_A.\n For additional information on how to set these fields, see\n [Multi-project and global rule evaluation](/stackdriver/docs/managed-prometheus/rules-managed#multi-project_and_global_rule_evaluation).\n- As in all other clusters, this rule evaluator is set up with Rules\n and ClusterRules resources that evaluate rules scoped to a namespace\n or cluster. These rules are automatically filtered to the *local*\n project---Project 1, in this case. Because scoping_project_A\n contains Project 1, Rules and ClusterRules-configured rules execute\n only against data from the local project as expected.\n\n- This cluster also has GlobalRules resources that execute rules against\n scoping_project_A. GlobalRules are not automatically filtered, and\n therefore GlobalRules execute exactly as written across all projects,\n locations, clusters, and namespaces in scoping_project_A.\n\n- Fired alerting rules will be sent to the self-hosted AlertManager as\n expected.\n\nUsing GlobalRules may have unexpected effects, depending on whether you\npreserve or aggregate the `project_id`, `location`, `cluster`, and\n`namespace` labels in your rules:\n\n- If your GlobalRules rule preserves the `project_id` label (by using\n a `by(project_id)` clause), then rule results are written back to\n Monarch using the original `project_id` value of the underlying\n time series.\n\n In this scenario, you need to ensure the underlying service account\n has the [Monitoring Metric Writer](/monitoring/access-control#mon_roles_desc) permissions for each\n monitored project in scoping_project_A. If you add a new\n monitored project to scoping_project_A, then you must also manually\n add a new permission to the service account.\n- If your GlobalRules rule does not preserve the `project_id` label (by\n not using a `by(project_id)` clause), then rule results are written back\n to Monarch using the `project_id` value of the cluster\n where the global rule evaluator is running.\n\n In this scenario, you do not need to further modify the underlying\n service account.\n- If your GlobalRules preserves the `location` label (by using a\n `by(location)` clause), then rule results are written back to\n Monarch using each original Google Cloud region from which\n the underlying time series originated.\n\n If your GlobalRules does not preserve the `location` label, then data\n is written back to the location of the cluster where the global rule\n evaluator is running.\n\nWe strongly recommend preserving the `cluster` and `namespace` labels in\nrule evaluation results unless the purpose of the rule is to aggregate away\nthose labels. Otherwise, query performance might decline and you might\nencounter cardinality limits. Removing both labels is strongly discouraged."]]
