モニタリング
OpenShift Container Platform 4.1 での Prometheus モニタリングスタックの設定および使用
概要
第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 によって送信されるアラートを処理します。 |
|
|
|
|
Grafana | Grafana 解析プラットフォームは、メトリクスの分析および可視化のためのダッシュボードを提供します。モニタリングスタックおよびダッシュボードと共に提供される Grafana インスタンスは読み取り専用です。 |
モニタリグスタックのすべてのコンポーネントはスタックによってモニターされ、OpenShift Container Platform の更新時に自動的に更新されます。
スタック自体のコンポーネントに加え、モニタリングスタックは以下をモニターします。
- CoreDNS
- Elasticsearch(ロギングがインストールされている場合)
- Etcd
- Fluentd(ロギングがインストールされている場合)
- HAProxy
- イメージレジストリー
- Kubelets
- Kubernetes apiserver
- Kubernetes controller manager
- Kubernetes scheduler
- Metering(メータリングがインストールされている場合)
- OpenShift apiserver
- OpenShift コントロールマネージャー
- Operator Lifecycle Manager (OLM)
- Telemeter クライアント
各 OpenShift Container Platform コンポーネントはそれぞれのモニタリング設定を行います。コンポーネントのモニタリングについての問題は、Bugzilla で一般的なモニタリングコンポーネントではなく、該当するコンポーネントに対してバグを報告してください。
他の OpenShift Container Platform フレームワークのコンポーネントもメトリクスを公開する場合があります。詳細については、それぞれのドキュメントを参照してください。
次のステップ
1.2. モニタリングスタックの設定
OpenShift Container Platform 4 よりも前のバージョンでは、 Prometheus クラスターモニタリングスタックは Ansible インベントリーファイルで設定されていました。そのため、スタックは利用可能な設定オプションのサブセットを Ansible 変数として公開し、スタックは OpenShift Container Platform のインストール前に設定していました。
OpenShift Container Platform 4 では、Ansible は OpenShift Container Platform をインストールするのに使用される主要なテクノロジーではなくなりました。インストールプログラムは、インストールの前に大幅に限定された設定オプションのみを提供します。ほとんどの OpenShift フレームワークコンポーネント (Prometheus クラスターモニタリングスタックを含む) の設定はインストール後に行われます。
このセクションでは、サポートされている設定内容を説明し、モニタリングスタックの設定方法を示し、いくつかの一般的な設定シナリオを示します。
前提条件
- モニタリングスタックには、追加のリソース要件があります。詳細は、「 Cluster Monitoring Operator のスケーリング」を 参照し、十分なリソースがあることを確認してください。
1.2.1. メンテナンスとサポート
OpenShift Container Platform モニタリングの設定は、本書で説明されているオプションを使用して行う方法がサポートされている方法です。サポートされていない他の設定は使用しないでください。設定のパラダイムが Prometheus リリース間で変更される可能性があり、このような変更には、設定のすべての可能性が制御されている場合のみ適切に対応できます。本セクションで説明されている設定以外の設定を使用する場合、cluster-monitoring-operator が差分を調整するため、変更内容は失われます。Operator はデフォルトで定義された状態へすべてを元に戻します。
明示的にサポート対象外とされているケースには、以下が含まれます。
-
追加の
ServiceMonitor
オブジェクトをopenshift-*
namespace に作成する。これにより、クラスターモニタリング Prometheus インスタンスの収集ターゲットが拡張されます。これは、対応不可能な競合および負荷の差異を生じさせる可能性があるため、Prometheus のセットアップが不安定になる可能性があります。 -
予期しない
ConfigMap
オブジェクトまたはPrometheusRule
オブジェクトの作成。これにより、クラスターモニタリング Prometheus インスタンスに追加のアラートおよび記録ルールが組み込まれます。 - スタックのリソースの変更。Prometheus Monitoring Stack スタックは、そのリソースが常に期待される状態にあることを確認します。これらが変更される場合、スタックはこれらをリセットします。
- 目的に合わせてスタックのリソースを使用する。Prometheus クラスターモニタリングスタックによって作成されるリソースは、後方互換性の保証がないために他のリソースで使用されることは意図されていません。
- クラスターモニタリング Operator によるモニタリングスタックの調整を停止する。
- 新規アラートルールの追加。
- モニタリングスタック Grafana インスタンスの変更。
1.2.2. クラスターモニタリング ConfigMap の作成
Prometheus クラスターモニタリングスタックを設定するには、クラスターモニタリング ConfigMap を作成する必要があります。
前提条件
-
インストール済みの
oc
CLI ツール - クラスターの管理者権限
手順
cluster-monitoring-config
ConfigMap オブジェクトが存在するかどうかを確認します。$ oc -n openshift-monitoring get configmap cluster-monitoring-config
存在しない場合は、これを作成します。
$ oc -n openshift-monitoring create configmap cluster-monitoring-config
cluster-monitoring-config
ConfigMap の編集を開始します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
data
セクションを作成します (存在していない場合)。apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: |
1.2.3. クラスターモニタリングスタックの設定
ConfigMap を使用して Prometheus クラスターモニタリングスタックを設定することができます。ConfigMap はクラスターモニタリング Operator を設定し、その後にスタックのコンポーネントが設定されます。
前提条件
-
cluster-monitoring-config
ConfigMap オブジェクトがdata/config.yaml
セクションに設定されていること。
手順
cluster-monitoring-config
ConfigMap の編集を開始します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
設定を、
data/config.yaml
の下に値とキーのペア<component_name>: <component_configuration>
として配置します。apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | component: configuration for the component
<component>
および<configuration for the component>
を随時置き換えます。たとえば、Prometheus の Persistent Volume Claim (永続ボリューム要求、PVC) を設定するために、この ConfigMap を作成します。
apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | prometheusK8s: volumeClaimTemplate: spec: storageClassName: fast volumeMode: filesystem resources: requests: storage: 40Gi
ここで、prometheusK8s は Prometheus コンポーネントを定義し、続く行ではその設定を定義します。
- 変更を適用するためにファイルを保存します。新規設定の影響を受けた Pod は自動的に再起動されます。
1.2.4. 設定可能なモニタリングコンポーネント
以下の表は、設定可能なモニタリングコンポーネントと、ConfigMap でコンポーネントを指定するために使用されるキーを示しています。
コンポーネント | キー |
---|---|
Prometheus Operator |
|
Prometheus |
|
Alertmanager 0.14.0 |
|
kube-state-metrics |
|
Grafana |
|
Telemeter クライアント |
|
Prometheus アダプター |
|
この一覧では、Prometheus および Alertmanager のみが多数の設定オプションを持ちます。通常、その他のすべてのコンポーネントは指定されたノードにデプロイされるように nodeSelector
フィールドのみを提供します。
1.2.5. モニタリングコンポーネントの異なるノードへの移動
モニタリングスタックコンポーネントのいずれかを指定されたノードに移動できます。
前提条件
-
cluster-monitoring-config
ConfigMap オブジェクトがdata/config.yaml
セクションに設定されていること。
手順
cluster-monitoring-config
ConfigMap の編集を開始します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
コンポーネントの
nodeSelector
制約をdata/config.yaml
に指定します。apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | component: nodeSelector: node key: node value node key: node value ...
<component>
を適宜置き換え、<node key>: <node value>
を、宛先ノードを指定するキーと値のペアのマップに置き換えます。通常は、単一のキーと値のペアのみが使用されます。コンポーネントは、指定されたキーと値のペアのそれぞれをラベルとして持つノードでのみ実行できます。ノードには追加のラベルを持たせることもできます。
たとえば、コンポーネントを
foo: bar
というラベルが付けられたノードに移動するには、以下を使用します。apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | prometheusOperator: nodeSelector: foo: bar prometheusK8s: nodeSelector: foo: bar alertmanagerMain: nodeSelector: foo: bar kubeStateMetrics: nodeSelector: foo: bar grafana: nodeSelector: foo: bar telemeterClient: nodeSelector: foo: bar k8sPrometheusAdapter: nodeSelector: foo: bar
- 変更を適用するためにファイルを保存します。新しい設定の影響を受けるコンポーネントは新しいノードに自動的に移動します。
追加リソース
-
nodeSelector
制約についての詳細は、Kubernetes ドキュメント を参照してください。
1.2.6. 永続ストレージの設定
クラスターモニタリングを永続ストレージと共に実行すると、メトリクスは永続ボリュームに保存され、Pod の再起動または再作成後も維持されます。これは、メトリクスデータまたはアラートデータをデータ損失から保護する必要がある場合に適しています。実稼働環境では、永続ストレージを設定することを強く推奨します。
「設定可能な推奨のストレージ技術」を参照してください。
前提条件
- ディスクが一杯にならないように十分な永続ストレージを確保します。必要な永続ストレージは Pod 数によって異なります。永続ストレージのシステム要件については、「Prometheus データベースのストレージ要件」を参照してください。
- 動的にプロビジョニングされるストレージを有効にしない場合、Persistent Volume Claime (永続ボリューム要求、PVC) で要求される永続ボリューム (PV) が利用できる状態にあることを確認する必要があります。Prometheus には 2 つのレプリカがあり、Alertmanager には 3 つのレプリカがあるため、モニタリングスタック全体をサポートするには、合計で 5 つの PV が必要になります。
- ストレージのブロックタイプを使用します。
1.2.6.1. Persistent Volume Claim (永続ボリューム要求) の設定
Prometheus または Alertmanager で永続ボリューム (PV) を使用するには、まず Persistent Volume Claim (永続ボリューム要求、PVC) を設定する必要があります。
前提条件
- 必要なストレージクラスが設定されていること。
-
cluster-monitoring-config
ConfigMap オブジェクトがdata/config.yaml
セクションに設定されていること。
手順
cluster-monitoring-config
ConfigMap を編集します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
コンポーネントの PVC 設定を
data/config.yaml
の下に配置します。apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | component: volumeClaimTemplate: metadata: name: PVC name spec: storageClassName: storage class resources: requests: storage: 40Gi
volumeClaimTemplate
の指定方法については、PersistentVolumeClaims についての Kubernetes ドキュメント を参照してください。たとえば、設定された OpenShift Container Platform ブロック PV を Prometheus の永続ストレージとして要求する PVC を設定するには、以下を使用します。
apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | prometheusK8s: volumeClaimTemplate: metadata: name: my-prometheus-claim spec: storageClassName: gluster-block resources: requests: storage: 40Gi
さらに、設定された OpenShift Container Platform ブロック PV を Alertmanager の永続ストレージとして要求する PVC を設定するには、以下を使用できます。
apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | alertmanagerMain: volumeClaimTemplate: metadata: name: my-alertmanager-claim spec: storageClassName: gluster-block resources: requests: storage: 40Gi
- 変更を適用するためにファイルを保存します。新規設定の影響を受けた Pod は自動的に再起動され、新規ストレージ設定が適用されます。
1.2.6.2. Prometheus メトリクスデータの保持期間の編集
デフォルトで、Prometheus クラスターモニタリングスタックは、Prometheus データの保持期間を 15 日間に設定します。この保持期間は、データ削除のタイミングを調整するために変更できます。
前提条件
-
cluster-monitoring-config
ConfigMap オブジェクトがdata/config.yaml
セクションに設定されていること。
手順
cluster-monitoring-config
ConfigMap の編集を開始します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
保持期間の設定を
data/config.yaml
に配置します。apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | prometheusK8s: retention: time specification
<time specification>
を、ms
(ミリ秒)、s
(秒)、m
(分)、h
(時)、d
(日)、w
(週)、またはy
(年) が直後に続く数字に置き換えます。たとえば、保持期間を 24 時間に設定するには、以下を使用します。
apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | prometheusK8s: retention: 24h
- 変更を適用するためにファイルを保存します。新規設定の影響を受けた Pod は自動的に再起動されます。
1.2.7. Alertmanager の設定
Prometheus Alertmanager は、以下を含む受信アラートを管理するコンポーネントです。
- アラートの非通知 (silence)
- アラートの抑制 (inhibition)
- アラートの集約 (aggregation)
- アラートの安定した重複排除
- アラートのグループ化
- メール、PagerDuty、および HipChat などの受信手段によるグループ化されたアラート通知の送信
1.2.7.1. Alertmanager のデフォルト設定
OpenShift Container Platform Monitoring Alertmanager クラスターのデフォルト設定:
global: resolve_timeout: 5m route: group_wait: 30s group_interval: 5m repeat_interval: 12h receiver: default routes: - match: alertname: Watchdog repeat_interval: 5m receiver: watchdog receivers: - name: default - name: watchdog
OpenShift Container Platform モニタリングには、モニターする側のインフラストラクチャーの可用性を確保するために常にデフォルトでトリガーされる「Watchdog アラート」機能が同梱されています。
1.2.7.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 -d > alertmanager.yaml
ファイル
alertmanager.yaml
の設定を新規設定に変更します。data: config.yaml: | global: resolve_timeout: 5m route: group_wait: 30s group_interval: 5m repeat_interval: 12h receiver: default routes: - match: alertname: Watchdog repeat_interval: 5m receiver: watchdog - match: service: _your service_ 1 routes: - match: _your matching rules_ 2 receiver: _receiver_ 3 receivers: - name: default - name: watchdog - name: _receiver_ _receiver configuration_
たとえば、この一覧では通知用に PagerDuty を設定しています。
data: config.yaml: | global: resolve_timeout: 5m route: group_wait: 30s group_interval: 5m repeat_interval: 12h receiver: default routes: - match: alertname: Watchdog repeat_interval: 5m receiver: watchdog - match: service: example-app routes: - match: severity: critical receiver: team-frontend-page receivers: - name: default - name: watchdog - name: team-frontend-page pagerduty_configs: - service_key: "your-key"
この設定では、
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=-
追加リソース
- PagerDuty についての詳細は、PagerDuty の公式サイトを参照してください。
-
service_key
を取得する方法については、『PagerDuty Prometheus Integration Guide 』を参照してください。 - 各種のアラートレシーバー経由でアラートを設定する方法については、「Alertmanager configuration」を参照してください。
1.2.7.3. アラートルール
デフォルトで、OpenShift Container Platform クラスター モニタリングには事前に定義されたアラートルールのセットが同梱されます。
以下に留意してください。
- デフォルトのアラートルールは OpenShift Container Platform クラスター用に使用され、それ以外の目的では使用されません。たとえば、クラスターの永続ボリュームについてのアラートを取得できますが、カスタム namespace の永続ボリュームについてのアラートは取得できません。
- 現時点で、カスタムアラートルールを追加することはできません。
- 一部のアラートルールには同じ名前が付けられています。これは意図的な理由によるものです。それらは同じイベントについてのアラートを送信しますが、それぞれ異なるしきい値、重大度、およびそれらの両方が設定されます。
- 抑制ルールを使用すると、高い重大度のアラートが発生する場合に重大度の低いアラートが抑制されます。
1.2.7.4. 有効なアラートルールのアクションの一覧表示
現時点でクラスターに適用されるアラートルールを一覧表示できます。
手順
必要なポート転送を設定します。
$ oc -n openshift-monitoring port-forward svc/prometheus-operated 9090
有効なアラートルールおよびそれらのプロパティーが含まれる JSON オブジェクトを取得します。
$ curl -s http://localhost:9090/api/v1/rules | jq '[.data.groups[].rules[] | select(.type=="alerting")]' [ { "name": "ClusterOperatorDown", "query": "cluster_operator_up{job=\"cluster-version-operator\"} == 0", "duration": 600, "labels": { "severity": "critical" }, "annotations": { "message": "Cluster operator {{ $labels.name }} has not been available for 10 mins. Operator may be down or disabled, cluster will not be kept up to date and upgrades will not be possible." }, "alerts": [], "health": "ok", "type": "alerting" }, { "name": "ClusterOperatorDegraded", ...
追加リソース
- Alertmanager ドキュメントを参照してください。
次のステップ
- クラスターアラートの管理
- Telemetry について確認してください。必要な場合はこれからオプトアウトしてください。
1.3. クラスターアラートの管理
OpenShift Container Platform 4 は、Alertmanager の Web インターフェースを提供します。これを使用してアラートを管理できます。 このセクションでは、アラート UI を使用する方法について説明します。
1.3.1. アラート UI の内容
このセクションでは、アラート UI、つまり Alertmanager の Web インターフェースの内容について説明します。
アラート UI の主なページとして、Alerts と Silences という 2 つのページがあります。
Alerts ページは、OpenShift Container Platform Web コンソールの Monitoring → Alerts にあります。
- 名前によるアラートのフィルター。
- 状態によるアラートのフィルター。アラートを実行するには、一部のアラートにおいて、タイムアウトの間に特定の条件が true である必要があります。アラートの条件が現時点で true であるが、タイムアウトに達していない場合、このアラートは Pending 状態になります。
- アラート名。
- アラートの説明。
- アラートの現在の状態と、アラートがこの状態に切り替わった時。
- アラートの重大度レベルの値。
- アラートに関して実行できるアクション。
Silences ページは、OpenShift Container Platform Web コンソールの Monitoring → Silences にあります。
- アラートのサイレンスの作成。
- 名前によるサイレンスのフィルター。
- 状態によるサイレンスのフィルター。サイレンスが保留中の場合、これは後で開始するようにスケジュールされているため、アクティブな状態ではありません。また、サイレンスの期間が過ぎると、終了時間に達したためにアクティブでなくなります。
- サイレンスの説明。これには、一致するアラートの仕様も含まれます。
- サイレンスの現在の状態。サイレンスがアクティブな場合は終了時間を示し、保留状態の場合は、開始時間を示します。
- サイレンス機能によってサイレンスにされているアラート数。
- サイレンスに関して実行できるアクション。
さらに、これらのページのそれぞれのタイトルの横には、古い Alertmanager インターフェースへのリンクがあります。
1.3.2. アラートおよびアラートルールについての情報の取得
アラートを見つけ、アラートおよびその規定するアラートルールについての情報を表示できます。
手順
- OpenShift Container Platform Web コンソールを開き、 Monitoring → Alerts に移動します。
- オプション: Filter alerts by name フィールドを使用して、名前でアラートをフィルターします。
- オプション: 1 つ以上の状態ボタン Firing、Silenced、Pending、Not firing を使用して、状態でアラートをフィルターします。
- オプション: 1 つ以上の Name、State、および Severity 列ヘッダーをクリックして、アラートを並び替えます。
アラートの表示後に、アラートまたはアラートを規定するアラートルールの詳細のいずれかを表示できます。
アラートの詳細を表示するには、アラートの名前をクリックします。これは、アラートの詳細を含むページです。
このページには、アラートの時系列を示すグラフがあります。また、以下をはじめとするアラートについての情報も含まれます。
- アラートを規定するアラートルールへのリンク
- アラートの説明。
アラートルールの詳細を表示するには、最後の列のボタンをクリックし、View Alerting Rule を選択します。これは、アラートルールの詳細が含まれるページです。
このページには、以下をはじめとするアラートルールについての情報が含まれます。
- アラートルール名、重大度、および説明
- アラートを発生させるための条件を定義する式
- アラートを発生させるための条件が true である期間
- アラートルールに規定される各アラートのグラフ。 アラートを発生させる際に使用する値が表示されます。
- アラートルールで規定されるすべてのアラートについての表
1.3.3. アラートをサイレンスにする
特定のアラート、または定義する仕様に一致するアラートのいずれかをサイレンスにすることができます。
手順
アラート仕様を作成してアラートのセットをサイレンスにするには、以下を実行します。
- OpenShift Container Platform Web コンソールの Monitoring → Silences ページに移動します。
- Create Silence をクリックします。
- Create Silence フォームにデータを設定します。
- サイレンスを作成するには、Create をクリックします。
特定のアラートをサイレンスにするには、以下を実行します。
- OpenShift Container Platform Web コンソールの Monitoring → Alerts ページに移動します。
- サイレンスにする必要のあるアラートについて、最後の列のボタンをクリックし、Silence Alert をクリックします。Create Silence フォームが、選択したアラートの事前にデータが設定された仕様と共に表示されます。
- オプション: サイレンスを変更します。
- サイレンスを作成するには、Create をクリックします。
1.3.4. サイレンスについての情報の取得
サイレンスを検索し、その詳細状態を表示できます。
手順
- OpenShift Container Platform Wed コンソールを開き、 Monitoring → Silences に移動します。
- オプション: Filter Silences by name フィールドを使用して、名前でサイレンスをフィルターします。
- オプション: 1 つ以上の状態ボタン Active、Pending、Expired を使用して、状態でサイレンスをフィルターします。
- オプション: 1 つ以上の Name、State、および Firing alerts 列ヘッダーをクリックしてサイレンスを並び替えます。
サイレンスの表示後、その名前をクリックして、以下をはじめとする詳細情報を確認します。
- アラート仕様
- 状態
- 開始時間
- 終了時間
- 発生するアラートの数および一覧
1.3.5. サイレンスの編集
サイレンスは編集することができます。 これにより、既存のサイレンスが期限切れとなり、変更された設定で新規のサイレンスが作成されます。
手順
- Monitoring → Silences 画面に移動します。
変更するサイレンスについて、最後の列のボタンをクリックし、Edit silence をクリックします。
または、特定のサイレンスについて、 Silence Overview 画面で Actions → Edit Silence をクリックできます。
- Edit Silence 画面では、変更を入力し、Save ボタンをクリックします。これにより、既存のサイレンスが期限切れとなり、選択された設定でサイレンスが作成されます。
1.3.6. 有効期限切れにするサイレンス
サイレンスは有効期限切れにすることができます。サイレンスはいったん期限切れになると、永久に無効にされます。
手順
- Monitoring → Silences ページに移動します。
期限切れにするサイレンスについては、最後の列のボタンをクリックし、Expire Silence をクリックします。
または、特定のサイレンスについて、Silence Overview ページで Actions → Expire Silence ボタンをクリックできます。
- Expire Silence をクリックして確定します。これにより、サイレンスが期限切れになります。
1.4. Prometheus、Alertmanager、および Grafana へのアクセス
モニタリングスタックによって収集されるデータを使用するには、Prometheus、Alertmanager、および Grafana インターフェースを使用できます。これらのインターフェースはデフォルトで利用可能です。
1.4.1. Web コンソールの使用による Prometheus、Alerting UI、および Grafana へのアクセス
OpenShift Container Platform Web コンソールで Web ブラウザーを使用し、Prometheus、Alerting UI、および 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" → "Alerts" or "Monitoring" → "Silences" に移動します。
Grafana にアクセスするには、"Monitoring" → "Dashboards" に移動します。
1.4.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 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 ...
https://
をアドレスに追加します。 暗号化されていない接続を使用して Web UI にアクセスすることはできません。たとえば、以下は Alertmanager の生成される URL です。
https://alertmanager-main-openshift-monitoring.apps.url.openshift.com
- Web ブラウザーを使用してアドレスに移動し、認証します。
追加リソース
- Alertmanager の新規インターフェースの説明については、「クラスターアラートの管理」を参照してください。
第2章 自動スケーリングのカスタムアプリケーションメトリクスの公開
Horizontal Pod Autoscaler のカスタムアプリケーションメトリクスをエクスポートできます。
2.1. Horizontal Pod Autoscaling のカスタムアプリケーションメトリクスの公開
prometheus-adapter
リソースを使用して、Horizontal Pod Autoscaler のカスタムアプリケーションメトリクスを公開できます。
Prometheus アダプターはテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。
前提条件
-
カスタム Prometheus インスタンスがインストールされていること。この例では、Prometheus が
default
namespace にインストールされていることが前提になります。 -
アプリケーションのモニタリングを設定されていること。この例では、アプリケーションとそのサービスモニターが
default
namespace にインストールされていることが前提になります。
手順
-
設定の YAML ファイルを作成します。この例では、これは
deploy.yaml
というファイルになります。 prometheus-adapter
のサービスアカウント、必要なロールおよびロールバインディングを作成するための設定を追加します。kind: ServiceAccount apiVersion: v1 metadata: name: custom-metrics-apiserver namespace: default --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: custom-metrics-server-resources rules: - apiGroups: - custom.metrics.k8s.io resources: ["*"] verbs: ["*"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: custom-metrics-resource-reader rules: - apiGroups: - "" resources: - namespaces - pods - services verbs: - get - list --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: custom-metrics:system:auth-delegator roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:auth-delegator subjects: - kind: ServiceAccount name: custom-metrics-apiserver namespace: default --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: custom-metrics-auth-reader namespace: kube-system roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: extension-apiserver-authentication-reader subjects: - kind: ServiceAccount name: custom-metrics-apiserver namespace: default --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: custom-metrics-resource-reader roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: custom-metrics-resource-reader subjects: - kind: ServiceAccount name: custom-metrics-apiserver namespace: default --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: hpa-controller-custom-metrics roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: custom-metrics-server-resources subjects: - kind: ServiceAccount name: horizontal-pod-autoscaler namespace: kube-system ---
prometheus-adapter
のカスタムメトリクスの設定を追加します。apiVersion: v1 kind: ConfigMap metadata: name: adapter-config namespace: default data: config.yaml: | rules: - seriesQuery: 'http_requests_total{namespace!="",pod!=""}' 1 resources: overrides: namespace: {resource: "namespace"} pod: {resource: "pod"} service: {resource: "service"} name: matches: "^(.*)_total" as: "${1}_per_second" 2 metricsQuery: 'sum(rate(<<.Series>>{<<.LabelMatchers>>}[2m])) by (<<.GroupBy>>)' ---
prometheus-adapter
を API サービスとして登録するための設定を追加します。apiVersion: v1 kind: Service metadata: annotations: service.alpha.openshift.io/serving-cert-secret-name: prometheus-adapter-tls labels: name: prometheus-adapter name: prometheus-adapter namespace: default spec: ports: - name: https port: 443 targetPort: 6443 selector: app: prometheus-adapter type: ClusterIP --- apiVersion: apiregistration.k8s.io/v1beta1 kind: APIService metadata: name: v1beta1.custom.metrics.k8s.io spec: service: name: prometheus-adapter namespace: default group: custom.metrics.k8s.io version: v1beta1 insecureSkipTLSVerify: true groupPriorityMinimum: 100 versionPriority: 100 ---
使用する Prometheus アダプターイメージを表示します。
$ kubectl get -n openshift-monitoring deploy/prometheus-adapter -o jsonpath="{..image}" quay.io/openshift-release-dev/ocp-v4.1-art-dev@sha256:76db3c86554ad7f581ba33844d6a6ebc891236f7db64f2d290c3135ba81c264c
prometheus-adapter
をデプロイするための設定を追加します。apiVersion: apps/v1 kind: Deployment metadata: labels: app: prometheus-adapter name: prometheus-adapter namespace: default spec: replicas: 1 selector: matchLabels: app: prometheus-adapter template: metadata: labels: app: prometheus-adapter name: prometheus-adapter spec: serviceAccountName: custom-metrics-apiserver containers: - name: prometheus-adapter image: openshift-release-dev/ocp-v4.1-art-dev 1 args: - --secure-port=6443 - --tls-cert-file=/var/run/serving-cert/tls.crt - --tls-private-key-file=/var/run/serving-cert/tls.key - --logtostderr=true - --prometheus-url=http://prometheus-operated.default.svc:9090/ - --metrics-relist-interval=1m - --v=4 - --config=/etc/adapter/config.yaml ports: - containerPort: 6443 volumeMounts: - mountPath: /var/run/serving-cert name: volume-serving-cert readOnly: true - mountPath: /etc/adapter/ name: config readOnly: true - mountPath: /tmp name: tmp-vol volumes: - name: volume-serving-cert secret: secretName: prometheus-adapter-tls - name: config configMap: name: adapter-config - name: tmp-vol emptyDir: {}
- 1
image: openshift-release-dev/ocp-v4.1-art-dev
は、直前の手順にある Prometheus Adapter イメージを指定します。
設定ファイルをクラスターに追加します。
$ oc apply -f deploy.yaml
- アプリケーションのメトリクスが公開され、Horizontal Pod Autoscaling を設定するために使用できます。
追加リソース
Legal Notice
Copyright © 2024 Red Hat, Inc.
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.