This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.モニタリング
OpenShift Container Platform でのモニタリングスタックの設定および使用
概要
第1章 クラスターモニタリング リンクのコピーリンクがクリップボードにコピーされました!
1.1. クラスターモニタリングについて リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform には、Prometheus オープンソースプロジェクトおよびその幅広いエコシステムをベースとする事前に設定され、事前にインストールされた自己更新型のモニタリングスタックが同梱されます。これはクラスターのモニタリング機能を提供し、クラスター管理者に問題の発生を即時に通知するアラートのセットと Grafana ダッシュボードのセットを提供します。クラスターモニタリングスタックは、OpenShift Container Platform クラスターのモニタリング用のみにサポートされています。
今後の OpenShift Container Platform の更新との互換性を確保するために、指定されたモニタリングスタックのオプションのみを設定することがサポートされます。
1.1.1. スタックコンポーネントおよびモニタリングターゲット リンクのコピーリンクがクリップボードにコピーされました!
モニタリングスタックには、以下の 3 つのコンポーネントが含まれます。
コンポーネント | 説明 |
---|---|
クラスターモニタリング Operator | OpenShift Container Platform クラスターモニタリング Operator (CMO) は、スタックの中心的なコンポーネントです。これは、デプロイされたモニタリングコンポーネントおよびリソースを制御し、それらを最新の状態に保ちます。 |
Prometheus Operator | Prometheus Operator (PO) は、Prometheus および Alertmanager インスタンスを作成し、設定し、管理します。また、Kubernetes ラベルのクエリーに基づいてモニタリングターゲットの設定を自動生成します。 |
Prometheus | Prometheus は、システムおよびサービスのモニタリングシステムであり、モニタリングスタックのベースとなります。 |
Prometheus アダプター | Prometheus アダプターは、Horizontal Pod Autoscaling のクラスターリソースメトリクス API を公開します。リソースメトリクスは CPU およびメモリーの使用率です。 |
Alertmanager 0.14.0 | Alertmanager サービスは、Prometheus によって送信されるアラートを処理します。 |
|
|
|
OpenShift Container Platform 固有のリソースのメトリクスを追加すると、 |
|
|
Thanos Querier | Thanos Querier は集約を有効にし、オプションで単一のマルチテナントインターフェイスでのクラスターおよびユーザーワークロードのメトリクスの重複を除去します。 |
Grafana | Grafana 解析プラットフォームは、メトリクスの分析および可視化のためのダッシュボードを提供します。モニタリングスタックおよびダッシュボードと共に提供される Grafana インスタンスは読み取り専用です。 |
モニターリグスタックのすべてのコンポーネントはスタックによってモニターされ、OpenShift Container Platform の更新時に自動的に更新されます。
スタック自体のコンポーネントに加え、モニタリングスタックは以下をモニターします。
- CoreDNS
- Elasticsearch(ロギングがインストールされている場合)
- etcd
- Fluentd(ロギングがインストールされている場合)
- HAProxy
- イメージレジストリー
- Kubelets
- Kubernetes apiserver
- Kubernetes controller manager
- Kubernetes スケジューラー
- Metering(メータリングがインストールされている場合)
- OpenShift apiserver
- OpenShift コントロールマネージャー
- Operator Lifecycle Manager (OLM)
- Telemeter クライアント
各 OpenShift Container Platform コンポーネントはそれぞれのモニタリング設定を行います。コンポーネントのモニタリングについての問題は、Bugzilla で一般的なモニタリングコンポーネントではなく、該当するコンポーネントに対してバグを報告してください。
他の OpenShift Container Platform フレームワークのコンポーネントもメトリクスを公開する場合があります。詳細については、それぞれのドキュメントを参照してください。
1.1.2. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
1.2. モニタリングスタックの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4 よりも前のバージョンでは、 Prometheus クラスターモニタリングスタックは Ansible インベントリーファイルで設定されていました。そのため、スタックは利用可能な設定オプションのサブセットを Ansible 変数として公開し、スタックは OpenShift Container Platform のインストール前に設定していました。
OpenShift Container Platform 4 では、Ansible は OpenShift Container Platform をインストールするのに使用される主要なテクノロジーではなくなりました。インストールプログラムは、インストールの前に大幅に限定された設定オプションのみを提供します。ほとんどの OpenShift フレームワークコンポーネント (Prometheus クラスターモニタリングスタックを含む) の設定はインストール後に行われます。
このセクションでは、サポートされている設定内容を説明し、モニタリングスタックの設定方法を示し、いくつかの一般的な設定シナリオを示します。
1.2.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- モニタリングスタックには、追加のリソース要件があります。詳細は、Cluster Monitoring Operator のスケーリング を参照し、十分なリソースがあることを確認してください。
1.2.2. メンテナーンスとサポート リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform モニタリングの設定は、本書で説明されているオプションを使用して行う方法がサポートされている方法です。サポートされていない他の設定は使用しないでください。設定のパラダイムが Prometheus リリース間で変更される可能性があり、このような変更には、設定のすべての可能性が制御されている場合のみ適切に対応できます。本セクションで説明されている設定以外の設定を使用する場合、cluster-monitoring-operator が差分を調整するため、変更内容は失われます。Operator はデフォルトで定義された状態へすべてを元に戻します。
明示的にサポート対象外とされているケースには、以下が含まれます。
-
追加の
ServiceMonitor
オブジェクトをopenshift-*
namespace に作成する。これにより、クラスターモニタリング Prometheus インスタンスの収集ターゲットが拡張されます。これは、対応不可能な競合および負荷の差異を生じさせる可能性があるため、Prometheus のセットアップが不安定になる可能性があります。 -
予期しない
ConfigMap
オブジェクトまたはPrometheusRule
オブジェクトの作成。これにより、クラスターモニタリング Prometheus インスタンスに追加のアラートおよび記録ルールが組み込まれます。 - スタックのリソースの変更。Prometheus Monitoring Stack スタックは、そのリソースが常に期待される状態にあることを確認します。これらが変更される場合、スタックはこれらをリセットします。
- 目的に合わせてスタックのリソースを使用する。Prometheus クラスターモニタリングスタックによって作成されるリソースは、後方互換性の保証がないために他のリソースで使用されることは意図されていません。
- クラスターモニタリング Operator によるモニタリングスタックの調整を停止する。
- 新規アラートルールの追加。
- モニタリングスタック Grafana インスタンスの変更。
1.2.3. クラスターモニタリング設定マップの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform モニタリングスタックを設定するには、クラスターモニタリングの ConfigMap
を作成する必要があります。
前提条件
- cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
-
OpenShift CLI (
oc
) がインストールされている。
手順
cluster-monitoring-config
ConfigMap
オブジェクトが存在するかどうかを確認します。oc -n openshift-monitoring get configmap cluster-monitoring-config
$ oc -n openshift-monitoring get configmap cluster-monitoring-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ConfigMap
オブジェクトが存在しない場合:以下の YAML マニフェストを作成します。以下の例では、このファイルは
cluster-monitoring-config.yaml
という名前です。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定を適用して
ConfigMap
を作成します。oc apply -f cluster-monitoring-config.yaml
$ oc apply -f cluster-monitoring-config.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.2.4. クラスターモニタリングスタックの設定 リンクのコピーリンクがクリップボードにコピーされました!
設定マップを使用して Prometheus クラスターモニタリングスタックを設定することができます。設定マップはクラスターモニタリング Operator を設定し、その後にスタックのコンポーネントが設定されます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできます。 - OpenShift CLI (oc) がインストールされている。
-
cluster-monitoring-config
ConfigMap
オブジェクトを作成している。
手順
cluster-monitoring-config
ConfigMap
オブジェクトの編集を開始します。oc -n openshift-monitoring edit configmap cluster-monitoring-config
$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定を、
data/config.yaml
の下に値とキーのペア<component_name>: <component_configuration>
として配置します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow <component>
および<configuration_for_the_component>
を随時置き換えます。たとえば、Prometheus の永続ボリューム要求 (PVC) を設定するために、この
ConfigMap
オブジェクトを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、prometheusK8s は Prometheus コンポーネントを定義し、続く行ではその設定を定義します。
- 変更を適用するためにファイルを保存します。新規設定の影響を受けた Pod は自動的に再起動されます。
追加リソース
-
cluster-monitoring-config
ConfigMap
オブジェクトを作成する方法については、クラスターモニターリングの設定マップの作成 について参照してください。
1.2.5. 設定可能なモニタリングコンポーネント リンクのコピーリンクがクリップボードにコピーされました!
以下の表は、設定可能なモニタリングコンポーネントと、設定マップでコンポーネントを指定するために使用されるキーを示しています。
コンポーネント | キー |
---|---|
Prometheus Operator |
|
Prometheus |
|
Alertmanager 0.14.0 |
|
kube-state-metrics |
|
openshift-state-metrics |
|
Grafana |
|
Telemeter クライアント |
|
Prometheus アダプター |
|
Thanos Querier |
|
この一覧では、Prometheus および Alertmanager のみが多数の設定オプションを持ちます。通常、その他のすべてのコンポーネントは指定されたノードにデプロイされるように nodeSelector
フィールドのみを提供します。
1.2.6. モニタリングコンポーネントの異なるノードへの移動 リンクのコピーリンクがクリップボードにコピーされました!
モニタリングスタックコンポーネントのいずれかを指定されたノードに移動できます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできます。 - OpenShift CLI (oc) がインストールされている。
-
cluster-monitoring-config
ConfigMap
オブジェクトを作成している。
手順
cluster-monitoring-config
ConfigMap
オブジェクトの編集を開始します。oc -n openshift-monitoring edit configmap cluster-monitoring-config
$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コンポーネントの
nodeSelector
制約をdata/config.yaml
に指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow <component>
を適宜置き換え、<node_key>: <node_value>
を、宛先ノードを指定するキーと値のペアのマップに置き換えます。通常は、単一のキーと値のペアのみが使用されます。コンポーネントは、指定されたキーと値のペアのそれぞれをラベルとして持つノードでのみ実行できます。ノードには追加のラベルを持たせることもできます。
たとえば、コンポーネントを
foo: bar
というラベルが付けられたノードに移動するには、以下を使用します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を適用するためにファイルを保存します。新しい設定の影響を受けるコンポーネントは新しいノードに自動的に移動します。
追加リソース
-
cluster-monitoring-config
ConfigMap
オブジェクトを作成する方法については、クラスターモニターリングの設定マップの作成 について参照してください。 - ノードセレクターの使用についての詳細は、Placing pods on specific nodes using node selectors を参照してください。
-
nodeSelector
制約についての詳細は、Kubernetes ドキュメント を参照してください。
1.2.7. モニタリングコンポーネントへの容認 (Toleration) の割り当て リンクのコピーリンクがクリップボードにコピーされました!
容認をモニタリングスタックのコンポーネントに割り当て、それらをテイントされたノードに移動することができます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできます。 - OpenShift CLI (oc) がインストールされている。
-
cluster-monitoring-config
ConfigMap
オブジェクトを作成している。
手順
cluster-monitoring-config
ConfigMap
オブジェクトの編集を開始します。oc -n openshift-monitoring edit configmap cluster-monitoring-config
$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コンポーネントの
tolerations
を指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow <component>
および<toleration_specification>
を随時置き換えます。たとえば、
oc adm taint nodes node1 key1=value1:NoSchedule
のテイントにより、スケジューラーがfoo: bar
ノードに Pod を配置するのを防ぎます。alertmanagerMain
コンポーネントを、そのテイントを無視して、foo: bar
にalertmanagerMain
を配置するには、通常以下の容認を使用します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を適用するためにファイルを保存します。新しいコンポーネントの配置設定が自動的に適用されます。
追加リソース
-
cluster-monitoring-config
ConfigMap
オブジェクトを作成する方法については、クラスターモニターリングの設定マップの作成 について参照してください。 - テイントおよび容認 (Toleration) については、OpenShift Container Platform ドキュメント を参照してください。
- テイントおよび容認 (Toleration) については、Kubernetes ドキュメント を参照してください。
1.2.8. 永続ストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスターモニタリングを永続ストレージと共に実行すると、メトリクスは永続ボリューム (PV) に保存され、Pod の再起動または再作成後も維持されます。これは、メトリクスデータまたはアラートデータをデータ損失から保護する必要がある場合に適しています。実稼働環境では、永続ストレージを設定することを強く推奨します。IO デマンドが高いため、ローカルストレージを使用することが有利になります。永続ストレージにローカルボリュームを使用する場合は、LocalVolume
オブジェクトの volumeMode: block
で記述される raw ブロックボリュームを使用しないでください。Elasticsearch は raw ブロックボリュームを使用できません。
設定可能な推奨のストレージ技術 を参照してください。
1.2.9. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- ディスクが一杯にならないように、十分なローカル永続ストレージを確保します。必要な永続ストレージは Pod 数によって異なります。永続ストレージのシステム要件については、Prometheus データベースのストレージ要件 を参照してください。
- 永続ボリューム要求 (PVC) で要求される永続ボリューム (PV) が利用できる状態にあることを確認する必要があります。各レプリカに 1 つの PV が必要です。Prometheus には 2 つのレプリカがあり、Alertmanager には 3 つのレプリカがあるため、モニタリングスタック全体をサポートするには、合計で 5 つの PV が必要になります。PV は、ローカルストレージ Operator で利用できる必要があります。動的にプロビジョニングされるストレージを有効にすると、この設定は適用されません。
- ストレージのブロックタイプを使用します。
- ローカル永続ストレージを設定 します。
1.2.9.1. ローカ永続ボリューム要求 (PVC) の設定 リンクのコピーリンクがクリップボードにコピーされました!
Prometheus または Alertmanager で永続ボリューム (PV) を使用するには、まず永続ボリューム要求 (PVC) を設定する必要があります。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできます。 - OpenShift CLI (oc) がインストールされている。
-
cluster-monitoring-config
ConfigMap
オブジェクトを作成している。
手順
cluster-monitoring-config
ConfigMap
オブジェクトを編集します。oc -n openshift-monitoring edit configmap cluster-monitoring-config
$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コンポーネントの PVC 設定を
data/config.yaml
の下に配置します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow volumeClaimTemplate
の指定方法については、PersistentVolumeClaims についての Kubernetes ドキュメント を参照してください。たとえば、Prometheus のローカル永続ストレージを要求する PVC を設定するには、以下を使用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 上記の例では、ローカルストレージ Operator によって作成されるストレージクラスは
local-storage
と呼ばれます。Alertmanager のローカル永続ストレージを要求する PVC を設定するには、以下を実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を適用するためにファイルを保存します。新規設定の影響を受けた Pod は自動的に再起動され、新規ストレージ設定が適用されます。
1.2.9.2. Prometheus メトリクスデータの保持期間の編集 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトで、Prometheus クラスターモニタリングスタックは、Prometheus データの保持期間を 15 日間に設定します。この保持期間は、データ削除のタイミングを調整するために変更できます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできます。 - OpenShift CLI (oc) がインストールされている。
-
cluster-monitoring-config
ConfigMap
オブジェクトを作成している。
手順
cluster-monitoring-config
ConfigMap
オブジェクトの編集を開始します。oc -n openshift-monitoring edit configmap cluster-monitoring-config
$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 保持期間の設定を
data/config.yaml
に配置します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow <time_specification>
を、ms
(ミリ秒)、s
(秒)、m
(分)、h
(時間)、d
(日)、w
(週)、またはy
(年) が直後に続く数字に置き換えます。たとえば、保持期間を 24 時間に設定するには、以下を使用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を適用するためにファイルを保存します。新規設定の影響を受けた Pod は自動的に再起動されます。
追加リソース
-
cluster-monitoring-config
ConfigMap
オブジェクトを作成する方法については、クラスターモニターリングの設定マップの作成 について参照してください。 - 永続ストレージについて
- ストレージの最適化
1.2.10. Alertmanager の設定 リンクのコピーリンクがクリップボードにコピーされました!
Prometheus Alertmanager は、以下を含む受信アラートを管理するコンポーネントです。
- アラートの非通知 (silence)
- アラートの抑制 (inhibition)
- アラートの集約 (aggregation)
- アラートの安定した重複排除
- アラートのグループ化
- メール、PagerDuty、および HipChat などの受信手段によるグループ化されたアラート通知の送信
1.2.10.1. Alertmanager のデフォルト設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Monitoring Alertmanager クラスターのデフォルト設定:
OpenShift Container Platform モニタリングには、継続的に実行される Watchdog アラートが同梱されます。Alertmanager は、たとえば PagerDuty などの通知プロバイダーに、Watchdog アラートの通知を繰り返し送信します。プロバイダーは通常、Watchdog アラートの受信を停止する際に管理者に通知するよう設定されます。このメカニズムは、Prometheus の継続的な運用、および Alertmanager と通知プロバイダー間の継続的な通信を可能にします。
1.2.10.2. カスタム Alertmanager 設定の適用 リンクのコピーリンクがクリップボードにコピーされました!
alertmanager-main
シークレットを openshift-monitoring
namespace 内で編集して、デフォルトの Alertmanager 設定を上書きできます。
前提条件
-
JSON データを処理するための
jq
ツールがインストールされていること
手順
現在アクティブな Alertmanager 設定をファイル
alertmanager.yaml
に出力します。oc -n openshift-monitoring get secret alertmanager-main --template='{{ index .data "alertmanager.yaml" }}' | base64 --decode > alertmanager.yaml
$ oc -n openshift-monitoring get secret alertmanager-main --template='{{ index .data "alertmanager.yaml" }}' | base64 --decode > alertmanager.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ファイル
alertmanager.yaml
の設定を新規設定に変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、この一覧では通知用に PagerDuty を設定しています。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この設定では、
example-app
サービスで発生する、重大度がcritical
のアラートが、team-frontend-page
レシーバーを使用して送信されます。 つまり、これらのアラートは選択された送信先に対して設定されます。新規設定をファイルで適用します。
oc -n openshift-monitoring create secret generic alertmanager-main --from-file=alertmanager.yaml --dry-run -o=yaml | oc -n openshift-monitoring replace secret --filename=-
$ oc -n openshift-monitoring create secret generic alertmanager-main --from-file=alertmanager.yaml --dry-run -o=yaml | oc -n openshift-monitoring replace secret --filename=-
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
関連情報
- PagerDuty についての詳細は、PagerDuty の公式サイト を参照してください。
-
service_key
を取得する方法については、PagerDuty Prometheus Integration Guide を参照してください。 - 各種のアラートレシーバー経由でアラートを設定する方法については、Alertmanager configuration を参照してください。
1.2.10.3. アラートルール リンクのコピーリンクがクリップボードにコピーされました!
デフォルトで、OpenShift Container Platform クラスター モニタリングには事前に定義されたアラートルールのセットが同梱されます。
以下に留意してください。
- デフォルトのアラートルールは OpenShift Container Platform クラスター用に使用され、それ以外の目的では使用されません。たとえば、クラスターの永続ボリュームについてのアラートを取得できますが、カスタム namespace の永続ボリュームについてのアラートは取得できません。
- 現時点で、カスタムアラートルールを追加することはできません。
- 一部のアラートルールには同じ名前が付けられています。これは意図的な理由によるものです。それらは同じイベントについてのアラートを送信しますが、それぞれ異なるしきい値、重大度、およびそれらの両方が設定されます。
- 抑制ルールを使用すると、高い重大度のアラートが発生する場合に重大度の低いアラートが抑制されます。
1.2.10.4. 有効なアラートルールのアクションの一覧表示 リンクのコピーリンクがクリップボードにコピーされました!
現時点でクラスターに適用されるアラートルールを一覧表示できます。
手順
必要なポート転送を設定します。
oc -n openshift-monitoring port-forward svc/prometheus-operated 9090
$ oc -n openshift-monitoring port-forward svc/prometheus-operated 9090
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 有効なアラートルールおよびそれらのプロパティーが含まれる JSON オブジェクトを取得します。
curl -s http://localhost:9090/api/v1/rules | jq '[.data.groups[].rules[] | select(.type=="alerting")]'
$ curl -s http://localhost:9090/api/v1/rules | jq '[.data.groups[].rules[] | select(.type=="alerting")]'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
追加リソース
- Alertmanager ドキュメント を参照してください。
1.2.11. 追加ラベルの時系列 (time series) およびアラートへの割り当て リンクのコピーリンクがクリップボードにコピーされました!
Prometheus の外部ラベル機能を使用して、追加のカスタムラベルを、Prometheus クラスターから出るすべての時系列およびアラートに割り当てることができます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできます。 - OpenShift CLI (oc) がインストールされている。
-
cluster-monitoring-config
ConfigMap
オブジェクトを作成している。
手順
cluster-monitoring-config
ConfigMap の編集を開始します。oc -n openshift-monitoring edit configmap cluster-monitoring-config
$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow data/config.yaml
の下にすべてのメトリクスについて追加する必要のあるラベルのマップを定義します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<key>: <value>
をキーと値のペアのマップに置き換えます。ここで、<key>
は新規ラベルの一意の名前で、<value>
はその値になります。
警告prometheus
またはprometheus_replica
は予約され、上書きされるため、これらをキー名として使用しないでください。たとえば、リージョンおよび環境に関するメタデータをすべての時系列およびアラートに追加するには、以下を使用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を適用するためにファイルを保存します。新しい設定は自動的に適用されます。
追加リソース
-
cluster-monitoring-config
ConfigMap
オブジェクトを作成する方法については、クラスターモニターリングの設定マップの作成 について参照してください。
1.2.12. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- クラスターアラートの管理
- リモート正常性レポート を確認し、必要な場合はこれをオプトアウトします。
1.3. クラスターアラートの管理 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.5 は、Alertmanager の Web インターフェイスを提供します。これを使用してアラートを管理できます。 このセクションでは、アラート UI を使用する方法について説明します。
現時点で、アラート UI は OpenShift Container Platform でデフォルトで提供されるアラートのみを表示します。ユーザー定義のアラートは一覧表示されません。これについては、今後のリリースで変更されます。
アラート UI は Administrator パースペクティブからのみアクセスでき、Developer パースペクティブからはアクセスできません。
1.3.1. アラート UI の内容 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、アラート UI、つまり Alertmanager の Web インターフェイスの内容について説明します。
アラート UI は、OpenShift Container Platform Web コンソールで Monitoring → Alerting をクリックしてアクセスできます。
アラート UI の主なページとして、Alerts、Silences、および Alerting rules という 3 つのページがあります。
Alerts ページ:
- 名前によるアラートのフィルター。
- 状態によるアラートのフィルター。アラートを実行するには、一部のアラートにおいて、タイムアウトの間に特定の条件が true である必要があります。アラートの条件が現時点で true であるが、タイムアウトに達していない場合、このアラートは Pending 状態になります。
- アラート名。
- アラートの説明。
- アラートの重大度レベルの値。
- アラートの現在の状態と、アラートがこの状態に切り替わった時。
- アラートに関して実行できるアクション。
Silences ページ:
- アラートのサイレンスの作成。
- 名前によるサイレンスのフィルター。
- 状態によるサイレンスのフィルター。サイレンスが保留中の場合、これは後で開始するようにスケジュールされているため、アクティブな状態ではありません。また、サイレンスの期間が過ぎると、終了時間に達したためにアクティブでなくなります。
- サイレンスの説明。これには、サイレンス名および一致するアラートの仕様が含まれます。
- サイレンス機能によってサイレンスにされているアラート数。
- サイレンスの現在の状態。サイレンスがアクティブな場合は、サイレンスが終了するタイミングを示します。保留中のサイレンスについては、サイレンスが開始するタイミングを示します。
- サイレンスを作成したユーザー。
- サイレンスに関して実行できるアクション。
Alerting Rules ページでは、以下が実行されます。
- 名前によるアラートルールのフィルター。
- 状態によるアラートルールのフィルター。
- アラートルール名。
- アラートルールの重大度レベルの値。
- アラートルールで定義されるアラートの状態。
また、これらのページのそれぞれのタイトルの横には、Alertmanager インターフェイスへのリンクがあります。
1.3.2. アラートおよびアラートルールについての情報の取得 リンクのコピーリンクがクリップボードにコピーされました!
アラートを見つけ、アラートおよびその規定するアラートルールについての情報を表示できます。
手順
- OpenShift Container Platform Web コンソールを開き、Monitoring → Alerting → Alerts ページに移動します。
- オプション: Filter Alerts by nameフィールドを使用して、名前でアラートをフィルター します。
- オプション: 1 つ以上の状態ボタン Firing、Silenced、Pending を使用して、状態でアラートをフィルターします。
- オプション: 1 つ以上の Name、Severity、および State 列ヘッダーをクリックして、アラートを並べ替えます。
必要とするアラートの表示後に、アラートまたはアラートを規定するアラートルールの詳細のいずれかを表示できます。
アラートの詳細を表示するには、アラートの名前をクリックします。開かれるページには、アラートの時系列を示すグラフがあります。また、以下をはじめとするアラートについての情報も含まれます。
- アラートを規定するアラートルールへのリンク
- アラートの説明。
- アラートに割り当てられるラベル
アラートルールの詳細を表示するには、最後の列のボタンをクリックし、View Alerting Rule を選択します。開かれるページには、以下をはじめとするアラートルールについての情報が含まれます。
- アラートルール名、重大度、および説明
- アラートを発生させるための条件を定義する式
- アラートを発生させるための条件が true である期間
- アラートルールに規定される各アラートのグラフ。 アラートを発生させる際に使用する値が表示されます。
- アラートルールで規定されるすべてのアラートについての表
1.3.3. アラートをサイレンスにする リンクのコピーリンクがクリップボードにコピーされました!
特定のアラート、または定義する仕様に一致するアラートのいずれかをサイレンスにすることができます。
手順
アラート仕様を作成してアラートのセットをサイレンスにするには、以下を実行します。
- OpenShift Container Platform Web コンソールの Monitoring → Alerting → Silences ページに移動します。
- Create Silence をクリックします。
- Create Silence フォームにデータを設定します。
- サイレンスを作成するには、Silence をクリックします。
特定のアラートをサイレンスにするには、以下を実行します。
- OpenShift Container Platform Web コンソールの Monitoring → Alerting → Alerts ページに移動します。
- サイレンスにする必要のあるアラートについて、最後の列のボタンをクリックし、Silence Alert をクリックします。Create Silence フォームが、選択したアラートの事前にデータが設定された仕様と共に表示されます。
- オプション: サイレンスを変更します。
- サイレンスを作成するには、Silence をクリックします。
1.3.4. サイレンスについての情報の取得 リンクのコピーリンクがクリップボードにコピーされました!
サイレンスを検索し、その詳細状態を表示できます。
手順
- OpenShift Container Platform Web コンソールを開き、Monitoring → Alerting → Silences ページに移動します。
- オプション: Filter Silences by name フィールドを使用して、名前でサイレンスをフィルターします。
- オプション: 1 つ以上の状態ボタン Active、Pending、Expired を使用して、状態でサイレンスをフィルターします。
- オプション: 1 つ以上の Name、Firing Alerts、State、および Creator 列ヘッダーをクリックしてサイレンスを並べ替えます。
サイレンスの表示後、その名前をクリックして、以下をはじめとする詳細情報を確認します。
- アラート仕様
- 状態
- 開始時間
- 終了時間
- 発生するアラートの数および一覧
1.3.5. サイレンスの編集 リンクのコピーリンクがクリップボードにコピーされました!
サイレンスは編集することができます。 これにより、既存のサイレンスが期限切れとなり、変更された設定で新規のサイレンスが作成されます。
手順
- Monitoring → Alerting → Silences ページに移動します。
変更するサイレンスについて、最後の列のボタンをクリックし、Edit silence をクリックします。
または、特定のサイレンスについて、 Silence Overview 画面で Actions → Edit Silence をクリックできます。
- Edit Silence 画面では、変更を入力し、Save ボタンをクリックします。これにより、既存のサイレンスが期限切れとなり、選択された設定でサイレンスが作成されます。
1.3.6. 有効期限切れにするサイレンス リンクのコピーリンクがクリップボードにコピーされました!
サイレンスは有効期限切れにすることができます。サイレンスはいったん期限切れになると、永久に無効にされます。
手順
- Monitoring → Alerting → Silences ページに移動します。
期限切れにするサイレンスについては、最後の列のボタンをクリックし、Expire Silence をクリックします。
または、特定のサイレンスについて、Silence Overview ページで Actions → Expire Silence ボタンをクリックできます。
- Expire Silence をクリックして確定します。これにより、サイレンスが期限切れになります。
1.3.7. Alertmanager 設定の変更 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して YAML 設定ファイルを編集し、Alertmanager 設定を変更できます。
手順
Alertmanager 設定を変更するには、以下を実行します。
- Web コンソールの Administration → Cluster Settings → Global Configuration → Alertmanager → YAML ページに移動します。
- YAML 設定ファイルを変更します。
- Save をクリックします。
追加リソース
- Alertmanager 設定の変更については、Configuring Alertmanager を参照してください。
1.3.8. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
1.4. クラスターメトリクスの検査 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.5 は、Prometheus への Web インターフェイスを提供します。 これにより、Prometheus のクエリー言語 (PromQL) のクエリーを実行し、プロットに可視化されるメトリクスを検査できます。この機能により、クラスターの状態に関する詳細な概要が提供され、問題のトラブルシューティングが可能になります。
メトリクス UI はクラスターメトリクスだけでなく、すべての namespace のメトリクスをクエリーします。
1.4.1. メトリクス UI の内容 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、メトリクス UI、Prometheus への Web インターフェイスの内容について表示し、説明します。
Metricsページは、OpenShift Container Platform Web コンソールの Monitoring → Metrics をクリックしてアクセスできます。
アクション。
- クエリーを追加します。
- すべてのクエリーテーブルを展開するか、または折りたたみます。
- すべてのクエリーを削除します。
- プロットを非表示にします。
- 対話式のプロット。
- 利用可能なメトリクスのカタログ。
- クエリーを追加します。
- クエリーを実行します。
- クエリーフォーム。
- フォームを展開または折りたたみます。
- クエリー。
- クエリーをクリアします。
- クエリーを有効または無効にします。
特定のクエリーのアクション。
- クエリーを有効または無効にします。
- プロットからすべてのクエリーのシリーズを表示または非表示にします。
- クエリーを削除します。
- クエリーのメトリクステーブル。
- メトリクスのグラフに割り当てられた色。四角をクリックして、メトリクスのグラフを表示するか、非表示にします。
また、ページのタイトルの横には古い Prometheus インターフェイスへのリンクもあります。
1.4.2. メトリクスクエリーの実行 リンクのコピーリンクがクリップボードにコピーされました!
メトリクスを使用するには、1 つまたは複数の Prometheus クエリー言語 (PromQL) クエリーを入力します。
手順
- OpenShift Container Platform Web コンソールを開き、Monitoring → Metrics ページに移動します。
クエリーフィールドに PromQL クエリーを入力します。
- 利用可能なすべてのメトリクスおよび PromQL 機能を表示するには、Insert Metric at Cursor をクリックします。
- 複数のクエリーについて、Add Query をクリックします。
-
クエリーを削除するには、クエリーの
をクリックしてから Delete query を選択します。
- クエリーを実行せずに維持するには、Disable query ボタンをクリックします。
クエリーの作成が完了したら、Run Queries ボタンをクリックします。クエリーからのメトリクスはプロットで可視化されます。クエリーが無効な場合、UI にはエラーメッセージが表示されます。
注記大量のデータで動作するクエリーは、時系列グラフの描画時にタイムアウトするか、またはブラウザーをオーバーロードする可能性があります。これを回避するには、グラフを非表示にし、メトリクステーブルのみを使用してクエリーを調整する必要があります。次に、使用できるクエリーを確認した後に、グラフを描画できるようにプロットを有効にします。
- オプション: ページ URL には、実行したクエリーが含まれます。このクエリーのセットを再度使用できるようにするには、この URL を保存します。
追加リソース
Prometheus Query Language ドキュメント を参照してください。
1.4.3. 視覚化されたメトリクスの使用 リンクのコピーリンクがクリップボードにコピーされました!
クエリーの実行後に、メトリクスが対話式プロットに表示されます。プロットの X 軸は時間を表します。Y 軸はメトリクスの値を表します。各メトリクスは彩色グラフとして表示されます。プロットを操作し、メトリクスを参照できます。
手順
最初に、有効なすべてのクエリーからのすべてのメトリクスがプロットに表示されます。表示されるメトリクスを選択できます。
-
クエリーからすべてのメトリクスを非表示にするには、クエリーの
をクリックし、Hide all series をクリックします。
- 特定のメトリクスを非表示にするには、クエリーテーブルに移動し、メトリクス名の横にある色の付いた四角をクリックします。
-
クエリーからすべてのメトリクスを非表示にするには、クエリーの
プロットをズームアップし、表示される時間範囲を変更するには、以下のいずれかを行います。
- プロットを水平にクリックし、ドラッグして、時間範囲を視覚的に選択します。
- 左上隅のメニューを使用して、時間範囲を選択します。
時間の範囲をリセットするには、Reset Zoom をクリックします。
- 特定の時点のすべてのクエリーの出力を表示するには、その時点のプロットにてマウスのカーソルを保持します。クエリーの出力はポップアップに表示されます。
- 特定クエリーのメトリクスの詳細については、ドロップダウンボタンを使用してクエリーの表を展開します。すべてのメトリクスは現在の値で表示されます。
- プロットを非表示にするには、Hide Graph をクリックします。
1.4.4. メトリックへの管理者以外のアクセス リンクのコピーリンクがクリップボードにコピーされました!
開発者は、プロジェクト内のアプリケーションまたはサービスのユーザーワークロードのモニタリングを有効にできます。管理者は、同一の機能を使用してインフラストラクチャーワークロードのモニターリングを有効にできます。この場合、プロジェクトの開発者または管理者は、Web コンソールで Developer パースペクティブを使用して、公開されたメトリクスを検査できます。
Developer パースペクティブを使用したメトリクスの検査はテクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
追加リソース
独自のサービスのモニターリングについてのドキュメント を参照してください。これには、クラスター以外のメトリクスに開発者または特権のあるユーザーとしてアクセスするための詳細情報が含まれます。
1.4.5. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
1.5. Prometheus、Alertmanager、および Grafana へのアクセス リンクのコピーリンクがクリップボードにコピーされました!
モニタリングスタックによって収集されるデータを使用するには、Prometheus、Alertmanager、および Grafana インターフェイスを使用できます。これらのインターフェイスはデフォルトで利用可能です。
1.5.1. Web コンソールの使用による Prometheus、Alerting UI、および Grafana へのアクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールで Web ブラウザーを使用し、Prometheus、Alerting、および Grafana Web UI にアクセスできます。
この手順でアクセスされる Alerting UI は、Alertmanager の新規インターフェイスです。
前提条件
-
認証は、OpenShift Container Platform アイデンティティーに対して行われ、OpenShift Container Platform の他の場所で使用されるのと同じ認証情報および認証方法が使用されます。
cluster-monitoring-view
クラスターロールなどの、すべての namespace への読み取りアクセスを持つロールを使用する必要があります。
手順
- OpenShift Container Platform Web コンソールに移動し、認証します。
Prometheus にアクセスするには、"Monitoring" → "Metrics" ページに移動します。
Alerting UI にアクセスするには、"Monitoring" → "Alerting" ページに移動します。
Grafana にアクセスするには、"Monitoring" → "Dashboards" ページに移動します。
1.5.2. Prometheus、Alertmanager、および Grafana への直接アクセス リンクのコピーリンクがクリップボードにコピーされました!
oc
ツールおよび Web ブラウザーを使用して、Prometheus、Alertmanager、および Grafana Web UI にアクセスできます。
この手順でアクセスされる Alertmanager UI は、 Alertmanager の古いインターフェイスです。
前提条件
-
認証は、OpenShift Container Platform アイデンティティーに対して行われ、OpenShift Container Platform の他の場所で使用されるのと同じ認証情報および認証方法が使用されます。
cluster-monitoring-view
クラスターロールなどの、すべての namespace への読み取りアクセスを持つロールを使用する必要があります。
手順
以下を実行します。
oc -n openshift-monitoring get routes
$ oc -n openshift-monitoring get routes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME HOST/PORT ... alertmanager-main alertmanager-main-openshift-monitoring.apps._url_.openshift.com ... grafana grafana-openshift-monitoring.apps._url_.openshift.com ... prometheus-k8s prometheus-k8s-openshift-monitoring.apps._url_.openshift.com ...
NAME HOST/PORT ... alertmanager-main alertmanager-main-openshift-monitoring.apps._url_.openshift.com ... grafana grafana-openshift-monitoring.apps._url_.openshift.com ... prometheus-k8s prometheus-k8s-openshift-monitoring.apps._url_.openshift.com ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow https://
をアドレスに追加します。 暗号化されていない接続を使用して Web UI にアクセスすることはできません。たとえば、以下は Alertmanager の生成される URL です。
https://alertmanager-main-openshift-monitoring.apps._url_.openshift.com
https://alertmanager-main-openshift-monitoring.apps._url_.openshift.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - web ブラウザーを使用してアドレスに移動し、認証します。
追加リソース
- Alertmanager の新規インターフェイスの説明については、クラスターアラートの管理 を参照してください。
モニタリングルートは Cluster Monitoring Operator によって管理され、ユーザーが変更することはできません。
第2章 独自のサービスのモニタリング リンクのコピーリンクがクリップボードにコピーされました!
クラスターのモニタリングに加えて、独自のサービスについて OpenShift Monitoring を使用できます。これを使用することにより、追加のモニタリングソリューションを使用する必要はありません。また、これはモニタリングの一元化に役立ちます。さらに、サービスのメトリクスへのアクセスを、クラスター管理者以外にも拡張できます。これにより、開発者および任意のユーザーがこれらのメトリクスにアクセスできます。
カスタム Prometheus インスタンスおよび Operator Lifecycle Manager (OLM) でインストールされる Prometheus Operator では、ユーザー定義のワークロードモニタリングが有効である場合にこれに関する問題が生じる可能性があります。カスタム Prometheus インスタンスは OpenShift Container Platform ではサポートされません。
独自のサービスのモニタリングはテクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。
2.1. 独自のサービスのモニタリングの有効化 リンクのコピーリンクがクリップボードにコピーされました!
独自のサービスのモニタリングを有効にするには、クラスターモニタリングの ConfigMap に techPreviewUserWorkload/enabled
フラグを設定します。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできます。 - OpenShift CLI (oc) がインストールされている。
-
cluster-monitoring-config
ConfigMap
オブジェクトを作成している。
手順
cluster-monitoring-config
ConfigMap
オブジェクトの編集を開始します。oc -n openshift-monitoring edit configmap cluster-monitoring-config
$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow data/config.yaml
でtechPreviewUserWorkload
設定をtrue
に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を適用するためにファイルを保存します。独自のサービスのモニタリングが自動的に有効にされます。
オプション:
prometheus-user-workload Pod
が作成されていることを確認できます。oc -n openshift-user-workload-monitoring get pod
$ oc -n openshift-user-workload-monitoring get pod
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
追加リソース
-
cluster-monitoring-config
ConfigMap
オブジェクトを作成する方法については、クラスターモニターリングの設定マップの作成 について参照してください。
2.2. サンプルサービスのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
独自のサービスのモニタリングをテストするために、サンプルサービスをデプロイすることができます。
手順
-
サービス設定の YAML ファイルを作成します。この例では、
prometheus-example-app.yaml
という名前です。 サービスをデプロイするための設定をファイルに入力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この設定は、
prometheus-example-app
という名前のサービスをns1
プロジェクトにデプロイします。このサービスは、カスタムversion
メトリクスを公開します。設定ファイルをクラスターに適用します。
oc apply -f prometheus-example-app.yaml
$ oc apply -f prometheus-example-app.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスをデプロイするには多少時間がかかります。
サービスが実行中であることを確認できます。
oc -n ns1 get pod
$ oc -n ns1 get pod
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE prometheus-example-app-7857545cb7-sbgwq 1/1 Running 0 81m
NAME READY STATUS RESTARTS AGE prometheus-example-app-7857545cb7-sbgwq 1/1 Running 0 81m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3. Web コンソールを使用したユーザーパーミッションの付与 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、Web コンソールを使用して、ユーザーに独自のサービスを監視するパーミッションを付与する方法を説明します。
前提条件
- ユーザーを作成している。
- クラスター管理者として Web コンソールにログインしている。
手順
- Web コンソールで、User Management → Role Bindings → Create Binding に移動します。
- Binding Typeで、Namespace Role Binding タイプを選択します。
- Name に、バインディングの名前を入力します。
-
Namespace で、アクセスを付与する namespace を選択します。たとえば、
ns1
を選択します。 Role Name に、
monitoring-rules-view
、monitoring-rules-edit
、またはmonitoring-edit
を入力します。-
monitoring-rules-view
では、namespace 内のPrometheusRule
カスタムリソースの読み取りを許可します。 -
monitoring-rules-edit
では、許可された namespace に一致するPrometheusRule
カスタムリソースの作成、変更、および削除を許可します。 -
monitoring-edit
は、monitoring-rules-edit
と同じパーミッションを付与します。さらに、サービスまたは Pod の収集ターゲットの作成を許可します。また、ServiceMonitor
およびPodMonitor
リソースの作成、変更、および削除も許可します。
重要選択したすべてのロールは、クラスター管理者が特定の namespace にバインドする必要があります。
たとえば、
monitoring-edit
を入力します。-
- Subject で User を選択します。
-
Subject Name に、ユーザーの名前を入力します。たとえば、
johnsmith
を入力します。 -
ロールバインディングを確認します。この例では、ユーザー
johnsmith
にメトリクスコレクションの設定およびアラートルールをns1
namespace に作成するためのパーミッションが割り当てられています。
2.4. CLI を使用したユーザーパーミッションの付与 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、CLI を使用して、ユーザーに独自のサービスを監視するパーミッションを付与する方法を説明します。
選択したすべてのロールは、クラスター管理者が特定の namespace にバインドする必要があります。
前提条件
- cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
- ユーザーを作成している。
-
oc
コマンドを使用してログインします。
手順
以下のコマンドを実行して、定義された namespace でロールをユーザーに割り当てます。
oc policy add-role-to-user <role> <user> -n <namespace>
$ oc policy add-role-to-user <role> <user> -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <role>
をmonitoring-rules-view
、monitoring-rules-edit
、またはmonitoring-edit
に置き換えます。-
monitoring-rules-view
では、namespace 内のPrometheusRule
カスタムリソースの読み取りを許可します。 -
monitoring-rules-edit
では、許可された namespace に一致するPrometheusRule
カスタムリソースの作成、変更、および削除を許可します。 -
monitoring-edit
は、monitoring-rules-edit
と同じパーミッションを付与します。さらに、サービスまたは Pod の収集ターゲットの作成を許可します。また、ServiceMonitor
およびPodMonitor
リソースの作成、変更、および削除も許可します。
たとえば、ロールを
monitoring-edit
に、ユーザーをjohnsmith
に、namespace をns1
に置き換えます。これにより、メトリクスコレクションを設定し、ns1
namespace にアラートルールを作成するパーミッションがjohnsmith
に割り当てられます。-
2.5. メトリクスコレクションの設定 リンクのコピーリンクがクリップボードにコピーされました!
サービスが公開するメトリクスを使用するには、OpenShift Monitoring を、/metrics
エンドポイントからメトリクスを収集できるように設定する必要があります。これは、サービスのモニターリング方法を指定する ServiceMonitor
カスタムリソース定義 (CRD) または Pod のモニターリング方法を指定する PodMonitor
CRD を使用して実行できます。前者の場合は Service
オブジェクトが必要ですが、後者の場合は不要です。これにより、Prometheus は Pod によって公開されるメトリクスエンドポイントからメトリクスを直接収集することができます。
以下の手順では、サービスの ServiceMonitor
リソースを作成する方法を説明します。
前提条件
-
クラスター管理者または
monitor-crd-edit
ロールを持つユーザーとしてログインします。
手順
-
ServiceMonitor
リソース設定の YAML ファイルを作成します。この例では、ファイルはexample-app-service-monitor.yaml
という名前です。 ServiceMonitor
リソースを作成するための設定をファイルに入力します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow この設定により、OpenShift Monitoring はサンプルサービスのデプロイでデプロイされるサンプルサービスによって公開されるメトリクスを収集します。これには、単一の
version
メトリクスが含まれます。設定ファイルをクラスターに適用します。
oc apply -f example-app-service-monitor.yaml
$ oc apply -f example-app-service-monitor.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ServiceMonitor
リソースをデプロイするのに多少時間がかかります。ServiceMonitor
リソースが実行中であることを確認できます。oc -n ns1 get servicemonitor
$ oc -n ns1 get servicemonitor
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE prometheus-example-monitor 81m
NAME AGE prometheus-example-monitor 81m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
関連情報
ServiceMonitor
および PodMonitor
リソースについての詳細は、Prometheus Operator API のドキュメント を参照してください。
2.6. アラートルールの作成 リンクのコピーリンクがクリップボードにコピーされました!
選択したメトリクスの値に基づいてアラートを出すアラートルールを作成できます。
ルールおよびアラートの表示および管理については、Web コンソールに統合されていません。クラスター管理者は、代わりに Alertmanager UI または Thenos Ruler を使用できます。手順については、それぞれのセクションを参照してください。
前提条件
-
アラートルールを作成する必要のある namespace の
monitoring-rules-edit
ロールを持つユーザーとしてログインします。
手順
-
アラートルールの YAML ファイルを作成します。この例では、
example-app-alerting-rule.yaml
という名前です。 アラートルールの設定をファイルに入力します。
注記アラートルールの作成時に、同じ名前のルールが別の namespace にある場合に namespace ラベルがこのアラートルールに対して適用されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この設定により、
example-alert
という名前のアラートルールが作成されます。これは、サンプルサービスで公開されるversion
メトリクスが0
になるとアラートを出します。重要すべての namespace について、その namespace およびクラスターメトリクスのメトリクスを使用できますが、別の namespace のメトリクスを使用することはできません。
たとえば、
ns1
のアラートルールには、ns1
、および CPU およびメモリーメトリクスなどのクラスターメトリクスなどを持たせることができます。ただし、ルールにはns2
からのメトリクスを含めることはできません。さらに、
openshift-*
コア OpenShift namespace のアラートルールを作成することはできません。デフォルトで OpenShift Container Platform Monitoring はこれらの namespace のアラートルールのセットを提供します。設定ファイルをクラスターに適用します。
oc apply -f example-app-alerting-rule.yaml
$ oc apply -f example-app-alerting-rule.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow アラートルールの作成には多少時間がかかります。
2.7. アラートルールの削除 リンクのコピーリンクがクリップボードにコピーされました!
アラートルールを削除できます。
前提条件
-
アラートルールを削除する必要のある namespace の
monitoring-rules-edit
ロールを持つユーザーとしてログインします。
手順
namespace のルールを削除するには、以下を実行します。
oc -n <namespace> delete prometheusrule <foo>
$ oc -n <namespace> delete prometheusrule <foo>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.8. プロジェクトのアラートルールへのアクセス リンクのコピーリンクがクリップボードにコピーされました!
プロジェクトの既存のアラートルールを一覧表示できます。
前提条件
-
プロジェクトに対して
monitoring-rules-view
ロールを持つユーザーとしてログインします。
手順
プロジェクトでアラートルールを一覧表示するには、以下を実行します。
oc -n <project> get prometheusrule
$ oc -n <project> get prometheusrule
Copy to Clipboard Copied! Toggle word wrap Toggle overflow アラートルールの設定を一覧表示するには、以下を実行します。
oc -n <project> get prometheusrule <rule> -oyaml
$ oc -n <project> get prometheusrule <rule> -oyaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.9. すべての namespace のアラートルールへのアクセス リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、単一ビューですべての namespace からアラートルールにアクセスできます。
今後のリリースでは、Thanos Ruler UI へのルートが非推奨となり、Web コンソールが優先されます。
前提条件
-
oc
コマンドがインストールされている。 - クラスター管理者としてログインしている。
手順
openshift-user-workload-monitoring
namespace のルートを一覧表示します。oc -n openshift-user-workload-monitoring get routes
$ oc -n openshift-user-workload-monitoring get routes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この出力には、Thanos Ruler UI の URL が表示されます。
NAME HOST/PORT ... thanos-ruler thanos-ruler-openshift-user-workload-monitoring.apps.example.devcluster.openshift.com
NAME HOST/PORT ... thanos-ruler thanos-ruler-openshift-user-workload-monitoring.apps.example.devcluster.openshift.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 一覧表示された URL に移動します。ここでは、すべての namespace からのユーザーアラートルールを確認できます。
2.10. 開発者としてのサービスのメトリクスへのアクセス リンクのコピーリンクがクリップボードにコピーされました!
独自のサービスのモニターリングを有効にし、サービスをデプロイし、そのサービスのメトリクスコレクションをセットアップした後に、開発者またはプロジェクトの表示パーミッションを持つユーザーとしてサービスのメトリクスにアクセスできます。
OpenShift Container Platform Monitoring に同梱される Grafana インスタンスは読み取り専用であり、インフラストラクチャー関連のダッシュボードのみを表示します。
前提条件
- モニターするサービスをデプロイします。
- 独自のサービスのモニターリングを有効にします。
- サービスについてのメトリクスの収集を設定します。
- 開発者またはプロジェクトの表示パーミッションを持つユーザーとしてログインします。
手順
OpenShift Container Platform Web コンソールに移動し、 Developer パースペクティブに切り替えてから、Advanced → Metrics をクリックします。メトリクスを表示するプロジェクトを選択します。
注記開発者は Developer パースペクティブのみを使用でき、Administrator パースペクティブは使用できません。単一プロジェクトからのみメトリクスをクエリーできます。それらは OpenShift Container Platform Monitoring で提供されるサードパーティーの UI にアクセスできません。
- PromQL インターフェイスを使用して、サービスのクエリーを実行します。
2.11. クラスター管理者としてのすべてのサービスのメトリクスへのアクセス リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者またはすべての namespace の表示パーミッションを持つユーザーの場合、単一ビューですべての namespace からすべてのサービスのメトリクスにアクセスできます。
前提条件
- クラスター管理者またはすべての namespace の表示パーミッションを持つユーザーとして Web コンソールにログインします。
-
オプションで、
oc
コマンドでもログインすることもできます。
手順
メトリクス Web インターフェイスの使用
OpenShift Container Platform Web コンソールに移動し、Administrator パースペクティブに切り替えてから Monitoring → Metrics をクリックします。
注記クラスター管理者は、Administrator パースペクティブを使用する場合、すべてのクラスターメトリクスおよびすべてのプロジェクトのカスタムサービスメトリクスにアクセスできます。
注記クラスター管理者のみが、OpenShift Container Platform Monitoring で提供されるサードパーティーの UI にアクセスできます。
- PromQL インターフェイスを使用して、サービスのクエリーを実行します。
Thanos Querier UI の使用:
注記今後のリリースでは、Thanos Querier UI が非推奨となり、Web コンソールが優先されます。
openshift-monitoring
namespace のルートを一覧表示します。oc -n openshift-monitoring get routes
$ oc -n openshift-monitoring get routes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この出力には、Thanos Querier UI の URL が表示されます。
NAME HOST/PORT ... thanos-querier thanos-querier-openshift-monitoring.apps.example.devcluster.openshift.com
NAME HOST/PORT ... thanos-querier thanos-querier-openshift-monitoring.apps.example.devcluster.openshift.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 一覧表示された URL に移動します。ここでは、すべての namespace からのすべてのメトリクスを確認できます。
追加リソース
- PromQL インターフェイスの使用についてのセクション を参照してください。
第3章 自動スケーリングのカスタムアプリケーションメトリクスの公開 リンクのコピーリンクがクリップボードにコピーされました!
Horizontal Pod Autoscaler のカスタムアプリケーションメトリクスをエクスポートできます。
Prometheus アダプターはテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。
3.1. Horizontal Pod Autoscaling のカスタムアプリケーションメトリクスの公開 リンクのコピーリンクがクリップボードにコピーされました!
prometheus-adapter
リソースを使用して、Horizontal Pod Autoscaler のカスタムアプリケーションメトリクスを公開できます。
前提条件
-
カスタム Prometheus インスタンスがインストールされていること。この例では、Prometheus が
default
namespace にインストールされていることが前提になります。 -
アプリケーションのモニタリングを設定されていること。この例では、アプリケーションとそのサービスモニターが
default
namespace にインストールされていることが前提になります。
手順
-
設定の YAML ファイルを作成します。この例では、これは
deploy.yaml
というファイルになります。 prometheus-adapter
のサービスアカウント、必要なロールおよびロールバインディングを作成するための設定を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow prometheus-adapter
のカスタムメトリクスの設定を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow prometheus-adapter
を API サービスとして登録するための設定を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用する Prometheus アダプターイメージを表示します。
oc get -n openshift-monitoring deploy/prometheus-adapter -o jsonpath="{..image}"
$ oc get -n openshift-monitoring deploy/prometheus-adapter -o jsonpath="{..image}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
quay.io/openshift-release-dev/ocp-v4.3-art-dev@sha256:76db3c86554ad7f581ba33844d6a6ebc891236f7db64f2d290c3135ba81c264c
quay.io/openshift-release-dev/ocp-v4.3-art-dev@sha256:76db3c86554ad7f581ba33844d6a6ebc891236f7db64f2d290c3135ba81c264c
Copy to Clipboard Copied! Toggle word wrap Toggle overflow prometheus-adapter
をデプロイするための設定を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
image: openshift-release-dev/ocp-v4.3-art-dev
は、直前の手順にある Prometheus Adapter イメージを指定します。
設定ファイルをクラスターに適用します。
oc apply -f deploy.yaml
$ oc apply -f deploy.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - アプリケーションのメトリクスが公開され、Horizontal Pod Autoscaling を設定するために使用できます。
追加リソース
- Horizontal Pod Autoscaling についてのドキュメント を参照してください。
- Horizontal Pod Autoscaler についての Kubernetes ドキュメント を参照してください。