huawei-cloud-dws-dymem-diag

Huawei Cloud DWS メモリ使用率高騰診断スキル

概要

このスキルは、DWS クラスターのメモリ使用率高騰の根本原因を診断するためのものです。クラスターでメモリ使用率が高すぎるというアラームが発生すると、メトリクスデータを自動収集し、根本原因（お客様側／システム側）を分析して、標準化された診断レポートを出力します。

アーキテクチャ：KooCLI（hcloud）→ DWS Autopilot API → クラスター監視メトリクス；MCP サーバー（dws_autopilot）→ 同じ API の代替チャネル

適用シナリオ：

• DWS クラスターのメモリ使用率高騰アラーム
• メモリ不足／OOM の調査
• ユーザーによるメモリ診断のリクエスト

代表的なユースケース：

• 「DWS クラスターのメモリ使用率が非常に高いので、診断してください」
• 「メモリアラームを受信しました。クラスター ID は xxx です。原因を分析してください」
• 「DWS クラスターで OOM が発生しました。原因を調べてください」

重要なルール：診断結果はすべて、実際のツールの戻り値に基づく必要があります。値を捏造したり、推測したりすることは禁止されています。出力は診断レポートのみとし、対処方法の提案、SQL 最適化ステートメントの出力、絵文字の使用は禁止されています。

背景知識：メモリ使用率の計算式、CN／DN インスタンスの違い、memory_pool の分析、メモリしきい値、重要な原則については、メモリの背景知識に記載されています。診断の前に必ずお読みください。

前提条件

1. CLI の要件

• KooCLI（hcloud）>= 3.2.0
• インストールの確認：hcloud version
• インストールされていない場合、またはバージョンが低すぎる場合は、CLI インストールガイドを参照してください。

2. MCP サーバーの設定（代替手段）

• KooCLI を使用できない場合は、代替手段として MCP サーバーを使用します。
• MCP インストールガイドを参照してください。

3. 認証の設定

• 有効な Huawei Cloud 認証情報（AK／SK モードまたは IAM トークン）
• セキュリティルール：
  • 会話やコマンドで AK／SK の値を公開しないでください。
  • 会話中にユーザーへ AK／SK の直接入力を求めないでください。
  • 認証情報の状態確認には hcloud configure list のみを使用してください。

4. IAM 権限の要件

• dws:clusters:get、dws:clusters:list
• dws:metricData:get、dws:hostOverview:get
• IAM ポリシーを参照してください。

KooCLI コマンド形式の標準

コマンド形式

# Query metric data
hcloud DWS ListMetricsData --cli-region=<region> --cluster_id=<id> --metric_name=<name> --project_id=<pid> --offset=0 --limit=200 --from=<from_ts> --to=<to_ts>

# Query host information
hcloud DWS ListHostOverview --cli-region=<region> --project_id=<pid> --offset=0 --limit=200

ツール選択の方針

KooCLI と MCP サーバーのいずれかを選択し、KooCLI を優先してください。ステップ 0 では hcloud が利用可能か確認します。

• hcloud が利用可能（バージョン >= 3.2.0）→ 以降のステップでは KooCLI のコマンドライン呼び出しを使用します。
• hcloud が利用不可（未インストール、またはバージョン < 3.2.0）→ 以降のステップでは MCP サーバーのツール呼び出しを使用します。

フォールバックと終了の方針：

• hcloud を選択した後、最初の呼び出しで NETWORK_ERROR（接続タイムアウト、ネットワークに到達できないなど）が返された場合は、自動的に MCP サーバーへフォールバックし、以降のステップではすべて MCP モードを使用します。
• hcloud が NETWORK_ERROR を返し、MCP サーバーも利用できない場合（未設定、または認証／接続エラーが返される場合）は、このスキルを終了し、次のメッセージを出力します：KooCLI network unavailable and MCP Server connection failed. Please check KooCLI network configuration or DWS Autopilot MCP Server configuration and retry
• MCP サーバーを選択した後、最初の呼び出しで認証エラー（例：401 Unauthorized）が返された場合、hcloud へフォールバックしないでください。このスキルを直ちに終了し、次のメッセージを出力します：MCP Server authentication failed. Please check DWS Autopilot MCP Server authentication configuration and retry
• NETWORK_ERROR 以外の hcloud 呼び出しの失敗（例：パラメーターエラー、権限不足）ではフォールバックしません。既存の再試行ロジックに従ってください。

ツールを選択したら（NETWORK_ERROR によるフォールバックを除き）、切り替えずに最後まで使用してください。呼び出しに失敗した場合は、1 回だけ再試行してください（最大 2 回）。それでも失敗する場合は、そのメトリクスを「利用不可」として記録し、次のステップへ進んでください。すべてのメトリクス取得に失敗した場合は、そのまま診断レポートを生成してください。

パラメーターのマッピング

共通パラメーター	hcloud パラメーター	MCP パラメーター
リージョン	--cli-region	（MCP 接続に組み込み済み）
プロジェクト ID	--project_id	project_id
クラスター ID	--cluster_id	cluster_id
メトリクス名	--metric_name	metric_name
開始時刻	--from	from_ts
終了時刻	--to	to_ts
ページネーションのオフセット	--offset	offset
ページネーションの上限	--limit	limit
ソートフィールド	（未対応）	order_by
ソート方向	（未対応）	sort_by

MCP ツール

ツール名	目的	主なパラメーター
dws_autopilot_get_clusters	クラスター一覧を照会	project_id, cluster_id, limit, offset
dws_autopilot_get_hosts	ホスト情報を照会	project_id, cluster_id, limit, offset
dws_autopilot_get_metric	メトリクスデータを照会	project_id, cluster_id, metric_name, from_ts, to_ts, limit, offset, order_by, sort_by

metric_data パラメーターに関する注意：metric_data では instance_name によるフィルタリングはサポートされていません（該当するパラメーターはありません）。クエリはクラスター全体のデータを返すため、対象インスタンスを絞り込むには inst_name フィールドでフィルタリングする必要があります。また、metric_data では period パラメーターはサポートされていません（サンプリング間隔はプラットフォームによって自動的に決定されます）。

使用可能な metric_name：MemStat、InstanceMemory、memory_diagnose_detail

時刻の仕様：from_ts/to_ts には Unix ミリ秒タイムスタンプを指定する必要があります。すべての時刻は UTC です。推奨する時間範囲は、アラーム時刻の 20 分前からアラーム時刻までです（from_ts = first_alarm_time - 1200000）。

戻り値の形式：成功時は {"code": 0, "data": [...]}、失敗時は {"code": -1, "message": "error description"} です。失敗した場合は 1 回再試行してください。それでも失敗する場合は縮退パスを使用し、レポートで「利用不可」と記載してください。

メトリクスごとの主なフィールド：

• MemStat：ctime, host_id, mem_total, mem_free, mem_available, cached, buffers, swap_total, swap_free, watermark_high, watermark_min → メモリ使用率 = (mem_total - mem_free - cached - buffers) / mem_total * 100%
• InstanceMemory：ctime, host_id, inst_name, dynamic_used_memory, max_dynamic_memory, dynamic_peak_memory, process_used_memory, max_process_memory, shared_used_memory, max_shared_memory, comm_used_memory, max_comm_memory, cstore_used_memory, max_cstore_memory, topsql_used_memory, max_topsql_memory, other_used_memory, udf_reserved_memory, mmap_used_memory, storage_compress_memory, pooler_conn_memory, pooler_freeconn_memory → 動的メモリ使用率 = (dynamic_used_memory / max_dynamic_memory) * 100%；プロセスメモリ使用率 = (process_used_memory / max_process_memory) * 100%
• memory_diagnose_detail：ctime, host_id, instance_name, active_sessions[{query, query_id, userName, mem_used, state, duration_ms, plan_type}], memory_pool{work_mem_used/total, shared_pool_used/total}

ステップごとのクエリの違いについては、メトリクスリファレンスを参照してください。

ページネーションの仕様

すべてのツール呼び出し（MCP と hcloud）では、単一の応答が大きくなりすぎてトークン制限を超えるのを防ぐため、ページネーション付きのクエリを使用する必要があります。

ページネーションのルール：

• 一律に limit=200 を使用してください（800 などの大きな値は使用しないでください）。
• 1 ページ目は offset=0 とします。返されたデータ数が 200 の場合は、offset+=200 としてクエリを続けてください。
• 返されたデータ数が 200 未満になるまで繰り返し、すべてのページのデータを結合してください。
• 結合する際は、すべてのページのデータ配列を連結して完全なデータセットを作成してください。

MCP 呼び出し例（MemStat を使用）：

Page 1: dws_autopilot_get_metric(project_id, cluster_id, metric_name="MemStat", from_ts, to_ts, limit=200, offset=0)
If returned data length = 200:
Page 2: dws_autopilot_get_metric(project_id, cluster_id, metric_name="MemStat", from_ts, to_ts, limit=200, offset=200)
If returned data length < 200: Stop pagination, merge page 1 + page 2 data

hcloud 呼び出し例（MemStat を使用）：

Page 1: hcloud DWS ListMetricsData --cli-region=<region> --cluster_id=<id> --metric_name=MemStat --project_id=<pid> --offset=0 --limit=200 --from=<from_ts> --to=<to_ts>
If returned data count = 200:
Page 2: hcloud DWS ListMetricsData --cli-region=<region> --cluster_id=<id> --metric_name=MemStat --project_id=<pid> --offset=200 --limit=200 --from=<from_ts> --to=<to_ts>
If returned data count < 200: Stop pagination, merge data

ワークフロー

診断の前に、ステップ 0～7 に基づいて実行計画を作成し、その後、順番に実行してください。ツールの選択方法については、「KooCLI コマンド形式の標準」セクションを参照してください。以降のステップでは、この内容を繰り返し説明しません。すべての MCP ツール呼び出しでは、「ページネーションの仕様」セクションに従ってください。以降のステップでは、ページネーションの詳細を繰り返し説明しません。

ステップ 0：環境の検出

hcloud version を実行します。バージョンが 3.2.0 以上の場合は tool_mode=hcloud、それ以外の場合は tool_mode=mcp とします。

hcloud のネットワーク利用可能性の確認：tool_mode=hcloud の場合、軽量な API 呼び出し（例：hcloud DWS ListClusters --cli-region=<region> --project_id=<project_id> --offset=0 --limit=1）を実行して、ネットワーク接続を確認します。

• 正常な結果または業務エラー（例：権限不足、パラメーターエラー）が返された場合 → ネットワーク利用可能、tool_mode=hcloud を維持
• NETWORK_ERROR が返された場合 → ネットワーク利用不可、tool_mode=mcp に切り替え
• 切り替え後、MCP も利用できない場合 → 実行を終了し、KooCLI のネットワーク設定または MCP サーバーの設定を確認するようユーザーに促します

ステップ 1：MemStat のクエリ

metric_name="MemStat" でメトリクスクエリを呼び出します。時間範囲：from_ts=first_alarm_time - 1200000、to_ts=first_alarm_time。MCP モードでは、limit=200 でページネーションを使用してクエリします。

Autopilot の利用不可判定：50201/RDS.9999 エラーが返された場合 → ステップ 1～6 をスキップし、すべてのメトリクスを「利用不可」としてマークしてから、直接ステップ 7 に進みます。

解析：host_id ごとにグループ化し、各ノードの最新のメモリデータを特定します。メモリ使用率 = (mem_total - mem_free - cached - buffers) / mem_total * 100%。使用率が高すぎるか（> 80%）、全体的に高いか（すべて > 70%）、偏りがあるか（偏差 > 30%）を判定します。メモリ使用量が最も高い 2 つのノードと TOP3 を特定します。

ノード範囲の分類（high_mem_nodes の数に基づく）：

• すべてのノードでメモリ使用率が高い：ほとんどのノードでメモリ使用率が高い（目安：メモリ使用率が高いノードの割合が 80% 以上）→ 業務側の原因（高い同時実行数、複雑な SQL など）の可能性が高い
• 単一ノードでメモリ使用率が高い：メモリ使用率が高いノード数 = 1 → データの偏り、接続の偏り、異常なプロセスの可能性が高い
• 一部のノードでメモリ使用率が高い：1 < メモリ使用率が高いノード数 < ほとんどのノード → 新旧ノードの差、ヘッド DN の偏り、ローカルデータの偏りの可能性が高い

出力：mem_by_host, max_mem_hosts, problem_host_id, problem_host_mem_usage, problem_host_used, problem_host_total, problem_host_available, top3_mem_nodes, cluster_avg_mem, is_imbalanced, is_global_high, mem_deviation, high_mem_nodes, mem_scope

ステップ 2：ホスト名の取得

ホスト情報クエリを呼び出し（MCP モードでは limit=200 でページネーションを使用）、host_id → {host_name, ip} のマッピングテーブルを作成します。ステップ 1 の出力にある max_mem_hosts に含まれるノードのホスト情報のみをクエリします。

出力：host_id_to_info_map, problem_host_ip, node_name

ステップ 3：InstanceMemory のクエリ

metric_name="InstanceMemory" でメトリクスクエリを呼び出します。時間範囲はステップ 1 と同じです。MCP モードでは、limit=200 でページネーションを使用してクエリします。注：metric_data は instance_name によるフィルタリングをサポートしていません。クエリはクラスター全体のデータを返すため、対象インスタンスは inst_name フィールドでフィルタリングする必要があります。

解析：各インスタンス（CN/DN）のメモリ使用率を抽出します。動的メモリ使用率 = (dynamic_used_memory / max_dynamic_memory) * 100%。プロセスメモリ使用率 = (process_used_memory / max_process_memory) * 100%。メモリ使用率が最も高いインスタンスを特定します。

CN/DN インスタンスの区別（inst_name フィールドに基づく。InstanceMemory には instance_type フィールドがありません）：

• inst_name に「cn」または「coordinator」が含まれる → CN インスタンス
• inst_name に「dn」または「datanode」が含まれる → DN インスタンス
• CN インスタンスのメモリ使用率が高い → 接続の偏り、プッシュダウンされない SQL、解析負荷に注目
• DN インスタンスのメモリ使用率が高い → データの偏り、計算の偏り、ソート／ハッシュのスピルに注目

メモリ種別の判定（InstanceMemory の動的メモリとプロセスメモリの比率に基づく）：

• 動的メモリの比率が比較的高い → 動的メモリの使用量が高い。業務 SQL、work_mem の設定に注目
• プロセスメモリの比率が比較的高い → プロセスメモリの使用量が高い。過剰な接続数、プロセスリークに注目

出力：instance_memory_data, high_memory_instances, instance_type_distribution, top3_dynamic_instances, inst_type, mem_type

ステップ 4：メモリ診断詳細のクエリ

metric_name="memory_diagnose_detail" を指定してメトリクスクエリを実行します。時間範囲はステップ 1 と同じにします。注：metric_data は instance_name によるフィルタリングをサポートしていません。クエリではクラスター全体のデータが返されるため、ステップ 1 の出力にある max_mem_hosts でフィルタリングする必要があります。 MCP モードでは limit=200 のページネーション付きクエリを使用し、返される件数が 200 未満になるまで続けます（このメトリクスはデータ量が最も多いため）。フィルタリングの前に、ページネーションで取得したデータをすべて結合します。

解析：アクティブなクエリ文、実行ユーザー（userName）、メモリ使用量、セッション情報、SQL レベルのメモリ統計を抽出します。

時刻注釈ルール：memory_diagnose_detail の ctime は Autopilot による収集スナップショットの時刻であり、実際の SQL 開始時刻ではありません。active_sessions に duration_ms フィールドがある場合、SQL 開始時刻 = ctime - duration_ms とし、「開始時刻」と注釈します。duration_ms がない場合は ctime をそのまま使用し、「収集時刻」と注釈します（収集時刻を「開始時刻」と注釈しないでください）。

アクティブユーザー統計ルール：state=active のユーザーと接続のみを集計します。idle 状態は集計しません。userName ごとにグループ化し、メモリ使用量を集計して上位ユーザーを特定します。

出力：user_memory_top5、session_memory_top5、sql_memory_top5、total_memory_by_users、total_memory_by_sqls、high_memory_sql_detected、high_memory_sql_info、high_freq_queries、heavy_queries、memory_pool_data、idle_session_with_high_mem

ステップ 5：診断結果の分析

ステップ 1～4 で収集したデータに、ユーザー ID 情報を組み合わせて、メモリ使用量が高い原因を分析します。

診断の優先順位：まず影響範囲を確認してから原因を特定します。業務上の異常を優先し、設定とシステムの確認は最後に行います。

時刻の形式：すべての Unix ミリ秒タイムスタンプ（first_alarm_time、ctime など）は UTC タイムゾーンです。レポートでは、YYYY-MM-DD HH:MM:SS 形式の北京時間（UTC+8）の文字列に変換する必要があります。python -c "from datetime import datetime,timezone,timedelta; print(datetime.fromtimestamp({ms}/1000,tz=timezone(timedelta(hours=8))).strftime('%Y-%m-%d %H:%M:%S'))" を使用できます。タイムスタンプ値を暗算しないでください。

ユーザー ID の判定（データベースユーザーに基づきます。つまり、memory_diagnose_detail の active_sessions にある userName を使用します）：

• データベースユーザーが "omm" または "Ruby" → システム側の原因
• データベースユーザーが "omm" でも "Ruby" でもない → お客様側の原因

memory_pool の分析（ステップ 4 の memory_pool_data に基づきます）：

• work_mem 使用率 = (work_mem_used / work_mem_total) * 100%。work_mem が高い場合、SQL のソート／ハッシュ処理が大量のメモリを消費していることを示します
• shared_pool 使用率 = (shared_pool_used / shared_pool_total) * 100%。shared_pool が高い場合、共有キャッシュに負荷がかかっていることを示します
• work_mem 使用率 > 80% → SQL のソート／ハッシュ処理によるディスクへのスピル、work_mem の設定値が大きすぎないかを重点的に確認します
• shared_pool 使用率 > 80% → 共有テーブル／インデックスキャッシュへの負荷、接続数の過剰を重点的に確認します

お客様側の原因

1. 単一 SQL によるメモリ使用量の増加：単一 SQL のメモリ使用割合が顕著（目安：割合 > 20%）で、ノードのメモリ使用量増加に大きく寄与しています。plan_type による補助的な判定：plan_type が HashJoin/HashAggregate の場合、ハッシュ処理がメモリ消費の主な原因です
2. 複数ユーザーの同時実行によるメモリ使用量の増加：複数のユーザーが同時に大量のメモリを消費しています
   • concurrent_mode の判定ルール：multi_user（アクティブなクエリを実行している異なるデータベースユーザーが複数存在し、アクティブユーザー数 >= 2）；single_user（データベースユーザーは 1 人だが並列クエリが多く、アクティブユーザー数 = 1 かつクエリ数が多い）；none（高い同時実行性が見られない状況）
3. セッションリークまたは長時間トランザクション：セッション状態が idle でありながら大量のメモリを保持している（ステップ 4 の idle_session_with_high_mem を参照）、またはセッションが長時間実行され（duration_ms が目安の 30 分を超過）、メモリが解放されていません
4. データの偏りによるメモリ使用量の不均衡：ノード間の偏差 > 30%

注：単一 SQL と複数ユーザーの同時実行は同時に該当する場合があります。それぞれを独立した異常項目として記載し、相互排他的に扱わないでください。

システムに起因する原因

1. メモリ使用量が多いシステム内部タスク：メモリを大量に消費する omm/Ruby ユーザー
2. インスタンスのメモリ設定が不適切：インスタンスのメモリ使用量が継続的に上限付近にあり（動的メモリ使用率が継続的に 80% を超える）、memory_pool のデータと合わせて work_mem/shared_pool の設定を判断します。
3. メモリリーク：MemStat または InstanceMemory の時系列データで、メモリ使用量が継続的に単調増加していることが確認できます（複数の ctime データポイントを比較し、低下せずに継続して増加する傾向を示す）。明らかな外部クエリがないにもかかわらず、メモリが増加し続けます。

総合的な判定ルール：

条件	判定
すべてのノードの使用率が 70% 超	クラスター全体のメモリ使用率が高い
ノード間の偏差が 30% 超	クラスターのメモリ負荷が不均衡で、データスキューの可能性あり
単一インスタンスの動的メモリ使用率が著しく異常	単一インスタンスのメモリ異常
high_memory_sql_detected = true	単一 SQL がメモリを大量に消費しており、該当する SQL を特定済み
user_memory_top5 に占める omm/Ruby の割合が 30% 超	システム内部タスクがメモリを大量に消費（システム側）
MemStat/InstanceMemory の時系列データが継続的に単調増加	メモリリークの可能性あり
work_mem の使用率が 80% 超	work_mem の設定が大きすぎる、または SQL のソート／ハッシュでスピルが発生
shared_pool の使用率が 80% 超	共有キャッシュの負荷が高く、接続数が過剰

統計および集計の要件：

1. メモリ使用量の割合が高いデータベースユーザー Top3：active_sessions の userName でグループ化し、mem_used を集計します（データベースユーザーのみを対象とし、プロセスユーザーは対象外）。pct-bar による可視化を含む HTML テーブルセクション「内存贡献 Top3 数据库用户」に表示します。割合 = ユーザーの mem_used 合計 / 全ユーザーの mem_used 合計 × 100%。pct-bar の幅の計算：width = Math.round(ratio / max_ratio * 200)。ここで max_ratio は最上位ユーザーの割合です。state=active のデータベースユーザーのみを集計します。データポイントが 3 件未満の場合は、実際の件数を表示します。
2. メモリ使用量の割合が高い SQL Top3：memory_diagnose_detail の active_sessions から mem_used の降順に並べ替え、HTML テーブルセクション「内存贡献 Top3 语句」に表示します。各行は 1 回のクエリ実行を表します。Top 3 を並べ替える際は各行を個別に扱います。QueryID は query_id フィールドから取得します（類似する SQL が複数ある場合は、件数の注記とともにカンマ区切りで表示）。ユーザー名は userName フィールドから取得します（データベースユーザー）。メモリ使用率は mem_used フィールドから取得し、ノードのメモリ総使用量に対する割合として計算して、小数第 1 位まで表示します。時間：duration_ms がある場合は、ctime - duration_ms を北京時間に変換します（列見出しは「启动时间」）。duration_ms がない場合は、ctime を北京時間に変換します（列見出しは「采集时间」）。SQL は query フィールドから取得し、最大 1000 文字まで表示します。超える場合は「...」で切り詰めます。gaussdb プロセスは、Top3 の独立したステートメントとして表示しません。そのメモリオーバーヘッドは、対応する根本原因の説明に統合します。ステートメントデータがない場合は、テーブルに「无法获取」と入力します。
3. 割合 =（ユーザー／SQL のメモリ使用量 / ノードのメモリ総使用量）× 100%

出力：root_cause_category, mem_scope, inst_type, mem_type, summary, high_memory_sql_info, session_info, top3_memory_users, top3_memory_statements, high_freq_queries, heavy_queries, memory_pool_summary, concurrent_mode

ステップ 6：クラスター名の取得

まず、入力パラメーター cluster_name からクラスター名を取得します。空の場合は、project_id と cluster_id を指定して dws_autopilot_get_clusters を呼び出し、cluster_name を取得します。この呼び出しも失敗した場合は、cluster_id を resource_name として使用します。

出力：resource_name, resource_id

ステップ 7：診断レポートの生成

「出力形式」セクションのテンプレートに従って HTML レポートを生成します。レポートを生成した後、HTML ファイルを現在の作業ディレクトリ（ワークスペースのルートフォルダー）に保存します。ファイル名は dws_mem_diagnosis_report_{timestamp}.html とし、{timestamp} には現在のマシンのローカル時刻を yyyyMMdd_HHmmss 形式で指定します（例：dws_mem_diagnosis_report_20260623_150421.html）。

コアコマンド

クラスターリストのクエリ

# hcloud
hcloud DWS ListClusters --cli-region=<region> --project_id=<pid> --offset=0 --limit=200
# MCP
dws_autopilot_get_clusters(project_id=<pid>)

ホスト情報の照会

# hcloud
hcloud DWS ListHostOverview --cli-region=<region> --project_id=<pid> --offset=0 --limit=200
# MCP
dws_autopilot_get_hosts(project_id=<pid>, cluster_id=<cid>, limit=200, offset=0)

メトリックデータの照会（一般形式）

# hcloud
hcloud DWS ListMetricsData --cli-region=<region> --cluster_id=<cid> --metric_name=<name> --project_id=<pid> --offset=0 --limit=200 --from=<from_ts> --to=<to_ts>
# MCP
dws_autopilot_get_metric(project_id=<pid>, cluster_id=<cid>, metric_name=<name>, from_ts=<from>, to_ts=<to>, limit=200, offset=0, order_by="ctime", sort_by="desc")

パラメーターの確認

パラメーター	必須／任意	説明	デフォルト
alarm_serial_number	必須	アラームのシリアル番号	N/A
project_id	必須	プロジェクト ID	N/A
cluster_id	必須	クラスター ID	N/A
first_alarm_time	必須	最初のアラーム時刻（ミリ秒単位のタイムスタンプ）	N/A
alarm_name	必須	アラーム名	N/A
region_id	任意	リージョン識別子	N/A
node_name	任意	アラート対象ノード名	空（クラスター単位のアラーム）
instance_name	任意	インスタンス名	空
cluster_name	任意	クラスター名	cluster_id を使用
alarm_severity	任意	アラームの重大度	N/A

出力形式

出力形式のテンプレートに従って、厳密に出力してください。テンプレートの内容を分析または要約したり、一部を省略したり、テンプレートの構造を変更したりしないでください。出力はテンプレートと一致している必要があります。

ベストプラクティス

1. タイムスタンプの処理：first_alarm_time はすでにミリ秒単位のタイムスタンプです。ツールのパラメーターにはそのまま使用してください。いったん時刻文字列に変換してからタイムスタンプに戻さないでください（8 時間のずれを防ぐため）。
2. ツールの選択：KooCLI と MCP のどちらかを選択し、KooCLI を優先してください。一度選択したら、その方法を一貫して使用してください。
3. ページ分割されたクエリ：すべてのツール呼び出しで、limit=200 を使用して返却件数が 200 未満になるまでページネーションを行い、すべてのページのデータを統合してください。memory_diagnose_detail はデータ量が最も多いため、ページネーションが必要です。
4. レポート時刻：すべてのタイムスタンプを北京時間（UTC+8）に変換してください。次のコマンドを使用できます：python -c "from datetime import datetime,timezone,timedelta; print(datetime.fromtimestamp({ms}/1000,tz=timezone(timedelta(hours=8))).strftime('%Y-%m-%d %H:%M:%S'))"
5. SQL の表示：メモリ使用量への寄与が大きい上位 3 件のステートメントでは、具体的な SQL を最大 1000 文字まで表示してください。超過する場合は「...」で省略してください。
6. メモリ使用量の計算：メモリ使用率 = (mem_total - mem_free - cached - buffers) / mem_total * 100%；動的メモリ使用率 = (dynamic_used_memory / max_dynamic_memory) * 100%；プロセスメモリ使用率 = (process_used_memory / max_process_memory) * 100%
7. CN／DN インスタンスの区別：inst_name に「cn」または「coordinator」が含まれる場合は CN、「dn」または「datanode」が含まれる場合は DN です。CN のメモリ使用量が高い場合は接続と解析に注目し、DN のメモリ使用量が高い場合はデータと計算に注目してください。
8. セッションリークの検出：アイドル状態で大量のメモリを保持している場合はセッションリークです。メモリが解放されないまま duration_ms > 30 分の場合は長時間トランザクションです。

参考資料

ドキュメント	説明
CLI インストールガイド	KooCLI のインストールと設定
MCP インストールガイド	DWS Autopilot MCP Server のインストールと設定
IAM ポリシー	必要な権限とポリシー JSON
メトリックリファレンス	メトリックのキー項目とクエリの違い
メモリの基礎知識	メモリの計算式、CN／DN の区別、memory_pool の分析、しきい値
出力形式	HTML テンプレートと入力ルール

注意事項

• セキュリティ：会話やコマンドで AK/SK の値を絶対に公開しないでください。また、会話でユーザーに AK/SK を直接入力するよう求めないでください。
• 時刻プロトコル：from_ts/to_ts にはミリ秒単位のタイムスタンプを使用する必要があります。レポートでは北京時間が表示されます。北京時間をタイムスタンプに変換する場合は、タイムゾーン接尾辞 +08:00 を必ず付けてください。タイムスタンプ値を暗算しないでください。既存のミリ秒単位のタイムスタンプを時刻文字列に変換してから戻さないでください。
• 出力制約：出力形式のセクションにあるテンプレートに従って、診断レポートのみを厳密に出力してください。テンプレートの構造を変更せず、どの部分も省略せず、修復の提案を追加せず、SQL の最適化文を出力せず、絵文字を使用せず、独自の書式タグを使用しないでください。
• データの信頼性：診断結果はすべて、実際のツールの戻り値に基づく必要があります。ツールの戻り値が空の場合、または呼び出しに失敗した場合は、「利用不可」と記載してください。値を捏造することは禁止されています。
• 既知の制限事項：hcloud は --order_by および --sort_by パラメーターをサポートしていません。クエリ後にローカルで ctime の降順に並べ替えてください。memory_diagnose_detail は host_id によるフィルタリングをサポートしていません。クラスター全体をクエリしてから、ローカルでフィルタリングしてください。memory_diagnose_detail の ctime は収集時刻であり、SQL の開始時刻ではありません。InstanceMemory には instance_type フィールドがないため、inst_name を使って CN/DN を判定する必要があります。