SambaRack 監視のインストール - SambaNova ドキュメント

本ガイドでは、SambaRack のハードウェア監視を Kubernetes クラスターにインストールする手順を解説します。インストールには次の 2 つのモードがあります。

モード	使用する場面
接続環境 (Connected)	クラスターが SambaNova レジストリからコンテナイメージと Helm チャートを取得できる場合。
エアギャップ環境 (Air-gapped)	クラスターにインターネットアクセスがない場合。インターネットに接続されたワークステーションでアーティファクトをダウンロードし、エアギャップ内へ持ち込んで、ローカルレジストリにプッシュします。

全ホストでの SambaNova エクスポーターの有効化
デバイスアドレスの収集
アーティファクトのクラスターへの配置
values ファイルの作成
チャートのインストール
メトリクスの確認
ダッシュボードのインストール

デバイスに到達できない問題、ダッシュボードにデータが表示されない問題、プローブの失敗については、トラブルシューティングをご参照ください。

事前準備

クラスター要件

要件	確認方法
Kubernetes 1.35 以降	`kubectl version`
cluster-admin アクセス	`kubectl auth can-i '' '' --all-namespaces`
Helm 3	`helm version --short`
prometheus-operator の CRD	`kubectl get crd probes.monitoring.coreos.com servicemonitors.monitoring.coreos.com`
ラベルでオブジェクトを選択する Prometheus	ステップ 4 でラベルを確認します
ダッシュボードサイドカー付きの Grafana	任意。ステップ 7

クラスターでまだ Prometheus と Grafana が稼働していない場合は、まず Prometheus と Grafana のリファレンスアーキテクチャに従ってセットアップしてください。

インストール先の名前空間

チャートとその Secret のインストール先となる monitoring 名前空間を作成します。

kubectl create namespace monitoring --dry-run=client -o yaml | kubectl apply -f -

SambaRack Manager

SambaRack Manager のセットアップが完了し、ラックのインポートと XRDU シークレットの設定が済んでいることを確認してください。ステップ 2 では、SambaRack Manager を使用してデバイスアドレスと BMC のパスワードを調べます。

SambaNova Runtime

各ホストモジュールに SambaNova Runtime 1.26.3-1 以降がインストールされていること。sambanova-runtime-exporter パッケージは Runtime に同梱されており、チャートからはインストールできません。

接続環境
エアギャップ環境

インストール作業を行うマシンには gcloud と helm 3 が必要です。また、そのマシンとクラスターノードの両方から SambaNova レジストリへのネットワークアクセスが必要です。

インターネットに接続された Linux (amd64) ワークステーションには、crane、helm 3、gcloud、jq が必要です。エアギャップ環境側には、以下が必要です。

クラスターノードがイメージを取得できる任意の OCI レジストリ — Harbor、Artifactory などのプライベートレジストリ。チャートが必要とするのは、global.imageRegistry で到達できるイメージだけです。
そのレジストリにプッシュできる、crane バイナリを備えたホスト。crane バイナリはアーティファクトと一緒に持ち込みます。静的リンクされており、依存関係はありません。
クラスターへの kubectl と helm アクセスを持つホスト。

これらの役割は別々のホストに分かれていることがよくあります。kubectl を持つホストがレジストリに到達できない場合もあれば、レジストリに到達できるホストに kubectl がない場合もあります。作業を始める前に、どのホストで何ができるかを確認してください。

ステップ 1: 全ホストでの SambaNova エクスポーターの有効化

どちらのモードでも、最初にこの作業を行います。チャートはこのエクスポーターをデプロイせず、起動もできません — チャートが行うのは、ホストのポートをスクレイプ可能にすることだけです。すべての RDU ノードでこのサービスが稼働するまで、以降のインストールを進めても RDU メトリクスは生成されません。各 SambaRack ホストモジュールで、特権ユーザーとして以下を実行します。

yum install -y sambanova-runtime-exporter
systemctl enable sambanova_exporter
systemctl start sambanova_exporter

動作を確認します。サービスが active を報告し、メトリクスエンドポイントが 200 を返す必要があります。

systemctl is-active sambanova_exporter
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:9101/metrics

ステップ 2: デバイスアドレスの収集

アドレスは手入力せず、ラックインベントリから読み取ります。SambaRack Manager がインストールされている場所で以下を実行します。

snctl rack show <rack-id>

Rack 001 (Part Number: 1001934, Type: SN40L-16)
Component                   Hostname     IP           Port  Username
--------------------------  -----------  -----------  ----  --------
Rack/001/pdu/1              rack1-pdu1   192.0.2.11   ...   ...
Rack/001/pdu/2              rack1-pdu2   192.0.2.12   ...   ...
Rack/001/Node/0/host        rack1-h1     192.0.2.20   ...   ...
Rack/001/Node/0/bmc         rack1-h1-sp  192.0.2.21   ...   ...
Rack/001/Node/0/xrdu/0      rack1-h1xr0  192.0.2.30   ...   ...
Rack/001/Node/0/xrdu/1      rack1-h1xr1  192.0.2.31   ...   ...

上記のホスト名とアドレスはプレースホルダです。-o wide を付けると Kubernetes ノード名が、-o json を付けると同じインベントリが JSON 形式で得られます。必要な情報の記入先は 1 つのファイル、つまりステップ 4 の values ファイルにまとまっています。本ガイドの他の箇所のために、これらを別途控えておく必要はありません。

インベントリの項目	記入先
各 `pdu` 行の IP	`pdu-exporter.targets[].address`
各 `xrdu` 行の IP	`xrdu-exporter.targets[].address`
各 `xrdu` 行のホスト名	`xrdu-exporter.targets[].name`
ラック ID	すべてのターゲットの `rack` ラベル
各 `Node/<n>/host` 行の Kubernetes ノード名	`sambanova-exporter.serviceMonitor.rackMap`

XRDU の BMC パスワードはステップ 4 で別途読み取り、Kubernetes Secret に直接格納します。values ファイルには決して記載しません。

ステップ 3: アーティファクトのクラスターへの配置

レジストリの接続情報は、サービスアカウントキーとともに SambaNova から提供されます。本ガイドを通して、<registry-host> はレジストリのホスト名を、<sambanova-registry> はチャートとイメージが公開されているリポジトリのフルパスを指します。

接続環境
エアギャップ環境

SambaNova レジストリへの認証

gcloud auth activate-service-account --key-file=<path-to-service-account-key>
gcloud auth print-access-token | helm registry login <registry-host> -u oauth2accesstoken --password-stdin

プルシークレットの作成

kubelet には専用のレジストリ認証情報が必要です。helm へのログインでは kubelet の認証情報は設定されません。

kubectl -n monitoring create secret docker-registry sambarack-pull \
  --docker-server=<registry-host> \
  --docker-username=_json_key \
  --docker-password="$(cat <path-to-service-account-key>)"

これ以外の準備は不要です。ステップ 5 で、kubelet がイメージを、Helm がチャートを直接取得します。

アーティファクトのダウンロード

インターネットに接続されたワークステーションでログインします。

gcloud auth activate-service-account --key-file=<path-to-service-account-key>
TOKEN="$(gcloud auth print-access-token)"
printf %s "$TOKEN" | crane auth login <registry-host> -u oauth2accesstoken --password-stdin
printf %s "$TOKEN" | helm registry login <registry-host> -u oauth2accesstoken --password-stdin

次に、チャートとイメージを取得します。

mkdir -p out
REPO=<sambanova-registry>

helm pull oci://$REPO/sambanova-hardware-monitoring --version 1.0.0 -d out
crane pull --platform linux/amd64 $REPO/pdu-exporter:1.0.0  out/pdu-exporter-1.0.0.tar
crane pull --platform linux/amd64 $REPO/xrdu-exporter:1.0.0 out/xrdu-exporter-1.0.0.tar
crane pull --platform linux/amd64 registry.access.redhat.com/ubi9/ubi-minimal:9.5 out/ubi-minimal-9.5.tar

アーティファクトの搬入

この 4 つのファイルと crane バイナリを、サイトで承認されている方法でエアギャップ環境に持ち込みます。ローカルレジストリにプッシュできるホストに配置してください。

サービスアカウントキーはエアギャップ環境に持ち込まないでください。このキーは SambaNova レジストリへのアクセスを許可するもので、エアギャップ内では使い道がありません。ここで扱うアーティファクトのうち、レジストリへのアクセス権を与えるのはこのキーだけです。

ローカルレジストリへのイメージのプッシュ

crane auth login <local-registry-host> -u <registry-user> --password-stdin

crane push pdu-exporter-1.0.0.tar  <local-registry-host>/<project-path>/pdu-exporter:1.0.0
crane push xrdu-exporter-1.0.0.tar <local-registry-host>/<project-path>/xrdu-exporter:1.0.0
crane push ubi-minimal-9.5.tar     <local-registry-host>/<project-path>/ubi-minimal:9.5

crane push はアーカイブを指定した宛先リファレンスに書き込むため、イメージはここで指定した名前とタグを保持します。イメージ名 (pdu-exporter、xrdu-exporter、ubi-minimal) とタグは変更しないでください。チャートは global.imageRegistry、リポジトリ名、タグから各イメージのリファレンスを組み立てます。

レジストリ証明書が原因で crane が失敗する場合は、--insecure を渡すのではなく、レジストリの CA 証明書をホストにインストールしてください。このフラグは転送全体の検証を無効化するうえ、コマンドごとに毎回指定し直す必要があります。

プッシュの結果を確認します。

crane ls <local-registry-host>/<project-path>/pdu-exporter
crane ls <local-registry-host>/<project-path>/xrdu-exporter
crane ls <local-registry-host>/<project-path>/ubi-minimal

ローカルレジストリ用プルシークレットの作成

kubectl アクセスを持つホストで以下を実行します。kubelet には専用の認証情報が必要です。ノード上でレジストリにログインしても、kubelet には何の効果もありません。

kubectl -n monitoring create secret docker-registry local-registry-pull \
  --docker-server=<local-registry-host> \
  --docker-username=<registry-user> \
  --docker-password=<registry-password>

ステップ 4: values ファイルの作成

デバイス認証情報 Secret の作成

XRDU の BMC は認証なしの読み取り (guest read) を許可していないため、XRDU エクスポーターには BMC のパスワードが必要です。SambaRack Manager がインストールされている場所でパスワードを読み取ります。

snctl secret get --device-type xrdu --show-value

次に、kubectl アクセスを持つホストで Secret を作成します。プロンプトから入力することで、パスワードがシェル履歴に残りません。

read -rs -p "XRDU BMC password: " XRDU_PASSWORD; echo

kubectl -n monitoring create secret generic xrdu-creds \
  --from-literal=XRDU_USERNAME=root \
  --from-literal=XRDU_PASSWORD="$XRDU_PASSWORD"

unset XRDU_PASSWORD

Prometheus のラベルの確認

Probe と ServiceMonitor オブジェクトには、お使いの Prometheus が選択対象とするラベルが必要です。

kubectl get prometheus -A -o jsonpath='{.items[*].spec.probeSelector}'; echo
kubectl get prometheus -A -o jsonpath='{.items[*].spec.serviceMonitorSelector}'; echo

kube-prometheus-stack は release: <its-release-name> で選択します。空のセレクター ({}) はすべてを選択するため、ラベルは不要です。

Prometheus が選択対象とするラベルのない Probe や ServiceMonitor は、作成自体は成功するものの、その後一切スクレイプされません。これは、正しくインストールしたのにデータが得られない場合の最も一般的な原因です。

values ファイルの記述

monitoring-values.yaml を作成します。設定を保持するのはこの 1 ファイルだけです — ステップ 2 で調べたすべてのアドレスをここに記入し、アップグレード時には helm get values でその内容を読み戻せます。 global.imageRegistry には、接続環境のインストールでは <sambanova-registry> を、エアギャップ環境のインストールでは <local-registry-host>/<project-path> を指定します。<pull-secret-name> には、ステップ 3 で作成したプルシークレットを指定します。接続環境では sambarack-pull、エアギャップ環境では local-registry-pull です。

global:
  imageRegistry: <sambanova-registry>
  imagePullSecrets:
    - name: <pull-secret-name>      # sambarack-pull or local-registry-pull

# Runs on the host; the chart only makes it scrapeable.
sambanova-exporter:
  enabled: true
  serviceMonitor:
    enabled: true
    interval: 15s
    labels:
      release: <prometheus-release-label>
    rackMap:                        # node name -> rack ID
      <node-name>: "<rack-id>"

pdu-exporter:
  enabled: true
  probe:
    enabled: true                   # without this, nothing scrapes the PDUs
    labels:
      release: <prometheus-release-label>
  targets:
    - address: <pdu-1-ip>
      name: <rack-id>-pdu1          # becomes the `pdu` label
      labels:
        rack: "<rack-id>"           # required for per-rack power panels
    - address: <pdu-2-ip>
      name: <rack-id>-pdu2
      labels:
        rack: "<rack-id>"

xrdu-exporter:
  enabled: true
  auth:
    existingSecret: xrdu-creds
  probe:
    enabled: true
    labels:
      release: <prometheus-release-label>
  targets:
    - address: <xrdu-0-ip>
      name: <xrdu-0-hostname>       # becomes the `xrdu` label
      labels:
        rack: "<rack-id>"
        node: <node-name>
        xrdu_index: XRDU_0          # lets you join with sambanova_* series
    # one entry per XRDU BMC

設定	効果
`<exporter>.enabled`	エクスポーターをデプロイします
`<exporter>.probe.enabled`	Prometheus によるデバイスのスクレイプを有効にします。`enabled` だけでは、エクスポーターは稼働するものの何も生成しません。
`<exporter>.targets`	デバイスエクスポーターを有効にする場合は必須です。指定がないと、チャートはレンダリングを拒否します。

各ターゲットに必須なのは address だけです。name を指定するとデバイスラベルの値がアドレスの代わりにその値になり、labels 配下の各キーは、そのデバイスから得られるすべての系列 (series) に付与されます。ターゲットの全オプションについては、PDU エクスポーターと XRDU エクスポーターをご参照ください。 SambaNova から特に指示がない限り、イメージタグは指定しないでください。チャートのデフォルトは、本リリースで検証済みのバージョン (pdu-exporter 1.0.0 と xrdu-exporter 1.0.0) です。

ステップ 5: チャートのインストール

接続環境
エアギャップ環境

helm upgrade --install hwmon \
  oci://<sambanova-registry>/sambanova-hardware-monitoring \
  --version 1.0.0 \
  --namespace monitoring \
  --values monitoring-values.yaml \
  --wait --timeout 5m

kubectl と helm アクセスを持つホストで、チャートアーカイブのあるディレクトリから以下を実行します。

helm upgrade --install hwmon ./sambanova-hardware-monitoring-1.0.0.tgz \
  --namespace monitoring \
  --values monitoring-values.yaml \
  --wait --timeout 5m

すべての Pod が Running になり、有効化した各デバイスエクスポーターに Probe が作成されているはずです。

kubectl -n monitoring get pods,svc
kubectl -n monitoring get probe,servicemonitor
helm -n monitoring get values hwmon

最後のコマンドは Helm が適用した values を出力します。ターゲットリストとラベルが意図どおりに反映されたかを確認する最も手早い方法です。続いて、SambaNova エクスポーターの Service に、各 RDU ノードのエンドポイントがあることを確認します。

kubectl -n monitoring get pods -l app=sambanova-exporter -o wide
kubectl -n monitoring get endpoints sambanova-exporter -o yaml | grep -E 'addresses|notReady'

Pod が Running のまま Ready にならない場合や、エンドポイントが notReadyAddresses に入っている場合は、そのノードでホスト側のサービスが停止しています。ステップ 1 に戻ってください。Readiness Probe は意図的にホストプロセスの状態に追随する設計のため、停止したエクスポーターはゼロ値を報告し続けるのではなく、Service から外れます。

チャートはこの Pod を、snRduArch ラベルの付いたノードにのみスケジュールします。エクスポーターの調整については、SambaNova エクスポーターの設定をご参照ください。

ステップ 6: メトリクスの確認

クラスター内部からのエクスポーターへのクエリ

この方法では、エクスポーター・認証情報・ネットワーク経路を一度に検証でき、Prometheus がスクレイプを始める前でも実行できます。エクスポーターのイメージにはシェルがないため、チャートが元々必要とする ubi-minimal イメージを使って、一時的な Pod をエクスポーターの隣で起動して確認します。以下のコマンドの <image-registry> には global.imageRegistry に設定したのと同じ値を、<pull-secret-name> にはステップ 3 のプルシークレットを指定します。kubectl run はプルシークレットを自動では付与しないため、確認用の Pod には明示的に指定する必要があります。

kubectl -n monitoring run hwmon-check --rm -i --restart=Never \
  --image=<image-registry>/ubi-minimal:9.5 \
  --overrides='{"spec":{"imagePullSecrets":[{"name":"<pull-secret-name>"}]}}' \
  --command -- \
  curl -s "http://pdu-exporter:9820/probe?target=<pdu-1-ip>"

三相 PDU は、相ごとに 1 サンプルと合計値を報告します。

pdu_up 1
pdu_info{device="<device-id>",firmware="5.10.8",label="Geist Upgradable rPDU",model="I-03",part="UU30010L",serial="<serial>",state="normal"} 1
pdu_power_watts{device="<device-id>",entity="phase0",label="Phase A",level="phase"} 729
pdu_power_watts{device="<device-id>",entity="phase1",label="Phase B",level="phase"} 245
pdu_power_watts{device="<device-id>",entity="phase2",label="Phase C",level="phase"} 706
pdu_power_watts{device="<device-id>",entity="total0",label="Total",level="total"} 1680
pdu_scrape_duration_seconds 0.690300349

XRDU エクスポーターに対して同じコマンドを実行します。

kubectl -n monitoring run hwmon-check --rm -i --restart=Never \
  --image=<image-registry>/ubi-minimal:9.5 \
  --overrides='{"spec":{"imagePullSecrets":[{"name":"<pull-secret-name>"}]}}' \
  --command -- \
  sh -c 'curl -s "http://xrdu-exporter:9821/probe?target=<xrdu-0-ip>" | grep -E "xrdu_up|fan_rpm|celsius" | head'

xrdu_up 1
xrdu_fan_rpm{sensor="fm0_fan0"} 7389
xrdu_fan_rpm{sensor="fm0_fan1"} 7140
xrdu_temperature_celsius{sensor="inlet"} 25.25
xrdu_temperature_celsius{sensor="outlet"} 46.062

すべてのデバイスを一度に確認するには、以下を実行します。ループ内には実際の PDU アドレスを列挙してください。

kubectl -n monitoring run hwmon-check --rm -i --restart=Never \
  --image=<image-registry>/ubi-minimal:9.5 \
  --overrides='{"spec":{"imagePullSecrets":[{"name":"<pull-secret-name>"}]}}' \
  --command -- \
  sh -c 'for ip in <pdu-1-ip> <pdu-2-ip>; do
           echo "$ip $(curl -s "http://pdu-exporter:9820/probe?target=$ip" | grep "^pdu_up")"
         done'

結果	意味
`up 1`	デバイスが応答しました
HTTP 200 で `up 0`	デバイスが応答しませんでした。XRDU の場合は、認証情報が拒否されたケースもこれに含まれます。トラブルシューティングをご参照ください。

XRDU の完全なプローブは約 97 本の系列を返します。内訳は、ファン 2 基ずつの 6 つのファンモジュールと 2 基の PSU ファン、およびセンサーごとの温度の系列です。

Prometheus 経由でのクエリ

組織で使用している URL で Grafana を開き、Explore に移動して Prometheus データソースを選択し、以下を実行します。

sum by (rack) (pdu_power_watts{level="total"})
pdu_up
xrdu_up
count by (xrdu) (xrdu_fan_rpm)
count(sambanova_platform_info)

sum by (rack) はラックごとに 1 本の系列を返します。pdu_up と xrdu_up はデバイスごとに 1 本の系列を返します。count by (xrdu) は XRDU ごとのファンセンサー数を返します。count(sambanova_platform_info) はメトリクスを報告しているホストの数を返します。結果が空の場合、Prometheus がターゲットをスクレイプしていません。トラブルシューティングをご参照ください。スクレイプ自体を確認するには、Prometheus UI を開き、Status → Targets に移動します。有効化した各 Probe が 1 つのジョブとして表示され、デバイスごとに 1 つのターゲットが含まれます。

ステップ 7: ダッシュボードのインストール

dashboards.enabled のデフォルトは true のため、ダッシュボードはステップ 5 ですでにインストールされています。false に設定していた場合は、以下で再度有効化します。

接続環境
エアギャップ環境

helm upgrade --install hwmon \
  oci://<sambanova-registry>/sambanova-hardware-monitoring \
  --version 1.0.0 -n monitoring --reuse-values \
  --set dashboards.enabled=true

helm upgrade --install hwmon ./sambanova-hardware-monitoring-1.0.0.tgz \
  -n monitoring --reuse-values \
  --set dashboards.enabled=true

--reuse-values により、適用済みのエクスポーターとターゲットの設定は維持されます。その他のインストール方法と各ダッシュボードの表示内容については、リファレンスダッシュボードをご参照ください。

アップグレード

ハードウェア監視のチャートとエクスポーターのバージョンは、SambaRack Manager リリースノートで提供されます。各リリースサイクルの一環としてアップグレードしてください。接続環境のインストールをアップグレードするには、ステップ 5 の helm upgrade --install コマンドを新しい --version で再実行します。エアギャップ環境の場合は、新しいバージョンでステップ 3 を繰り返し、新しい .tgz を指定してコマンドを再実行します。いずれの場合も、入力となるのは values ファイルです。手元に残っていない場合は、クラスターから復元できます。

helm -n monitoring get values hwmon -o yaml > monitoring-values.yaml

アンインストール

helm uninstall hwmon --namespace monitoring

これにより、チャートが作成したものはすべて削除されます。ホスト側の sambanova_exporter サービスは停止されず、ご自身で作成した Secret も削除されません。

次のステップ

SambaNova エクスポーター、PDU エクスポーター、XRDU エクスポーター — 独自のダッシュボードやアラートに利用できるメトリクスとラベル
リファレンスダッシュボード
トラブルシューティング

はじめに

サービス管理

ハードウェア管理

リファレンスアーキテクチャ

リソース

監視のインストール

事前準備

クラスター要件

インストール先の名前空間

SambaRack Manager

SambaNova Runtime

ステップ 1: 全ホストでの SambaNova エクスポーターの有効化

ステップ 2: デバイスアドレスの収集

ステップ 3: アーティファクトのクラスターへの配置

SambaNova レジストリへの認証

プルシークレットの作成

アーティファクトのダウンロード

アーティファクトの搬入

ローカルレジストリへのイメージのプッシュ

ローカルレジストリ用プルシークレットの作成

ステップ 4: values ファイルの作成

デバイス認証情報 Secret の作成

Prometheus のラベルの確認

values ファイルの記述

ステップ 5: チャートのインストール

ステップ 6: メトリクスの確認

クラスター内部からのエクスポーターへのクエリ

Prometheus 経由でのクエリ

ステップ 7: ダッシュボードのインストール

アップグレード

アンインストール

次のステップ

​事前準備

​クラスター要件

​インストール先の名前空間

​SambaRack Manager

​SambaNova Runtime

​ステップ 1: 全ホストでの SambaNova エクスポーターの有効化

​ステップ 2: デバイスアドレスの収集

​ステップ 3: アーティファクトのクラスターへの配置

​SambaNova レジストリへの認証

​プルシークレットの作成

​アーティファクトのダウンロード

​アーティファクトの搬入

​ローカルレジストリへのイメージのプッシュ

​ローカルレジストリ用プルシークレットの作成

​ステップ 4: values ファイルの作成

​デバイス認証情報 Secret の作成

​Prometheus のラベルの確認

​values ファイルの記述

​ステップ 5: チャートのインストール

​ステップ 6: メトリクスの確認

​クラスター内部からのエクスポーターへのクエリ

​Prometheus 経由でのクエリ

​ステップ 7: ダッシュボードのインストール

​アップグレード

​アンインストール

​次のステップ

事前準備

クラスター要件

インストール先の名前空間

SambaRack Manager

SambaNova Runtime

ステップ 1: 全ホストでの SambaNova エクスポーターの有効化

ステップ 2: デバイスアドレスの収集

ステップ 3: アーティファクトのクラスターへの配置

SambaNova レジストリへの認証

プルシークレットの作成

アーティファクトのダウンロード

アーティファクトの搬入

ローカルレジストリへのイメージのプッシュ

ローカルレジストリ用プルシークレットの作成

ステップ 4: values ファイルの作成

デバイス認証情報 Secret の作成

Prometheus のラベルの確認

values ファイルの記述

ステップ 5: チャートのインストール

ステップ 6: メトリクスの確認

クラスター内部からのエクスポーターへのクエリ

Prometheus 経由でのクエリ

ステップ 7: ダッシュボードのインストール

アップグレード

アンインストール

次のステップ