ロギングとモニタリングの使用

このページでは、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 コンソールでプロジェクトのログビューアを開きます。
次の方法でコンテナのログを検索します。
1. 左上のカタログプルダウンボックスをクリックし、[Kubernetes コンテナ] を選択します。
2. クラスタ名、Namespace、コンテナの順に選択します。

クラスタの状態をモニタリングするダッシュボードを作成する

Anthos clusters on VMware クラスタは、システムおよびコンテナの指標をモニタリングするようにデフォルトで構成されています。クラスタ（管理者またはユーザー）を作成したら、Cloud Monitoring で次のダッシュボードを作成し、Anthos clusters on VMware 運用チームがクラスタの状態をモニタリングできるようにすることをおすすめします。

コントロールプレーンの稼働時間ダッシュボード
Pod のステータスダッシュボード
ノードのステータスダッシュボード
VM のヘルスステータスダッシュボード
ノード使用率ダッシュボード

ダッシュボードは、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] をクリックします。ページに指標が表示されます。

ロギングとモニタリングの使用

Cloud Logging と Cloud Monitoring の使用

モニタリング対象リソース

ログデータにアクセスする

クラスタの状態をモニタリングするダッシュボードを作成する

前提条件

コントロール プレーンの稼働時間ダッシュボードを作成する

Pod ステータス ダッシュボードを作成する

ノード ステータス ダッシュボードを作成する

VM のヘルス ステータス ダッシュボードを作成する

ノード使用率ダッシュボードを作成する

Stackdriver コンポーネント リソースの構成

CPU とメモリのリクエストと上限のデフォルト値をオーバーライドする

ストレージ サイズのデフォルトをオーバーライドする

ストレージ クラスのデフォルトをオーバーライドする

指標データにアクセスする

Monitoring のメタデータにアクセスする

デフォルトの Cloud Monitoring 割り当て上限

既知の問題: Cloud Monitoring のエラー条件

Cloud Monitoring の障害の診断

Cloud Monitoring のエラーからの復旧

Prometheus と Grafana

Prometheus と Grafana を有効にする

既知の問題

Grafana ダッシュボードからモニタリング指標にアクセスする

アラートにアクセスする

Prometheus Alertmanager の構成を変更する

Prometheus リソースをスケーリングする

Grafana ダッシュボードを作成する

クラスタ内モニタリングを無効にする

例: アプリケーション レベルの指標を Grafana ダッシュボードに追加する

サンプル アプリケーションをデプロイする

指標が公開、取得されていることを確認する

コントロールプレーンの稼働時間ダッシュボードを作成する

Pod ステータスダッシュボードを作成する

ノードステータスダッシュボードを作成する

VM のヘルスステータスダッシュボードを作成する

Stackdriver コンポーネントリソースの構成

ストレージサイズのデフォルトをオーバーライドする

ストレージクラスのデフォルトをオーバーライドする

例: アプリケーションレベルの指標を Grafana ダッシュボードに追加する

サンプルアプリケーションをデプロイする