このページでは、Cloud Logging、Cloud Monitoring、および Prometheus と Grafana を使用して Anthos clusters on VMware(GKE On-Prem)実装のロギングとモニタリングを行う方法について説明します。使用可能な構成オプションの概要については、ロギングとモニタリングの概要をご覧ください。
Cloud Logging と Cloud Monitoring の使用
以降のセクションでは、Anthos clusters on VMware(GKE On-Prem)クラスタで Cloud Logging と Cloud Monitoring を使用する方法について説明します。
モニタリング対象リソース
モニタリング対象リソースとは、Google がクラスタ、ノード、Pod、コンテナなどのリソースを表す方法です。詳細は、Cloud Monitoring のモニタリング対象リソースタイプのドキュメントをご覧ください。
ログと指標のクエリを行うには、少なくとも次のリソースラベルを認識している必要があります。
project_id
: クラスタの logging-monitoring プロジェクトの ID 用のプロジェクト ID。この値は、クラスタ構成ファイルのstackdriver.projectID
フィールドで指定した値です。location
: Cloud Logging のログと Cloud Monitoring の指標を保存する Google Cloud リージョン。オンプレミスのデータセンターに近いリージョンを選択することをおすすめします。この値は、インストール時にクラスタ構成ファイルのstackdriver.clusterLocation
フィールドに入力した値です。cluster_name
: クラスタの作成時に選択したクラスタ名。Stackdriver カスタム リソースを調べることで、管理クラスタまたはユーザー クラスタの
cluster_name
の値を取得できます。kubectl get stackdriver stackdriver --namespace kube-system \ --kubeconfig CLUSTER_KUBECONFIG --output yaml | grep 'clusterName:'
ここで
CLUSTER_KUBECONFIG
は、クラスタ名が必要な管理クラスタまたはユーザー クラスタの kubeconfig ファイルのパスです。
ログデータにアクセスする
Google Cloud コンソールのログ エクスプローラを使用してログにアクセスできます。たとえば、コンテナのログにアクセスするには、次のようにします。
- Google Cloud コンソールでプロジェクトのログビューアを開きます。
- 次の方法でコンテナのログを検索します。
- 左上のカタログ プルダウン ボックスをクリックし、[Kubernetes コンテナ] を選択します。
- クラスタ名、Namespace、コンテナの順に選択します。
クラスタの状態をモニタリングするダッシュボードを作成する
Anthos clusters on VMware クラスタは、システムおよびコンテナの指標をモニタリングするようにデフォルトで構成されています。クラスタ(管理者またはユーザー)を作成したら、Cloud Monitoring で次のダッシュボードを作成し、Anthos clusters on VMware 運用チームがクラスタの状態をモニタリングできるようにすることをおすすめします。
ダッシュボードは、Cloud Monitoring が有効になっている場合、管理クラスタのインストール時に自動的に作成されます。
ここでは、これらのダッシュボードを作成する方法について説明します。以下で説明するダッシュボード作成プロセスの詳細については、API によるダッシュボードの管理をご覧ください。
前提条件
ダッシュボードを作成するには、Google アカウントに次の権限が付与されている必要があります。
monitoring.dashboards.create
monitoring.dashboards.delete
monitoring.dashboards.update
アカウントに次のいずれかのロールが割り当てられていると、これらの権限が付与されます。権限は、Google Cloud コンソールで確認できます。
monitoring.dashboardEditor
monitoring.editor
- プロジェクト
editor
- プロジェクト
owner
また、gcloud
(gcloud CLI)を使用してダッシュボードを作成するには、Google アカウントに serviceusage.services.use
権限が必要です。
次のいずれかのロールが割り当てられている場合、アカウントにこの権限が割り当てられます。
roles/serviceusage.serviceUsageConsumer
roles/serviceusage.serviceUsageAdmin
roles/owner
roles/editor
- プロジェクト
editor
- プロジェクト
owner
コントロール プレーンの稼働時間ダッシュボードを作成する
Anthos clusters on VMware のコントロール プレーンは、API サーバー、スケジューラ、コントローラ マネージャー、etcd で構成されています。コントロール プレーンのステータスをモニタリングするには、これらのコンポーネントの状態をモニタリングするダッシュボードを作成します。
ダッシュボード構成
control-plane-uptime.json
をダウンロードします。次のコマンドを実行して、構成ファイルを含むカスタム ダッシュボードを作成します。
gcloud monitoring dashboards create --config-from-file=control-plane-uptime.json
Google Cloud Console で [Monitoring] を選択するか、次のボタンを使用します。
[リソース] > [ダッシュボード] を選択し、[GKE on-prem control plane uptime] というダッシュボードを表示します。各ユーザー クラスタのコントロール プレーンの稼働時間は、管理クラスタ内の別の Namespace から収集されます。namespace_name フィールドは、ユーザー クラスタ名です。
必要に応じてアラート ポリシーを作成します。
Pod ステータス ダッシュボードを作成する
各 Pod のフェーズ、各コンテナの再起動時間とリソース使用状況を含むダッシュボードの作成は、次の手順で行います。
ダッシュボード構成
pod-status.json
をダウンロードします。次のコマンドを実行して、構成ファイルを含むカスタム ダッシュボードを作成します。
gcloud monitoring dashboards create --config-from-file=pod-status.json
Google Cloud Console で [Monitoring] を選択するか、次のボタンを使用します。
[リソース] > [ダッシュボード] を選択し、[GKE On-Prem Pod Status] というダッシュボードを表示します。
必要に応じてアラート ポリシーを作成します。
ノード ステータス ダッシュボードを作成する
ノードの状態、CPU、メモリ、ディスクの使用状況をモニタリングするノード ステータス ダッシュボードを作成するには、次の手順を実行します。
ダッシュボード構成
node-status.json
をダウンロードします。次のコマンドを実行して、構成ファイルを含むカスタム ダッシュボードを作成します。
gcloud monitoring dashboards create --config-from-file=node-status.json
Google Cloud Console で [Monitoring] を選択するか、次のボタンを使用します。
[リソース] > [ダッシュボード] を選択し、[GKE On-Prem Node Status] というダッシュボードを表示します。
必要に応じてアラート ポリシーを作成します。
VM のヘルス ステータス ダッシュボードを作成する
VM のヘルス ステータス ダッシュボードは、管理クラスタとユーザー クラスタの VM の CPU、メモリ、ディスク リソースの競合シグナルをモニタリングします。
VM のヘルス ステータス ダッシュボードを作成するには:
stackdriver.disableVsphereResourceMetrics
が false に設定されていることを確認します。ユーザー クラスタの構成ファイルをご覧ください。ダッシュボード構成
vm-health-status.json
をダウンロードします。次のコマンドを実行して、構成ファイルを含むカスタム ダッシュボードを作成します。
gcloud monitoring dashboards create --config-from-file=vm-health-status.json
Google Cloud Console で [Monitoring] を選択するか、次のボタンを使用します。
[リソース] > [ダッシュボード] を選択し、GKE on-prem VM health status というダッシュボードを表示します。
必要に応じてアラート ポリシーを作成します。
ノード使用率ダッシュボードを作成する
ノード使用率ダッシュボードには、クラスタでの次の使用率が表示されます。
- ノード CPU の割り当て率
- Kubernetes ワークロードをスケジュールするために使用できる vCPU
- ノードメモリの割り当て率
- K8s ワークロードをスケジュールするために使用できるメモリ
- ノードディスクの使用率
ノード使用率ダッシュボードを作成するには:
ダッシュボード構成
node-utilization.json
をダウンロードします。次のコマンドを実行し、この構成ファイルでカスタム ダッシュボードを作成します。
gcloud monitoring dashboards create --config-from-file=node-utilization.json
Google Cloud Console で [モニタリング] を選択するか、次のボタンを使用します。
[リソース ] > [ダッシュボード] を選択し、[GKE On-Prem node utilization] というダッシュボードを表示します。
必要に応じてアラート ポリシーを作成します。
Stackdriver コンポーネント リソースの構成
クラスタを作成すると、Anthos clusters on VMware が Stackdriver カスタム リソースを自動的に作成します。カスタム リソースの仕様を編集して、Stackdriver コンポーネントの CPU リクエストとメモリ リクエストのデフォルト値と上限をオーバーライドできます。また、デフォルトのストレージ サイズを個別にオーバーライドすることもできます。
CPU とメモリのリクエストと上限のデフォルト値をオーバーライドする
これらのデフォルトをオーバーライドする手順は次のとおりです。
コマンドライン エディタで Stackdriver カスタム リソースを開きます。
kubectl --kubeconfig=KUBECONFIG -n kube-system edit stackdriver stackdriver
ここで、KUBECONFIG はクラスタの kubeconfig ファイルのパスです。これは、管理クラスタまたはユーザー クラスタのいずれかです。
Stackdriver カスタム リソースで、
spec
セクションの下にresourceAttrOverride
フィールドを追加します。resourceAttrOverride: POD_NAME_WITHOUT_RANDOM_SUFFIX/CONTAINER_NAME: LIMITS_OR_REQUESTS: RESOURCE: RESOURCE_QUANTITY
resourceAttrOverride
フィールドは、指定したコンポーネントの既存のデフォルトの制限とリクエストをすべてオーバーライドします。サンプル ファイルは次のようになります。apiVersion: addons.sigs.k8s.io/v1alpha1 kind: Stackdriver metadata: name: stackdriver namespace: kube-system spec: projectID: my-project clusterName: my-cluster clusterLocation: us-west-1a resourceAttrOverride: stackdriver-prometheus-k8s/prometheus-server: limits: cpu: 500m memory: 3000Mi requests: cpu: 300m memory: 2500Mi
変更を保存してコマンドライン エディタを終了します。
Pod のヘルスチェックを行います。
kubectl --kubeconfig=KUBECONFIG -n kube-system get pods | grep stackdriver
たとえば、正常な Pod では次のようになります。
stackdriver-prometheus-k8s-0 2/2 Running 0 5d19h
コンポーネントの Pod 仕様を確認して、リソースが正しく設定されていることを確認します。
kubectl --kubeconfig=KUBECONFIG -n kube-system describe pod POD_NAME
POD_NAME
は、先ほど変更した Pod の名前です。例:stackdriver-prometheus-k8s-0
レスポンスは次のようになります。
Name: stackdriver-prometheus-k8s-0 Namespace: kube-system ... Containers: prometheus-server: Limits: cpu: 500m memory: 3000Mi Requests: cpu: 300m memory: 2500Mi ...
ストレージ サイズのデフォルトをオーバーライドする
これらのデフォルトをオーバーライドする手順は次のとおりです。
コマンドライン エディタで Stackdriver カスタム リソースを開きます。
kubectl --kubeconfig=KUBECONFIG -n kube-system edit stackdriver stackdriver
spec
セクションの下にstorageSizeOverride
フィールドを追加します。コンポーネントstackdriver-prometheus-k8s
またはstackdriver-prometheus-app
を使用できます。このセクションの形式は次のとおりです。storageSizeOverride: STATEFULSET_NAME: SIZE
この例では、statefulset
stackdriver-prometheus-k8s
とサイズ120Gi
を使用します。apiVersion: addons.sigs.k8s.io/v1alpha1 kind: Stackdriver metadata: name: stackdriver namespace: kube-system spec: projectID: my-project clusterName: my-cluster clusterLocation: us-west-1a storageSizeOverride: stackdriver-prometheus-k8s: 120Gi
保存してコマンドライン エディタを終了します。
Pod のヘルスチェックを行います。
kubectl --kubeconfig=KUBECONFIG -n kube-system get pods | grep stackdriver
たとえば、正常な Pod では次のようになります。stackdriver-prometheus-k8s-0 2/2 Running 0 5d19h
コンポーネントの Pod 仕様を確認して、ストレージ サイズが正しくオーバーライドされていることを確認します。
kubectl --kubeconfig=KUBECONFIG -n kube-system describe statefulset STATEFULSET_NAME
レスポンスは次のようになります。
Volume Claims: Name: my-statefulset-persistent-volume-claim StorageClass: my-storage-class Labels: Annotations: Capacity: 120Gi Access Modes: [ReadWriteOnce]
ストレージ クラスのデフォルトをオーバーライドする
要件
まず、使用する StorageClass を作成する必要があります。
ロギングとモニタリングのコンポーネントによって要求される永続ボリュームのデフォルトのストレージ クラスをオーバーライドするには、次のようにします。
コマンドライン エディタで Stackdriver カスタム リソースを開きます。
kubectl --kubeconfig=KUBECONFIG -n kube-system edit stackdriver stackdriver
ここで、KUBECONFIG はクラスタの kubeconfig ファイルのパスです。これは、管理クラスタまたはユーザー クラスタのいずれかです。
spec
セクションの下にstorageClassName
フィールドを追加します。storageClassName: STORAGECLASS_NAME
storageClassName
フィールドは、既存のデフォルトのストレージ クラスをオーバーライドし、要求される永続ボリュームですべてのロギングとモニタリングのコンポーネントに適用されます。サンプル ファイルは次のようになります。apiVersion: addons.sigs.k8s.io/v1alpha1 kind: Stackdriver metadata: name: stackdriver namespace: kube-system spec: projectID: my-project clusterName: my-cluster clusterLocation: us-west-1a proxyConfigSecretName: my-secret-name enableVPC:
optimizedMetrics: true storageClassName: my-storage-class 変更を保存します
Pod のヘルスチェックを行います。
kubectl --kubeconfig=KUBECONFIG -n kube-system get pods | grep stackdriver
たとえば、正常な Pod では次のようになります。
stackdriver-prometheus-k8s-0 1/1 Running 0 5d19h
コンポーネントの Pod 仕様を確認して、ストレージ クラスが正しく設定されていることを確認します。
kubectl --kubeconfig=KUBECONFIG -n kube-system describe statefulset STATEFULSET_NAME
たとえば、ステートフル セット
stackdriver-prometheus-k8s
を使用すると、レスポンスは次のようになります。Volume Claims: Name: stackdriver-prometheus-data StorageClass: my-storage-class Labels: Annotations: Capacity: 120Gi Access Modes: [ReadWriteOnce]
指標データにアクセスする
Metrics Explorer では 1,500 以上の指標を選択できます。Metrics Explorer にアクセスするには、次のようにします。
Google Cloud Console で [Monitoring] を選択するか、次のボタンを使用します。
[リソース] > [Metrics Explorer] を選択します。
Monitoring のメタデータにアクセスする
メタデータは、指標で間接的に使用されます。Monitoring Metrics Explorer で指標をフィルタする場合、metadata.systemLabels
と metadata.userLabels
で指標をフィルタするオプションが表示されます。システムラベルは、Pod のノード名や Service 名などのラベルです。ユーザーラベルは、Pod 仕様の「metadata」セクションの Kubernetes YAML ファイル内の Pod に割り当てられるラベルです。
デフォルトの Cloud Monitoring 割り当て上限
Anthos clusters on VMware のモニタリングには、プロジェクトごとに 1 分あたり 6,000 回の API 呼び出しのデフォルト上限があります。この上限を超えると、指標が表示されない場合があります。モニタリングの上限を引き上げる必要がある場合は、Google Cloud Console からリクエストしてください。
既知の問題: Cloud Monitoring のエラー条件
(問題 ID 159761921)
特定の条件下で、新しい各クラスタにデフォルトでデプロイされたデフォルトの Cloud Monitoring Pod が応答しなくなる場合があります。たとえば、クラスタがアップグレードされた場合に、statefulset/prometheus-stackdriver-k8s
内の Pod が再起動されると、ストレージ データが破損する可能性があります。
具体的には、破損したデータによって、prometheus-stackdriver-sidecar
がクラスタ ストレージ PersistentVolume
に書き込むことができない場合、モニタリングを行っている Pod stackdriver-prometheus-k8s-0
がループ状態になる可能性があります。
エラーを手動で診断して復旧する手順は次のとおりです。
Cloud Monitoring の障害の診断
モニタリングを行っている Pod に障害が発生すると、次のログが報告されます。
{"log":"level=warn ts=2020-04-08T22:15:44.557Z caller=queue_manager.go:534 component=queue_manager msg=\"Unrecoverable error sending samples to remote storage\" err=\"rpc error: code = InvalidArgument desc = One or more TimeSeries could not be written: One or more points were written more frequently than the maximum sampling period configured for the metric.: timeSeries[0-114]; Unknown metric: kubernetes.io/anthos/scheduler_pending_pods: timeSeries[196-198]\"\n","stream":"stderr","time":"2020-04-08T22:15:44.558246866Z"}
{"log":"level=info ts=2020-04-08T22:15:44.656Z caller=queue_manager.go:229 component=queue_manager msg=\"Remote storage stopped.\"\n","stream":"stderr","time":"2020-04-08T22:15:44.656798666Z"}
{"log":"level=error ts=2020-04-08T22:15:44.663Z caller=main.go:603 err=\"corruption after 29032448 bytes: unexpected non-zero byte in padded page\"\n","stream":"stderr","time":"2020-04-08T22:15:44.663707748Z"}
{"log":"level=info ts=2020-04-08T22:15:44.663Z caller=main.go:605 msg=\"See you next time!\"\n","stream":"stderr","time":"2020-04-08T22:15:44.664000941Z"}
Cloud Monitoring のエラーからの復旧
Cloud Monitoring を手動で復旧するには:
クラスタのモニタリングを停止します。モニタリングの調整を防ぐため、
stackdriver
Operator をスケールダウンします。kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system scale deployment stackdriver-operator --replicas 0
モニタリング パイプライン ワークロードを削除します。
kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system delete statefulset stackdriver-prometheus-k8s
モニタリング パイプラインの PersistentVolumeClaim(PVC)を削除します。
kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system delete pvc -l app=stackdriver-prometheus-k8s
クラスタ モニタリングを再開します。Stackdriver Operator をスケールアップして、新しいモニタリング パイプラインを再インストールし、調整を再開します。
kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system scale deployment stackdriver-operator --replicas=1
Prometheus と Grafana
以降のセクションでは、Anthos clusters on VMware クラスタとともに Prometheus と Grafana を使用する方法について説明します。
Prometheus と Grafana を有効にする
バージョン 1.2 以降の Anthos clusters on VMware では、Prometheus と Grafana を有効にするか無効にするかを選択できます。新しいユーザー クラスタでは、Prometheus と Grafana はデフォルトで無効になっています。
ユーザー クラスタには
monitoring-sample
という名前の Monitoring オブジェクトがあります。このオブジェクトを編集用に開きます。kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] edit \ monitoring monitoring-sample --namespace kube-system
ここで、[USER_CLUSTER_KUBECONFIG] はユーザー クラスタの kubeconfig ファイルです。
Prometheus と Grafana を有効にするには、
enablePrometheus
をtrue
に設定します。Prometheus と Grafana を無効にするには、enablePrometheus
をfalse
に設定します。apiVersion: addons.k8s.io/v1alpha1 kind: Monitoring metadata: labels: k8s-app: monitoring-operator name: monitoring-sample namespace: kube-system spec: channel: stable ... enablePrometheus: true
編集セッションを閉じると変更が保存されます。
既知の問題
ユーザー クラスタでは、アップグレード中に Prometheus と Grafana は自動的に無効になります。ただし、構成データと指標データは失われません。
この問題を回避するには、アップグレード後に monitoring-sample
を編集用に開いて enablePrometheus
を true
に設定します。
Grafana ダッシュボードからモニタリング指標にアクセスする
Grafana は、クラスタから収集された指標を表示します。これらの指標を表示するには、次の手順で Grafana のダッシュボードにアクセスする必要があります。
ユーザー クラスタの
kube-system
Namespace で実行されている Grafana Pod の名前を取得します。kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] -n kube-system get pods
[USER_CLUSTER_KUBECONFIG] は、ユーザー クラスタの kubeconfig ファイルです。
Grafana Pod には、TCP localhost ポート 3000 をリッスンする HTTP サーバーがあります。ローカルポートを Pod のポート 3000 に転送すると、ウェブブラウザで Grafana のダッシュボードを表示できます。
たとえば、Pod の名前が
grafana-0
であるとします。ポート 50000 を Pod のポート 3000 に転送するには、次のコマンドを入力します。kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] -n kube-system port-forward grafana-0 50000:3000
ウェブブラウザで
http://localhost:50000
に移動します。ログインページで、ユーザー名とパスに「
admin
」と入力します。ログインに成功すると、パスワードを変更するように求められます。デフォルトのパスワードを変更すると、ユーザー クラスタの Grafana ホーム ダッシュボードが読み込まれます。
他のダッシュボードにアクセスするには、ページの左上にあるホーム プルダウン メニューをクリックします。
Grafana の使用例については、Grafana ダッシュボードを作成するをご覧ください。
アラートにアクセスする
Prometheus Alertmanager は、Prometheus サーバーからアラートを収集します。これらのアラートは Grafana ダッシュボードに表示できます。アラートを表示するには、次の手順でダッシュボードにアクセスする必要があります。
alertmanager-0
Pod のコンテナは、TCP ポート 9093 をリッスンします。ローカルポートを Pod のポート 9093 に転送します。kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] port-forward \ -n kube-system alertmanager-0 50001:9093
ウェブブラウザで
http://localhost:50001
に移動します。
Prometheus Alertmanager の構成を変更する
ユーザー クラスタの monitoring.yaml
ファイルを編集して、Prometheus Alertmanager のデフォルト構成を変更できます。これは、アラートをダッシュボードに保存するのではなく、特定の宛先に転送したい場合に行います。Prometheus で AlertManager を構成する方法については、構成ドキュメントをご覧ください。
Alertmanagerager の構成を変更するには、次の手順を行います。
ユーザー クラスタの
monitoring.yaml
マニフェスト ファイルのコピーを作成します。kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] -n kube-system \ get monitoring monitoring-sample -o yaml > monitoring.yaml
Alertmanager を構成するには、
spec.alertmanager.yml
のフィールドを変更します。完了したら、変更したマニフェストを保存します。マニフェストをクラスタに適用します。
kubectl apply --kubeconfig [USER_CLUSTER_KUBECONIFG] -f monitoring.yaml
Prometheus リソースをスケーリングする
デフォルトのモニタリング構成では、最大 5 つのノードがサポートされます。大規模なクラスタの場合は、Prometheus サーバーのリソースを調整できます。推奨値は、クラスタノードあたりの CPU コア数が 50m で、メモリが 500Mi です。クラスタに 2 つのノードがあり、それぞれに Prometheus に適したリソースがあることを確認してください。詳細については、ユーザー クラスタのサイズ変更をご覧ください。
Prometheus Server のリソースを変更するには、次の手順を行います。
ユーザー クラスタの
monitoring.yaml
マニフェスト ファイルのコピーを作成します。kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] -n kube-system get monitoring monitoring-sample -o yaml > monitoring.yaml
リソースをオーバーライドするには、
spec.resourceOverride
のフィールドを変更します。完了したら、変更したマニフェストを保存します。例:spec: resourceOverride: - component: Prometheus resources: requests: cpu: 300m memory: 3000Mi limits: cpu: 300m memory: 3000Mi
マニフェストをクラスタに適用します。
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] apply -f monitoring.yaml
Grafana ダッシュボードを作成する
これまでの手順で、指標を公開するアプリケーションをデプロイし、指標が公開されて Prometheus により取得されていることを確認しました。次は、アプリケーション レベルの指標をカスタムの Grafana ダッシュボードに追加します。
Gradfana ダッシュボードを作成するには、次の手順を行います。
- 必要に応じて、Grafana にアクセスします。
- Home Dashboard で、ページの左上隅にあるホーム プルダウン メニューをクリックします。
- 右側のメニューで [New dashboard] をクリックします。
- [New panel] セクションで [Graph] をクリックします。空のグラフ ダッシュボードが表示されます。
- [Panel title] をクリックし、[Edit] をクリックします。下部の [Graph] パネルの [Metrics] タブが開きます。
- [Data Source] プルダウン メニューから [user] を選択します。[Add query] をクリックし、検索フィールドに
foo
と入力します。 - 画面右上の [Back to dashboard] ボタンをクリックします。ダッシュボードが表示されます。
- ダッシュボードを保存するには、画面右上の [Save dashboard] をクリックします。ダッシュボードの名前を選択して、[Save] をクリックします。
クラスタ内モニタリングを無効にする
クラスタ内モニタリングを無効にするには、monitoring-sample
オブジェクトに加えた変更を元に戻します。
monitoring-sample
オブジェクトを編集用に開きます。kubectl --kubeconfig USER_CLUSTER_KUBECONFIG edit \ monitoring monitoring-sample --namespace kube-system
USER_CLUSTER_KUBECONFIG をユーザー クラスタの kubeconfig ファイルに置き換えます。
Prometheus と Grafana を無効にするには、
enablePrometheus
をfalse
に設定します。apiVersion: addons.k8s.io/v1alpha1 kind: Monitoring metadata: labels: k8s-app: monitoring-operator name: monitoring-sample namespace: kube-system spec: channel: stable ... enablePrometheus: false
編集セッションを閉じると変更が保存されます。
prometheus-0
、prometheus-1
、grafana-0
statefulsets が削除されたことを確認します。kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods --namespace kube-system
例: アプリケーション レベルの指標を Grafana ダッシュボードに追加する
以下では、アプリケーションの指標を追加する方法について説明します。このセクションでは、次のタスクを行います。
foo
という指標を公開するサンプル アプリケーションをデプロイします。- Prometheus が指標を公開、取得していることを確認します。
- カスタム Grafana ダッシュボードを作成します。
サンプル アプリケーションをデプロイする
サンプル アプリケーションは 1 つの Pod で実行します。Pod のコンテナは定数値 40
で指標 foo
を公開します。
次の Pod マニフェスト pro-pod.yaml
を作成します。
apiVersion: v1
kind: Pod
metadata:
name: prometheus-example
annotations:
prometheus.io/scrape: 'true'
prometheus.io/port: '8080'
prometheus.io/path: '/metrics'
spec:
containers:
- image: registry.k8s.io/prometheus-dummy-exporter:v0.1.0
name: prometheus-example
command:
- /bin/sh
- -c
- ./prometheus_dummy_exporter --metric-name=foo --metric-value=40 --port=8080
続いて、この Pod マニフェストをユーザー クラスタに適用します。
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] apply -f pro-pod.yaml
指標が公開、取得されていることを確認する
prometheus-example
Pod のコンテナは、TCP ポート 8080 をリッスンします。ローカルポートを Pod のポート 8080 に転送します。kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] port-forward prometheus-example 50002:8080
アプリケーションが指標を公開していることを確認するには、次のコマンドを実行します。
curl localhost:50002/metrics | grep foo
このコマンドは、次の出力を返します。
# HELP foo Custom metric # TYPE foo gauge foo 40
prometheus-0
Pod のコンテナは、TCP ポート 9090 をリッスンします。ローカルポートを Pod のポート 9090 に転送します。kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] port-forward prometheus-0 50003:9090
Prometheus が指標を取得していることを確認するには、http://localhost:50003/targets に移動します。これにより、
prometheus-io-pods
ターゲット グループのprometheus-0
Pod にアクセスできます。Prometheus で指標を表示するには、http://localhost:50003/graph に移動します。検索フィールドに「
foo
」と入力し、[Execute] をクリックします。ページに指標が表示されます。