1.4. 可観測性のカスタマイズ
可観測性サービスが収集するデータのカスタマイズ、管理、および表示については、以下のセクションを参照してください。
must-gather
コマンドで可観測性リソース用に作成される新規情報についてのログを収集します。詳細は、トラブルシューティング ドキュメントの Must-gather セクションを参照してください。
1.4.1. カスタムルールの作成
可観測性リソースに、Prometheus レコードルール および アラートルール を追加して、可観測性インストールのカスタムルールを作成します。詳細は、Prometheus configuration を参照してください。
- レコードルールでは、必要に応じてコストの掛かる式を事前に計算するか、コンピュートできます。結果は新たな時系列のセットとして保存されます。
- アラートルールでは、アラートを外部サービスに送信する方法に基づいてアラート条件を指定する機能を提供します。
Prometheus でカスタムルールを定義してアラート条件を作成し、通知を外部メッセージングサービスに送信します。注記: カスタムルールを更新すると、observability-thanos-rule
Pod は自動的に再起動されます。
open-cluster-management-observability
namespace に thanos-ruler-custom-rules
という名前の ConfigMap を作成します。以下の例のように、キーは custom_rules.yaml
という名前を指定する必要があります。設定には、複数のルールを作成できます。
デフォルトでは、同梱のアラートルールは
open-cluster-management-observability
namespace のthanos-ruler-default-rules
ConfigMap に定義されます。たとえば、CPU の使用状況が定義値を超えた場合に通知するカスタムのアラートルールを作成できます。YAML の内容は以下のようになります。
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
thanos-ruler-custom-rules
ConfigMap 内にカスタムの録画ルールを作成することもできます。たとえば、Pod のコンテナーメモリーキャッシュの合計を取得できるようにする記録ルールを作成することができます。YAML の内容は以下のようになります。
data: custom_rules.yaml: | groups: - name: container-memory recording_rules: - record: pod:container_memory_cache:sum expr: sum(container_memory_cache{pod!=""}) BY (pod, container)
注記: これが最初の新規カスタムルールである場合には、すぐに作成されます。ConfigMap に変更が加えられると、設定は自動的に再読み込みされます。この設定は、
observability-thanos-ruler
サイドカー内のconfig-reload
により再読み込みされます。
アラートルールが適切に機能していることを確認するには、Grafana ダッシュボードを起動し、Explore ページに移動し、ALERTS
にクエリーを実行します。アラートは、アラートが開始された場合に Grafana でのみ利用できます。
1.4.2. AlertManager の設定
メール、Slack、PagerDuty などの外部メッセージングツールを統合し、AlertManager から通知を受信します。open-cluster-management-observability
namespace で alertmanager-config
シークレットを上書きして、統合を追加し、AlertManager のルートを設定します。以下の手順を実行して、カスタムのレシーバールールを更新します。
alertmanager-config
シークレットからデータを抽出します。以下のコマンドを実行します。oc -n open-cluster-management-observability get secret alertmanager-config --template='{{ index .data "alertmanager.yaml" }}' |base64 -d > alertmanager.yaml
以下のコマンドを実行し、
alertmanager.yaml
ファイル設定を編集して保存します。oc -n open-cluster-management-observability create secret generic alertmanager-config --from-file=alertmanager.yaml --dry-run -o=yaml | oc -n open-cluster-management-observability replace secret --filename=-
更新したシークレットは以下の内容のようになります。
global smtp_smarthost: 'localhost:25' smtp_from: 'alertmanager@example.org' smtp_auth_username: 'alertmanager' smtp_auth_password: 'password' templates: - '/etc/alertmanager/template/*.tmpl' route: group_by: ['alertname', 'cluster', 'service'] group_wait: 30s group_interval: 5m repeat_interval: 3h receiver: team-X-mails routes: - match_re: service: ^(foo1|foo2|baz)$ receiver: team-X-mails
変更内容は、変更後すぐに適用されます。AlertManager の例については、prometheus/alertmanager を参照してください。
1.4.3. カスタムメトリクスの追加
metrics_list.yaml
ファイルにメトリクスを追加して、マネージドクラスターから収集されるようにします。
カスタムメトリクスを追加する前に、oc get mco observability -o yaml
コマンドで、mco observability
が有効になっていることを確認します。status.conditions.message
の メッセージが Observability components are deployed and running
となっていることを確認します。
observability-metrics-custom-allowlist.yaml
という名前のファイルを作成し、metrics_list.yaml
パラメーターにカスタムメトリックの名前を追加します。ConfigMap の YAML は、以下の内容のようになります。
kind: ConfigMap apiVersion: v1 metadata: name: observability-metrics-custom-allowlist data: metrics_list.yaml: | names: - node_memory_MemTotal_bytes rules: - 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))
-
names
セクションで、マネージドクラスターから収集されるカスタムメトリクスの名前を追加します。 -
rules
セクションで、パラメーターペアexpr
とrecord
に値を 1 つだけ入力し、クエリー式を定義します。メトリクスは、マネージドクラスターのrecord
パラメーターで定義される名前で収集されます。クエリー式の実行後の結果が、メトリックの値として返されます。 -
names
とrules
セクションはオプションです。セクションのいずれかまたは両方を使用できます。
oc apply -n open-cluster-management-observability -f observability-metrics-custom-allowlist.yaml
のコマンドで、open-cluster-management-observability
namespace に observability-metrics-custom-allowlist
ConfigMap を作成します。
Grafana ダッシュボードから Explore ページからメトリックをクエリーし、カスタムメトリックからのデータが収集されていることを確認します。独自のダッシュボードでカスタムメトリクスを使用することもできます。ダッシュボードの表示に関する詳細は、Grafana ダッシュボードの設計 を参照してください。
1.4.4. デフォルトメトリクスの削除
マネージドクラスターで特定のメトリック用にデータを収集しない場合は、observability-metrics-custom-allowlist.yaml
ファイルからメトリックを削除します。メトリックを削除すると、メトリックデータはマネージドクラスターでは収集されません。前述したように、mco observability
が有効になっていることを確認します。
メトリック名の先頭にハイフン -
を指定して metrics_list.yaml
パラメーターにデフォルトのメトリック名を追加します。例: -cluster_infrastructure_provider
oc apply -n open-cluster-management-observability -f observability-metrics-custom-allowlist.yaml
のコマンドで、open-cluster-management-observability
namespace に observability-metrics-custom-allowlist
ConfigMap を作成します。
特定のメトリックがマネージドクラスターから収集されていないことを確認します。Grafana ダッシュボードからメトリックをクエリーしても、メトリックは表示されません。
1.4.5. 外部エンドポイントへのメトリックのエクスポート
可観測性をカスタマイズして、Prometheus Remote Write プロトコルをリアルタイムでサポートする外部エンドポイントにメトリックをエクスポートできます。詳細は、Prometheus Remote Write プロトコル を参照してください。
1.4.5.1. 外部エンドポイントの Kubernetes シークレットの作成
open-cluster-management-observability
namespace の外部エンドポイントのアクセス情報を使用して Kubernetes シークレットを作成する必要があります。次のシークレットの例を表示します。
apiVersion: v1 kind: Secret metadata: name: victoriametrics namespace: open-cluster-management-observability type: Opaque stringData: ep.yaml: | url: http://victoriametrics:8428/api/v1/write http_client_config: basic_auth: username: test password: test
ep.yaml
はコンテンツのキーであり、次のステップの multiclusterobservability
CR で使用されます。現在、可観測性は、セキュリティーチェックなし、基本認証、または tls
の有効化を使用して、エンドポイントへのメトリックのエクスポートをサポートしています。サポートされているパラメーターの完全なリストについては、次の表を参照してください。
名前 | 説明 | スキーマ |
---|---|---|
url | 外部エンドポイントの URL。 | string |
http_client_config | HTTP クライアントの高度な設定。 |
HttpClientConfig
名前 | 説明 | スキーマ |
---|---|---|
basic_auth | 基本認証用の HTTP クライアント設定。 | |
tls_config | TLS の HTTP クライアント設定。 |
BasicAuth
名前 | 説明 | スキーマ |
---|---|---|
username | 基本認証のユーザー名。 | string |
password | 基本認証用のパスワード。 | string |
TLSConfig
名前 | 説明 | スキーマ |
secret_name | 証明書を含むシークレットの名前。 | string |
ca_file_key | シークレットの CA 証明書のキー (insecure_skip_verify が true に設定されている場合のみオプション)。 | string |
cert_file_key | シークレット内のクライアント証明書のキー。 | string |
key_file_key | シークレットのクライアントキーのキー。 | string |
insecure_skip_verify | ターゲット証明書の検証をスキップするパラメーター。 | ブール型 |
1.4.5.2. MultiClusterObservability CR の更新
Kubernetes シークレットを作成した後、multiclusterobservability
CR を更新して、spec.storageConfig
パラメーターに writeStorage
を追加する必要があります。以下の例を参照してください。
spec: storageConfig: writeStorage: - key: ep.yaml name: victoriametrics
writeStorage
の値はリストです。メトリクスを 1 つの外部エンドポイントにエクスポートする場合は、リストにアイテムを追加できます。リストに複数のアイテムを追加すると、メトリクスは複数の外部エンドポイントにエクスポートされます。各アイテムには、name と key の 2 つの属性が含まれています。Name は、エンドポイントアクセス情報を含む Kubernetes シークレットの名前であり、key はシークレット内のコンテンツのキーです。次の説明表を参照してください
1.4.5.3. メトリックエクスポートのステータスの表示
メトリクスのエクスポートを有効にした後、acm_remote_write_requests_total
メトリクスをチェックすることにより、メトリクスのエクスポートのステータスを表示できます。ハブクラスターの OpenShift コンソールから、Observe セクションの Metrics をクリックして、Metrics ページに移動します。
次に、acm_remote_write_requests_total
メトリックをクエリーします。そのメトリックの値は、1 つの observatorium API インスタンスで、1 つの外部エンドポイントに対する特定の応答を持つリクエストの総数です。name
ラベルは、外部エンドポイントの名前です。code
ラベルは、メトリクスエクスポートの HTTP リクエストのリターンコードです。
1.4.6. 詳細 設定の追加
advanced
設定セクションを追加して、必要に応じて可観測性コンポーネントごとに保持内容を更新します。
MultiClusterObservability
CR を編集し、oc edit mco observability -o yaml
コマンドで advanced
セクションを追加します。YAML ファイルは以下の内容のようになります。
spec: advanced: retentionConfig: blockDuration: 2h deleteDelay: 48h retentionInLocal: 24h retentionResolutionRaw: 30d retentionResolution5m: 180d retentionResolution1h: 0d receive: resources: limits: memory: 4096Gi replicas: 3
advanced
設定に追加できるすべてのパラメーターの説明は、Observability API を参照してください。
1.4.7. コンソールからの multiclusterobservability CR レプリカの更新
ワークロードが増加する場合は、可観測性 Pod のレプリカ数を増やします。ハブクラスターから Red Hat OpenShift Container Platform コンソールに移動します。multiclusterobservability
カスタムリソース (CR) を見つけ、レプリカを変更するコンポーネントの replicas
パラメーターの値を更新します。更新した YAML は以下のようになります。
spec: advanced: receive: replicas: 6
observability
CR 内のパラメーターの詳細は、Observability API を参照してください。
1.4.8. アラートの転送
可観測性を有効にした後には、OpenShift Container Platform マネージドクラスターからのアラートは自動的にハブクラスターに送信されます。alertmanager-config
YAML ファイルを使用して、外部通知システムでアラートを設定できます。
alertmanager-config
YAML ファイルの例を以下に示します。
global: slack_api_url: '<slack_webhook_url>' route: receiver: 'slack-notifications' group_by: [alertname, datacenter, app] receivers: - name: 'slack-notifications' slack_configs: - channel: '#alerts' text: 'https://internal.myorg.net/wiki/alerts/{{ .GroupLabels.app }}/{{ .GroupLabels.alertname }}'
アラート転送用のプロキシーを設定する場合は、alertmanager-config
YAML ファイルに次の global
エントリーを追加します。
global: slack_api_url: '<slack_webhook_url>' http_config: proxy_url: http://****
詳細は、Prometheus Alertmanager のドキュメント を参照してください。
1.4.8.1. マネージドクラスターの転送アラートの無効化
マネージドクラスターのアラート転送を無効にします。次のアノテーションを MultiClusterObservability
カスタムリソースに追加します。
metadata: annotations: mco-disable-alerting: "true"
アノテーションを設定すると、マネージドクラスターのアラート転送設定が元に戻ります。openshift-monitoring
namespace の ocp-monitoring-config
ConfigMap に加えられた変更は元に戻ります。アノテーションを設定すると、ocp-monitoring-config
ConfigMap が可観測性オペレーターのエンドポイントによって管理または更新されなくなります。設定を更新すると、マネージドクラスターの Prometheus インスタンスが再起動します。
重要: メトリック用の永続ボリュームを持つ Prometheus インスタンスがある場合、マネージドクラスターのメトリックは失われ、Prometheus インスタンスが再起動されます。ただし、ハブクラスターからのメトリックは影響を受けません。
変更が元に戻ると、cluster-monitoring-reverted
という名前の ConfigMap が open-cluster-management-addon-observability
namespace に作成されます。手動で追加された新しいアラート転送設定は、ConfigMap から元に戻りません。
ハブクラスターアラートマネージャーがマネージドクラスターアラートをサードパーティーのメッセージングツールに伝達していないことを確認します。前のセクション AlertManager の設定 を参照してください。
1.4.9. アラートをサイレントにする
受信したくないアラートを追加します。アラート名、一致ラベル、または期間によってアラートをサイレントにすることができます。サイレントにしたいアラートを追加すると、ID が作成されます。サイレントにしたアラートの ID は、文字列 d839aca9-ed46-40be-84c4-dca8773671da
のようになります。
アラートをサイレントにする方法は、引き続きお読みください。
Red Hat Advanced Cluster Management アラートをサイレントにするには、
open-cluster-management-observability
namespace のalertmanager-main
Pod にアクセスできる必要があります。たとえば、Pod ターミナルに次のコマンドを入力して、SampleAlert
をサイレントにします。amtool silence add --alertmanager.url="http://localhost:9093" --author="user" --comment="Silencing sample alert" alertname="SampleAlert"
複数の一致ラベルを使用してアラートをサイレントにします。次のコマンドは
match-label-1
とmatch-label-2
を使用します。amtool silence add --alertmanager.url="http://localhost:9093" --author="user" --comment="Silencing sample alert" <match-label-1>=<match-value-1> <match-label-2>=<match-value-2>
特定の期間アラートをサイレントにする場合は、
--duration
フラグを使用します。次のコマンドを実行して、SampleAlert
を 1 時間サイレントにします。amtool silence add --alertmanager.url="http://localhost:9093" --author="user" --comment="Silencing sample alert" --duration="1h" alertname="SampleAlert"
消音アラートの開始時刻または終了時刻を指定することもできます。次のコマンドを入力して、特定の開始時刻に
SampleAlert
をサイレントにします。amtool silence add --alertmanager.url="http://localhost:9093" --author="user" --comment="Silencing sample alert" --start="2023-04-14T15:04:05-07:00" alertname="SampleAlert"
作成されたサイレント化されたアラートをすべて表示するには、次のコマンドを実行します。
amtool silence --alertmanager.url="http://localhost:9093"
アラートをサイレントにしたくない場合は、次のコマンドを実行してアラートのサイレントを終了します。
amtool silence expire --alertmanager.url="http://localhost:9093" "d839aca9-ed46-40be-84c4-dca8773671da"
すべてのアラートをサイレントにするのを終了するには、次のコマンドを実行します。
amtool silence expire --alertmanager.url="http://localhost:9093" $(amtool silence query --alertmanager.url="http://localhost:9093" -q)
1.4.10. アラートの抑制
重大度の低い Red Hat Advanced Cluster Management アラートをクラスター全体でグローバルに抑制します。アラートを抑制するには、open-cluster-management-observability
namespace の alertmanager-config
で抑制ルールを定義します。
抑制ルールは、既存のマッチャーの別のセットと一致する一連のパラメーター一致がある場合にアラートをミュートします。ルールを有効にするには、ターゲットアラートとソースアラートの両方で、equal
リスト内のラベル名のラベル値が同じである必要があります。Inhibit_rules
は次のようになります。
global: resolve_timeout: 1h inhibit_rules:1 - equal: - namespace source_match:2 severity: critical target_match_re: severity: warning|info
- 1
hibit_rules
パラメーターセクションは、同じ namespace のアラートを検索するために定義されています。critical
アラートがネームスペース内で開始し、その namespace に重大度レベルのwarning
またはinfo
を含む他のアラートがある場合は、critical
アラートのみが AlertManager レシーバーにルーティングされます。一致するものがあった場合、次のアラートが表示される場合があります。ALERTS{alertname="foo", namespace="ns-1", severity="critical"} ALERTS{alertname="foo", namespace="ns-1", severity="warning"}
- 2
source_match
パラメーターとtarget_match_re
パラメーターの値が一致しない場合、アラートはレシーバーにルーティングされます。ALERTS{alertname="foo", namespace="ns-1", severity="critical"} ALERTS{alertname="foo", namespace="ns-2", severity="warning"}
Red Hat Advanced Cluster Management で抑制されたアラートを表示するには、次のコマンドを入力します。
amtool alert --alertmanager.url="http://localhost:9093" --inhibited
1.4.11. ルート認定のカスタマイズ
OpenShift Container Platform ルート認証をカスタマイズする場合は、ルートを alt_names
セクションに追加する必要があります。OpenShift Container Platform ルートにアクセスできるようにするには、alertmanager.apps.<domainname>
、observatorium-api.apps.<domainname>
、rbac-query-proxy.apps.<domainname>
の情報を追加します。
注記: ユーザーは証明書のローテーションおよび更新を行います。
1.4.11.1. オブジェクトストアにアクセスするための証明書のカスタマイズ
オブジェクトストアにアクセスするための証明書をカスタマイズできます。オブジェクトストアシークレットに証明書を追加して、http_config
セクションを編集します。以下の例を参照してください。
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 insecure_skip_verify: false
open-cluster-management-observability
namespace にシークレットを指定する必要があります。シークレットには、前のシークレットの例で定義した ca.crt
が含まれている必要があります。相互 TLS を有効にする場合は、前のシークレットで public.crt
および private.key
を提供する必要があります。以下の例を参照してください。
thanos.yaml: | type: s3 config: ... http_config: tls_config: ca_file: /etc/minio/certs/ca.crt cert_file: /etc/minio/certs/public.crt key_file: /etc/minio/certs/private.key insecure_skip_verify: false
MultiClusterObservability
CR でシークレット名、TLSSecretName
パラメーターを設定することもできます。シークレット名が tls-certs-secret
である次の例を表示します。
metricObjectStorage: key: thanos.yaml name: thanos-object-storage tlsSecretName: tls-certs-secret
このシークレットは、オブジェクトストアにアクセスする必要のあるすべてのコンポーネントにマウントでき、次のコンポーネントが含まれます: receiver
、store
、ruler
、compact
。
1.4.12. データの表示および展開
ハブクラスターから Grafana にアクセスして、マネージドクラスターからデータを表示します。特定のアラートを照会して、そのクエリーのフィルターを追加できます。
たとえば、単一ノードクラスターから cluster_infrastructure_provider をクエリーするには、以下のクエリー式 cluster_infrastructure_provider{clusterType="SNO"}
を使用します。
注記: 単一ノードのマネージドクラスターで可観測性が有効になっている場合は、ObservabilitySpec.resources.CPU.limits
パラメーターを設定しないでください。CPU 制限を設定すると、可観測性 Pod がマネージドクラスターの容量にカウントされます。詳細は、管理ワークロードのパーティショニング を参照してください。
1.4.12.1. etcd テーブルの表示
Grafana のハブクラスターダッシュボードから etcd テーブルを表示し、データストアとしての etcd の安定性を確認します。
ハブクラスターから Grafana リンクを選択して、ハブクラスターから収集された etcd テーブルデータを表示します。マネージドクラスターの Leader election changes が表示されます。
1.4.12.2. Kubernetes API サーバーダッシュボードのクラスターフリートサービスレベルの概要の表示
Grafana のハブクラスターダッシュボードから、Kubernetes API サービスレベルの概要を表示します。
Grafana ダッシュボードに移動した後に、Kubernetes > Service-Level Overview > API Server を選択して管理ダッシュボードメニューにアクセスします。Fleet Overview および Top Cluster の詳細が表示されます。
過去 7 日間または 30 日間のターゲットとする サービスレベル目標 (SLO) 値を超えるか、満たしているクラスターの合計数、オフラインクラスター、および API サーバー要求の期間を表示します。
1.4.12.3. Kubernetes API サーバーダッシュボードのクラスターサービスレベルの概要の表示
Grafana のハブクラスターダッシュボードから Kubernetes API サービスレベルの概要テーブルを表示します。
Grafana ダッシュボードに移動した後に、Kubernetes > Service-Level Overview > API Server を選択して管理ダッシュボードメニューにアクセスします。Fleet Overview および Top Cluster の詳細が表示されます。
過去 7 日間または 30 日間のエラーとなっている予算、残りのダウンタイム、および傾向を表示します。
1.4.13. 可観測性の無効化
可観測性を無効にして、Red Hat Advanced Cluster Management ハブクラスターでデータ収集を停止します。
1.4.13.1. すべてのクラスターで可観測性を無効にする
すべてのマネージドクラスターで可観測性コンポーネントを削除して、可観測性を無効にします。
enableMetrics
を false
に設定して、multicluster-observability-operator
リソースを更新します。更新されたリソースは、以下のような変更内容になります。
spec: imagePullPolicy: Always imagePullSecret: multiclusterhub-operator-pull-secret observabilityAddonSpec: # The ObservabilityAddonSpec defines the global settings for all managed clusters which have observability add-on enabled enableMetrics: false #indicates the observability addon push metrics to hub server
1.4.13.2. 単一クラスターで可観測性を無効にする
特定のマネージドクラスターの可観測性コンポーネントを削除して可観測性を無効にします。managedclusters.cluster.open-cluster-management.io
のカスタムリソースに observability: disabled
ラベルを追加します。
Red Hat Advanced Cluster Management コンソールの Clusters ページから、指定したクラスターに observability=disabled
ラベルを追加します。
注記: 可観測性コンポーネントが含まれるマネージドクラスターをデタッチすると、metrics-collector
デプロイメントが削除されます。
可観測性サービスを使用したコンソールでのデータの監視に関する詳細は、環境の監視の紹介 を参照してください。