Cluster Observability Operator
OpenShift Container Platform での Cluster Observability Operator の設定と使用
概要
第1章 Cluster Observability Operator リリースノート
Cluster Observability Operator はテクノロジープレビュー機能としてのみ使用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
Cluster Observability Operator (COO) は、オプションの OpenShift Container Platform Operator です。管理者はこれを使用して、さまざまなサービスやユーザーが使用できるように個別に設定できる、スタンドアロンのモニタリングスタックを作成できます。
COO は、OpenShift Container Platform のビルトインモニタリング機能を補完します。これは、Cluster Monitoring Operator (CMO) で管理されるデフォルトのプラットフォームおよびユーザーワークロードモニタリングスタックと並行してデプロイできます。
これらのリリースノートは、OpenShift Container Platform での Cluster Observability Operator の開発を追跡します。
次の表に、Cluster Observability Operator と OpenShift Container Platform のバージョンに応じて利用可能な機能に関する情報を示します。
COO のバージョン | OCP のバージョン | ダッシュボード | 分散トレーシング | ロギング | トラブルシューティングパネル |
---|---|---|---|---|---|
0.2.0 | 4.11 | ✔ | ✘ | ✘ | ✘ |
0.3.0 以降 | 4.11 - 4.15 | ✔ | ✔ | ✔ | ✘ |
0.3.0 以降 | 4.16 以降 | ✔ | ✔ | ✔ | ✔ |
1.1. Cluster Observability Operator 0.4.1
Cluster Observability Operator 0.4.1 では、次のアドバイザリーを利用できます。
1.1.1. 新機能および機能拡張
- Prometheus および Alertmanager の WebTLS を設定できるようになりました。
1.1.2. CVE
1.1.3. バグ修正
-
以前は、ダッシュボード UI プラグインを削除しても、
consoles.operator.openshift.io
リソースにはconsole-dashboards-plugin
が残っていました。このリリースでこの問題が解決されました。(COO-152) - 以前は、Web コンソールに Red Hat COO の正しいアイコンが表示されませんでした。このリリースでこの問題が解決されました。(COO-353)
- 以前は、Web コンソールから COO をインストールすると、サポートセクションに無効なリンクが含まれていました。このリリースでこの問題が解決されました。(COO-354)
- 以前は、COO のクラスターサービスバージョン (CSV) は、非公式のドキュメントバージョンにリンクされていました。このリリースでこの問題が解決されました。(COO-356)
1.2. Cluster Observability Operator 0.4.0
Cluster Observability Operator 0.4.0 では、次のアドバイザリーを利用できます。
1.2.1. 新機能および機能拡張
1.2.1.1. トラブルシューティング UI プラグイン
- トラブルシューティング UI パネルが改善され、特定の開始シグナルを選択して絞り込むことができるようになりました。
- 深さを選択するオプションにより、Korrel8r クエリーの可視性が向上しました。
-
OpenShift Container Platform バージョン 4.17 以降のユーザーは、アプリケーションランチャー
からトラブルシューティング UI パネルにアクセスできます。または、バージョン 4.16 以降では、Web コンソールで Observe → Alerting をクリックしてアクセスすることもできます。
詳細は、トラブルシューティング UI プラグイン を参照してください。
1.2.1.2. 分散トレーシング UI プラグイン
- 分散トレーシング UI プラグインが強化され、トレースの探索にガントチャートが利用できるようになりました。
詳細は、分散トレーシング UI プラグイン を参照してください。
1.2.2. バグ修正
- 以前は、通常のユーザーが Web コンソールの Developer パースペクティブで Observe → Logs をクリックしてアクセスした場合はメトリクスを利用できませんでした。このリリースでこの問題が解決されました。(COO-288)
- 以前は、トラブルシューティング UI プラグインによって、ネットワーク可観測性に対して誤ったフィルターが使用されていました。このリリースでこの問題が解決されました。(COO-299)
- 以前は、トラブルシューティング UI プラグインによって、Pod ラベル検索に対して誤った URL が生成されていました。このリリースでこの問題が解決されました。(COO-298)
-
以前は、分散トレーシング UI プラグインに認可の脆弱性がありました。このリリースでこの問題が解決されました。今後はマルチテナントの
TempoStack
およびTempoMonolithic
インスタンスのみを使用することで、分散トレーシング UI プラグインが強化されました。
1.3. Cluster Observability Operator 0.3.2
Cluster Observability Operator 0.3.2 では、次のアドバイザリーを利用できます。
1.3.1. 新機能および機能拡張
-
このリリースでは、
MonitoringStack
コンポーネントで toleration とノードセレクターを使用できるようになりました。
1.3.2. バグ修正
-
以前は、ロギング UIPlugin を特定のバージョンの OpenShift Container Platform にインストールすると、ロギング UIPlugin が
Available
状態にならず、ロギング Pod が作成されませんでした。このリリースでこの問題が解決されました。(COO-260)
1.4. Cluster Observability Operator 0.3.0
Cluster Observability Operator 0.3.0 では、次のアドバイザリーを利用できます。
1.4.1. 新機能および機能拡張
- このリリースでは、Cluster Observability Operator は、今後の OpenShift Container Platform 可観測性 Web コンソール UI プラグインと可観測性コンポーネントのバックエンドサポートを追加します。
1.5. Cluster Observability Operator 0.2.0
Cluster Observability Operator 0.2.0 では、次のアドバイザリーを利用できます。
1.5.1. 新機能および機能拡張
- このリリースでは、Cluster Observability Operator は、OpenShift Container Platform Web コンソールユーザーインターフェイス (UI) の可観測性関連プラグインのインストールと管理をサポートします。(COO-58)
1.6. Cluster Observability Operator 0.1.3
Cluster Observability Operator 0.1.3 では、次のアドバイザリーを利用できます。
1.6.1. バグ修正
-
以前は、
http://<prometheus_url>:9090/graph
で Prometheus Web ユーザーインターフェイス (UI) にアクセスしようとすると、Error opening React index.html: open web/ui/static/react/index.html: no such file or directory
エラーメッセージが表示されていました。このリリースでは問題が解決され、Prometheus Web UI が正しく表示されるようになりました。(COO-34)
1.7. Cluster Observability Operator 0.1.2
Cluster Observability Operator 0.1.2 では、次のアドバイザリーを利用できます。
1.7.1. CVE
1.7.2. バグ修正
- 以前は、特定のクラスターサービスバージョン (CSV) アノテーションが COO のメタデータに含まれていませんでした。これらのアノテーションが欠落していたため、COO の一部の特長と機能がパッケージマニフェストまたは OperatorHub ユーザーインターフェイスに表示されませんでした。このリリースで、欠落していたアノテーションが追加され、この問題が解決されました。(COO-11)
- 以前は、COO の自動更新が機能せず、OperatorHub で新しいバージョンが利用可能であっても、Operator の新しいバージョンで古いバージョンが自動的に置き換えられませんでした。このリリースでこの問題が解決されました。(COO-12)
-
以前は、Thanos Querier が 127.0.0.1 (
localhost
) のポート 9090 でネットワークトラフィックのみをリッスンしていたため、Thanos Querier サービスにアクセスしようとすると502 Bad Gateway
エラーが発生しました。このリリースで、Thanos Querier 設定が更新され、コンポーネントがデフォルトポート (10902) でリッスンするようになり、問題が解決されました。この変更の結果、必要に応じて、SSA (Server Side Apply) を使用してポートを変更し、プロキシーチェーンを追加することもできるようになりました。(COO-14)
1.8. Cluster Observability Operator 0.1.1
Cluster Observability Operator 0.1.1 では、次のアドバイザリーを利用できます。
1.8.1. 新機能および機能拡張
このリリースでは、Cluster Observability Operator が更新され、制限されたネットワークまたは非接続環境での Operator のインストールがサポートされるようになりました。
1.9. Cluster Observability Operator 0.1
このリリースでは、Cluster Observability Operator のテクノロジープレビューバージョンが OperatorHub で利用できるようになります。
第2章 Cluster Observability Operator の概要
Cluster Observability Operator はテクノロジープレビュー機能としてのみ使用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
Cluster Observability Operator (COO) は、高度にカスタマイズ可能なモニタリングスタックを作成し、管理するために設計された OpenShift Container Platform のオプションのコンポーネントです。これにより、クラスター管理者はモニタリングの設定と管理を大幅に自動化でき、デフォルトの OpenShift Container Platform のモニタリングシステムと比べて、各 namespace に対するより詳細でカスタマイズされたビューを提供できます。
COO は、次のモニタリングコンポーネントをデプロイします。
- Prometheus: リモート書き込みを使用してメトリクスを外部エンドポイントに送信できる高可用性 Prometheus インスタンス。
- Thanos Querier (オプション): Prometheus インスタンスを中央の場所からクエリーできるようにします。
- Alertmanager (オプション): さまざまなサービスのアラート設定機能を提供します。
- UI plugins (オプション): モニタリング、ロギング、分散トレーシング、およびトラブルシューティング用にプラグインで可観測性機能を強化します。
- Korrel8r (オプション): オープンソースの Korrel8r プロジェクトが提供する可観測性シグナルの相関を提供します。
2.1. デフォルトのモニタリングスタックと比較した COO
COO コンポーネントは、Cluster Monitoring Operator (CMO) でデプロイおよび管理されるデフォルトのクラスター内モニタリングスタックとは独立して機能します。2 つの Operator でデプロイされたモニタリングスタックは競合しません。CMO でデプロイされたデフォルトのプラットフォームモニタリングコンポーネントに加え、COO モニタリングスタックを使用できます。
COO とデフォルトのクラスター内のモニタリングスタックの主な相違点を次の表に示します。
機能 | COO | デフォルトのモニタリングスタック |
---|---|---|
スコープおよびインテグレーション | クラスターやワークロードのパフォーマンスを含め、エンタープライズレベルのニーズに対応した包括的なモニタリングと分析を提供します。 ただし、OpenShift Container Platform との直接統合がなく、通常はダッシュボードに外部 Grafana インスタンスが必要です。 | クラスター内のコアコンポーネント (API サーバーや etcd など) および OpenShift 固有の namespace に限定されます。 OpenShift Container Platform へのディープインテグレーションがあり、コンソールのダッシュボードやアラート管理が含まれています。 |
設定とカスタマイズ | データ保持期間、ストレージ方法、収集したデータタイプなど、より広範な設定オプション。 COO は、カスタマイズを強化する Server-Side Apply (SSA) を使用して、カスタムリソース内にある 1 つの設定可能フィールドの所有権をユーザーに委譲できます。 | カスタマイズオプションが制限された組み込み設定。 |
データの保持とストレージ | 長期のデータ保持。履歴分析と容量計画をサポートします。 | 短期間のデータ保持。短期間のモニタリングとリアルタイム検出に焦点を当てています。 |
2.2. COO を使用する主な利点
COO のデプロイは、デフォルトのモニタリングスタックを使用して達成することが困難なモニタリング要件に対応する際に役立ちます。
2.2.1. 拡張性
- COO でデプロイされたモニタリングスタックにさらにメトリクスを追加できますが、これをコアプラットフォームモニタリングで行った場合はサポートされません。
- フェデレーションを介して、コアプラットフォームのモニタリングからクラスター固有のメトリクスを受け取ることができます。
- COO は、トレンド予測や異常検出などの高度なモニタリングシナリオをサポートします。
2.2.2. マルチテナンシーのサポート
- ユーザー namespace ごとにモニタリングスタックを作成できます。
- namespace ごとに複数のスタックをデプロイすることや、複数の namespace に単一のスタックをデプロイすることができます。
- COO は、異なるチームのアラートとレシーバーの独立した設定を可能にします。
2.2.3. スケーラビリティー
- 単一クラスターで複数のモニタリングスタックをサポートします。
- 手動シャーディングを使用した大規模なクラスターのモニタリングを可能にします。
- メトリクスが単一の Prometheus インスタンスの機能を超えるケースに対応します。
2.2.4. 柔軟性
- OpenShift Container Platform リリースサイクルから切り離されます。
- より速いリリースサイクルを実現し、変化する要件へ迅速に対応します。
- アラートルールを独立して管理します。
2.3. COO のターゲットユーザー
COO は、特に複雑なマルチテナントエンタープライズ環境で、高いカスタマイズ性、スケーラビリティー、および長期のデータ保持が必要なユーザーに適しています。
2.3.1. エンタープライズレベルのユーザーおよび管理者
エンタープライズユーザーには、高度なパフォーマンス分析、長期のデータ保持、トレンド予測、履歴分析など、OpenShift Container Platform クラスターの詳細なモニタリング機能が必要です。これらの機能により、企業はリソースの使用状況をより深く理解し、パフォーマンスの問題を防ぎ、リソースの割り当てを最適化できます。
2.3.2. マルチテナント環境でのオペレーションチーム
マルチテナンシーのサポートにより、COO はさまざまなチームがプロジェクトやアプリケーションのモニタリングビューを設定できるため、柔軟なモニタリングニーズがあるチームに適しています。
2.3.3. 開発およびオペレーションチーム
COO は、詳細なトラブルシューティング、異常検出、開発および運用時のパフォーマンス調整のために、きめ細かなモニタリングとカスタマイズ可能な可観測性ビューを提供します。
2.4. Server-Side Apply を使用した Prometheus リソースのカスタマイズ
Server-Side Apply は、Kubernetes リソースの共同管理を可能にする機能です。コントロールプレーンは、さまざまなユーザーおよびコントローラーが Kubernetes オブジェクト内のフィールドをどのように管理するかを追跡します。フィールドマネージャーの概念を導入し、フィールドの所有権を追跡します。この集中制御により、競合検出および解決が行われ、意図しない上書きのリスクが軽減されます。
Client-Side Apply と比較すると、より宣言的であり、最後に適用された状態ではなく、フィールド管理を追跡します。
- Server-Side Apply
- リソースの状態を更新することで、削除や再作成を必要とせずに宣言型の設定を管理します。
- フィールド管理
- ユーザーは、他のフィールドに影響を与えずに、更新するリソースのフィールドを指定できます。
- 管理対象フィールド
-
Kubernetes は、メタデータ内の
managedFields
フィールドでオブジェクトの各フィールドを管理するユーザーに関するメタデータを保存します。 - Conflicts
- 複数のマネージャーが同じフィールドを変更しようとすると、競合が発生します。アプライヤーは、上書きするか、制御を放棄するか、または管理を共有するかを選択できます。
- マージストラテジー
- Server-Side Apply は、管理しているアクターに基づいてフィールドをマージします。
手順
次の設定を使用して
MonitoringStack
リソースを追加します。MonitoringStack
オブジェクトの例apiVersion: monitoring.rhobs/v1alpha1 kind: MonitoringStack metadata: labels: coo: example name: sample-monitoring-stack namespace: coo-demo spec: logLevel: debug retention: 1d resourceSelector: matchLabels: app: demo
sample-monitoring-stack
という名前の Prometheus リソースが、coo-demo
namespace に生成されます。次のコマンドを実行して、生成された Prometheus リソースの管理対象フィールドを取得します。$ oc -n coo-demo get Prometheus.monitoring.rhobs -oyaml --show-managed-fields
出力例
managedFields: - apiVersion: monitoring.rhobs/v1 fieldsType: FieldsV1 fieldsV1: f:metadata: f:labels: f:app.kubernetes.io/managed-by: {} f:app.kubernetes.io/name: {} f:app.kubernetes.io/part-of: {} f:ownerReferences: k:{"uid":"81da0d9a-61aa-4df3-affc-71015bcbde5a"}: {} f:spec: f:additionalScrapeConfigs: {} f:affinity: f:podAntiAffinity: f:requiredDuringSchedulingIgnoredDuringExecution: {} f:alerting: f:alertmanagers: {} f:arbitraryFSAccessThroughSMs: {} f:logLevel: {} f:podMetadata: f:labels: f:app.kubernetes.io/component: {} f:app.kubernetes.io/part-of: {} f:podMonitorSelector: {} f:replicas: {} f:resources: f:limits: f:cpu: {} f:memory: {} f:requests: f:cpu: {} f:memory: {} f:retention: {} f:ruleSelector: {} f:rules: f:alert: {} f:securityContext: f:fsGroup: {} f:runAsNonRoot: {} f:runAsUser: {} f:serviceAccountName: {} f:serviceMonitorSelector: {} f:thanos: f:baseImage: {} f:resources: {} f:version: {} f:tsdb: {} manager: observability-operator operation: Apply - apiVersion: monitoring.rhobs/v1 fieldsType: FieldsV1 fieldsV1: f:status: .: {} f:availableReplicas: {} f:conditions: .: {} k:{"type":"Available"}: .: {} f:lastTransitionTime: {} f:observedGeneration: {} f:status: {} f:type: {} k:{"type":"Reconciled"}: .: {} f:lastTransitionTime: {} f:observedGeneration: {} f:status: {} f:type: {} f:paused: {} f:replicas: {} f:shardStatuses: .: {} k:{"shardID":"0"}: .: {} f:availableReplicas: {} f:replicas: {} f:shardID: {} f:unavailableReplicas: {} f:updatedReplicas: {} f:unavailableReplicas: {} f:updatedReplicas: {} manager: PrometheusOperator operation: Update subresource: status
-
metadata.managedFields
値を確認し、metadata
とspec
の一部のフィールドがMonitoringStack
リソースによって管理されていることを確認します。 MonitoringStack
リソースで制御されないフィールドを変更します。MonitoringStack
リソースによって設定されていないフィールドであるspec.enforcedSampleLimit
を変更します。prom-spec-edited.yaml
ファイルを作成します。prom-spec-edited.yaml
apiVersion: monitoring.rhobs/v1 kind: Prometheus metadata: name: sample-monitoring-stack namespace: coo-demo spec: enforcedSampleLimit: 1000
以下のコマンドを実行して YAML を適用します。
$ oc apply -f ./prom-spec-edited.yaml --server-side
注記--server-side
フラグを使用する必要があります。変更された Prometheus オブジェクトを取得し、
spec.enforcedSampleLimit
を持つmanagedFields
に、もう 1 つセクションがあることに注意してください。$ oc get prometheus -n coo-demo
出力例
managedFields: 1 - apiVersion: monitoring.rhobs/v1 fieldsType: FieldsV1 fieldsV1: f:metadata: f:labels: f:app.kubernetes.io/managed-by: {} f:app.kubernetes.io/name: {} f:app.kubernetes.io/part-of: {} f:spec: f:enforcedSampleLimit: {} 2 manager: kubectl operation: Apply
MonitoringStack
リソースによって管理されるフィールドを変更します。次の YAML 設定を使用して、
MonitoringStack
リソースによって管理されるフィールドであるspec.LogLevel
を変更します。# changing the logLevel from debug to info apiVersion: monitoring.rhobs/v1 kind: Prometheus metadata: name: sample-monitoring-stack namespace: coo-demo spec: logLevel: info 1
- 1
spec.logLevel
が追加されました。
以下のコマンドを実行して YAML を適用します。
$ oc apply -f ./prom-spec-edited.yaml --server-side
出力例
error: Apply failed with 1 conflict: conflict with "observability-operator": .spec.logLevel Please review the fields above--they currently have other managers. Here are the ways you can resolve this warning: * If you intend to manage all of these fields, please re-run the apply command with the `--force-conflicts` flag. * If you do not intend to manage all of the fields, please edit your manifest to remove references to the fields that should keep their current managers. * You may co-own fields by updating your manifest to match the existing value; in this case, you'll become the manager if the other manager(s) stop managing the field (remove it from their configuration). See https://kubernetes.io/docs/reference/using-api/server-side-apply/#conflicts
-
フィールド
spec.logLevel
はobservability-operator
によってすでに管理されているため、Server-Side Apply を使用して変更できないことに注意してください。 この変更を強制するには、
--force-conflicts
フラグを使用します。$ oc apply -f ./prom-spec-edited.yaml --server-side --force-conflicts
出力例
prometheus.monitoring.rhobs/sample-monitoring-stack serverside-applied
--force-conflicts
フラグの場合、このフィールドは強制的に変更できますが、同じフィールドがMonitoringStack
リソースでも管理されるため、Observability Operator は変更を検出し、MonitoringStack
リソースによって設定された値に戻します。注記MonitoringStack
リソースによって生成される一部の Prometheus フィールドは、logLevel
など、MonitoringStack
spec
スタンザのフィールドの影響を受けます。これらは、MonitoringStack
spec
を変更することで変更できます。Prometheus オブジェクトの
logLevel
を変更するには、次の YAML を適用してMonitoringStack
リソースを変更します。apiVersion: monitoring.rhobs/v1alpha1 kind: MonitoringStack metadata: name: sample-monitoring-stack labels: coo: example spec: logLevel: info
変更が実行されたことを確認するには、次のコマンドを実行してログレベルについてクエリーします。
$ oc -n coo-demo get Prometheus.monitoring.rhobs -o=jsonpath='{.items[0].spec.logLevel}'
出力例
info
Operator の新規バージョンが、以前にアクターによって生成および制御されるフィールドを生成する場合、アクターによって設定された値はオーバーライドされます。
たとえば、
MonitoringStack
リソースによって生成されないフィールドenforcedSampleLimit
を管理しているとします。Observability Operator がアップグレードされ、新しいバージョンの Operator がenforcedSampleLimit
の値を生成すると、以前に設定した値がオーバーライドされます。-
MonitoringStack
リソースによって生成されたPrometheus
オブジェクトには、モニタリングスタックによって明示的に設定されていないフィールドが含まれる場合があります。これらのフィールドは、デフォルト値があるために表示されます。
第3章 Cluster Observability Operator のインストール
Cluster Observability Operator はテクノロジープレビュー機能としてのみ使用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
クラスター管理者は、OpenShift Container Platform Web コンソールまたは CLI を使用して、OperatorHub から Cluster Observability Operator (COO) をインストールまたは削除できます。OperatorHub は、クラスター上に Operator をインストールして管理する Operator Lifecycle Manager (OLM) と連動して動作するユーザーインターフェイスです。
3.1. Web コンソールに Cluster Observability Operator のインストール
OpenShift Container Platform Web コンソールを使用して、OperatorHub から Cluster Observability Operator (COO) をインストールします。
前提条件
-
cluster-admin
クラスターロールを持つユーザーとしてクラスターにアクセスできる。 - OpenShift Container Platform Web コンソールにログインしている。
手順
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
-
Filter by keyword ボックスに
cluster observability operator
と入力します。 - 結果リストで Cluster Observability Operator をクリックします。
Operator に関する情報を読み、次のデフォルトのインストール設定を確認します。
- Update channel → development
- Version → <most_recent_version>
- Installation mode → All namespaces on the cluster (default)
- Installed Namespace → openshift-operators
- Update approval → Automatic
- オプション: 要件に合わせてデフォルトのインストール設定を変更します。たとえば、別の更新チャネルをサブスクライブしたり、Operator の古いリリースバージョンをインストールしたり、Operator の新しいバージョンへの更新に手動の承認を必要とするように選択できます。
- Install をクリックします。
検証
- Operators → Installed Operators に移動し、リストに Cluster Observability Operator エントリーが表示されていることを確認します。
関連情報
3.2. Web コンソールを使用した Cluster Observability Operator のアンインストール
OperatorHub を使用して Cluster Observability Operator (COO) をインストールした場合は、OpenShift Container Platform Web コンソールでそれをアンインストールできます。
前提条件
-
cluster-admin
クラスターロールを持つユーザーとしてクラスターにアクセスできる。 - OpenShift Container Platform Web コンソールにログインしている。
手順
- Operators → Installed Operators に移動します。
- リスト内で Cluster Observability Operator エントリーを見つけます。
-
このエントリーの
をクリックし、Uninstall Operator を選択します。
検証
- Operator → Installed Operator に移動し、Cluster Observability Operator エントリーがリストに表示されなくなったことを確認します。
第4章 サービスを監視するための Cluster Observability Operator 設定
Cluster Observability Operator はテクノロジープレビュー機能としてのみ使用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
Cluster Observability Operator (COO) で管理されるモニタリングスタックを設定することで、サービスのメトリクスを監視できます。
サービスのモニタリングをテストするには、次の手順に従います。
- サービスエンドポイントを定義するサンプルサービスをデプロイします。
-
COO によるサービスのモニタリング方法を指定する
ServiceMonitor
オブジェクトを作成します。 -
ServiceMonitor
オブジェクトを検出するためのMonitoringStack
オブジェクトを作成します。
4.1. Cluster Observability Operator のサンプルサービスのデプロイ
この設定では、ユーザー定義の ns1-coo
プロジェクトに prometheus-coo-example-app
という名前のサンプルサービスをデプロイします。このサービスは、カスタム version
メトリクスを公開します。
前提条件
-
cluster-admin
クラスターロールを持つユーザーとして、または namespace の管理権限を持つユーザーとして、クラスターにアクセスできる。
手順
prometheus-coo-example-app.yaml
という名前の YAML ファイルを作成します。このファイルには、namespace、デプロイメント、およびサービスに関する次の設定の詳細が含まれます。apiVersion: v1 kind: Namespace metadata: name: ns1-coo --- apiVersion: apps/v1 kind: Deployment metadata: labels: app: prometheus-coo-example-app name: prometheus-coo-example-app namespace: ns1-coo spec: replicas: 1 selector: matchLabels: app: prometheus-coo-example-app template: metadata: labels: app: prometheus-coo-example-app spec: containers: - image: ghcr.io/rhobs/prometheus-example-app:0.4.2 imagePullPolicy: IfNotPresent name: prometheus-coo-example-app --- apiVersion: v1 kind: Service metadata: labels: app: prometheus-coo-example-app name: prometheus-coo-example-app namespace: ns1-coo spec: ports: - port: 8080 protocol: TCP targetPort: 8080 name: web selector: app: prometheus-coo-example-app type: ClusterIP
- ファイルを保存します。
次のコマンドを実行して、設定をクラスターに適用します。
$ oc apply -f prometheus-coo-example-app.yaml
次のコマンドを実行して出力を確認し、Pod が実行されていることを確認します。
$ oc -n ns1-coo get pod
出力例
NAME READY STATUS RESTARTS AGE prometheus-coo-example-app-0927545cb7-anskj 1/1 Running 0 81m
4.2. Cluster Observability Operator によるサービスのモニタリング方法の指定
「Cluster Observability Operator のサンプルサービスのデプロイ」セクションで作成したサンプルサービスが公開するメトリクスを使用するには、/metrics
エンドポイントからメトリクスを取得するようにモニタリングコンポーネントを設定する必要があります。
この設定は、サービスのモニタリング方法を指定する ServiceMonitor
オブジェクト、または Pod のモニタリング方法を指定する PodMonitor
オブジェクトを使用して作成できます。ServiceMonitor
オブジェクトには Service
オブジェクトが必要です。PodMonitor
オブジェクトには必要ないため、MonitoringStack
オブジェクトは Pod が公開するメトリクスエンドポイントから直接メトリクスを取得できます。
この手順は、ns1-coo
namespace に prometheus-coo-example-app
という名前のサンプルサービスの ServiceMonitor
オブジェクトを作成する方法を示しています。
前提条件
-
cluster-admin
クラスターロールを持つユーザーとして、または namespace の管理権限を持つユーザーとして、クラスターにアクセスできる。 - Cluster Observability Operator がインストールされている。
prometheus-coo-example-app
サンプルサービスをns1-coo
namespace にデプロイしている。注記prometheus-example-app
サンプルサービスは、TLS 認証をサポートしていません。
手順
次の
ServiceMonitor
オブジェクト設定の詳細を含む YAML ファイルを、example-coo-app-service-monitor.yaml
という名前で作成します。apiVersion: monitoring.rhobs/v1 kind: ServiceMonitor metadata: labels: k8s-app: prometheus-coo-example-monitor name: prometheus-coo-example-monitor namespace: ns1-coo spec: endpoints: - interval: 30s port: web scheme: http selector: matchLabels: app: prometheus-coo-example-app
この設定は、
prometheus-coo-example-app
サンプルサービスが公開するメトリクスデータを収集するためにMonitoringStack
オブジェクトが参照するServiceMonitor
オブジェクトを定義します。次のコマンドを実行して、設定をクラスターに適用します。
$ oc apply -f example-coo-app-service-monitor.yaml
次のコマンドを実行して出力を観察し、
ServiceMonitor
リソースが作成されたことを確認します。$ oc -n ns1-coo get servicemonitors.monitoring.rhobs
出力例
NAME AGE prometheus-coo-example-monitor 81m
4.3. Cluster Observability Operator への MonitoringStack オブジェクト作成
ターゲットの prometheus-coo-example-app
サービスが公開するメトリクスデータを収集するには、「Cluster Observability Operator におけるサービスのモニター方法の指定」セクションで作成した ServiceMonitor
オブジェクトを参照する MonitoringStack
オブジェクトを作成します。この MonitoringStack
オブジェクトはサービスを検出し、そこから公開されているメトリクスデータを収集できます。
前提条件
-
cluster-admin
クラスターロールを持つユーザーとして、または namespace の管理権限を持つユーザーとして、クラスターにアクセスできる。 - Cluster Observability Operator がインストールされている。
-
prometheus-coo-example-app
サンプルサービスをns1-coo
namespace にデプロイしている。 -
ns1-coo
namespace に、prometheus-coo-example-monitor
という名前のServiceMonitor
オブジェクトを作成している。
手順
-
MonitoringStack
オブジェクト設定の YAML ファイルを作成します。この例では、ファイル名をexample-coo-monitoring-stack.yaml
にします。 以下の
MonitoringStack
オブジェクト設定の詳細を追加します。MonitoringStack
オブジェクトの例apiVersion: monitoring.rhobs/v1alpha1 kind: MonitoringStack metadata: name: example-coo-monitoring-stack namespace: ns1-coo spec: logLevel: debug retention: 1d resourceSelector: matchLabels: k8s-app: prometheus-coo-example-monitor
次のコマンドを実行して、
MonitoringStack
オブジェクトを適用します。$ oc apply -f example-coo-monitoring-stack.yaml
次のコマンドを実行し、出力で
MonitoringStack
オブジェクトが利用可能であることを確認します。$ oc -n ns1-coo get monitoringstack
出力例
NAME AGE example-coo-monitoring-stack 81m
以下のコマンドを実行して、Prometheus からアクティブなターゲットに関する情報を取得し、出力をフィルタリングして、
app=prometheus-coo-example-app
のラベルが付けられたターゲットのみをリスト表示します。これにより、この特定のラベルの付いたターゲットのうち、どれが Prometheus によって検出およびアクティブに監視されるかが検証されます。$ oc -n oc -n ns1-coo exec -c prometheus prometheus-example-coo-monitoring-stack-0 -- curl -s 'http://localhost:9090/api/v1/targets' | jq '.data.activeTargets[].discoveredLabels | select(.__meta_kubernetes_endpoints_label_app=="prometheus-coo-example-app")'
出力例
{ "__address__": "10.129.2.25:8080", "__meta_kubernetes_endpoint_address_target_kind": "Pod", "__meta_kubernetes_endpoint_address_target_name": "prometheus-coo-example-app-5d8cd498c7-9j2gj", "__meta_kubernetes_endpoint_node_name": "ci-ln-8tt8vxb-72292-6cxjr-worker-a-wdfnz", "__meta_kubernetes_endpoint_port_name": "web", "__meta_kubernetes_endpoint_port_protocol": "TCP", "__meta_kubernetes_endpoint_ready": "true", "__meta_kubernetes_endpoints_annotation_endpoints_kubernetes_io_last_change_trigger_time": "2024-11-05T11:24:09Z", "__meta_kubernetes_endpoints_annotationpresent_endpoints_kubernetes_io_last_change_trigger_time": "true", "__meta_kubernetes_endpoints_label_app": "prometheus-coo-example-app", "__meta_kubernetes_endpoints_labelpresent_app": "true", "__meta_kubernetes_endpoints_name": "prometheus-coo-example-app", "__meta_kubernetes_namespace": "ns1-coo", "__meta_kubernetes_pod_annotation_k8s_ovn_org_pod_networks": "{\"default\":{\"ip_addresses\":[\"10.129.2.25/23\"],\"mac_address\":\"0a:58:0a:81:02:19\",\"gateway_ips\":[\"10.129.2.1\"],\"routes\":[{\"dest\":\"10.128.0.0/14\",\"nextHop\":\"10.129.2.1\"},{\"dest\":\"172.30.0.0/16\",\"nextHop\":\"10.129.2.1\"},{\"dest\":\"100.64.0.0/16\",\"nextHop\":\"10.129.2.1\"}],\"ip_address\":\"10.129.2.25/23\",\"gateway_ip\":\"10.129.2.1\",\"role\":\"primary\"}}", "__meta_kubernetes_pod_annotation_k8s_v1_cni_cncf_io_network_status": "[{\n \"name\": \"ovn-kubernetes\",\n \"interface\": \"eth0\",\n \"ips\": [\n \"10.129.2.25\"\n ],\n \"mac\": \"0a:58:0a:81:02:19\",\n \"default\": true,\n \"dns\": {}\n}]", "__meta_kubernetes_pod_annotation_openshift_io_scc": "restricted-v2", "__meta_kubernetes_pod_annotation_seccomp_security_alpha_kubernetes_io_pod": "runtime/default", "__meta_kubernetes_pod_annotationpresent_k8s_ovn_org_pod_networks": "true", "__meta_kubernetes_pod_annotationpresent_k8s_v1_cni_cncf_io_network_status": "true", "__meta_kubernetes_pod_annotationpresent_openshift_io_scc": "true", "__meta_kubernetes_pod_annotationpresent_seccomp_security_alpha_kubernetes_io_pod": "true", "__meta_kubernetes_pod_controller_kind": "ReplicaSet", "__meta_kubernetes_pod_controller_name": "prometheus-coo-example-app-5d8cd498c7", "__meta_kubernetes_pod_host_ip": "10.0.128.2", "__meta_kubernetes_pod_ip": "10.129.2.25", "__meta_kubernetes_pod_label_app": "prometheus-coo-example-app", "__meta_kubernetes_pod_label_pod_template_hash": "5d8cd498c7", "__meta_kubernetes_pod_labelpresent_app": "true", "__meta_kubernetes_pod_labelpresent_pod_template_hash": "true", "__meta_kubernetes_pod_name": "prometheus-coo-example-app-5d8cd498c7-9j2gj", "__meta_kubernetes_pod_node_name": "ci-ln-8tt8vxb-72292-6cxjr-worker-a-wdfnz", "__meta_kubernetes_pod_phase": "Running", "__meta_kubernetes_pod_ready": "true", "__meta_kubernetes_pod_uid": "054c11b6-9a76-4827-a860-47f3a4596871", "__meta_kubernetes_service_label_app": "prometheus-coo-example-app", "__meta_kubernetes_service_labelpresent_app": "true", "__meta_kubernetes_service_name": "prometheus-coo-example-app", "__metrics_path__": "/metrics", "__scheme__": "http", "__scrape_interval__": "30s", "__scrape_timeout__": "10s", "job": "serviceMonitor/ns1-coo/prometheus-coo-example-monitor/0" }
注記上記の例では、
jq
コマンドライン JSON プロセッサー を使用して、便宜上出力をフォーマットします。
4.4. モニタリングスタックの検証
モニタリングスタックが正しく機能していることを確認するには、サンプルサービスにアクセスし、収集したメトリクスを表示します。
前提条件
-
cluster-admin
クラスターロールを持つユーザーとして、または namespace の管理権限を持つユーザーとして、クラスターにアクセスできる。 - Cluster Observability Operator がインストールされている。
-
prometheus-coo-example-app
サンプルサービスをns1-coo
namespace にデプロイしている。 -
ns1-coo
namespace に、prometheus-coo-example-monitor
という名前のServiceMonitor
オブジェクトを作成している。 -
ns1-coo
namespace にexample-coo-monitoring-stack
という名前のMonitoringStack
オブジェクトを作成している。
手順
prometheus-coo-example-app
サービスのサンプルを公開するためのルートを作成します。ターミナルから、以下のコマンドを実行します。$ oc expose svc prometheus-coo-example-app
- ブラウザーまたはコマンドラインからルートにアクセスし、メトリクスを生成します。
Prometheus Pod でクエリーを実行し、HTTP 要求メトリクスの合計を返します。
$ oc -n ns1-coo exec -c prometheus prometheus-example-coo-monitoring-stack-0 -- curl -s 'http://localhost:9090/api/v1/query?query=http_requests_total'
出力例 (便宜上
jq
を使用したフォーマット){ "status": "success", "data": { "resultType": "vector", "result": [ { "metric": { "__name__": "http_requests_total", "code": "200", "endpoint": "web", "instance": "10.129.2.25:8080", "job": "prometheus-coo-example-app", "method": "get", "namespace": "ns1-coo", "pod": "prometheus-coo-example-app-5d8cd498c7-9j2gj", "service": "prometheus-coo-example-app" }, "value": [ 1730807483.632, "3" ] }, { "metric": { "__name__": "http_requests_total", "code": "404", "endpoint": "web", "instance": "10.129.2.25:8080", "job": "prometheus-coo-example-app", "method": "get", "namespace": "ns1-coo", "pod": "prometheus-coo-example-app-5d8cd498c7-9j2gj", "service": "prometheus-coo-example-app" }, "value": [ 1730807483.632, "0" ] } ] } }
第5章 可観測性 UI プラグイン
5.1. 可観測性 UI プラグインの概要
Cluster Observability Operator はテクノロジープレビュー機能としてのみ使用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
Cluster Observability Operator (COO) を使用すると、UI プラグインをインストールおよび管理し、OpenShift Container Platform Web コンソールの監視機能を強化できます。プラグインはデフォルトの機能を拡張し、監視、トラブルシューティング、分散トレーシング、クラスターロギング用の新しい UI 機能を提供します。
5.1.1. ダッシュボード
ダッシュボード UI プラグインは、OpenShift Container Platform Web コンソールの Observe → Dashboards のダッシュボードを拡張するものです。クラスター内のデータソースに加えて、その他の Prometheus データソースをクラスターからデフォルトのダッシュボードに追加できます。これにより、さまざまなデータソース全体で統一された可観測性エクスペリエンスが実現します。
詳細は、ダッシュボード UI プラグイン ページを参照してください。
5.1.2. トラブルシューティング
OpenShift Container Platform バージョン 4.16 以降のトラブルシューティングパネル UI プラグインは、オープンソースの Korrel8r プロジェクトを利用した可観測性シグナル相関付け機能を提供します。Observe → Alerting ページから利用できるトラブルシューティングパネルを使用すると、さまざまなデータストア全体のメトリクス、ログ、アラート、ネットフロー、その他の可観測性シグナルとリソースを簡単に相関付けることができます。OpenShift Container Platform バージョン 4.17 以降のユーザーは、アプリケーションランチャー
からもトラブルシューティング UI パネルにアクセスできます。
Korrel8r の出力は、インタラクティブなノードグラフとして表示されます。ノードをクリックすると、メトリクス、ログ、Pod など、そのノードの詳細情報を含む対応する Web コンソールページに自動的にリダイレクトされます。
詳細は、トラブルシューティング UI プラグイン ページを参照してください。
5.1.3. 分散トレーシング
分散トレーシング UI プラグインは、Web コンソールの Observe → Traces ページにトレース関連の機能を追加するものです。マイクロサービスのフロントエンドからバックエンドまで要求を追跡できるため、分散システムにおけるコードエラーやパフォーマンスのボトルネックを特定するのに役立ちます。クラスターで実行中のサポートされている TempoStack
または TempoMonolithic
マルチテナントインスタンスを選択し、時間範囲とクエリーを設定してトレースデータを表示できます。
詳細は、分散トレーシング UI プラグイン ページを参照してください。
5.1.4. クラスターロギング
ロギング UI プラグインは、Web コンソールの Observe → Logs ページにロギングデータを表示します。フィルター、クエリー、時間範囲、更新頻度を指定できます。結果には折りたたまれたログのリストが表示されます。リストを展開すると、各ログの詳細情報が表示されます。
詳細は、ロギング UI プラグイン ページを参照してください。
5.2. ダッシュボード UI プラグイン
Cluster Observability Operator はテクノロジープレビュー機能としてのみ使用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
ダッシュボード UI プラグインは、OpenShift Web コンソールの Observe → Dashboards のダッシュボードを拡張するものです。クラスター内のデータソースに加えて、その他の Prometheus データソースをクラスターからデフォルトのダッシュボードに追加できます。これにより、さまざまなデータソース全体で統一された可観測性エクスペリエンスが実現します。
このプラグインは、openshift-config-managed
namespace 内の ConfigMap
リソースから、ラベル console.openshift.io/dashboard-datasource: 'true'
を持つデータソースを検索します。
5.2.1. Cluster Observability Operator ダッシュボード UI プラグインのインストール
前提条件
-
cluster-admin
クラスターロールを持つユーザーとしてクラスターにアクセスできる。 - OpenShift Container Platform Web コンソールにログインしている。
- Cluster Observability Operator がインストールされている。
手順
- OpenShift Container Platform Web コンソールで、Operator → Installed Operator をクリックし、Cluster Observability Operator を選択します。
- UI Plugin タブ (タブリストの右端) を選択し、Create UIPlugin を押します。
YAML view を選択し、次の内容を入力して、Create を押します。
apiVersion: observability.openshift.io/v1alpha1 kind: UIPlugin metadata: name: dashboards spec: type: Dashboards
5.2.2. ダッシュボードの設定
ダッシュボード UI プラグインは、openshift-config-managed
namespace 内の ConfigMap
リソースから、ラベル console.openshift.io/dashboard-datasource: 'true'
を持つデータソースを検索します。ConfigMap
リソースでは、データソースタイプと、データを取得できるクラスター内サービスを定義する必要があります。
次のセクションの例は、https://github.com/openshift/console-dashboards-plugin から取得したものです。
前提条件
-
cluster-admin
クラスターロールを持つユーザーとしてクラスターにアクセスできる。 - OpenShift Container Platform Web コンソールにログインしている。
- Cluster Observability Operator がインストールされている。
- ダッシュボード UI プラグインがインストールされている。
手順
ラベル
console.openshift.io/dashboard-datasource: 'true'
を使用して、openshift-config-managed
namespace にConfigMap
リソースを作成します。以下の例は prometheus-datasource-example.yaml からのものです。apiVersion: v1 kind: ConfigMap metadata: name: cluster-prometheus-proxy namespace: openshift-config-managed labels: console.openshift.io/dashboard-datasource: "true" data: "dashboard-datasource.yaml": |- kind: "Datasource" metadata: name: "cluster-prometheus-proxy" project: "openshift-config-managed" spec: plugin: kind: "prometheus" spec: direct_url: "https://prometheus-k8s.openshift-monitoring.svc.cluster.local:9091"
データソースに接続するカスタムダッシュボードを設定します。サンプルダッシュボードの YAML は、prometheus-dashboard-example.yaml で入手できます。そのファイルからの抜粋を例として以下に示します。
例5.1 prometheus-dashboard-example.yaml から取得したサンプルダッシュボードの抜粋
apiVersion: v1 kind: ConfigMap metadata: name: dashboard-example namespace: openshift-config-managed labels: console.openshift.io/dashboard: "true" data: k8s-resources-workloads-namespace.json: |- { "annotations": { "list": [ ] }, "editable": true, "gnetId": null, "graphTooltip": 0, "hideControls": false, "links": [ ], "refresh": "10s", "rows": [ { "collapse": false, "height": "250px", "panels": [ { "aliasColors": { }, "bars": false, "dashLength": 10, "dashes": false, "datasource": { "name": "cluster-prometheus-proxy", "type": "prometheus" }, "fill": 10, "id": 1, "interval": "1m", "legend": { "alignAsTable": true, "avg": false, "current": false, "max": false, "min": false, "rightSide": true, "show": true, "total": false, "values": false }, "lines": true, "linewidth": 0, "links": [ ], "nullPointMode": "null as zero", "percentage": false, "pointradius": 5, "points": false, "renderer": "flot", "seriesOverrides": [ { "alias": "quota - requests", "color": "#F2495C", "dashes": true, "fill": 0, "hiddenSeries": true, "hideTooltip": true, "legend": true, "linewidth": 2, "stack": false }, { "alias": "quota - limits", "color": "#FF9830", "dashes": true, "fill": 0, "hiddenSeries": true, "hideTooltip": true, "legend": true, "linewidth": 2, "stack": false } ], "spaceLength": 10, "span": 12, "stack": false, "steppedLine": false, "targets": [ { "expr": "sum( node_namespace_pod_container:container_cpu_usage_seconds_total:sum_irate{cluster=\"$cluster\", namespace=\"$namespace\"}* on(namespace,pod) group_left(workload, workload_type) namespace_workload_pod:kube_pod_owner:relabel{cluster=\"$cluster\", namespace=\"$namespace\", workload_type=\"$type\"}) by (workload, workload_type)", "format": "time_series", "intervalFactor": 2, "legendFormat": "{{workload}} - {{workload_type}}", "legendLink": null, "step": 10 }, { "expr": "scalar(kube_resourcequota{cluster=\"$cluster\", namespace=\"$namespace\", type=\"hard\",resource=\"requests.cpu\"})", "format": "time_series", "intervalFactor": 2, "legendFormat": "quota - requests", "legendLink": null, "step": 10 }, { "expr": "scalar(kube_resourcequota{cluster=\"$cluster\", namespace=\"$namespace\", type=\"hard\",resource=\"limits.cpu\"})", "format": "time_series", "intervalFactor": 2, "legendFormat": "quota - limits", "legendLink": null, "step": 10 } ], "thresholds": [ ], "timeFrom": null, "timeShift": null, "title": "CPU Usage", "tooltip": { "shared": false, "sort": 2, "value_type": "individual" }, "type": "graph", "xaxis": { "buckets": null, "mode": "time", "name": null, "show": true, "values": [ ] }, ...
Observe → Dashboards をクリックすると、
prometheus-dashboard-example.yaml
の設定に基づく ** DASHBOARD EXAMPLE ** というタイトルのカスタムダッシュボードを使用できます。UI で、ダッシュボードの namespace、時間範囲、更新間隔を設定できます。
5.2.3. 関連情報
- console-dashboards-plugin GitHub リポジトリーで 新しいデータソースを追加する 方法を参照してください。
5.3. 分散トレーシング UI プラグイン
Cluster Observability Operator はテクノロジープレビュー機能としてのみ使用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
分散トレーシング UI プラグインは、OpenShift Web コンソールの Observe → Traces の Administrator パースペクティブにトレース関連の機能を追加するものです。マイクロサービスのフロントエンドからバックエンドまで要求を追跡できるため、分散システムにおけるコードエラーやパフォーマンスのボトルネックを特定するのに役立ちます。
5.3.1. Cluster Observability Operator 分散トレーシング UI プラグインのインストール
前提条件
-
cluster-admin
クラスターロールを持つユーザーとしてクラスターにアクセスできる。 - OpenShift Container Platform Web コンソールにログインしている。
- Cluster Observability Operator がインストールされている。
手順
- OpenShift Container Platform Web コンソールで、Operator → Installed Operator をクリックし、Cluster Observability Operator を選択します。
- UI Plugin タブ (タブリストの右端) を選択し、Create UIPlugin を押します。
YAML view を選択し、次の内容を入力して、Create を押します。
apiVersion: observability.openshift.io/v1alpha1 kind: UIPlugin metadata: name: distributed-tracing spec: type: DistributedTracing
5.3.2. Cluster Observability Operator 分散トレーシング UI プラグインの使用
前提条件
-
cluster-admin
クラスターロールを持つユーザーとしてクラスターにアクセスできる。 - OpenShift Container Platform Web コンソールにログインしている。
- Cluster Observability Operator がインストールされている。
- Cluster Observability Operator 分散トレーシング UI プラグインがインストールされている。
-
クラスター内に
TempoStack
またはTempoMonolithic
マルチテナントインスタンスがある。
手順
- OpenShift Container Platform Web コンソールの Administrator パースペクティブで、Observe → Traces をクリックします。
TempoStack
またはTempoMonolithic
マルチテナントインスタンスを選択し、ロードするトレースの時間範囲とクエリーを設定します。トレースの開始時刻、期間、スパンの数を示す散布図にトレースが表示されます。散布図の下には、
Trace Name
、Spans
の数、Duration
などの情報を示すトレースのリストがあります。トレース名のリンクをクリックします。
選択したトレースのトレース詳細ページに、トレース内の全スパンのガントチャートが表示されます。スパンを選択して、設定した属性の内訳を表示します。
5.4. トラブルシューティング UI プラグイン
Cluster Observability Operator はテクノロジープレビュー機能としてのみ使用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
OpenShift Container Platform バージョン 4.16 以降のトラブルシューティング UI プラグインは、オープンソースの Korrel8r プロジェクトを利用した可観測性シグナル相関付け機能を提供します。Observe → Alerting で利用できるトラブルシューティングパネルを使用すると、さまざまなデータストア全体のメトリクス、ログ、アラート、ネットフロー、その他の可観測性シグナルとリソースを簡単に相関付けることができます。OpenShift Container Platform バージョン 4.17 以降のユーザーは、アプリケーションランチャー
からもトラブルシューティング UI パネルにアクセスできます。
トラブルシューティング UI プラグインをインストールすると、korrel8r
という名前の Korrel8r サービスが同じ namespace にデプロイされ、相関エンジンから関連する可観測性シグナルと Kubernetes リソースを特定できるようになります。
Korrel8r の出力は、OpenShift Container Platform Web コンソールにインタラクティブなノードグラフの形式で表示されます。グラフ内のノードはリソースまたはシグナルの種類を表し、エッジは関係を表します。ノードをクリックすると、メトリクス、ログ、Pod など、そのノードの詳細情報を含む対応する Web コンソールページに自動的にリダイレクトされます。
5.4.1. Cluster Observability Operator トラブルシューティング UI プラグインのインストール
前提条件
-
cluster-admin
クラスターロールを持つユーザーとしてクラスターにアクセスできる。 - OpenShift Container Platform Web コンソールにログインしている。
- Cluster Observability Operator がインストールされている。
手順
- OpenShift Container Platform Web コンソールで、Operator → Installed Operator をクリックし、Cluster Observability Operator を選択します。
- UI Plugin タブ (タブリストの右端) を選択し、Create UIPlugin を押します。
YAML view を選択し、次の内容を入力して、Create を押します。
apiVersion: observability.openshift.io/v1alpha1 kind: UIPlugin metadata: name: troubleshooting-panel spec: type: TroubleshootingPanel
5.4.2. Cluster Observability Operator トラブルシューティング UI プラグインの使用
前提条件
-
cluster-admin
クラスターロールを持つユーザーとして OpenShift Container Platform クラスターにアクセスできる。クラスターのバージョンが 4.17 以降の場合は、アプリケーションランチャーからトラブルシューティング UI パネルにアクセスできます。
- OpenShift Container Platform Web コンソールにログインしている。
- OpenShift Container Platform Logging がインストールされている (相関ログを視覚化する場合)。
- OpenShift Container Platform Network Observability がインストールされている (相関ネットフローを視覚化する場合)。
- Cluster Observability Operator がインストールされている。
Cluster Observability Operator トラブルシューティング UI プラグインがインストールされている。
注記トラブルシューティングパネルは、クラスターにインストールされている可観測性シグナルストアに依存します。Kubernetes リソース、アラート、およびメトリクスは、OpenShift Container Platform クラスターで常にデフォルトで使用できます。以下に示すその他のシグナルタイプを使用するには、オプションのコンポーネントをインストールする必要があります。
- ログ: Red Hat Openshift Logging (コレクション) および Red Hat が提供する Loki Operator (ストア)
- ネットワークイベント: Red Hat が提供する Network Observability (コレクション) と Red Hat が提供する Loki Operator (ストア)
手順
Web コンソールの Administrator パースペクティブで、Observe → Alerting に移動し、アラートを選択します。アラートに相関項目があると、アラート詳細ページのグラフの上に Troubleshooting Panel リンクが表示されます。
Troubleshooting Panel リンクをクリックしてパネルを表示します。
-
パネルは、クエリーの詳細とクエリー結果のトポロジーグラフで構成されています。選択したアラートは、Korrel8r クエリー文字列に変換され、
korrel8r
サービスに送信されます。結果は、返されたシグナルとリソースを結ぶグラフネットワークとして表示されます。これは、現在のリソースから始まり、開始点から最大 3 ステップ離れた関連オブジェクトを含む 近傍 グラフです。グラフ内のノードをクリックすると、それらのリソースに対応する Web コンソールページに移動します。 トラブルシューティングパネルを使用して、選択したアラートに関連するリソースを見つけることができます。
注記ノードをクリックすると、グラフに表示されているよりも少ない結果が表示される場合があります。これは既知の問題であり、今後のリリースで対処される予定です。
-
Alert (1): このノードはグラフの開始点です。Web コンソールに表示される
KubeContainerWaiting
アラートを表します。 -
Pod (1): このノードは、このアラートに関連付けられた
Pod
リソースが 1 つあることを示しています。このノードをクリックすると、コンソール検索が開き、関連する Pod が直接表示されます。 - Event (2): Pod に関連付けられた Kuberenetes イベントが 2 つあります。このノードをクリックすると、イベントが表示されます。
- Logs (74): この Pod には 74 行のログがあります。このノードをクリックすると、ログにアクセスできます。
- Metrics (105): Pod に関連付けられたメトリクスが多数あります。
-
Network (6): 複数のネットワークイベントがあります。これは、Pod がネットワーク経由で通信したことを示しています。グラフ内の残りのノードは、Pod が通信した
Service
、Deployment
、DaemonSet
リソースを表しています。 - Focus: このボタンをクリックすると、グラフが更新されます。デフォルトでは、グラフ内のノードをクリックしてもグラフ自体は変わりません。代わりに、メインの Web コンソールページが変更され、ページ上のリンクを使用して他のリソースに移動できるようになります。トラブルシューティングパネル自体は、開いたまま変更されません。トラブルシューティングパネルのグラフを強制的に更新するには、Focus をクリックします。すると、Web コンソールの現在のリソースを開始点として使用して、新しいグラフが描画されます。
Show Query: このボタンをクリックすると、いくつかの実験的な機能が有効になります。
- Hide Query をクリックすると、実験的な機能が非表示になります。
- グラフの開始点を示すクエリー。グラフの作成に使用される Korrel8r 相関エンジンの一部であるクエリー言語は、実験段階であり、今後変更される可能性があります。Focus ボタンを押すと、メインの Web コンソールウィンドウ内のリソースに合わせてクエリーが更新されます。
Neighbourhood depth は、表示する近傍の数を増減するために使用します。
注記大規模なクラスターで大きな値を設定すると、結果の数が多すぎる場合にクエリーが失敗する可能性があります。
Goal class を選択すると、近傍検索ではなく目標指向型の検索になります。目標指向型の検索では、開始点から目標クラスまでのすべてのパスが表示されます。目標クラスは、リソースまたはシグナルの種類を示します。目標クラス形式は実験的なものであり、変更する可能性があります。現在、次の目標が有効です。
-
k8s:RESOURCE[VERSION.[GROUP]]
は、kuberenetes リソースの種類を示します。たとえば、k8s:Pod
やk8s:Deployment.apps.v1
です。 -
alert:alert
は、アラートを表します。 -
metric:metric
は、メトリクスを表します。 -
netflow:network
は、ネットワークの可観測性ネットワークイベントを表します。 -
log:LOG_TYPE
は、保存されたログを表します。LOG_TYPE
は、application
、infrastructure
、またはaudit
のいずれかである必要があります。
-
-
Alert (1): このノードはグラフの開始点です。Web コンソールに表示される
5.4.3. サンプルアラートの作成
トラブルシューティング UI パネルで出発点として使用するアラートをトリガーする場合は、意図的に誤った設定を指定したコンテナーをデプロイできます。
手順
コマンドラインまたは Web コンソールから次の YAML を使用して、システムの namespace に壊れたデプロイメントを作成します。
apiVersion: apps/v1 kind: Deployment metadata: name: bad-deployment namespace: default 1 spec: selector: matchLabels: app: bad-deployment template: metadata: labels: app: bad-deployment spec: containers: 2 - name: bad-deployment image: quay.io/openshift-logging/vector:5.8
アラートを表示します。
Observe → Alerting に移動し、clear all filters をクリックします。
Pending
のアラートを表示します。重要アラートは最初
Pending
状態で表示されます。コンテナーがクラッシュするまで、アラートの発生 (Firing
) は開始しません。Pending
のアラートを確認できるため、アラートが発生するまで待つ必要はありません。-
KubeContainerWaiting
、KubePodCrashLooping
、またはKubePodNotReady
アラートのいずれかを選択し、リンクをクリックしてトラブルシューティングパネルを開きます。または、パネルがすでに開いている場合は、"Focus" ボタンをクリックしてグラフを更新します。
5.5. ロギング UI プラグイン
現在は テクノロジープレビュー (TP) 機能である Cluster Observability Operator (COO) の一般提供 (GA) リリースが近づくまで、Red Hat は、OpenShift Container Platform 4.14 以降のロギング UI プラグインの COO で Logging 6.0 以降を使用しているお客様にサポートを提供します。COO にはいくつかの独立した機能が含まれており、その一部はまだテクノロジープレビュー機能であるため、このサポート例外は一時的なものです。ただし、ロギング UI プラグインは GA の準備が完了しています。
ロギング UI プラグインは、OpenShift Container Platform Web コンソールの Observe → Logs ページにロギングデータを表示します。フィルター、クエリー、時間範囲、更新頻度を指定すると、結果が折りたたまれたログのリストとして表示されます。リストを展開すると、各ログの詳細情報が表示されます。
OpenShift Container Platform バージョン 4.16 以降にトラブルシューティング UI プラグインもデプロイすると、Korrel8r サービスに接続され、Administration パースペクティブの Observe → Logs ページから、相関 PromQL クエリーを含む Observe → Metrics ページへの直接リンクが追加されます。また、Administration パースペクティブのアラート詳細ページ (Observe → Alerting) から、相関フィルターセットが選択済みの Observe → Logs ページへの See Related Logs リンクが追加されます。
このプラグインの機能は次のように分類されます。
- dev-console
- Developer パースペクティブにログビューを追加します。
- alerts
- Web コンソールのアラートを、Loki ルーラーで定義されたログベースのアラートとマージします。アラート詳細ビューにログベースのメトリクスチャートを追加します。
- dev-alerts
- Web コンソールのアラートを、Loki ルーラーで定義されたログベースのアラートとマージします。Developer パースペクティブのアラート詳細ビューにログベースのメトリクスチャートを追加します。
Cluster Observability Operator (COO) の各バージョンについて、OpenShift Container Platform 各バージョンにおけるこれらの機能のサポート状況を次の表に示します。
COO のバージョン | OCP のバージョン | 機能 |
---|---|---|
0.3.0 以降 | 4.12 |
|
0.3.0 以降 | 4.13 |
|
0.3.0 以降 | 4.14 以降 |
|
5.5.1. Cluster Observability Operator ログ UI プラグインのインストール
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - OpenShift Container Platform Web コンソールにログインしている。
- Cluster Observability Operator がインストールされている。
-
クラスター内に
LokiStack
インスタンスがある。
手順
- OpenShift Container Platform Web コンソールで、Operator → Installed Operator をクリックし、Cluster Observability Operator を選択します。
- UI Plugin タブ (タブリストの右端) を選択し、Create UIPlugin をクリックします。
YAML view を選択し、次の内容を入力して、Create をクリックします。
apiVersion: observability.openshift.io/v1alpha1 kind: UIPlugin metadata: name: logging spec: type: Logging logging: lokiStack: name: logging-loki logsLimit: 50 timeout: 30s
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.