Things Cloud DataHub の運用

このセクションでは、システム情報、使用統計、および監査ログにアクセスする方法について説明します。

システム情報の確認

必要条件
システム情報にアクセスするには、管理者権限が必要です。 詳細については、Things Cloud DataHubの権限とロールの定義を参照してください。

ナビゲーターにある、管理を選択し、システムステータスからシステム構成とそのステータスに関する情報を取得します。

マイクロサービスの下に、緑または赤でマークされたマイクロサービスのステータスが表示されます。 このステータスは、マイクロサービスにWebアプリケーションからアクセスできるかどうかを反映しています。 マイクロサービスが有効の場合は、現在のバージョンが表示されます。 そうでない場合は、アプリケーションの管理の説明に従って、マイクロサービスとそのログのステータスを確認してください。

Webアプリケーションの下に、Webアプリケーションのバージョンが記載されています。

Dremioの下に、Dremioのステータスが表示され、緑色または赤色でマークされています。 このステータスは、Dremio がマイクロサービスからアクセスできるかどうかを反映しています。 Dremio にアクセスできる場合は、現在のバージョンが表示されます。 そうでない場合は、マイクロサービスのステータスとそのログをアプリケーションの管理に記載の説明に従って確認してください。

管理の下に、システムのセットアップがあります。 右の矢印をクリックしてそのボックスを展開すると、関連するすべてのシステムプロパティとその値が一覧表示されます。 実行中のマイクロサービスの値は変更できませんのでご注意ください。 テナント管理者は、対応する新しい値を使用してマイクロサービスを再デプロイする必要があります。

使用統計の追跡

有効であれば、Things Cloud は、処理中のデータ量に関する使用統計を追跡できます。 これらの統計は、オフロード クエリ用に収集され、これらのクエリがThings Cloudのオペレーショナル ストアから読み取ったデータの量を追跡します。 統計は、アドホック クエリ用にも収集され、これらのクエリがデータ レイクから読み取ったデータの量を追跡します。 使用統計は、従量ベースの課金に利用できます。 また、ネットワーク負荷に関して、リソースを集中的に使用するクエリを特定するためにも利用できます。

備考
使用統計の追跡は、Things Cloud DataHub Cloudエディションでサポートされています。Things Cloud DataHub Edgeエディションではサポートされていません。

ナビゲータで、管理を選択し、次に使用統計を選択して使用統計を表示します。

アクション バーでは、日付コントロールを使用して、使用統計を表示する月を選択できます。

上部の 3 つのパネルには、全体的な要約統計と、オフロードおよびアドホック クエリ用に分けられた統計が表示されます。 選択した月の前月のデータが存在する場合、選択した月のデータ量が減少したか、増加したか、横ばいであったかを矢印で示します。 オフロードとアドホック クエリの統計を含むパネルの方には、毎日の最小/最大従量と 1 日の平均従量の一覧も表示されます。

要約統計の下の表には、選択した月の日別の詳細が表示されます。 日ごとに、オフロードされた従量とクエリされた従量が表示され、それらの合計が 1 日あたりの従量になります。 さらに、月間従量の割合い、つまり、月間従量全体に対して 1 日あたりの従量がどれだけか表示されます。 各日付は、クエリログへリンクしており、それぞれの日のすべてのクエリが一覧表示されます。

備考
統計は 1 時間に 1 回更新されます。 したがって、当月の統計には最新のデータが含まれていない場合があります。 統計は保持期間後に削除されるため、それより古い月の統計は利用できなくなる可能性があります。

監査ログの表示

監査では、実行中のクエリがクエリ ログに表示され、ユーザーが実行した操作がシステム ログに表示されます。

クエリログ

ナビゲーターで 監査を選択し、クエリ ログを選択してクエリ ログを表示します。

必要条件
クエリ プロファイルを保存するための Things Cloud DataHub 機能を有効にする必要があります。 プロファイルは保持期間が過ぎると削除されるため、それより古い月のプロファイルは使用できなくなる可能性があります。

ページの上部では、オフロード クエリまたはアドホック クエリを選択できます。オフロード タスク/アドホック クエリ文字列にテキスト フィルターを定義し、期間を選択してください。 ページの下部にあるページボタンから、結果一覧内を移動できます。

オフロード クエリごとに、次の情報が提供されます。

列名 説明
オフロードのタスク パイプラインのタスク名。パイプライン実行の成功または失敗を示すステータス アイコン付き
ランタイム (s) オフロード実行に関連するDremioクエリの実行ランタイム
スキャンされたデータ (MB) オフロードクエリがThings Cloudのオペレーショナルストアから読み取ったデータの量
データ請求 (MB) 請求されるデータ量(契約にもよります)。オフロード クエリ内の 10 MB 未満のデータ量は、10 MB として請求されます。
詳細 展開可能なボックスで表示された、内部タスク UUID

各アドホッククエリについて、以下の情報が提供されます。

列名 説明
ユーザー クエリを実行するために使用されたDremioユーザーのユーザー名
クエリ SQLクエリ、クエリ実行の成功または失敗を示すステータスアイコン付き
ランタイム (s)実行時間 実行時間 (秒単位)
スキャンされたデータ (MB) アドホック クエリがデータ レイクから読み取ったデータの量
データ請求 (MB) 請求されるデータの量 (契約にもよります)。アドホック クエリの 10 MB 未満のデータ量は、10 MB として請求されます。
詳細 展開可能なボックスで表示された、クエリ文字列と、関連する Dremio ジョブへのリンク

システムログ

ナビゲータで 監査 を選択し、次に システムログ を選択してシステムログを表示します。

ページの上部で、ステータスが、すべて/成功/エラー/実行中のログ エントリを選択し、ログ エントリにテキスト フィルタを定義して、期間を選択できます。 ページの下部にあるページボタンから、結果一覧内を移動できます。

ログ エントリごとに、次の情報が提供されます。

列名 説明
ユーザー 操作を行なったユーザー
イベント 操作の種類
詳細 操作の詳細と、存在する場合は、より詳細な情報が展開可能なボックスで表示されます。

監視用のエンドポイント

ETL パイプラインの正常性

Things Cloud DataHub マイクロサービスは、有効なオフロード構成の状態を自動的に監視するエンドポイントをさらします。 ETL パイプラインの状態は、エンドポイント GET /service/datahub/scheduler/health で監視できます。エンドポイントは、formatcheck という2つのオプションパラメータを受け入れます。

パラメータ format はレスポンス本文の形式を決定します。以下の値をサポートします。

定義
text レスポンス本文をプレーンテキストとして送信します。
json レスポンス本文を JSON として送信します。

format が設定されていない場合、デフォルトで text オプションが使用されます。

パラメータ check は、レポートするジョブを定義します。このパラメータは以下の値をサポートします。

定義
ALL すべてのジョブが報告されます。
OFFLOADING オフロード ジョブのみが報告されます。対応するメッセージでは、このようなジョブは CTAS ジョブとも呼ばれます。
COMPACTION 圧縮ジョブのみが報告されます。
DremioJobDetailPersistence_OFFLOADING オフロード使用状況データを収集して保持するジョブのみが報告されます。
DremioJobDetailPersistence_QUERY アドホック クエリの使用状況データを収集して保持するジョブのみが報告されます。
C8Y_BILLING_METRICS 使用状況データを送信するジョブのみが報告されます。

check が設定されていない場合は、C8Y_BILLING_METRICS 以外のすべてのジョブが報告されます。

エンドポイントは、すべてのジョブの最新のジョブ実行を調べて分類します。

  • ジョブが失敗した場合、CRITICALとして報告されます。
  • ジョブがまだ実行中の場合、次のように分類されます。
    • 最大 1 時間実行されている場合、そのヘルスは STEADY に分類されます。
    • 最大 6 時間実行されている場合、そのヘルスは WARNING に分類されます。
    • 6 時間以上稼働している場合、ヘルスは CRITICAL に分類されます。
  • ジョブが成功した場合、それがこの構成で実行されるべき最後のジョブであったかどうか確認されます。 新たなジョブを実行する必要があると確認され、システムがスケジュールされた実行時刻からすでに 10 分遅れている場合、ジョブは CRITICAL として分類されます。 それ以外の場合、ジョブは STEADY として分類されます。

すべてのジョブが STEADY として分類される場合、エンドポイントは次のメッセージとともに HTTP ステータス コード 200 を返します。

“HTTP 200 CDHCBEI0029 - Scheduler healthcheck succeeded.”

それ以外の場合、エンドポイントは次のメッセージとともに HTTP ステータス コード 500 を返します。

“HTTP 500 CDHCBEE0031 - Scheduler healthcheck failed: There were failed or suspended jobExecutions.”

応答本文は、管理者が確認する必要のあるジョブを示します。

“There were failed or suspended jobExecutions:
CRITICAL: Job should already have been executed at 14:08:03.705: uuid=34391b71-abaa-477e-b870-2c32aa6ea790, jobType=CTAS, jobRunId=CDHScheduler_9cd4309c-99d7-43ae-92f7-4f1d267faff71713875003234”

エンドポイントには、Things Cloud DataHub マイクロサービスへのアクセスを許可されている、ログインしている Things Cloud ユーザーがアクセスできます。

データレイクの管理

Things Cloud DataHub は、Things Cloud の運用データベースからオフロードされたデータをデータレイクに保存します。データは、時間的な階層構造に従って階層フォルダに整理されています。フォルダ内では、オフロードされたデータが Parquet ファイルに整理されています。オフロード処理中、Things Cloud DataHub は、一時的な Parquet ファイルを作成し、中間データを保持しますが、これらのファイルは処理後に削除されます。データが複数の小さなファイルに分散するのを防ぐため、定期的に圧縮プロセスが実行され、より少数の大きなファイルが生成されます。

データレイクの内容と階層は変更しないでください。データが失われ、その後のデータレイクへのクエリで不完全な結果が生成されるリスクが高くなります。

フォルダ構造

データレイク内のデータは階層的に構成されています。各オフロードパイプラインは1つのターゲットテーブルに関連付けられています。各ターゲットテーブルは、データレイク内の同じ名前のフォルダに対応しています。このようなフォルダは、3種類のサブフォルダで構成されています。

  • 月次/日次フォルダ:フォルダ名は monthly または daily で始まり、その後にそのフォルダ内で管理されるデータの期間が続きます。たとえば、monthly_2024_01 には2024年1月のすべてのデータが含まれ、daily_2024_01_15 には2024年1月15日からのすべてのデータが含まれます。
  • 初期オフロードフォルダ:測定収集用のオフロードパイプラインが初めてオフロードを実行する際、この初期オフロードのデータを含むすべてのフォルダは、chunk で始まるフォルダに配置されます。チャンクフォルダ内のデータは、フォルダ名にエンコードされている年、月、日に基づいて階層的に整理されます。チャンクフォルダはオプションです。
  • 内部フォルダ: incremental で始まるフォルダには内部情報が含まれており、削除しないでください。

空の Parquet ファイル

Things Cloud DataHub は、書き込み処理中に実行ノードがクラッシュするなど特定の状況で、空の Parquet ファイルを生成することがあります。このような空のファイルがデータレイクに存在する場合、初期設定とオフロード実行は失敗します。そのため、データレイクとのやり取りが必要になります。Things Cloud DataHub はこれらの空のファイルを自動的に削除しません。AWS S3 コンソールや Azure Storage Explorer などのデータレイクプロバイダーのツールを使用して手動で削除する必要があります。

空の Parquet ファイルが原因で初期設定に失敗した場合、失敗した設定試行中に表示されるエラーメッセージにファイルの詳細が示されます。これには、c8y_cdh_temp/connectionTest のような空の Parquet ファイルを含むフォルダも含まれます。不完全または部分的に書き込まれたデータによる不整合を回避するため、このフォルダとそのサブフォルダ(空ではない可能性のある他の Parquet ファイルを含む)をすべて削除する必要があります。

オフロードが失敗した場合、ジョブ履歴に関連エラーが表示され、エラーの原因となっている空の Parquet ファイルの詳細が提供されます。データ レイク内の eventsalarms などの関連コレクション フォルダーを参照する必要があります。そのフォルダー内には、incremental_daily_monthly_chunk_ で始まるいくつかのサブフォルダーが存在する場合があります。エラー メッセージには、events/incremental_1694787385 のように、その空の Parquet ファイルが配置されている対応するフォルダーが示されます。フォルダーとそのすべてのサブフォルダーを削除する必要があります。次回のオフロード実行では、そのフォルダー内の対応する時間枠のデータが再度オフロードされるため、データは失われません。ただし、対応するオフロードが正常に実行される前に、データがオペレーショナル データベースの保持ウィンドウから既に移動されている場合は、データが失われる可能性があります。