Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

未解決のアラートのクエリと表示

このページでは、GDC コンソールと Cortex エンドポイントの curl ツールを使用して、オープンアラートをクエリして可視化し、問題の認識と解決を行う方法について詳しく説明します。

Google Distributed Cloud（GDC）エアギャップアプライアンス環境のログと指標に基づいてアラートルールを作成したら、プロジェクトのオープンアラートのモニタリングを開始できます。GDC コンソールでシステムイベントによってトリガーされるアラートを可視化してフィルタリングできます。また、柔軟なスクリプト作成と自動化のために、Cortex から curl ツールを使用してアラートに直接アクセスすることもできます。

オープンアラートには、次の 2 つの方法でアクセスできます。

GDC コンソール: 特定のデータソースのアラート数、重大度、期間、ステータス、メッセージ、ラベルなどの情報を含む統合パネルでアラートデータを可視化します。GDC コンソールには、システムコンポーネントからのアラートをフィルタリングして分析するための使いやすいインターフェースが用意されています。
Cortex Alertmanager エンドポイント: より高度なユースケースでは、コマンドラインで curl ツールを使用して、プロジェクトの Cortex インスタンスを直接クエリします。 Cortex は、プロジェクトの Alertmanager アラートを保存し、プログラムによるアクセス用の HTTP エンドポイントを提供します。このアクセスにより、データのエクスポート、タスクの自動化、cron ジョブの構成、カスタム統合の構築が可能になります。

始める前に

アラートのクエリと可視化に必要な権限を取得するには、プロジェクトの IAM 管理者に、プロジェクト Namespace で関連するプロジェクト Cortex Alertmanager ロールのいずれかを付与するよう依頼してください。必要なアクセスレベルと権限に応じて、プロジェクトでこのリソースの編集者ロールまたは閲覧者ロールを取得できます。

ログをエクスポートするために必要な権限を取得するには、プロジェクトの IAM 管理者にプロジェクト Grafana 閲覧者（project-grafana-viewer）ロールを付与するよう依頼してください。このロールベースのアクセス制御プロセスにより、データ可視化に安全にアクセスできます。これらのロールの詳細については、IAM 権限を準備するをご覧ください。

次の表に、PA and AO persona の Role 要件をまとめます。

ペルソナ	オブジェクト	クラスタ	ロール	Namespace	グループ/ユーザー	構成
PA	alertmanager	org-admin	`project-cortex-alertmanager-viewer`	platform-obs	グループ	1
PA	alertmanager	org-admin	`project-cortex-alertmanager-viewer`	platform-obs	ユーザー	2
AO	alertmanager	org-admin	`project-cortex-alertmanager-viewer`	PROJECT_NAMESPACE	グループ	1
AO	alertmanager	org-admin	`project-cortex-alertmanager-viewer`	PROJECT_NAMESPACE	ユーザー	2

次の変数を適切に置き換えます。

変数	説明
`KUBECONFIG`	この RoleBinding が適用される `NAMESPACE` を含む特定のクラスタの kubeconfig が必要になります。
`RULE_NAME`	Namespace 内のこの `RoleBinding` リソースの一意の名前。例: `pa-cortex-alertmanager-viewer`
`NAMESPACE`	この `RoleBinding` が作成され、適用される Kubernetes Namespace。前の表の `Namespace` 列を確認してください。
`EMAIL_ADDRESS`	ロールが付与されるユーザーの識別子。多くの場合、これはメールアドレスです。例: `platform-administrator@example.com`
`ROLE`	ユーザーに付与する権限を含む `Role` の名前。前の表で利用可能なロールを確認してください。
`GROUP_NAME`	PA/AO ユーザーが属する `Group` の名前。例: `pa-group`
`ZONE`	ゾーンの名前

構成 1

この構成では、ユーザーグループに org クラスタ内の PA/AO アラートにアクセスする権限が付与されます。この構成を設定したら、このドキュメントのコンソールのセクションを参照して、GDC コンソールでアラートを表示します。

kubectl コマンド

一般的なコマンド形式は次のとおりです。

kubectl --kubeconfig `KUBECONFIG` create rolebinding `RULE_NAME` -n `NAMESPACE` --group=`GROUP_NAME` --role=project-cortex-alertmanager-viewer

例:

kubectl --kubeconfig <path-to-kubeconfig> create rolebinding project-cortex-alertmanager-viewer-binding --role=project-cortex-alertmanager-viewer --group=my-team --namespace=platform-obs

.yaml ファイル

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: RULE_NAME
  namespace: NAMESPACE
subjects:
- kind: Group
  name: GROUP_NAME
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: project-cortex-alertmanager-viewer
  apiGroup: rbac.authorization.k8s.io

構成 2

この構成では、ユーザーに org クラスタ内の PA/AO アラートにアクセスする権限が付与されます。この構成を設定したら、このドキュメントのコンソールのセクションを参照して、GDC コンソールでアラートを表示します。

kubectl コマンド

一般的なコマンド形式は次のとおりです。

kubectl --kubeconfig `KUBECONFIG` create rolebinding `RULE_NAME` -n `NAMESPACE` --user=`EMAIL_ADDRESS` --role=project-cortex-alertmanager-viewer

例:

kubectl --kubeconfig <path-to-kubeconfig> create rolebinding project-cortex-alertmanager-viewer-binding --role=project-cortex-alertmanager-viewer --user=my-email@example.com --namespace=platform-obs

IAC ファイルパス

/infrastructure/zonal/zones/`ZONE`/org-admin/rolebindings/`EMAIL_ADDRESS`/<YAML_FILE>

.yaml ファイル

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: RULE_NAME
  namespace: NAMESPACE
subjects:
- kind: User
  name: EMAIL_ADDRESS
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: project-cortex-alertmanager-viewer
  apiGroup: rbac.authorization.k8s.io

これらのロールの詳細については、 IAM 権限を準備するをご覧ください。

Grafana エンドポイント

アプリケーションオペレーター（AO）の場合:

次の URL を開いて、プロジェクトのエンドポイントにアクセスします。

https://GDC_URL/PROJECT_NAMESPACE/grafana

次のように置き換えます。

GDC_URL: GDC 内の組織の URL。
PROJECT_NAMESPACE: プロジェクトの Namespace。

プロジェクトの UI には、アラートに関する情報を含む [アラート - 概要] ダッシュボードなどのデフォルトのダッシュボードが含まれています。UI からアラートをクエリすると、プロジェクトからアラート情報を視覚的に取得し、リソースの統合ビューを取得して、問題を認識して迅速に解決できます。

プラットフォーム管理者（PA）の場合:

次の URL を開いて、platform-obs プロジェクトのエンドポイントにアクセスします。

https://GDC_URL/platform-obs/grafana

GDC_URL は、GDC 内の組織の URL に置き換えます。

システムモニタリングインスタンスのユーザーインターフェース（UI）には、データオブザーバビリティのアラートに関する情報を含む [アラート - 概要] ダッシュボードなどのデフォルトのダッシュボードが含まれています。UI からアラートをクエリすると、プロジェクトからアラート情報を視覚的に取得し、リソースの統合ビューを取得して、問題を認識して迅速に解決できます。

[アラート - 概要] ダッシュボードには、特定のデータソースのアラート数と、アラート履歴の折れ線グラフが表示されます。このグラフには、データソースで 1 時間あたりに開いているアラートの数が表示されます。

図 1.Grafana UI の [アラート - 概要] ダッシュボード。

オープンアラートを表示してフィルタする

プロジェクト Namespace からオープンアラートをクエリしてフィルタするには、次のいずれかの方法を選択します。

コンソール

GDC コンソールからプロジェクトのオープンアラートを表示します。

GDC コンソールにログインします。
GDC コンソールで、プロジェクトを選択します。
ナビゲーションメニューで、 [**オペレーション**] [>] [**アラート**] を選択します。
[アラート] タブを選択します。
アラートのリストを表示します。
[オープンアラート] セクションで [フィルタ] をクリックすると、オープンアラートのみが表示されます。他のプロパティ名または値でアラートをフィルタすることもできます。
アラート名をクリックすると、アラートの詳細が表示されます。

Cortex エンドポイント

このセクションでは、Cortex Alertmanager エンドポイントを使用してアラートにアクセスする方法について説明します。

Cortex エンドポイントを確認する

次の URL は、プロジェクトの Cortex インスタンスのエンドポイントです。

  https://GDC_URL/PROJECT_NAMESPACE/cortex/alertmanager/

次のように置き換えます。

GDC_URL: GDC 内の組織の URL。
PROJECT_NAMESPACE: プロジェクト Namespace。

たとえば、platform-obs プロジェクトの org-1 組織の Cortex エンドポイントは https://org-1/platform-obs/cortex/alertmanager/ です。

注: ウェブブラウザで URL を直接開いてアラートをクエリできます。次のセクションの手順では、curl コマンドを使用してエンドポイントを呼び出しますが、ウェブブラウザにも同じことが当てはまります。

`curl` リクエストを認証する

gdcloud CLI をダウンロードしてインストールします。

設定します gdcloud core/organization_console_url プロパティ:

gdcloud config set core/organization_console_url
https://GDC_URL

構成済みの ID プロバイダでログインします:
```
gdcloud auth login
```
ユーザー名とパスワードを使用して認証し、ログインします。

ログインに成功したら、gdcloud auth print-identity-token コマンドを使用して、cURL リクエストの認可ヘッダーを使用できます。詳細については、 gdcloud auth をご覧ください。

Cortex エンドポイントを呼び出す

curl ツールを使用して Cortex エンドポイントにアクセスする手順は次のとおりです。

リクエストcurlを認証します。
curl を使用して Cortex エンドポイントを呼び出し、標準の Alertmanager API 仕様 (https://prometheus.io/docs/prometheus/latest/querying/api/#alertmanagers) を使用して URL を拡張し、アラートをクエリします。

curl リクエストの例を次に示します。
```
  curl https://GDC_URL/PROJECT_NAME/cortex/alertmanager/api/v1/alertmanagers \
  -H "Authorization: Bearer $(gdcloud auth print-identity-token \
  --audiences=https://GDC_URL)"
```
コマンドの後に次の出力が表示されます。API レスポンスは JSON 形式です。

注: URL からアクティブなアラートと削除されたアラートをクエリするには、api/v1/alertmanagers エンドポイントを追加します。

Alertmanager

Alertmanager では、クライアントアプリケーションからのアラート通知をモニタリングできます。Alertmanager を使用してアラートを調べ、ミュートし、アラートをフィルタまたはグループ化できます。

ルート管理クラスタで Loki 拒否監査ログアラートを無視する

図 2.Alertmanager から監査ログをクエリするメニューオプション。

事前定義のアラートポリシー

次の表に、Prometheus にプリインストールされているアラートルールを示します。

名前	説明
KubeAPIDown（重大）	KubeAPI は Prometheus ターゲットの検出から 15 分間、表示されなくなりました。
KubeClientErrors（警告）	Kubernetes API サーバークライアントエラー率が 0.01 を 15 分間超えました。
KubeClientErrors（重大）	Kubernetes API サーバークライアントエラー率が 0.1 を 15 分間超えました。
KubePodCrashLooping（警告）	Pod がクラッシュループ状態のまま 15 分以上経過しています。
KubePodNotReady（警告）	Pod が 15 分以上準備されていない状態です。
KubePersistentVolumeFillingUp（重大）	要求された PersistentVolume のフリーバイトが 0.03 未満です。
KubePersistentVolumeFillingUp（警告）	要求された PersistentVolume のフリーバイトが 0.15 未満です。
KubePersistentVolumeError（重大）	永続ボリュームが 5 分間、失敗または保留フェーズにあります。
KubeNodeNotReady（警告）	ノードが 15 分以上準備できていません。
KubeNodeCPUUsageHigh（重大）	ノードの CPU 使用率が 80% を超えています。
KubeNodeMemoryUsageHigh（重大）	ノードのメモリ使用量が 80% を超えています。
NodeFilesystemSpaceFillingUp（警告）	ノードファイルシステムの使用量が 60% を超えています。
NodeFilesystemSpaceFillingUp（重大）	ノードファイルシステムの使用量が 85% を超えています。
CertManagerCertExpirySoon（事前警告）	証明書の有効期限が 21 日後に切れます。
CertManagerCertNotReady（重大）	10 分後にトラフィックを処理するための証明書が準備ができていません。
CertManagerHittingRateLimits（重大）	5 分間にわたり、証明書の作成と更新のレート制限に達しました。
DeploymentNotReady（重大）	組織管理者クラスタの Deployment が 15 分以上準備されていない状態です。

alertmanagerConfigurationConfigmaps のサンプル

alertmanagerConfigurationConfigmaps にリストされている ConfigMap の構成の構文は、https://prometheus.io/docs/alerting/latest/configuration/ に従う必要があります。

apiVersion: observability.gdc.goog/v1alpha1
kind: ObservabilityPipeline
metadata:
  # Choose namespace that matches the project's namespace
  namespace: kube-system
  name: observability-config
# Configure Alertmanager
 alerting:
  # Storage size for alerting data within organization
  # Permission: PA
  localStorageSize: 1Gi

  # Permission: PA & AO
  # alertmanager config must be under the key "alertmanager.yml" in the configMap
  alertmanagerConfig: <configmap-for-alertmanager-config>

  # Permission: PA
  volumes:
    - <volume referenced in volumeMounts>

  # Permission: PA
  volumeMounts:
    - <volumeMount referenced in alertmanagerConfig>

ルールの構成例

# Configures either an alert or a target record for precomputation
apiVersion: monitoring.gdc.goog/v1alpha1
kind: MonitoringRule
metadata:
  # Choose namespace that contains the metrics that rules are based on
  # Note: alert/record will be produced in the same namespace
  namespace: g-fleetns-a
  name: alerting-config
spec:
  # Rule evaluation interval
  interval: <duration>

  # Configure limit for number of alerts (0: no limit)
  # Optional, Default: 0 (no limit)
  limit: <int>

  # Configure record rules
  recordRules:
    # Define which timeseries to write to (must be a valid metric name)
  - record: <string>

    # Define PromQL expression to evaluate for this rule
    expr: <string>

    # Define labels to add or overwrite
    # Optional, Map of {key, value} pairs
    labels:
      <labelname>: <labelvalue>

  # Configure alert rules
  alertRules:
    # Define alert name 
  - alert: <string>

    # Define PromQL expression to evaluate for this rule
    # https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/
    expr: <string>

    # Define when an active alert moves from pending to firing
    # Optional, Default: 0s
    for: <duration>

    # Define labels to add or overwrite
    # Required, Map of {key, value} pairs
    # Required labels: 
    #     severity: [error, critical, warning, info]
    #     code: 
    #     resource: component/service/hardware related to alert
    #     additional labels are optional
    labels:
      severity: <enum: [error, critical, warning, info]>
      code: 
      resource: <Short name of the related operable component>
      <labelname>: <tmpl_string>

    # Define annotations to add
    # Optional, Map of {key, value} pairs
    # Recommended annotations:
    #     message: value of Message field in UI
    #     expression: value of Rule field in UI
    #     runbookurl: URL for link in Actions to take field in UI
    annotations:
      <labelname>: <tmpl_string>

# Configures either an alert or a target record for precomputation
apiVersion: logging.gdc.goog/v1alpha1
kind: LoggingRule
metadata:
  # Choose namespace that contains the logs that rules are based on
  # Note: alert/record will be produced in the same namespace
  namespace: g-fleetns-a
  name: alerting-config
spec:
  # Choose which log source to base alerts on (Operational/Audit/Security Logs)
  # Optional, Default: Operational
  source: <string>

  # Rule evaluation interval
  interval: <duration>

  # Configure limit for number of alerts (0: no limit)
  # Optional, Default: 0 (no limit)
  limit: <int>

  # Configure record rules
  recordRules:
    # Define which timeseries to write to (must be a valid metric name)
  - record: <string>

    # Define LogQL expression to evaluate for this rule
    # https://grafana.com/docs/loki/latest/rules/
    expr: <string>

    # Define labels to add or overwrite
    # Optional, Map of {key, value} pairs
    labels:
      <labelname>: <labelvalue>

  # Configure alert rules
  alertRules:
    # Define alert name
  - alert: <string>

    # Define LogQL expression to evaluate for this rule
    expr: <string>

    # Define when an active alert moves from pending to firing
    # Optional, Default: 0s
    for: <duration>

    # Define labels to add or overwrite
    # Required, Map of {key, value} pairs
    # Required labels: 
    #     severity: [error, critical, warning, info]
    #     code: 
    #     resource: component/service/hardware related to alert
    #     additional labels are optional
    labels:
      severity: <enum: [error, critical, warning, info]>
      code:
      resource: <Short name of the related operable component>
      <labelname>: <tmpl_string>

    # Define annotations to add
    # Optional, Map of {key, value} pairs
    # Recommended annotations:
    #     message: value of Message field in UI
    #     expression: value of Rule field in UI
    #     runbookurl: URL for link in Actions to take field in UI
    annotations:
      <labelname>: <tmpl_string>

HTTP API からアラートをクエリする

オブザーバビリティプラットフォームは、システムモニタリングのためにプロジェクトから指標、アラート、その他の時系列データをクエリして読み取るための HTTP API エンドポイントを公開します。

オブザーバビリティ HTTP API からアラートを直接クエリして、ユースケースに応じて自動タスクの設定、レスポンスの調整、統合の構築を行います。たとえば、出力を別のコマンドに挿入したり、詳細をテキストファイル形式でエクスポートしたり、Linux cron ジョブを構成したりします。コマンドラインインターフェース（CLI）またはウェブブラウザからオブザーバビリティ HTTP API を呼び出し、結果を JSON 形式で取得できます。

このセクションでは、 API 仕様を使用して CLI からオブザーバビリティ HTTP API エンドポイントを呼び出し、アラートをクエリする方法について説明します。

このセクションでは、Alertmanager API 仕様を使用して CLI からオブザーバビリティ HTTP API エンドポイントを呼び出し、指標をクエリする方法について説明します。

始める前に

オブザーバビリティ HTTP API エンドポイントにアクセスするために必要な権限を取得するには、プロジェクトの IAM 管理者に、プロジェクト Namespace でプロジェクト Cortex Alertmanager 閲覧者（project-cortex-alertmanager-viewer）ロールを付与するよう依頼してください。

プロジェクトの IAM 管理者は、ロールバインディングを作成してアクセス権を付与できます。

a. インフラストラクチャオペレーター（IO）ルート管理者 - Project Cortex Alertmanager Viewer:

kubectl --kubeconfig $HOME/root-admin-kubeconfig create rolebinding 
io-cortex-alertmanager-viewer-binding -n infra-obs 
--user=fop-infrastructure-operator@example.com 
--role=project-cortex-alertmanager-viewer

b. プラットフォーム管理者（PA）ルート管理者 - Project Cortex Alertmanager Viewer:

kubectl --kubeconfig $HOME/root-admin-kubeconfig create rolebinding
pa-cortex-alertmanager-viewer-binding -n platform-obs 
--user=fop-platform-admin@example.com 
--role=project-cortex-alertmanager-viewer

c. アプリケーションオペレーター（AO）ルート管理者 - Project Cortex Alertmanager Viewer: Project: $AO_PROJECT AO User Name: $AO_USER

kubectl --kubeconfig $HOME/root-admin-kubeconfig create rolebinding 
project-cortex-alertmanager-viewer-binding -n $AO_PROJECT 
--user=$AO_USER 
--role=project-cortex-alertmanager-viewer

ロールバインディングが作成されたら、ログインユーザー名で対応する Alertmanager にアクセスできます。

ロールバインディングを確認する

kubectl --kubeconfig $HOME/org-1-admin-kubeconfig get rolebinding -n platform-obs

GDC コンソールからロールバインディングを設定する方法については、リソースへのアクセス権を付与するをご覧ください。

Cortex エンドポイント

次の URL は、アラートにアクセスするための Cortex エンドポイントです。

https://GDC_URL/PROJECT_NAME/cortex/alertmanager/

次のように置き換えます。

GDC_URL: GDC 内の組織の URL。
PROJECT_NAME: プロジェクトの名前。

API エンドポイントを呼び出す

CLI から Cortex API エンドポイントにアクセスしてアラートをクエリする手順は次のとおりです。

前提条件を満たしていることを確認します。
CLI を開きます。
curl ツールを使用して Cortex エンドポイント URL を呼び出し、標準の https://prometheus.io/docs/prometheus/latest/querying/api/#alertmanagers を使用して URL を拡張し、アラートをクエリします。次に例を示します。
```
curl https://console.org-1.zone1.google.gdch.test/alice/cortex/alertmanager/api/v1/alertmanagers
```

コマンドの後に CLI に出力が表示されます。API レスポンスの形式は JSON です。

未解決のアラートのクエリと表示 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

始める前に

構成 1

構成 2

Grafana エンドポイント

オープン アラートを表示してフィルタする

コンソール

Cortex エンドポイント

Cortex エンドポイントを確認する

curl リクエストを認証する

Cortex エンドポイントを呼び出す

Alertmanager

事前定義のアラート ポリシー

alertmanagerConfigurationConfigmaps のサンプル

ルールの構成例

HTTP API からアラートをクエリする

始める前に

ロール バインディングを確認する

Cortex エンドポイント

API エンドポイントを呼び出す

未解決のアラートのクエリと表示

オープンアラートを表示してフィルタする

`curl` リクエストを認証する

事前定義のアラートポリシー

ロールバインディングを確認する