メインコンテンツまでスキップ
バージョン: 3.5

監査ログに対してSQLベースの分析を実行する

PhoenixAI クラスター内のデータに対して行われたすべてのクエリについての監査情報をクエリおよび分析します。

PhoenixAI は、クラスター監査ログファイルをクラスターにストリーミングすることをサポートしており、クラスター内で直接監査ログに対して SQL ベースの分析を実行できます。

一般的なユースケース:

  • クライアント接続の監査
  • クエリがどのように、何を、どこから来ているかを分析する
  • データベース、テーブル、マテリアライズドビューへの変更の監視
  • マテリアライズドビューの効率の追跡
  • クラスターリソースの消費量の観察

監査ログストリーミングの有効化

監査ログのストリーミングを有効化するには、次の手順に従います:

  1. PhoenixAI Cloud console にサインインします。
  2. 左側のナビゲーションペインで、Cluster を選択します。
  3. Cluster ページで、監査ログストリーミングを有効化するクラスターをクリックします。
  4. クラスターの詳細ページで、Open cluster をクリックします。
  5. Connect to your Cluster ページで、クラスターにアクセスするための UsernamePassword を入力し、Sign in をクリックして PhoenixAI Studio を開きます。
  6. PhoenixAI Studio の Administrator タブで、Query Audit logs セクションのスイッチをオンにします。

監査ログのクエリ

監査ログストリーミングが有効化されると、PhoenixAI はクラスター内に監査ログレコードを保存するデータベースとテーブルを作成します。カタログ、データベース、テーブルは default_catalogstarrocks_audit_db__starrocks_audit_tbl__ です。完全なパスは default_catalog.starrocks_audit_db__.starrocks_audit_tbl__ です。

監査データは PhoenixAI Studio または任意のSQLツールを使用してクエリできます。

important

監査ログは 60 秒ごとにバッチロードされるため、監査データが利用可能になるまでに 60 秒の遅延が発生します。

starrocks_audit_tbl__ の CREATE TABLE 文は以下のとおりです:

CREATE TABLE starrocks_audit_db__.starrocks_audit_tbl__ (
`queryId` VARCHAR(64) COMMENT "クエリの一意の ID",
`timestamp` DATETIME NOT NULL COMMENT "クエリ開始時刻",
`queryType` VARCHAR(12) COMMENT "クエリタイプ(query、slow_query、connection)",
`clientIp` VARCHAR(32) COMMENT "クライアントIP",
`user` VARCHAR(64) COMMENT "クエリユーザー名",
`authorizedUser` VARCHAR(64) COMMENT "ユーザーの一意の識別子、つまり user_identity",
`resourceGroup` VARCHAR(64) COMMENT "リソースグループ名",
`catalog` VARCHAR(32) COMMENT "カタログ名",
`db` VARCHAR(96) COMMENT "クエリが実行されるデータベース",
`state` VARCHAR(8) COMMENT "クエリ状態(EOF、ERR、OK)",
`errorCode` VARCHAR(512) COMMENT "エラーコード",
`queryTime` BIGINT COMMENT "クエリ実行時間(ミリ秒)",
`scanBytes` BIGINT COMMENT "クエリがスキャンしたバイト数",
`scanRows` BIGINT COMMENT "クエリがスキャンした行数",
`returnRows` BIGINT COMMENT "クエリが返した行数",
`cpuCostNs` BIGINT COMMENT "クエリが消費した CPU 時間(ナノ秒)",
`memCostBytes` BIGINT COMMENT "クエリが消費したメモリ(バイト)",
`stmtId` INT COMMENT "SQL文のインクリメンタル ID",
`isQuery` TINYINT COMMENT "SQLがクエリかどうか(1 または 0)",
`feIp` VARCHAR(128) COMMENT "文を実行したFEのIP",
`stmt` VARCHAR(1048576) COMMENT "元の SQL 文",
`digest` VARCHAR(32) COMMENT "スロー SQL のフィンガープリント",
`planCpuCosts` DOUBLE COMMENT "クエリプランニング中の CPU 使用量(ナノ秒)",
`planMemCosts` DOUBLE COMMENT "クエリプランニング中のメモリ使用量(バイト)",
`pendingTimeMs` BIGINT COMMENT "クエリがキューで待機した時間(ミリ秒)",
`candidateMVs` VARCHAR(65533) NULL COMMENT "候補マテリアライズドビューのリスト",
`hitMvs` VARCHAR(65533) NULL COMMENT "マッチしたマテリアライズドビューのリスト",
`QueriedRelations` ARRAY<VARCHAR(65533)> NULL COMMENT "直接参照されたテーブルとビューのリスト",
`warehouse` VARCHAR(32) NULL COMMENT "ウェアハウス名"
) ENGINE = OLAP
DUPLICATE KEY (`queryId`, `timestamp`, `queryType`)
COMMENT "監査ログテーブル"
PARTITION BY date_trunc('day', `timestamp`)
PROPERTIES (
"replication_num" = "1",
"partition_live_number" = "30"
);

監査ログに対して SQL ベースの分析を実行する

このセクションでは、監査ログに対する SQL ベースの分析のいくつかの例を示します。

CPU消費量の分析

以下の SQL は、過去 30 日間のユーザーごとの合計 CPU 時間(cpuCostNs)を集計し、秒に変換して、CPU 使用量の合計に対するパーセンテージを計算します。

SELECT
user,
SUM(cpuCostNs) / 1e9 AS total_cpu_seconds, -- 合計 CPU 時間をクエリします。
(
SUM(cpuCostNs) /
(
SELECT SUM(cpuCostNs)
FROM starrocks_audit_db__.starrocks_audit_tbl__
WHERE state IN ('EOF','OK')
AND timestamp >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
)
) * 100 AS cpu_usage_percentage -- ユーザーごとの合計 CPU 使用量のパーセンテージを計算します。
FROM starrocks_audit_db__.starrocks_audit_tbl__
WHERE state IN ('EOF','OK') -- 完了したクエリのみを含めます。
AND timestamp >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY) -- 過去 30 日間のデータをクエリします。
GROUP BY user
ORDER BY total_cpu_seconds DESC
LIMIT 20; -- CPU 消費量が最も多い上位 20 ユーザーを一覧表示します。

メモリ使用量の分析

以下の SQL は、過去 30 日間の 1 クエリあたりのユーザーごとの最大メモリ使用量(memCostBytes)を計算します。

SELECT
user,
MAX(memCostBytes) / (1024 * 1024) AS max_mem_mb -- クエリあたりの最大メモリ使用量(MB 単位)。
FROM starrocks_audit_db__.starrocks_audit_tbl__
WHERE state IN ('EOF','OK') -- 完了したクエリのみを含めます。
AND timestamp >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY) -- 過去 30 日間のデータをクエリします。
GROUP BY user
ORDER BY max_mem_mb DESC
LIMIT 20; -- メモリ消費量が最も多い上位 20 ユーザーを一覧表示します。

クエリ同時実行数の分析

以下の SQL は、過去 30 日間の分単位のクエリ同時実行数を分析し、ユーザーごとに観測された最大同時実行数を抽出します。

WITH UserConcurrency AS (
SELECT
user,
DATE_FORMAT(timestamp, '%Y-%m-%d %H:%i') AS minute_bucket,
COUNT(*) AS query_concurrency
FROM starrocks_audit_db__.starrocks_audit_tbl__
WHERE state IN ('EOF', 'OK') -- 完了したクエリのみを含めます。
AND timestamp >= DATE_SUB(NOW(), INTERVAL 30 DAY) -- 過去 30 日間のデータをクエリします。
AND LOWER(stmt) LIKE '%select%' -- SELECT 文のみを含めます。
GROUP BY user, minute_bucket
HAVING query_concurrency > 1 -- 1 分あたり 1 クエリ未満の同時実行シナリオを除外します。
)
SELECT
user,
minute_bucket,
query_concurrency / 60.0 AS query_concurrency_per_second -- 秒あたりの同時実行数をクエリします。
FROM (
SELECT
user,
minute_bucket,
query_concurrency,
ROW_NUMBER() OVER (
PARTITION BY user
ORDER BY query_concurrency DESC
) AS rn
FROM UserConcurrency
) ranked
WHERE rn = 1 -- 各ユーザーの最高記録を保持します。
ORDER BY query_concurrency_per_second DESC
LIMIT 50; -- 同時実行数が最も高い上位 50 ユーザーを一覧表示します。

マテリアライズドビューのリフレッシュ操作のメモリ使用量の分析

以下の SQL は、通常 INSERT OVERWRITE 文によって特徴付けられるメモリを多く消費するマテリアライズドビューのリフレッシュ操作を特定します。

SELECT
user,
MAX(memCostBytes) / (1024 * 1024) AS max_mem_mb -- クエリあたりの最大メモリ使用量(MB 単位)。
FROM starrocks_audit_db__.starrocks_audit_tbl__
WHERE state IN ('EOF','OK') -- 完了したクエリのみを含めます。
AND timestamp >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY) -- 過去 30 日間のデータをクエリします。
AND LOWER(stmt) LIKE '%insert overwrite%' -- マテリアライズドビューのリフレッシュ操作のみを含めます。
GROUP BY user
ORDER BY max_mem_mb DESC
LIMIT 20; -- メモリ消費量が最も多い上位 20 ユーザーを一覧表示します。