第4章 Prometheus アダプターの監査ログレベルの設定
デフォルトのプラットフォームモニタリングでは、Prometheus アダプターの監査ログレベルを設定できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
クラスターロールを持つユーザーとしてクラスターにアクセスできます。 -
cluster-monitoring-config
ConfigMap
オブジェクトを作成している。
手順
デフォルトの openshift-monitoring
プロジェクトで Prometheus アダプターの監査ログレベルを設定できます。
openshift-monitoring
プロジェクトでcluster-monitoring-config
ConfigMap
オブジェクトを編集します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
k8sPrometheusAdapter/audit
セクションにprofile:
をdata/config.yaml
の下に追加します。apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | k8sPrometheusAdapter: audit: profile: <audit_log_level> 1
- 1
- Prometheus アダプターに適用する監査ログレベル。
profile:
パラメーターに以下のいずれかの値を使用して、監査ログレベルを設定します。-
None
: イベントをログに記録しません。 -
Metadata
: ユーザー、タイムスタンプなど、リクエストのメタデータのみをログに記録します。リクエストテキストと応答テキストはログに記録しないでください。metadata
はデフォルトの監査ログレベルです。 -
Request
: メタデータと要求テキストのみをログに記録しますが、応答テキストはログに記録しません。このオプションは、リソース以外の要求には適用されません。 -
RequestResponse
: イベントのメタデータ、要求テキスト、および応答テキストをログに記録します。このオプションは、リソース以外の要求には適用されません。
-
変更を適用するためにファイルを保存します。変更を適用すると、Prometheus Adapter 用の Pod が自動的に再起動します。
警告変更がモニタリング設定マップに保存されると、関連するプロジェクトの Pod およびその他のリソースが再デプロイされる可能性があります。該当するプロジェクトの実行中のモニタリングプロセスも再起動する可能性があります。
検証
-
設定マップの
k8sPrometheusAdapter/audit/profile
で、ログレベルをRequest
に設定し、ファイルを保存します。 Prometheus アダプターの Pod が実行されていることを確認します。以下の例は、
openshift-monitoring
プロジェクトの Pod のステータスを一覧表示します。$ oc -n openshift-monitoring get pods
監査ログレベルと監査ログファイルのパスが正しく設定されていることを確認します。
$ oc -n openshift-monitoring get deploy prometheus-adapter -o yaml
出力例
... - --audit-policy-file=/etc/audit/request-profile.yaml - --audit-log-path=/var/log/adapter/audit.log
正しいログレベルが
openshift-monitoring
プロジェクトのprometheus-adapter
デプロイメントに適用されていることを確認します。$ oc -n openshift-monitoring exec deploy/prometheus-adapter -c prometheus-adapter -- cat /etc/audit/request-profile.yaml
出力例
"apiVersion": "audit.k8s.io/v1" "kind": "Policy" "metadata": "name": "Request" "omitStages": - "RequestReceived" "rules": - "level": "Request"
注記ConfigMap
オブジェクトで Prometheus アダプターに認識されないprofile
値を入力すると、Prometheus アダプターには変更が加えられず、Cluster Monitoring Operator によってエラーがログに記録されます。Prometheus アダプターの監査ログを確認します。
$ oc -n openshift-monitoring exec -c <prometheus_adapter_pod_name> -- cat /var/log/adapter/audit.log
関連情報
- モニタリング設定マップを作成する手順は、モニタリングスタックの設定の準備 を参照してください。
4.1. デフォルトの Grafana デプロイメントの無効化
デフォルトでは、読み取り専用の Grafana インスタンスは、クラスターメトリクスを表示するダッシュボードのコレクションと共にデプロイされます。Grafana インスタンスは、ユーザー側で設定できません。
Grafana デプロイメントを無効にすると、関連するリソースがクラスターから削除されます。これらのダッシュボードを必要とせずに、クラスターのリソースを節約するには、以下を行うことができます。ただし、引き続き Web コンソールに含まれるメトリクスおよびダッシュボードを表示できます。Grafana はいつでも再度有効化することができます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
cluster-monitoring-config
ConfigMap
オブジェクトを作成している。 -
OpenShift CLI (
oc
) がインストールされている。
手順
openshift-monitoring
プロジェクトでcluster-monitoring-config
ConfigMap
オブジェクトを編集します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
grafana
コンポーネントのenabled: false
をdata/config.yaml
の下に追加します。apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | grafana: enabled: false
変更を適用するためにファイルを保存します。リソースは、変更を適用したら、自動的に削除されます。
警告この変更により、Prometheus および Thanos Querier など、一部のコンポーネントが生成されます。これにより、永続ストレージの設定のセクションの手順が完了していない場合に、収集されたメトリクスが失われる可能性があります。
Grafana Pod が実行されていないことを確認します。以下の例は、
openshift-monitoring
プロジェクトの Pod のステータスを一覧表示します。$ oc -n openshift-monitoring get pods
注記これらの Pod を終了するまでに数分かかる場合があります。
関連情報
- モニタリング設定マップを作成する手順は、モニタリングスタックの設定の準備 を参照してください。