> ## Documentation Index > Fetch the complete documentation index at: https://docs.sambanova.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # 監視のインストール 本ガイドでは、SambaRack のハードウェア監視を Kubernetes クラスターにインストールする手順を解説します。インストールには次の 2 つのモードがあります。 | モード | 使用する場面 | | :- | :- | | **接続環境 (Connected)** | クラスターが SambaNova レジストリからコンテナイメージと Helm チャートを取得できる場合。 | | **エアギャップ環境 (Air-gapped)** | クラスターにインターネットアクセスがない場合。インターネットに接続されたワークステーションでアーティファクトをダウンロードし、エアギャップ内へ持ち込んで、ローカルレジストリにプッシュします。 | 1. [全ホストでの SambaNova エクスポーターの有効化](#ステップ-1-全ホストでの-sambanova-エクスポーターの有効化) 2. [デバイスアドレスの収集](#ステップ-2-デバイスアドレスの収集) 3. [アーティファクトのクラスターへの配置](#ステップ-3-アーティファクトのクラスターへの配置) 4. [values ファイルの作成](#ステップ-4-values-ファイルの作成) 5. [チャートのインストール](#ステップ-5-チャートのインストール) 6. [メトリクスの確認](#ステップ-6-メトリクスの確認) 7. [ダッシュボードのインストール](#ステップ-7-ダッシュボードのインストール) デバイスに到達できない問題、ダッシュボードにデータが表示されない問題、プローブの失敗については、[トラブルシューティング](https://docs.sambanova.ai/docs/ja/v2.2.3/sambastack/hardware-admin/sambarack-manager/monitoring/monitoring-troubleshooting.md)をご参照ください。 ## 事前準備 ### クラスター要件 | 要件 | 確認方法 | | :- | :- | | 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](#ステップ-4-values-ファイルの作成) でラベルを確認します | | ダッシュボードサイドカー付きの Grafana | 任意。[ステップ 7](#ステップ-7-ダッシュボードのインストール) | クラスターでまだ Prometheus と Grafana が稼働していない場合は、まず [Prometheus と Grafana のリファレンスアーキテクチャ](https://docs.sambanova.ai/docs/ja/v2.2.3/sambastack/reference-architecture/observability/monitoring-prom.md)に従ってセットアップしてください。 ### インストール先の名前空間 チャートとその Secret のインストール先となる `monitoring` 名前空間を作成します。 ```bash theme={} kubectl create namespace monitoring --dry-run=client -o yaml | kubectl apply -f - ``` ### SambaRack Manager [SambaRack Manager](https://docs.sambanova.ai/docs/ja/v2.2.3/sambastack/hardware-admin/sambarack-manager/srm-overview.md) のセットアップが完了し、ラックのインポートと XRDU シークレットの設定が済んでいることを確認してください。[ステップ 2](#ステップ-2-デバイスアドレスの収集) では、SambaRack Manager を使用してデバイスアドレスと BMC のパスワードを調べます。 ### SambaNova Runtime * 各ホストモジュールに SambaNova Runtime 1.26.3-1 以降がインストールされていること。`sambanova-runtime-exporter` パッケージは Runtime に同梱されており、チャートからはインストールできません。 **接続環境** インストール作業を行うマシンには `gcloud` と `helm` 3 が必要です。また、そのマシンとクラスターノードの両方から SambaNova レジストリへのネットワークアクセスが必要です。 **エアギャップ環境** インターネットに接続された Linux (amd64) ワークステーションには、[`crane`](https://github.com/google/go-containerregistry/blob/main/cmd/crane/README.md)、`helm` 3、`gcloud`、`jq` が必要です。 エアギャップ環境側には、以下が必要です。 * クラスターノードがイメージを取得できる任意の OCI レジストリ — Harbor、Artifactory などのプライベートレジストリ。チャートが必要とするのは、`global.imageRegistry` で到達できるイメージだけです。 * そのレジストリにプッシュできる、`crane` バイナリを備えたホスト。`crane` バイナリはアーティファクトと一緒に持ち込みます。静的リンクされており、依存関係はありません。 * クラスターへの `kubectl` と `helm` アクセスを持つホスト。 > [!NOTE] > > これらの役割は別々のホストに分かれていることがよくあります。`kubectl` を持つホストがレジストリに到達できない場合もあれば、レジストリに到達できるホストに `kubectl` がない場合もあります。作業を始める前に、どのホストで何ができるかを確認してください。 ## ステップ 1: 全ホストでの SambaNova エクスポーターの有効化 どちらのモードでも、最初にこの作業を行います。チャートはこのエクスポーターをデプロイせず、起動もできません — チャートが行うのは、ホストのポートをスクレイプ可能にすることだけです。すべての RDU ノードでこのサービスが稼働するまで、以降のインストールを進めても RDU メトリクスは生成されません。 各 SambaRack ホストモジュールで、特権ユーザーとして以下を実行します。 ```bash theme={} yum install -y sambanova-runtime-exporter systemctl enable sambanova_exporter systemctl start sambanova_exporter ``` 動作を確認します。サービスが `active` を報告し、メトリクスエンドポイントが `200` を返す必要があります。 ```bash theme={} systemctl is-active sambanova_exporter curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:9101/metrics ``` ## ステップ 2: デバイスアドレスの収集 アドレスは手入力せず、ラックインベントリから読み取ります。SambaRack Manager がインストールされている場所で以下を実行します。 ```bash theme={} snctl rack show ``` ```text theme={} 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](#ステップ-4-values-ファイルの作成) の values ファイルにまとまっています。本ガイドの他の箇所のために、これらを別途控えておく必要はありません。 | インベントリの項目 | 記入先 | | :- | :- | | 各 `pdu` 行の IP | `pdu-exporter.targets[].address` | | 各 `xrdu` 行の IP | `xrdu-exporter.targets[].address` | | 各 `xrdu` 行のホスト名 | `xrdu-exporter.targets[].name` | | ラック ID | すべてのターゲットの `rack` ラベル | | 各 `Node//host` 行の Kubernetes ノード名 | `sambanova-exporter.serviceMonitor.rackMap` | XRDU の BMC パスワードは [ステップ 4](#ステップ-4-values-ファイルの作成) で別途読み取り、Kubernetes Secret に直接格納します。values ファイルには決して記載しません。 ## ステップ 3: アーティファクトのクラスターへの配置 レジストリの接続情報は、サービスアカウントキーとともに SambaNova から提供されます。本ガイドを通して、`` はレジストリのホスト名を、`` はチャートとイメージが公開されているリポジトリのフルパスを指します。 **接続環境** ### SambaNova レジストリへの認証 ```bash theme={} gcloud auth activate-service-account --key-file= gcloud auth print-access-token | helm registry login -u oauth2accesstoken --password-stdin ``` ### プルシークレットの作成 kubelet には専用のレジストリ認証情報が必要です。`helm` へのログインでは kubelet の認証情報は設定されません。 ```bash theme={} kubectl -n monitoring create secret docker-registry sambarack-pull \ --docker-server= \ --docker-username=_json_key \ --docker-password="$(cat )" ``` これ以外の準備は不要です。[ステップ 5](#ステップ-5-チャートのインストール) で、kubelet がイメージを、Helm がチャートを直接取得します。 **エアギャップ環境** ### アーティファクトのダウンロード インターネットに接続されたワークステーションでログインします。 ```bash theme={} gcloud auth activate-service-account --key-file= TOKEN="$(gcloud auth print-access-token)" printf %s "$TOKEN" | crane auth login -u oauth2accesstoken --password-stdin printf %s "$TOKEN" | helm registry login -u oauth2accesstoken --password-stdin ``` 次に、チャートとイメージを取得します。 ```bash theme={} mkdir -p out REPO= 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` バイナリを、サイトで承認されている方法でエアギャップ環境に持ち込みます。ローカルレジストリにプッシュできるホストに配置してください。 > [!WARNING] > > サービスアカウントキーはエアギャップ環境に持ち込まないでください。このキーは SambaNova レジストリへのアクセスを許可するもので、エアギャップ内では使い道がありません。ここで扱うアーティファクトのうち、レジストリへのアクセス権を与えるのはこのキーだけです。 ### ローカルレジストリへのイメージのプッシュ ```bash theme={} crane auth login -u --password-stdin crane push pdu-exporter-1.0.0.tar //pdu-exporter:1.0.0 crane push xrdu-exporter-1.0.0.tar //xrdu-exporter:1.0.0 crane push ubi-minimal-9.5.tar //ubi-minimal:9.5 ``` `crane push` はアーカイブを指定した宛先リファレンスに書き込むため、イメージはここで指定した名前とタグを保持します。イメージ名 (`pdu-exporter`、`xrdu-exporter`、`ubi-minimal`) とタグは変更しないでください。チャートは `global.imageRegistry`、リポジトリ名、タグから各イメージのリファレンスを組み立てます。 > [!WARNING] > > レジストリ証明書が原因で `crane` が失敗する場合は、`--insecure` を渡すのではなく、レジストリの CA 証明書をホストにインストールしてください。このフラグは転送全体の検証を無効化するうえ、コマンドごとに毎回指定し直す必要があります。 プッシュの結果を確認します。 ```bash theme={} crane ls //pdu-exporter crane ls //xrdu-exporter crane ls //ubi-minimal ``` ### ローカルレジストリ用プルシークレットの作成 `kubectl` アクセスを持つホストで以下を実行します。kubelet には専用の認証情報が必要です。ノード上でレジストリにログインしても、kubelet には何の効果もありません。 ```bash theme={} kubectl -n monitoring create secret docker-registry local-registry-pull \ --docker-server= \ --docker-username= \ --docker-password= ``` ## ステップ 4: values ファイルの作成 ### デバイス認証情報 Secret の作成 XRDU の BMC は認証なしの読み取り (guest read) を許可していないため、XRDU エクスポーターには BMC のパスワードが必要です。SambaRack Manager がインストールされている場所でパスワードを読み取ります。 ```bash theme={} snctl secret get --device-type xrdu --show-value ``` 次に、`kubectl` アクセスを持つホストで Secret を作成します。プロンプトから入力することで、パスワードがシェル履歴に残りません。 ```bash theme={} 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 が選択対象とするラベルが必要です。 ```bash theme={} kubectl get prometheus -A -o jsonpath='{.items[*].spec.probeSelector}'; echo kubectl get prometheus -A -o jsonpath='{.items[*].spec.serviceMonitorSelector}'; echo ``` `kube-prometheus-stack` は `release: ` で選択します。空のセレクター (`{}`) はすべてを選択するため、ラベルは不要です。 > [!WARNING] > > Prometheus が選択対象とするラベルのない `Probe` や `ServiceMonitor` は、作成自体は成功するものの、その後一切スクレイプされません。これは、正しくインストールしたのにデータが得られない場合の最も一般的な原因です。 ### values ファイルの記述 `monitoring-values.yaml` を作成します。設定を保持するのはこの 1 ファイルだけです — ステップ 2 で調べたすべてのアドレスをここに記入し、アップグレード時には `helm get values` でその内容を読み戻せます。 `global.imageRegistry` には、接続環境のインストールでは `` を、エアギャップ環境のインストールでは `/` を指定します。`` には、ステップ 3 で作成したプルシークレットを指定します。接続環境では `sambarack-pull`、エアギャップ環境では `local-registry-pull` です。 ```yaml theme={} global: imageRegistry: imagePullSecrets: - 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: rackMap: # node name -> rack ID : "" pdu-exporter: enabled: true probe: enabled: true # without this, nothing scrapes the PDUs labels: release: targets: - address: name: -pdu1 # becomes the `pdu` label labels: rack: "" # required for per-rack power panels - address: name: -pdu2 labels: rack: "" xrdu-exporter: enabled: true auth: existingSecret: xrdu-creds probe: enabled: true labels: release: targets: - address: name: # becomes the `xrdu` label labels: rack: "" node: xrdu_index: XRDU_0 # lets you join with sambanova_* series # one entry per XRDU BMC ``` | 設定 | 効果 | | :- | :- | | `.enabled` | エクスポーターをデプロイします | | `.probe.enabled` | Prometheus によるデバイスのスクレイプを有効にします。`enabled` だけでは、エクスポーターは稼働するものの何も生成しません。 | | `.targets` | デバイスエクスポーターを有効にする場合は必須です。指定がないと、チャートはレンダリングを拒否します。 | 各ターゲットに必須なのは `address` だけです。`name` を指定するとデバイスラベルの値がアドレスの代わりにその値になり、`labels` 配下の各キーは、そのデバイスから得られるすべての系列 (series) に付与されます。ターゲットの全オプションについては、[PDU エクスポーター](https://docs.sambanova.ai/docs/ja/v2.2.3/sambastack/hardware-admin/sambarack-manager/monitoring/exporter-pdu.md#ターゲット)と [XRDU エクスポーター](https://docs.sambanova.ai/docs/ja/v2.2.3/sambastack/hardware-admin/sambarack-manager/monitoring/exporter-xrdu.md#ターゲット)をご参照ください。 SambaNova から特に指示がない限り、イメージタグは指定しないでください。チャートのデフォルトは、本リリースで検証済みのバージョン (`pdu-exporter` 1.0.0 と `xrdu-exporter` 1.0.0) です。 ## ステップ 5: チャートのインストール **接続環境** ```bash theme={} helm upgrade --install hwmon \ oci:///sambanova-hardware-monitoring \ --version 1.0.0 \ --namespace monitoring \ --values monitoring-values.yaml \ --wait --timeout 5m ``` **エアギャップ環境** `kubectl` と `helm` アクセスを持つホストで、チャートアーカイブのあるディレクトリから以下を実行します。 ```bash theme={} helm upgrade --install hwmon ./sambanova-hardware-monitoring-1.0.0.tgz \ --namespace monitoring \ --values monitoring-values.yaml \ --wait --timeout 5m ``` すべての Pod が Running になり、有効化した各デバイスエクスポーターに `Probe` が作成されているはずです。 ```bash theme={} kubectl -n monitoring get pods,svc kubectl -n monitoring get probe,servicemonitor helm -n monitoring get values hwmon ``` 最後のコマンドは Helm が適用した values を出力します。ターゲットリストとラベルが意図どおりに反映されたかを確認する最も手早い方法です。 続いて、SambaNova エクスポーターの Service に、各 RDU ノードのエンドポイントがあることを確認します。 ```bash theme={} 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](#ステップ-1-全ホストでの-sambanova-エクスポーターの有効化) に戻ってください。Readiness Probe は意図的にホストプロセスの状態に追随する設計のため、停止したエクスポーターはゼロ値を報告し続けるのではなく、Service から外れます。 > [!NOTE] > > チャートはこの Pod を、`snRduArch` ラベルの付いたノードにのみスケジュールします。エクスポーターの調整については、[SambaNova エクスポーターの設定](https://docs.sambanova.ai/docs/ja/v2.2.3/sambastack/hardware-admin/sambarack-manager/monitoring/exporter-sambanova.md#設定)をご参照ください。 ## ステップ 6: メトリクスの確認 ### クラスター内部からのエクスポーターへのクエリ この方法では、エクスポーター・認証情報・ネットワーク経路を一度に検証でき、Prometheus がスクレイプを始める前でも実行できます。エクスポーターのイメージにはシェルがないため、チャートが元々必要とする `ubi-minimal` イメージを使って、一時的な Pod をエクスポーターの隣で起動して確認します。 以下のコマンドの `` には `global.imageRegistry` に設定したのと同じ値を、`` にはステップ 3 のプルシークレットを指定します。`kubectl run` はプルシークレットを自動では付与しないため、確認用の Pod には明示的に指定する必要があります。 ```bash theme={} kubectl -n monitoring run hwmon-check --rm -i --restart=Never \ --image=/ubi-minimal:9.5 \ --overrides='{"spec":{"imagePullSecrets":[{"name":""}]}}' \ --command -- \ curl -s "http://pdu-exporter:9820/probe?target=" ``` 三相 PDU は、相ごとに 1 サンプルと合計値を報告します。 ```text theme={} pdu_up 1 pdu_info{device="",firmware="5.10.8",label="Geist Upgradable rPDU",model="I-03",part="UU30010L",serial="",state="normal"} 1 pdu_power_watts{device="",entity="phase0",label="Phase A",level="phase"} 729 pdu_power_watts{device="",entity="phase1",label="Phase B",level="phase"} 245 pdu_power_watts{device="",entity="phase2",label="Phase C",level="phase"} 706 pdu_power_watts{device="",entity="total0",label="Total",level="total"} 1680 pdu_scrape_duration_seconds 0.690300349 ``` XRDU エクスポーターに対して同じコマンドを実行します。 ```bash theme={} kubectl -n monitoring run hwmon-check --rm -i --restart=Never \ --image=/ubi-minimal:9.5 \ --overrides='{"spec":{"imagePullSecrets":[{"name":""}]}}' \ --command -- \ sh -c 'curl -s "http://xrdu-exporter:9821/probe?target=" | grep -E "xrdu_up|fan_rpm|celsius" | head' ``` ```text theme={} 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 アドレスを列挙してください。 ```bash theme={} kubectl -n monitoring run hwmon-check --rm -i --restart=Never \ --image=/ubi-minimal:9.5 \ --overrides='{"spec":{"imagePullSecrets":[{"name":""}]}}' \ --command -- \ sh -c 'for ip in ; do echo "$ip $(curl -s "http://pdu-exporter:9820/probe?target=$ip" | grep "^pdu_up")" done' ``` | 結果 | 意味 | | :- | :- | | `up 1` | デバイスが応答しました | | HTTP 200 で `up 0` | デバイスが応答しませんでした。XRDU の場合は、認証情報が拒否されたケースもこれに含まれます。[トラブルシューティング](https://docs.sambanova.ai/docs/ja/v2.2.3/sambastack/hardware-admin/sambarack-manager/monitoring/monitoring-troubleshooting.md)をご参照ください。 | XRDU の完全なプローブは約 97 本の系列を返します。内訳は、ファン 2 基ずつの 6 つのファンモジュールと 2 基の PSU ファン、およびセンサーごとの温度の系列です。 ### Prometheus 経由でのクエリ 組織で使用している URL で Grafana を開き、**Explore** に移動して Prometheus データソースを選択し、以下を実行します。 ```promql theme={} 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 がターゲットをスクレイプしていません。[トラブルシューティング](https://docs.sambanova.ai/docs/ja/v2.2.3/sambastack/hardware-admin/sambarack-manager/monitoring/monitoring-troubleshooting.md#prometheus-にも-grafana-にもデータが表示されない)をご参照ください。 スクレイプ自体を確認するには、Prometheus UI を開き、**Status** → **Targets** に移動します。有効化した各 `Probe` が 1 つのジョブとして表示され、デバイスごとに 1 つのターゲットが含まれます。 ## ステップ 7: ダッシュボードのインストール `dashboards.enabled` のデフォルトは `true` のため、ダッシュボードはステップ 5 ですでにインストールされています。`false` に設定していた場合は、以下で再度有効化します。 **接続環境** ```bash theme={} helm upgrade --install hwmon \ oci:///sambanova-hardware-monitoring \ --version 1.0.0 -n monitoring --reuse-values \ --set dashboards.enabled=true ``` **エアギャップ環境** ```bash theme={} helm upgrade --install hwmon ./sambanova-hardware-monitoring-1.0.0.tgz \ -n monitoring --reuse-values \ --set dashboards.enabled=true ``` `--reuse-values` により、適用済みのエクスポーターとターゲットの設定は維持されます。その他のインストール方法と各ダッシュボードの表示内容については、[リファレンスダッシュボード](https://docs.sambanova.ai/docs/ja/v2.2.3/sambastack/hardware-admin/sambarack-manager/monitoring/monitoring-reference-dashboards.md)をご参照ください。 ## アップグレード ハードウェア監視のチャートとエクスポーターのバージョンは、[SambaRack Manager リリースノート](https://docs.sambanova.ai/docs/ja/release-notes/sambarack-manager.md)で提供されます。各リリースサイクルの一環としてアップグレードしてください。 接続環境のインストールをアップグレードするには、[ステップ 5](#ステップ-5-チャートのインストール) の `helm upgrade --install` コマンドを新しい `--version` で再実行します。エアギャップ環境の場合は、新しいバージョンで [ステップ 3](#ステップ-3-アーティファクトのクラスターへの配置) を繰り返し、新しい `.tgz` を指定してコマンドを再実行します。 いずれの場合も、入力となるのは values ファイルです。手元に残っていない場合は、クラスターから復元できます。 ```bash theme={} helm -n monitoring get values hwmon -o yaml > monitoring-values.yaml ``` ## アンインストール ```bash theme={} helm uninstall hwmon --namespace monitoring ``` これにより、チャートが作成したものはすべて削除されます。ホスト側の `sambanova_exporter` サービスは停止されず、ご自身で作成した Secret も削除されません。 ## 次のステップ * [SambaNova エクスポーター](https://docs.sambanova.ai/docs/ja/v2.2.3/sambastack/hardware-admin/sambarack-manager/monitoring/exporter-sambanova.md)、[PDU エクスポーター](https://docs.sambanova.ai/docs/ja/v2.2.3/sambastack/hardware-admin/sambarack-manager/monitoring/exporter-pdu.md)、[XRDU エクスポーター](https://docs.sambanova.ai/docs/ja/v2.2.3/sambastack/hardware-admin/sambarack-manager/monitoring/exporter-xrdu.md) — 独自のダッシュボードやアラートに利用できるメトリクスとラベル * [リファレンスダッシュボード](https://docs.sambanova.ai/docs/ja/v2.2.3/sambastack/hardware-admin/sambarack-manager/monitoring/monitoring-reference-dashboards.md) * [トラブルシューティング](https://docs.sambanova.ai/docs/ja/v2.2.3/sambastack/hardware-admin/sambarack-manager/monitoring/monitoring-troubleshooting.md)