Things Cloud DataHub の運用

システム情報の確認

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

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

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

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

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

使用統計の追跡

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

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

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

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

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

監査ログの表示

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

クエリログ

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

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

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

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

システムログ

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

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

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

監視用のエンドポイント

ETL パイプラインの正常性

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

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

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

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

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