1.4. 可観測性設定のカスタマイズ
可観測性を有効にした後、環境の特定のニーズに合わせて可観測性設定をカスタマイズします。可観測性サービスが収集するクラスターフリートデータを管理および表示します。
必要なアクセス権限: クラスターの管理者
1.4.1. カスタムルールの作成
可観測性リソースに、Prometheus レコードルール および アラートルール を追加して、可観測性インストールのカスタムルールを作成します。
高価な式を事前計算するには、Prometheus の記録ルール機能を使用してアラート条件を作成し、外部サービスにアラートを送信する方法に基づいて通知を送信します。結果は新たな時系列のセットとして保存されます。observability-thanos-rule-custom-rules
config map 内にカスタムアラートルールを作成するには、次の例を参照してください。
CPU 使用率が定義した値を超えたときに通知を受け取るには、次のカスタムアラートルールを作成します。
data: custom_rules.yaml: | groups: - name: cluster-health rules: - alert: ClusterCPUHealth-jb annotations: summary: Notify when CPU utilization on a cluster is greater than the defined utilization limit description: "The cluster has a high CPU usage: {{ $value }} core for {{ $labels.cluster }} {{ $labels.clusterID }}." expr: | max(cluster:cpu_usage_cores:sum) by (clusterID, cluster, prometheus) > 0 for: 5s labels: cluster: "{{ $labels.cluster }}" prometheus: "{{ $labels.prometheus }}" severity: critical
注記:
-
カスタムルールを更新すると、
observability-thanos-rule
Pod が自動的に再起動します。 - 設定には、複数のルールを作成できます。
-
デフォルトのアラートルールは、
open-cluster-management-observability
namespace のobservability-thanos-rule-default-rules
config map にあります。
-
カスタムルールを更新すると、
Pod のコンテナーメモリーキャッシュの合計を取得するためのカスタム記録ルールを作成するには、次のカスタムルールを作成します。
data: custom_rules.yaml: | groups: - name: container-memory rules: - record: pod:container_memory_cache:sum expr: sum(container_memory_cache{pod!=""}) BY (pod, container)
注記: config map に変更を加えた後、設定は自動的に再読み込みされます。この設定は、
observability-thanos-rule
サイドカー内のconfig-reload
により、設定が再読み込みされます。
アラートルールが正しく機能していることを確認するには、Grafana ダッシュボードに移動し、Explore ページを選択して、ALERTS
にクエリーを実行します。アラートを作成した場合、アラートは Grafana でのみ使用できます。
1.4.2. カスタムメトリックの追加
metrics_list.yaml
ファイルにメトリクスを追加して、マネージドクラスターから収集します。以下の手順を実行します。
カスタムメトリックを追加する前に、次のコマンドを使用して
mco observability
が有効になっていることを確認します。oc get mco observability -o yaml
status.conditions.message
セクションで、以下のメッセージを確認します。Observability components are deployed and running
以下のコマンドで、
open-cluster-management-observability
namespace にobservability-metrics-custom-allowlist
config map を作成します。oc apply -n open-cluster-management-observability -f observability-metrics-custom-allowlist.yaml
metrics_list.yaml
パラメーターにカスタムメトリックの名前を追加します。config map の YAML は、以下の内容のようになります。kind: ConfigMap apiVersion: v1 metadata: name: observability-metrics-custom-allowlist data: metrics_list.yaml: | names: 1 - node_memory_MemTotal_bytes rules: 2 - record: apiserver_request_duration_seconds:histogram_quantile_90 expr: histogram_quantile(0.90,sum(rate(apiserver_request_duration_seconds_bucket{job=\"apiserver\", verb!=\"WATCH\"}[5m])) by (verb,le))
セクションのいずれかまたは両方を使用できます。ユーザーワークロードメトリクスは、ユーザーワークロードメトリクスの追加 セクションを参照してください。
注記: カスタムメトリクス許可リスト内の各マネージドクラスターを、フリート全体に適用するのではなく、個別にカスタマイズすることもできます。同じ YAML をマネージドクラスター上で直接作成してカスタマイズできます。
- Grafana ダッシュボードの Explore ページからメトリクスをクエリーして、カスタムメトリクスからのデータコレクションを確認します。独自のダッシュボードでカスタムメトリックを使用することもできます。
1.4.2.1. ユーザーワークロードメトリクスの追加
OpenShift Container Platform のワークロードから OpenShift Container Platform ユーザー定義のメトリクスを収集し、Grafana ダッシュボードからメトリクスを表示します。以下の手順を実行します。
OpenShift Container Platform クラスターでモニタリングを有効にします。関連情報 セクションの ユーザー定義プロジェクトの監視の有効化 を参照してください。
ユーザー定義のワークロードの監視が有効になっているマネージドクラスターがある場合、ユーザーのワークロードは
test
namespace に配置され、メトリクスを生成します。これらのメトリクスは、OpenShift Container Platform ユーザーワークロードから Prometheus によって収集されます。ユーザーワークロードメトリックを
observability-metrics-custom-allowlist
config map に追加して、test
namespace のメトリックを収集します。以下の例を参照してください。kind: ConfigMap apiVersion: v1 metadata: name: observability-metrics-custom-allowlist namespace: test data: uwl_metrics_list.yaml: 1 names: 2 - sample_metrics
1.4.2.2. デフォルトメトリックの削除
マネージドクラスターから特定のメトリクスのデータを収集したくない場合は、observability-metrics-custom-allowlist.yaml
ファイルからメトリクスを削除します。メトリックを削除すると、メトリックデータはマネージドクラスターでは収集されません。デフォルトメトリックを削除するには、以下の手順を実施します。
以下のコマンドを使用して、
mco observability
が有効になっていることを確認します。oc get mco observability -o yaml
メトリック名の先頭にハイフン
-
を指定してmetrics_list.yaml
パラメーターにデフォルトのメトリック名を追加します。次のメトリックの例を確認してください。-cluster_infrastructure_provider
以下のコマンドで、
open-cluster-management-observability
namespace にobservability-metrics-custom-allowlist
config map を作成します。oc apply -n open-cluster-management-observability -f observability-metrics-custom-allowlist.yaml
- 可観測性サービスがマネージドクラスターから特定のメトリクスを収集していないことを確認します。Grafana ダッシュボードからメトリックをクエリーしても、メトリックは表示されません。
1.4.3. 保持の詳細設定の追加
必要に応じて各可観測性コンポーネントの保持を更新するには、advanced
設定セクションを追加します。以下の手順を実行します。
次のコマンドを使用して、
MultiClusterObservability
カスタムリソースを編集します。oc edit mco observability -o yaml
ファイルに
advanced
セクションを追加します。YAML ファイルは以下の内容のようになります。spec: advanced: retentionConfig: blockDuration: 2h deleteDelay: 48h retentionInLocal: 24h retentionResolutionRaw: 365d retentionResolution5m: 365d retentionResolution1h: 365d receive: resources: limits: memory: 4096Gi replicas: 3
注記:
-
advanced
設定に追加できるすべてのパラメーターの説明は、Observability API ドキュメントを参照してください。 -
すべての解像度レベル (
retentionResolutionRaw
、retentionResolution5m
、retentionResolution1h
など) のデフォルトの保持期間は 365 日 (365d
) です。MultiClusterObservability
spec.advanced.retentionConfig
パラメーターで、解像度保持の明示的な値を設定する必要があります。
-
以前のバージョンからアップグレードし、そのバージョン保持設定を保持する場合は、前述の設定を追加します。以下の手順を実行します。
次のコマンドを実行して、
MultiClusterObservability
リソースに移動します。edit mco observability
-
spec.advanced.retentionConfig
パラメーターで、次の設定を適用します。
spec: advanced: retentionConfig: retentionResolutionRaw: 365d retentionResolution5m: 365d retentionResolution1h: 365d
1.4.4. シングルノード OpenShift クラスターの動的メトリクス
動的メトリックコレクションは、特定の条件に基づく自動メトリック収集をサポートします。デフォルトでは、シングルノードの OpenShift クラスターは Pod およびコンテナーのリソースメトリクスを収集しません。シングルノードの OpenShift クラスターが特定のレベルのリソース消費に達すると、定義された詳細なメトリクスが動的に収集されます。クラスターリソースの消費量が一定期間しきい値を一貫して下回ると、詳細なメトリック収集が停止します。
メトリックは、コレクションルールで指定されたマネージドクラスターの状態に基づいて動的に収集されます。これらのメトリックは動的に収集されるため、以下の Red Hat Advanced Cluster Management Grafana ダッシュボードではデータは表示されません。コレクションルールがアクティブになり、対応するメトリックが収集されると、以下のパネルには、コレクションルールが開始される期間のデータが表示されます。
- Kubernetes/コンピューティングリソース/namespace (Pod)
- Kubernetes/コンピューティングリソース/namespace (ワークロード)
- Kubernetes/コンピューティングリソース/ノード (Pod)
- Kubernetes/コンピューティングリソース/Pod
- Kubernetes/コンピューティングリソース/ワークロード収集ルールには次の条件が含まれます。
- 動的に収集するメトリックのセット。
- PromQL 式として記述された条件。
-
コレクションの間隔。
true
に設定する必要があります。 - 収集ルールを評価する必要のあるクラスターを選択するための一致式。
デフォルトでは、コレクションルールは、30 秒ごとにマネージドクラスターで継続的に評価されるか、特定の間隔で評価されます。コレクションの間隔と時間間隔の最小値が優先されます。収集ルールの条件が for
属性で指定された期間持続すると、収集ルールが開始され、ルールで指定されたメトリクスがマネージドクラスターに自動的に収集されます。メトリクスの収集は、収集ルールの条件がマネージドクラスターに存在しなくなった後、開始してから少なくとも 15 分後に自動的に停止します。
収集ルールは、collect_rules
という名前のパラメーターセクションとしてグループ化され、グループとして有効または無効にできます。Red Hat Advanced Cluster Management インストールには、コレクションルールグループ (HighCPUUsage
および HighMemoryUsage
) のデフォルトコレクションルール SNOResourceUsage
が含まれます。HighCPUUsage
コレクションルールは、ノードの CPU 使用率が 70% を超えると開始されます。HighMemoryUsage
収集ルールは、シングルノード OpenShift クラスターの全体的なメモリー使用率が使用可能なノードメモリーの 70% を超えると開始されます。現在、上記のしきい値は固定されており、変更できません。コレクションルールが for
属性で指定された間隔を超えて開始すると、システムは dynamic_metrics
セクションに指定されたメトリックの収集を自動的に開始します。
以下の YAML ファイルで、collect_rules
セクションからの動的メトリックのリストを表示します。
collect_rules: - group: SNOResourceUsage annotations: description: > By default, a {sno} cluster does not collect pod and container resource metrics. Once a {sno} cluster reaches a level of resource consumption, these granular metrics are collected dynamically. When the cluster resource consumption is consistently less than the threshold for a period of time, collection of the granular metrics stops. selector: matchExpressions: - key: clusterType operator: In values: ["{sno}"] rules: - collect: SNOHighCPUUsage annotations: description: > Collects the dynamic metrics specified if the cluster cpu usage is constantly more than 70% for 2 minutes expr: (1 - avg(rate(node_cpu_seconds_total{mode=\"idle\"}[5m]))) * 100 > 70 for: 2m dynamic_metrics: names: - container_cpu_cfs_periods_total - container_cpu_cfs_throttled_periods_total - kube_pod_container_resource_limits - kube_pod_container_resource_requests - namespace_workload_pod:kube_pod_owner:relabel - node_namespace_pod_container:container_cpu_usage_seconds_total:sum_irate - node_namespace_pod_container:container_cpu_usage_seconds_total:sum_rate - collect: SNOHighMemoryUsage annotations: description: > Collects the dynamic metrics specified if the cluster memory usage is constantly more than 70% for 2 minutes expr: (1 - sum(:node_memory_MemAvailable_bytes:sum) / sum(kube_node_status_allocatable{resource=\"memory\"})) * 100 > 70 for: 2m dynamic_metrics: names: - kube_pod_container_resource_limits - kube_pod_container_resource_requests - namespace_workload_pod:kube_pod_owner:relabel matches: - __name__="container_memory_cache",container!="" - __name__="container_memory_rss",container!="" - __name__="container_memory_swap",container!="" - __name__="container_memory_working_set_bytes",container!=""
以下の例のように、collect_rules.group
は custom-allowlist
で無効にできます。collect_rules.group
を無効にすると、メトリックコレクションは以前の動作に戻ります。これらのメトリックは定期的に、指定された間隔で収集されます。
collect_rules: - group: -SNOResourceUsage
データは、ルールの開始時のみ Grafana に表示されます。
1.4.5. コンソールからの MultiClusterObservability カスタムリソースレプリカの更新
ワークロードが増加する場合は、可観測性 Pod のレプリカ数を増やします。ハブクラスターから Red Hat OpenShift Container Platform コンソールに移動します。MultiClusterObservability
カスタムリソースを見つけて、レプリカを変更するコンポーネントの replicas
パラメーター値を更新します。更新した YAML は以下のようになります。
spec: advanced: receive: replicas: 6
mco observability
カスタムリソース内のパラメーターの詳細は、可観測性 API ドキュメントを参照してください。
1.4.6. 永続ボリュームおよび永続ボリューム要求の増減
永続ボリュームと永続ボリューム要求を増減して、ストレージクラス内のストレージの量を変更します。以下の手順を実行します。
-
ストレージクラスがボリュームの拡張をサポートしている場合は、
MultiClusterObservability
カスタムリソースを更新して、永続ボリュームのサイズを増やします。 永続ボリュームのサイズを小さくするには、永続ボリュームを使用している Pod を削除し、永続ボリュームを削除して再作成します。永続ボリュームでデータが失われる可能性があります。以下の手順を実行します。
-
MultiClusterObservability
カスタムリソースにアノテーションmco-pause: "true"
を追加して、MultiClusterObservability
Operator を一時停止します。 目的のコンポーネントのステートフルセットまたはデプロイメントを探します。レプリカ数を
0
に変更します。これによりシャットダウンが開始され、データの損失を避けるために、該当する場合はローカルデータがアップロードされます。たとえば、ThanosReceive
ステートフルセットの名前はobservability-thanos-receive-default
で、デフォルトでは 3 つのレプリカがあります。したがって、次の永続ボリューム要求を探します。-
data-observability-thanos-receive-default-0
-
data-observability-thanos-receive-default-1
-
data-observability-thanos-receive-default-2
-
- 必要なコンポーネントによって使用される永続ボリュームおよび永続ボリューム要求を削除します。
-
MultiClusterObservability
カスタムリソースで、コンポーネントの設定のストレージサイズを、ストレージサイズフィールドで必要な量に編集します。接頭辞にはコンポーネントの名前が付いています。 -
以前に追加したアノテーションを削除して
MultiClusterObservability
Operator の一時停止を解除します。 -
Operator を一時停止した後に調整を開始するには、
multicluster-observability-operator
およびobservatorium-operator
Pod を削除します。Pod はすぐに再作成され、調整されます。
-
-
MultiClusterObservability
カスタムリソースをチェックして、永続ボリュームとボリューム要求が更新されていることを確認します。
1.4.7. ルート証明書のカスタマイズ
OpenShift Container Platform ルート認証をカスタマイズする場合は、ルートを alt_names
セクションに追加する必要があります。OpenShift Container Platform ルートにアクセスできるようにするには、alertmanager.apps.<domainname>
、observatorium-api.apps.<domainname>
、rbac-query-proxy.apps.<domainname>
の情報を追加します。
詳細は、ガバナンスドキュメントの alertmanager ルートの証明書の置き換え を参照してください。
注記: ユーザーは証明書のローテーションおよび更新を行います。
1.4.8. オブジェクトストアにアクセスするための証明書のカスタマイズ
認証局を含む Secret
リソースを作成し、MultiClusterObservability
カスタムリソースを設定することで、監視オブジェクトストアとの安全な接続を設定できます。以下の手順を実行します。
オブジェクトストア接続を検証するには、次のコマンドを使用して、認証局を含むファイルに
Secret
オブジェクトを作成します。oc create secret generic <tls_secret_name> --from-file=ca.crt=<path_to_file> -n open-cluster-management-observability
- あるいは、次の YAML を適用してシークレットを作成することもできます。
apiVersion: v1 kind: Secret metadata: name: <tls_secret_name> namespace: open-cluster-management-observability type: Opaque data: ca.crt: <base64_encoded_ca_certificate>
オプション: 相互 TLS を有効にする場合は、前のシークレットに
public.crt
キーとprivate.key
キーを追加する必要があります。次のコマンドを使用して、
metricObjectStorage
セクションに TLS シークレットの詳細を追加します。oc edit mco observability -o yaml
ファイルは次の YAML のようになります。
metricObjectStorage: key: thanos.yaml name: thanos-object-storage tlsSecretName: tls-certs-secret 1 tlsSecretMountPath: /etc/minio/certs 2
証明書の詳細を含む
http_config.tls_config
セクションを追加して、thanos-object-storage
シークレットのthanos.yaml
定義を更新します。以下の例を参照してください。thanos.yaml: | type: s3 config: bucket: "thanos" endpoint: "minio:9000" insecure: false 1 access_key: "minio" secret_key: "minio123" http_config: tls_config: ca_file: /etc/minio/certs/ca.crt 2 insecure_skip_verify: false
オプション: 相互 TLS を有効にする場合は、
tls_config
セクションにcert_file
キーとkey_file
キーを追加する必要があります。以下の例を参照してください。thanos.yaml: | type: s3 config: bucket: "thanos" endpoint: "minio:9000" insecure: false access_key: "minio" secret_key: "minio123" http_config: tls_config: ca_file: /etc/minio/certs/ca.crt 1 cert_file: /etc/minio/certs/public.crt key_file: /etc/minio/certs/private.key insecure_skip_verify: false
- 1
ca_file
、cert_file
、およびkey_file
のパスは、MultiClusterObservability
カスタムリソースのtlsSecretMountPath
と一致させる必要があります。ca.crt
、public.crt
、private.crt
は、tls_secret_name>
Secret
リソース内のそれぞれのキーと一致させる必要があります。
オブジェクトストアにアクセスできることを確認するには、Pod がデプロイされていることを確認します。以下のコマンドを実行します。
oc -n open-cluster-management-observability get pods -l app.kubernetes.io/name=thanos-store
1.4.9. 可観測性アドオンのプロキシー設定
マネージドクラスターからの通信が HTTP および HTTPS プロキシーサーバー経由でハブクラスターにアクセスできるようにプロキシー設定を指定します。通常、アドオンでは、ハブクラスターとマネージドクラスターの間で HTTP および HTTPS プロキシーサーバーをサポートする特別な設定は必要ありません。ただし、可観測性アドオンを有効にしている場合は、プロキシー設定を完了する必要があります。
1.4.10. 前提条件
- ハブクラスターがある。
- ハブクラスターとマネージドクラスター間のプロキシー設定が有効にしている。
可観測性アドオンのプロキシー設定を指定するには、以下の手順を実行します。
- ハブクラスターのクラスター namespace に移動します。
spec.proxyConfig
パラメーターを追加して、プロキシー設定を使用してAddOnDeploymentConfig
リソースを作成します。以下は、YAML の例です。apiVersion: addon.open-cluster-management.io/v1alpha1 kind: AddOnDeploymentConfig metadata: name: <addon-deploy-config-name> namespace: <managed-cluster-name> spec: agentInstallNamespace: open-cluster-managment-addon-observability proxyConfig: httpsProxy: "http://<username>:<password>@<ip>:<port>" 1 noProxy: ".cluster.local,.svc,172.30.0.1" 2
マネージドクラスターで IP アドレスを取得するには、以下のコマンドを実行します。
oc -n default describe svc kubernetes | grep IP:
ManagedClusterAddOn
リソースに移動し、作成したAddOnDeploymentConfig
リソースを参照して更新します。以下は、YAML の例です。apiVersion: addon.open-cluster-management.io/v1alpha1 kind: ManagedClusterAddOn metadata: name: observability-controller namespace: <managed-cluster-name> spec: installNamespace: open-cluster-managment-addon-observability configs: - group: addon.open-cluster-management.io resource: AddonDeploymentConfig name: <addon-deploy-config-name> namespace: <managed-cluster-name>
プロキシー設定を確認してください。プロキシー設定が正常に指定されている場合に、マネージドクラスター上の可観測性アドオンエージェントによってデプロイされたメトリックコレクターはデータをハブクラスターに送信します。以下の手順を実行します。
- ハブクラスターに移動し、Grafana ダッシュボードでマネージドクラスターに移動します。
- プロキシー設定のメトリクスを表示します。
1.4.11. 可観測性アドオンのプロキシー設定の無効化
開発に必要な変更がある場合は、ハブクラスターとマネージドクラスターに設定した可観測性アドオンのプロキシー設定を無効にすることが必要な場合があります。可観測性アドオンのプロキシー設定はいつでも無効にできます。以下の手順を実行します。
-
ManagedClusterAddOn
リソースに移動します。 -
参照される
AddOnDeploymentConfig
リソースを削除します。
1.4.12. マネージドクラスター Observatorium API と Alertmanager URL のカスタマイズ (テクノロジープレビュー)
ロードバランサーまたはリザーブプロキシーを使用するときに、マネージドクラスターがハブクラスターとの通信に使用する Observatorium API および Alertmanager URL をカスタマイズして、すべての Red Hat Advanced Cluster Management 機能を維持できます。URL をカスタマイズするには、次の手順を実行します。
-
MultiClusterObservability
spec
のadvanced
セクションに URL を追加します。以下の例を参照してください。
spec: advanced: customObservabilityHubURL: <yourURL> customAlertmanagerHubURL: <yourURL>
注記:
-
HTTPS URL のみがサポートされます。URL に
https://
を追加しない場合、スキームは自動的に追加されます。 -
customObservabilityHubURL
spec
に、リモート書き込み API の標準パス/api/metrics/v1/default/api/v1/receive
を含めることができます。パスを含めない場合、Observability サービスは実行時にパスを自動的に追加します。 カスタム Observability ハブクラスター URL に使用する中間コンポーネントは MTLS 認証に依存しているため、TLS 終端を使用できません。カスタム Alertmanager ハブクラスター URL は、独自の既存の証明書手順を使用して中間コンポーネントの TLS 終端をサポートします。
-
customObservabilityHubURL
を使用している場合は、次のテンプレートを使用してルートオブジェクトを作成します。<intermediate_component_url>
を中間コンポーネントの URL に置き換えます。
-
apiVersion: route.openshift.io/v1 kind: Route metadata: name: proxy-observatorium-api namespace: open-cluster-management-observability spec: host: <intermediate_component_url> port: targetPort: public tls: insecureEdgeTerminationPolicy: None termination: passthrough to: kind: Service name: observability-observatorium-api weight: 100 wildcardPolicy: None
-
customAlertmanagerHubURL
を使用している場合は、次のテンプレートを使用してルートオブジェクトを作成します。<intermediate_component_url>
を中間コンポーネントの URL に置き換えます。
apiVersion: route.openshift.io/v1 kind: Route metadata: name: alertmanager-proxy namespace: open-cluster-management-observability spec: host: <intermediate_component_url> path: /api/v2 port: targetPort: oauth-proxy tls: insecureEdgeTerminationPolicy: Redirect termination: reencrypt to: kind: Service name: alertmanager weight: 100 wildcardPolicy: None
1.4.13. 詳細な RBAC の設定 (テクノロジープレビュー)
クラスター内の特定 namespace へのメトリクスアクセスを制限するには、詳細なロールベースアクセス制御 (RBAC) を使用します。詳細な RBAC を使用すると、アクセス権が付与された namespace のメトリクスのみの表示をアプリケーションチームに許可することができます。
ハブクラスターのユーザーのメトリクスアクセス制御は、ハブクラスター上で設定する必要があります。このハブクラスターでは、ManagedCluster
カスタムリソースによってすべてのマネージドクラスターが表されます。RBAC を設定し、許可する namespace を選択するには、ManagedCluster
カスタムリソースで指定されているルールとアクション動詞を使用します。
たとえば、my-awesome-app
という名前のアプリケーションがあり、このアプリケーションが devcluster1
と devcluster2
という 2 つの異なるマネージドクラスター上にあるとします。どちらのクラスターも AwesomeAppNS
namespace にあります。my-awesome-app-admins
という名前の admin
ユーザーグループがあり、このユーザーグループが、ハブクラスター上のこれら 2 つの namespace からのメトリクスにのみアクセスできるように制限するとします。
この例では、詳細な RBAC を使用してユーザーグループのアクセスを制限するために、次の手順を実行します。
メトリクスにアクセスする権限を持つ
ClusterRole
リソースを定義します。リソースは次の YAML のようになります。apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: awesome-app-metrics-role rules: - apiGroups: - "cluster.open-cluster-management.io" resources: - managedclusters: 1 resourceNames: 2 - devcluster1 - devcluster2 verbs: 3 - metrics/AwesomeAppNS
グループ
my-awesome-app-admins
をawesome-app-metrics-role
のClusterRole
リソースにバインドするClusterRoleBinding
リソースを定義します。リソースは次の YAML のようになります。kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: awesome-app-metrics-role-binding subjects: - kind: Group apiGroup: rbac.authorization.k8s.io name: my-awesome-app-admins roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: awesome-app-metrics-role
これらの手順を完了すると、my-awesome-app-admins
のユーザーが Grafana コンソールにログインするときに、次の制限が適用されます。
- フリートレベルのデータを要約したダッシュボードのデータがユーザーに表示されません。
-
ユーザーは、
ClusterRole
リソースで指定されているマネージドクラスターと namespace のみを選択できます。
異なるタイプのユーザーアクセスを設定するには、namespace 内の異なるマネージドクラスターを表す個別の ClusterRoles
および ClusterRoleBindings
リソースを定義します。
1.4.14. 関連情報
- 詳細は、Prometheus の設定 を参照してください。記録ルールとアラートルールの詳細は、Prometheus ドキュメント の記録ルールとアラートルールを参照してください。
- ダッシュボードの表示の詳細は、Grafana ダッシュボードの使用 を参照してください。
- 外部エンドポイントへのメトリクスのエクスポート を参照してください。
- ユーザー定義プロジェクトのモニタリングの有効化 を参照してください。
- 可観測性 API を参照してください。
- alertmanager ルートの証明書の更新に関する詳細は、alertmanager の 証明書の置き換え を参照してください。
- 可観測性アラートの詳細は、可観測性アラート を参照してください。
- アラート転送の詳細は、Prometheus Alertmanager ドキュメント を参照してください。
- 詳細は、可観測性アラート を参照してください。
- 可観測性サービスに関する詳細なトピックは、可観測性サービス を参照してください。
- 詳細は、管理ワークロードのパーティショニング を参照してください。