For AI agents: the complete documentation index is available at https://docs.dataplatform.ovh.net/ja/llms.txt, the full documentation bundle is available at https://docs.dataplatform.ovh.net/ja/llms-full.txt, and this page is available as Markdown at https://docs.dataplatform.ovh.net/ja/tutorials-iot-fleet-monitoring-superset-dashboards.md.
  • 🇯🇵 日本語
  • Superset ダッシュボードの構築

    このページは、IoT フリート監視パイプラインチュートリアルのステップ7の詳細な補足です

    目的

    このページは、IoT フリート監視パイプライン チュートリアルのステップ7の詳細な補足です。このページでは、フリート監視ダッシュボードの各パネルの仮想データセットと正確なチャート構成を提供します。

    Superset は Trino を通じて Lakehouse にクエリを実行します。このページのすべての SQL は Trino 方言 です。Superset をまだデプロイしていない場合は、まず Deploy Apache Superset に従ってください。

    構築する完成したダッシュボード:

    IoT フリート監視ダッシュボード
    Info

    ts の解析について。 プロデューサは ts を ISO-8601 形式の文字列として出力します。テーブルの列が VARCHAR の場合、すべてのクエリは from_iso8601_timestamp(ts) でそれを解析します。Lakehouse Manager で列を実際の TIMESTAMP に設定した場合、解析を削除して ts を直接使用できます。いずれにせよ、解析された時刻列を Superset のデータセットの主要な時刻列としてマークしてください。そうすることで、時間フィルタと時系列チャートが正しく動作します。

    Info

    解析不能な行への対策。 テストメッセージが ts が有効なタイムスタンプでないレコードを残した場合(例: device_id = 'local-test')、from_iso8601_timestamp は INVALID_FUNCTION_ARGUMENT: Invalid format をスローします。以下のクエリでは、解析を try() でラップすることで、その行は null に解決され、フィルタリングされます。クリーンな修正は、DELETE FROM iot_readings WHERE device_id = 'local-test' で一度削除することです。その後、try() ラッパーはオプションです。

    セットアップ

    1. Trino をデータベースとして接続 します。Superset の Settings > Database Connections > + で行います。SQLAlchemy URI は trino://<user>@<trino-host>:<port>/<catalog> の形式です。続行する前に接続をテストしてください。
    2. 物理データセット iot_readings を Datasets > + で追加します。カタログ、スキーマ、テーブルを選択します。
    3. 以下の仮想データセット を SQL Lab で作成します(クエリを実行し、Save > Save dataset を選択)。「デバイスごとの現在の状態」ロジックは複数のチャートで再利用されるため、一度 iot_current_state として保存します。

    iot_current_state 仮想データセット

    このデータセットは、各デバイスの最新行を返します。複数のパネルでこのデータセットを基にしています。iot_current_state として保存します。

    SELECT *
    FROM (
      SELECT
        device_id, site, region, device_type,
        temperature, humidity, co2, pm25,
        battery_pct, status, error_code,
        ts_parsed AS ts,
        row_number() OVER (
          PARTITION BY device_id
          ORDER BY ts_parsed DESC
        ) AS rn
      FROM (
        SELECT *, try(from_iso8601_timestamp(ts)) AS ts_parsed
        FROM iot_readings
      )
      WHERE ts_parsed IS NOT NULL
    )
    WHERE rn = 1

    内部の try() に WHERE ts_parsed IS NOT NULL を追加することで、解析不能な行を削除します。これにより、悪い行が row_number() の順序に勝つことがなく、デバイスの現在の状態として扱われるのを防ぎます。

    パネル1: KPI 行

    ダッシュボードの上部に4つのヘッドラインの Big Number チャート。

    チャートタイプデータセットメトリック
    デバイスオンラインBig Number仮想(以下)過去2分間に見られたデバイスの数
    フリートサイズBig Numberiot_current_stateCOUNT(DISTINCT device_id)
    アラート中のデバイスBig Numberiot_current_stateCOUNT_IF(status <> 'OK')
    現在の平均CO₂Big Numberiot_current_stateAVG(co2)

    デバイスオンライン 仮想データセットを保存します:

    SELECT count(DISTINCT device_id) AS devices_online
    FROM iot_readings
    WHERE try(from_iso8601_timestamp(ts)) >= current_timestamp - interval '2' minute
    Info

    「オンライン」とは、過去2分間に報告されたことを意味します。これは、オフラインデバイスがカウントから外れる方法です。カウントするための OFFLINE 行はなく、最近の行の欠如のみです。

    パネル2: フリートヘルスドーナツ

    フリート全体の現在のステータス分布、デバイスごとのスライスではなく行ごとのスライス。

    • チャートタイプ: Pie / Donut
    • データセット: iot_current_state
    • 次元: status。メトリック: COUNT(DISTINCT device_id)
    • 推奨カラー: OKは緑、DEGRADEDはアンバー、FAULTは赤。OFFLINE はここにはほとんど表示されません。オフラインデバイスは発信を停止するため、現在の状態から外れます。パネル5 を参照してください。

    パネル3: バッテリーレベル

    「予測できたはずの」チャート、最もリスクの高いデバイスを最初にソートします。

    • チャートタイプ: Bar Chart。カスタマイズで Bar Orientation を Horizontal に設定します。
    • データセット: iot_current_state
    • X軸: device_id。メトリック: MAX(battery_pct)。次元は空のままにします。
    • MAX(battery_pct) で昇順にソートし、行の制限を15に設定します。
    Warning

    カテゴリ型の棒グラフには、15%の故障トリガーの閾値線は 利用できません。アノテーションレイヤーは時系列チャートにのみ存在します。閾値を伝えるには、昇順ソートに依存して最も低いバッテリーが明確になるようにするか、代わりに Table を構築し、Customize > Conditional formatting を使用して MAX(battery_pct) を15未満で赤に着色します。

    Info

    棒グラフでは、カテゴリを X軸 に配置し、Dimensions ボックスを空のままにします。Dimensions は、各棒をサブシリーズに分割するためだけに使用され、ここではそれを望みません。

    パネル4: 読み取り値のトレンド

    ヘッドラインのトレンド: 時間を通じた平均メトリック、サイトまたは地域でスライス可能。

    • チャートタイプ: Line Chart(時系列)
    • データセット: 解析された ts が時刻列であるデータセット(トップの解析メモを参照)。try(from_iso8601_timestamp(ts)) AS ts を公開する仮想データセットを作成し、主要な時刻列としてマークします。
    • 時間粒度: 1分(または30秒)
    • X軸: ts。メトリック: AVG(co2), AVG(pm25), AVG(temperature)。次元: site を1つのサイトごとに1つの行にします。
    • region と device_type にダッシュボードフィルタを追加します。
    Warning

    CO₂値(約480)は、共有軸上で温度(約21)とPM2.5(約9)を圧倒します。3つすべてを読み取るためには、CO₂を別途チャート化するか、小さなメトリックを二次Y軸に配置します。

    デバイスごとの異常値のクローズアップを表示するには、このチャートを複製し、シリーズ次元を device_id に設定し、スクリプト化されたデバイスのいずれかにフィルタリングします:

    SELECT
      try(from_iso8601_timestamp(ts)) AS ts,
      device_id, pm25, status
    FROM iot_readings
    WHERE device_id = 'paris-dc1-sensor-01'
    ORDER BY ts

    パネル5: ダウンタイムテーブル

    真のダウンタイムを検出します: 発信を停止したため、最新の読み取り値が古いデバイス。

    • チャートタイプ: Table
    • データセット: 以下の仮想データセット

    このデータセットを保存します。このデータセットは、各デバイスの最後の読み取りからの時間を返すため、パネルは空になりません:

    SELECT
      device_id,
      site,
      region,
      max(try(from_iso8601_timestamp(ts)))                                  AS last_seen,
      date_diff('second', max(try(from_iso8601_timestamp(ts))), current_timestamp) AS seconds_since_last
    FROM iot_readings
    WHERE device_id <> 'local-test'
    GROUP BY device_id, site, region
    ORDER BY seconds_since_last DESC

    その後、Table チャートで Customize > Conditional formatting を使用して、seconds_since_last が30を超える場合に赤に着色します。

    Info

    30秒の閾値は、5秒間隔の発信を想定しています。約6サイクルが欠けているデバイスはダウンと見なされます。好みに合わせて調整してください。ダウンデバイスのみをリスト表示したい場合は、クエリに HAVING date_diff('second', max(try(from_iso8601_timestamp(ts))), current_timestamp) > 30 を追加します。フリートが健全な場合、このバージョンは空になります。これはライブデモで壊れているように見えることがあります。

    パネル6: エラーコードの内訳

    ウィンドウ内で発生する種類の故障。

    • チャートタイプ: Bar Chart
    • データセット: iot_readings
    • X軸: error_code。メトリック: COUNT(*)。次元は空のままにします。
    • フィルタ: error_code <> 'NONE' および時間範囲を過去15分に設定します。

    パネル7: サイト別の読み取り値

    フリート全体の環境読み取り値を比較します。

    • チャートタイプ: Bar Chart
    • データセット: iot_current_state
    • X軸: site(またはregion)。メトリック: AVG(co2), AVG(pm25)。次元は空のままにします。
    Warning

    パネル4と同様に、CO₂はPM2.5を共有軸上で圧倒します。両方を読み取る必要がある場合は、別々にチャート化するか、二次Y軸を使用します。

    ダッシュボードのレイアウト

    7つのパネルの実用的な配置:

    +-----------------------------------------------------------------+
    |  Devices online | Fleet size | Devices in alert | Avg CO2 (now) |   KPI row
    +------------------------------+----------------------------------+
    |  Fleet health donut          |  Battery levels                  |
    +------------------------------+----------------------------------+
    |  Readings trend over time, by site                              |
    +------------------------------+----------------------------------+
    |  Downtime table              |  Error-code breakdown            |
    +------------------------------+----------------------------------+

    region、site、device_type、および時間範囲のダッシュボードフィルターを追加します。ダッシュボードの自動更新間隔を30秒に設定してください(ダッシュボードの編集の下)リアルタイムの感覚を得るためです。

    スクリプトによる障害が進行するにつれて、ダッシュボードは全体のストーリーを通過します: 健全なフリート、デバイスの劣化と故障、ダウンタイムテーブルに現れ、トレンドのギャップとして現れるダウンタイムのウィンドウ、そして最後に、デバイスを通常状態に戻す修理です。

    さらに詳しく

    トレーニングや技術的なサポートを実装するために、営業担当者にお問い合わせください、またはプロフェッショナルサービスページをご覧ください。見積もりをリクエストして、専門家にプロジェクトを分析してもらいます。

    質問をする、フィードバックを送る、Data Platformを構築するチームと直接交流するには、専用のDiscordチャネルをご利用ください。

    OVHcloudサービスについてサポートが必要な場合は、ヘルプセンターでリクエストを作成してください。

    ユーザーコミュニティに参加してください。