監視スタックを使用する

EKS/AKS 上の Prometheus、Grafana、Alert Manager を使用して Automation Suite を監視します。

Automation Suite クラスターの監視スタックには Prometheus、Grafana、Alertmanager が含まれ、独自の監視スタックを使用しない限り、これらは自動的にインストールされます。

このページでは、Automation Suite クラスターにバンドルされている監視ツールを使用するために最適化された一連の監視シナリオについて説明します。独自の監視スタックを利用する場合は、使用するツールの公式ドキュメントに従ってクラスターの健全性を監視してください。

重要:

コレクターを使用してサードパーティ ツールにメトリックをエクスポートする場合、アプリケーションの監視を有効化すると、Automation Suite の機能が中断される可能性があります。

監視ツールにアクセスする

概要

Automation Suite クラスターの監視スタックには、Prometheus、Grafana、Alert Manager が含まれます。

Automation Suite 監視ツールには、次の URL を使用して個別にアクセスできます。

アプリケーション	ツール	URL	例
メトリック	Prometheus	https://monitoring.fqdn/metrics	https://monitoring.automationsuite.mycompany.com/metrics
ダッシュボード	Grafana	https://monitoring.fqdn/grafana	https://monitoring.automationsuite.mycompany.com/grafana
アラート管理	Alertmanager	https://monitoring.fqdn/alertmanager	https://monitoring.automationsuite.mycompany.com/alertmanager

監視ツールの認証

監視ツールに初めてアクセスするには、「Automation Suite にアクセスする」の手順に従います。

現在発生しているアラートを確認する

アラートを表示するには、https://monitoring.fqdn/metrics を使用して Prometheus に移動し、[Alerts] タブを選択します。ここでは、Automation Suite で設定されたすべてのアラートを確認できます。

• アクティブなアラートを表示するには、[Firing] チェックボックスを使用してアラートのステータスをフィルター処理します。

• 特定のアラートの詳細を確認するには、表示するアラートを展開します。

  以下の画像は、現在アラートが発生している [Prometheus Alerts] タブを示しています。

  

アラートを抑制する

アラートが多すぎる場合は、これらを抑制できます。そのためには、以下の手順に従ってください。

1. https://monitoring.fqdn/alertmanager を使用して Alertmanager にアクセスします。
2. 該当のアラートを見つけ、[Silence] を選択します。
3. [Creator] と [Comment] の詳細を入力し、[Create] を選択します。アラートが [ Monitoring] ダッシュボード に表示されたり、設定した受信者にレポートされることはなくなります。

アラートを設定する

注:

アラートの構成を開始する前に、 kubectl を有効化してください。

新しいメール設定を追加する

インストール後に新しいメール設定を追加するには、次のコマンドを実行します。

./uipathctl config alerts add-email \
  --name test \
  --to "[e-mail]" \
  --from "[e-mail]" \
  --smtp server.mycompany.com \
  --username admin \
  --password somesecret \
  --require-tls \
  --ca-file <path_to_ca_file> \
  --cert-file <path_to_cert_file> \
  --key-file <path_to_key_file> \
  --send-resolved \
  --ASEA

次の表で、 add-email コマンドで使用できるフラグについて説明します。

フラグ	説明	例
name	メール設定の名前	testconfig
to	受信者のメール アドレス	[e-mail]
from	送信者のメール アドレスです。	[e-mail]
SMTP	SMTP サーバーの URL または IP アドレスとポート番号	server.mycompany.com:567
username	認証ユーザー名	admin
password	認証パスワード	securepassword
require-tls	SMTP サーバーで TLS が有効化されることを示す Boolean フラグ。	N/A
ca-file	SMTP サーバーの CA 証明書を含むファイル パス。CA がプライベートの場合、これは任意です。	./ca-file.crt
cert-file	SMTP サーバーの証明書を含むファイル パス。証明書がプライベートの場合、これは任意です。	./cert-file.crt
key-file	SMTP サーバーの証明書の秘密キーを含むファイル パスです。証明書がプライベートの場合、これは必須です。	./key-file.crt
send-resolved	アラートの解決後にメールを送信する Boolean フラグ。	N/A
ASEA	Automation Suite を EKS または AKS にインストールしたことを示す Boolean フラグ。	N/A

メール設定を削除する

メール設定を削除するには、次のコマンドを実行する必要があります。必ず、削除するメール設定の名前を渡してください。

./uipathctl config alerts remove-email --name test --ASEA

メール設定を更新する

メール設定を更新するには、次のコマンドを実行する必要があります。必ず、更新するメール設定の名前と、編集する追加の任意パラメーターを渡してください。これらのパラメーターは、新しいメール設定を追加するためのパラメーターと同じです。1 つ以上のフラグを同時に渡すことができます。

./uipathctl config alerts update-email --name test --ASEA [additional_flags]

Grafana ダッシュボードにアクセスする

Grafana ダッシュボードにアクセスするには、資格情報を取得し、その資格情報を使用してログインする必要があります。

• ユーザー名:

  kubectl -n monitoring get secrets/grafana-creds -o "jsonpath={.data.admin-user}" | base64 -d; echo
  

• パスワード:

  kubectl -n monitoring get secrets/grafana-creds -o "jsonpath={.data.admin-password}" | base64 -d; echo
  

永続ボリュームの監視

[Kubernetes / Persistent Volumes] ダッシュボードでは、永続ボリュームを監視できます。各ボリュームについて、空き領域と使用されている領域を追跡できます。

次の図は、Kubernetes 永続ボリューム ダッシュボードを示しています。

クラスター エクスプローラーの [ストレージ] メニュー内の [PersistentVolumes] 項目を選択して、各ボリュームのステータスを確認することもできます。

ハードウェアの使用状況を監視する

ノードごとのハードウェア使用率を確認するには、 ノード/エクスポーター/ノード ダッシュボードを使用します。CPU、メモリ、ディスク、およびネットワーク上のデータが利用可能です。

[Kubernetes / Compute Resources / Namespace (Workloads)] ダッシュボードを使用して、特定のワークロードのハードウェア使用状況を監視できます。uipath 名前空間を選択して必要なデータを取得します。

Grafana のグラフの共有可能な視覚的スナップショットを作成する

1. グラフのタイトルの横にあるメニュー ボタンを選択し、[ 共有] を選択します。
2. [Snapshot] タブを選択し、[Snapshot name] と [Expire] を設定します。
3. [ snapshot.raintank.io にパブリッシュ] を選択します 。

詳細については、 ダッシュボードの共有に関する Grafana のドキュメントをご覧ください。

注:

このスナップショットは、このリンクを持つ誰もがパブリック インターネット上で表示できます。

カスタムの永続 Grafana ダッシュボードを作成する

注:

Grafana UI で直接作成したダッシュボードは、ポッドまたはノードの再起動後も保持されません。既成のダッシュボードは monitoring 名前空間に ConfigMap として保存されるため、影響を受けません。

永続的なカスタム ダッシュボードを作成するには、次の手順を実行します。

1. Grafana でダッシュボードを構築します。手順については、 Grafana のドキュメントをご覧ください。
2. ダッシュボードを JSON ファイルとしてエクスポートします。
3. 次の ConfigMap 設定を YAML ファイルとして保存し、 <dashboard-name> を一意の名前に、 <dashboard-json> をエクスポートした JSON ファイルの内容に置き換えます。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: <dashboard-name>
     namespace: monitoring
     labels:
       grafana_dashboard: "1"
   data:
     dashboard.json: |
       <dashboard-json>
   

4. コンフィグマップを適用します。

   kubectl apply -f <file_name.yaml>
   

ConfigMap を適用すると、Grafana によってダッシュボードが自動的にインポートされます。

Temporal as a Service (TaaS) の監視

TaaS サーバー ポッドは Prometheus メトリックを公開します。クラスターで Prometheus が有効化されている場合、メトリックは taas-temporal-* ポッドから自動的にスクレイピングされます。

次の表に、TaaS の正常性とパフォーマンスを監視するための主要なメトリックを示します。

メトリック	説明
temporal_activity_schedule_to_start_latency_bucket	アクティビティがスケジュールされてから、作業者がそれを受け取るまでの時間。高い値は、ワーカーがタスクを十分な速度で処理できないことを示します。
temporal_workflow_task_schedule_to_start_latency_bucket	ワークフロータスクがスケジュールされてから、ワーカーが開始するまでの時間。値が大きい場合は、キューのバックログを示します。
temporal_workflow_completed	正常に完了したワークフローの実行回数です。
temporal_workflow_failed	失敗したワークフロー実行の数。
temporal_num_pollers	現在アクティブなワーカー ポーリング ラーの数 (ポーリング ラーの種類別)。
temporal_request_latency_bucket	TaaS フロントエンドへのクライアント gRPC 要求の待機時間。

テンポラル UI にアクセスする

既定では、Temporal Web UI はクラスター外には公開されません。診断目的でアクセスするには、デプロイにポートフォワードします。

kubectl port-forward -n uipath deployment/taas-temporal-web 8008:8008

ブラウザーで http://localhost:8008 を開きます。ポートフォワードでアクセスする場合、ログインは必要ありません。

テンポラル UI では、個々のワークフロー実行の検査、実行履歴の表示、失敗やタイムアウトのアクティビティの特定を行うことができます。

利用可能なメトリック

利用可能なメトリックは、Prometheus の UI で検索できます。

使用可能なメトリックについてのドキュメントを以下に示します。

• https://github.com/prometheus/node_exporter#enabled-by-default - プレビューに接続する
• https://github.com/kubernetes/kube-state-metrics/tree/master/docs#exposed-metrics - プレビューへの接続
• 「Querying Metrics from Prometheus」 (Istio)