dt-obs-hosts

インフラストラクチャホストスキル

CPU、メモリ、ディスク、ネットワーク、テクノロジーのインベントリなど、ホストとプロセスのインフラストラクチャを監視、管理します。

このスキルを使用するタイミング

次のようなニーズがある場合に、このスキルを使用します。

• インベントリ：「AWS us-east-1 にあるすべての Linux ホストを表示して」
• エージェントのインベントリ：「FULL_STACK、INFRASTRUCTURE、または DISCOVERY モードで実行されているホストはどれ？」／「OneAgent のバージョン分布を表示して」
• 監視：「CPU 使用率が高いホストはどれ？」
• トラブルシューティング：「メモリを最も多く消費しているプロセスはどれ？」
• 検出：「本番環境で実行されているデータベースは何？」
• 計画：「アップグレード計画のために Kubernetes のバージョン分布を追跡して」
• コスト：「コストセンター別にインフラストラクチャのコストを計算して」
• セキュリティ：「ポート 22 でリッスンしているすべてのプロセスを見つけて」
• コンプライアンス：「EOL の Java バージョンを実行しているホストを特定して」
• 品質：「AWS ホストのデータ完全性を確認して」
• 最適化：「使用率に基づいて適正規模化の候補を見つけて」

---

複数のソース間の結合が必要です： クエリでホストデータをログやその他のテレメトリソースと組み合わせる必要がある場合（例：「IP アドレスとともに Linux ホストのログを表示して」）、クエリを作成する前に dt-dql-essentials/references/smartscape-topology-navigation.md も読んでください。

---

基本概念

エンティティ

• HOST - 物理マシンまたは仮想マシン（クラウドまたはオンプレミス）
• PROCESS - 実行中のプロセスとプロセスグループ
• CONTAINER - Kubernetes コンテナ
• NETWORK_INTERFACE - ホストのネットワークインターフェイス
• DISK - ホストのディスクボリューム

メトリクスのカテゴリ

1. ホストメトリクス - dt.host.cpu.*、dt.host.memory.*、dt.host.disk.*、dt.host.net.*
2. プロセスメトリクス - dt.process.cpu.*、dt.process.memory.*、dt.process.io.*、dt.process.network.*
3. インベントリ - OS の種類、クラウドプロバイダー、テクノロジースタック、バージョン
4. コスト - dt.cost.costcenter、dt.cost.product
5. 品質 - メタデータの完全性、バージョンコンプライアンス

アラートのしきい値

• CPU／メモリ／ディスク： 80% で警告、90% で重大
• ネットワーク： 70% 超で高、85% 超で飽和
• ディスクレイテンシ： 20ms 超でボトルネック
• ネットワークエラー： ドロップ率 1% 超、エラー率 0.1% 超
• スワップ： 30% 超で警告、50% 超で重大

---

主なワークフロー

1. ホストの検出と分類

ホストを検出し、OS／クラウド別に分類して、リソースのインベントリを作成します。

smartscapeNodes "HOST"
| fieldsAdd os.type, cloud.provider, host.logical.cpu.cores, host.physical.memory
| summarize host_count = count(), by: {os.type, cloud.provider}
| sort host_count desc

OS の種類： LINUX、WINDOWS、AIX、SOLARIS、ZOS

→ クラウド固有の属性については、references/inventory-discovery.md を参照してください。

2. リソース使用率の監視

ホスト全体の CPU、メモリ、ディスク、ネットワークを監視します。

timeseries {
  cpu = avg(dt.host.cpu.usage),
  memory = avg(dt.host.memory.usage),
  disk = avg(dt.host.disk.used.percent)
}, by: {dt.smartscape.host}
| fieldsAdd host_name = getNodeName(dt.smartscape.host)
| filter arrayAvg(cpu) > 80 or arrayAvg(memory) > 80
| sort arrayAvg(cpu) desc

高使用率のしきい値： 80% で警告、90% で重大

主な CPU メトリクス：

• dt.host.cpu.usage — CPU の合計使用率（0～100%）
• dt.host.cpu.idle — CPU のアイドル時間（使用率の逆数。異常検出に便利）
• dt.host.cpu.user — ユーザーモードでの CPU 時間
• dt.host.cpu.system — カーネルモードでの CPU 時間
• dt.host.cpu.iowait — I/O 待機中の CPU 時間（Linux のみ）

→ CPU の詳細な分析については、references/host-metrics.md を参照してください。
→ メモリの内訳については、references/host-metrics.md を参照してください。

ディスク空き容量 — 空きディスク容量が最も多い／少ないホストを検索

timeseries disk_used_pct = avg(dt.host.disk.used.percent), by: {dt.smartscape.host}
| fieldsAdd host_name = getNodeName(dt.smartscape.host)
| fieldsAdd avg_disk_used = arrayAvg(disk_used_pct),
    free_pct = 100 - arrayAvg(disk_used_pct)
| sort free_pct desc
| limit 10

3. プロセスのリソース分析

プロセスレベルで、最も多くのリソースを消費しているものを特定します。

timeseries {
  cpu = avg(dt.process.cpu.usage),
  memory = avg(dt.process.memory.usage)
}, by: {dt.smartscape.process}
| fieldsAdd process_name = getNodeName(dt.smartscape.process)
| filter arrayAvg(cpu) > 50
| sort arrayAvg(cpu) desc
| limit 20

→ プロセスの I/O 分析については、references/process-monitoring.md を参照してください。
→ プロセスのネットワークメトリクスについては、references/process-monitoring.md を参照してください。

4. テクノロジースタックのインベントリ

ソフトウェアのテクノロジーとバージョンを検出し、追跡します。

smartscapeNodes "PROCESS"
| fieldsAdd process.software_technologies
| expand tech = process.software_technologies
| fieldsAdd tech_type = tech[type], tech_version = tech[version]
| summarize process_count = count(), by: {tech_type, tech_version}
| sort process_count desc

一般的なテクノロジー： Java、Node.js、Python、.NET、データベース、Web サーバー、メッセージングシステム

→ バージョンコンプライアンスの確認については、references/inventory-discovery.md を参照してください。

5. ポートによるサービス検出

セキュリティとインベントリ管理のため、リスニングポートをサービスに対応付けます。

smartscapeNodes "PROCESS"
| fieldsAdd process.listen_ports, dt.process_group.detected_name
| filter isNotNull(process.listen_ports) and arraySize(process.listen_ports) > 0
| expand listen_port = process.listen_ports
| summarize process_count = count(), by: {listen_port, dt.process_group.detected_name}
| sort toLong(listen_port) asc
| limit 50

既知のポート： 80（HTTP）、443（HTTPS）、22（SSH）、3306（MySQL）、5432（PostgreSQL）

→ 包括的なポートマッピングについては、references/inventory-discovery.md を参照してください。

6. コンテナと Kubernetes の監視

コンテナの分布と K8s のワークロードタイプを追跡します。

smartscapeNodes "CONTAINER"
| fieldsAdd k8s.cluster.name, k8s.namespace.name, k8s.workload.kind
| summarize container_count = count(), by: {k8s.cluster.name, k8s.workload.kind}
| sort k8s.cluster.name, container_count desc

ワークロードタイプ： deployment、daemonset、statefulset、job、cronjob

注： コンテナイメージ名／バージョンは smartscape では利用できません。

→ K8s のバージョン追跡については、references/container-monitoring.md を参照してください。
→ コンテナのライフサイクルについては、references/container-monitoring.md を参照してください。

7. コストの帰属とチャージバック

コストセンター別にインフラストラクチャのコストを算出します。

smartscapeNodes "HOST"
| fieldsAdd dt.cost.costcenter, host.logical.cpu.cores, host.physical.memory
| filter isNotNull(dt.cost.costcenter)
| fieldsAdd memory_gb = toDouble(host.physical.memory) / 1024 / 1024 / 1024
| summarize 
    host_count = count(),
    total_cores = sum(toLong(host.logical.cpu.cores)),
    total_memory_gb = sum(memory_gb),
    by: {dt.cost.costcenter}
| sort total_cores desc

→ 製品レベルのコスト追跡については、references/inventory-discovery.md を参照してください。

8. インフラストラクチャの健全性の相関分析

ホストとプロセスのメトリクスを相関させ、レイヤーを横断して分析します。

timeseries {
  host_cpu = avg(dt.host.cpu.usage),
  host_memory = avg(dt.host.memory.usage),
  process_cpu = avg(dt.process.cpu.usage)
}, by: {dt.smartscape.host, dt.smartscape.process}
| fieldsAdd
    host_name = getNodeName(dt.smartscape.host),
    process_name = getNodeName(dt.smartscape.process)
| filter arrayAvg(host_cpu) > 70
| sort arrayAvg(host_cpu) desc

健全性スコア： いずれかのリソースが 90% を超えると重大、80% を超えると警告

→ 複数リソースの飽和検出については、references/host-metrics.md を参照してください。

9. OneAgent インベントリ

OneAgent の監視モード、バージョン、またはクラウドリージョン別にホストをカウントして一覧表示します。

ONEAGENT エンティティ： OneAgent は独立した smartscape エンティティタイプ（smartscapeNodes "ONEAGENT"）です。monitors エッジをたどって HOST から逆方向に移動するとアクセスできます（エッジは ONEAGENT → HOST 方向のため、HOST→ONEAGENT は direction: backward です）。

主な ONEAGENT フィールド：

• dt.agent.monitoring_mode — 監視範囲のレベル：FULL_STACK ／ INFRASTRUCTURE ／ DISCOVERY
• dt.agent.module.version — インストール済みバージョン文字列。例：1.347.0.20260809-172428

監視モード別のカウント：

smartscapeNodes "HOST"
| traverse edgeTypes: {monitors}, targetTypes: {ONEAGENT}, direction: backward
| fieldsAdd oa_mode = `dt.agent.monitoring_mode`
| summarize host_count = count(), by: {oa_mode}
| sort host_count desc

エージェントバージョン別のカウント：

smartscapeNodes "HOST"
| traverse edgeTypes: {monitors}, targetTypes: {ONEAGENT}, direction: backward
| fieldsAdd oa_version = `dt.agent.module.version`
| summarize host_count = count(), by: {oa_version}
| sort host_count desc

モードとバージョンの組み合わせ（アップグレード計画用）：

smartscapeNodes "HOST"
| traverse edgeTypes: {monitors}, targetTypes: {ONEAGENT}, direction: backward
| fieldsAdd oa_mode = `dt.agent.monitoring_mode`, oa_version = `dt.agent.module.version`
| summarize host_count = count(), by: {oa_mode, oa_version}
| sort host_count desc

監視モード： FULL_STACK（コードレベルの完全な監視とインフラストラクチャ）、INFRASTRUCTURE（コードレベルの監視は行わず、インフラストラクチャのメトリクスのみ）、DISCOVERY（トポロジーの検出と基本的なホスト監視）

→ モード／バージョン別のホスト一覧については、references/inventory-discovery.md を参照してください。

---

応答の作成

ユーザーがデータの取得や DQL クエリ（例：「CPU 使用率が高いホストを表示して」）を求めた場合、結果とあわせてDQL クエリを応答に含めてください。ユーザーはクエリを確認して再利用したいと考えています。クエリは結果を得るための手段にとどまらず、提供物の一部です。

ユーザーが分析（異常検出、予測、季節性分析）を求めた場合、分析結果が提供物です。次の点を意識して、結果をわかりやすく提示してください。

• データ収集上の問題より、メトリクスレベルの結果を優先してください。分析ツールが実際の異常とともにデータの欠落を報告した場合は、ユーザーが尋ねたメトリクスの挙動を最初に示し、欠落については補足情報として触れてください。
• getNodeName(dt.smartscape.host) または get-entity-name ツールを使って、ID だけでなくホスト名を含めてください。
• 分析した期間と、使用したツール／パラメーターを明記してください。

---

分析ワークフロー

ホストメトリクスのクエリは、異常検出、予測、季節性分析などの分析ツールへの入力としてよく使用されます。このスキルは適切な DQL クエリの作成に役立ちます。実際の分析は専用ツールが実行します。

異常検知とパターン分析

ユーザーがホストメトリクスの「異常な動作」、「異常」、「急増」、「急激な変化」について尋ねた場合のワークフローは次のとおりです。

1. このスキルのパターンを使って時系列クエリを作成します
2. 適切な分析ツール（異常検知ツール、新規性検知ツール）に渡します

検知ツールの選択：

• adaptive-anomaly-detector — ユーザーが「急増」、「急激な変化」、「通常値を超えた値」、「突然の上昇」など、大きさについて尋ねた場合に使用します。「このメトリクスは予想外のしきい値を超えましたか？」に答え、アラートの継続時間とピーク値を報告します。
• timeseries-novelty-detection — ユーザーが「異常なパターン」、「何かが変わった」、「傾向」、「新しい動作」など、動作の変化について尋ねた場合に使用します。特定のしきい値を超えたことを示唆せずに、「シグナルの形状は変化しましたか？」に答えます。

異常検知結果の応答形式： タイムスタンプと値に加えて、ホストの名前（getNodeName(dt.smartscape.host) または get-entity-name で解決）とホストのエンティティ IDの両方を含めてください。エンティティ ID だけではユーザーにとって意味が分からず、名前だけでは後続のクエリを実行できません。

新規性タイプの選択ルール： 新規性検知を使用する場合、デフォルトでは analysisNoveltyType を [SPIKE, CHANGE_IN_VALUES, TREND_IN_VALUES] のみに設定します。ユーザーがデータギャップや監視範囲について明示的に尋ねない限り、GAP_WITH_MISSING_VALUES と CHANGE_IN_MISSING_VALUES は除外してください。データギャップはインフラストラクチャの問題であり、メトリクスの動作異常ではありません。ユーザーが CPU やメモリのパターンについて尋ねている際に報告するのは不適切です。

分析ツール向けのクエリでは、単一の集約メトリクスと適切な時間範囲を指定したシンプルな timeseries 形式を使用してください。

timeseries avg(dt.host.cpu.idle), by: {dt.smartscape.host}

timeseries avg(dt.host.memory.usage), by: {dt.smartscape.host}

データを絞り込むフィルターやフィールド変換の追加は避けてください。分析ツールは、完全な時系列データを最も効果的に処理できます。

予測

ユーザーがホストメトリクスの「予測」、「将来予測」、「将来の推定」を求めた場合：

1. 十分な履歴データ（短期なら 7d、より長期の予測なら 30d など）を使って、時系列クエリを作成します
2. 希望する予測期間を指定して、予測ツールに渡します

予測期間（どれだけ先まで予測するか）と履歴ウィンドウ（モデルのトレーニングに使う過去データの量）は独立しています。「次の 2 時間を予測して」というリクエストでは、予測期間を 2h に設定しますが、振り返り期間については何も指定していません。予測期間がどれほど短くても、履歴データは必ず 7 日分以上使用してください。トレーニングデータの点が少なすぎると、予測モデルは失敗し、過去の生データにフォールバックします。

timeseries avg(dt.host.cpu.usage), by: {dt.smartscape.host}

季節性の検知

ユーザーが「季節性」、「週次パターン」、「繰り返し発生する動作」について尋ねた場合：

1. 長めの時間範囲（週次なら 14d 以上、月次なら 30d 以上）を使用します
2. 季節ベースライン異常検知ツールに渡します

季節性分析の応答形式： 結果を提示する際は、次の内容を含めてください。

• 季節性の異常が検知されたかどうか（はい／いいえ）
• 使用した分析期間とパラメーター
• 影響を受けたホストごとに、ホスト名（ID だけでなく）、違反のタイムスタンプ、違反件数、ベースライン値と実測値、上限値と下限値
• 複数のホストが関係する場合は、ホストごとに結果をまとめます

対象範囲の境界 — サービスレベルとホストレベルのメトリクス

このスキルの対象は、ホストとプロセスのインフラストラクチャメトリクスのみです。ユーザーがサービスレベルのメトリクス（リクエストレート、レスポンスタイム、エラーレート、1 分あたりのサービス呼び出し数、スループット）について尋ねた場合、予測や異常検知についての質問であっても、代わりに dt-obs-services を使用してください。

次の内容は dt-obs-services に案内してください： 「1 分あたりのサービス呼び出し数」、「リクエストレート」、「サービスごとのレスポンスタイム」、「エンドポイントごとのエラーレート」、「サービススループットの予測」。

---

よく使うクエリパターン

パターン 1：Smartscape の探索

smartscapeNodes を使用してエンティティを探索し、分類します。

smartscapeNodes "HOST"
| fieldsAdd <attributes>
| filter <conditions>
| summarize <aggregations>

パターン 2：時系列パフォーマンス

timeseries を使用して、時間経過に伴うメトリクスを分析します。

timeseries metric = avg(dt.host.<metric>), by: {dt.smartscape.host}
| fieldsAdd <calculations>
| filter <thresholds>

パターン 3：レイヤー間の相関

ホストとプロセスのメトリクスを相関させます。

timeseries {
  host_cpu = avg(dt.host.cpu.usage),
  process_cpu = avg(dt.process.cpu.usage)
}, by: {dt.smartscape.host, dt.smartscape.process}

パターン 4：ルックアップによるエンティティのエンリッチメント

エンティティ属性でデータをエンリッチメントします。lookup の後は、lookup. プレフィックスを付けてフィールドを参照します。

timeseries cpu = avg(dt.host.cpu.usage), by: {dt.smartscape.host}
| lookup [
    smartscapeNodes HOST
    | fields id, cpuCores, memoryTotal
  ], sourceField:dt.smartscape.host, lookupField:id
| fieldsAdd cores = lookup.cpuCores, mem_gb = lookup.memoryTotal / 1024 / 1024 / 1024

---

タグとメタデータ

重要な注意事項

• 汎用の tags フィールドは、スマートスケープクエリでは設定されません
• 固有のタグフィールドを使用します：tags:azure[*]、tags:environment
• カスタムメタデータを使用します：host.custom.metadata[*]

使用可能なタグ

• Azure タグ： tags:azure[dt_owner_team]、tags:azure[dt_cloudcost_capability]
• 環境： tags:environment
• カスタムメタデータ： host.custom.metadata[OperatorVersion]、host.custom.metadata[Cluster]
• コスト： dt.cost.costcenter、dt.cost.product

→ タグの完全なリファレンスについては、references/inventory-discovery.md を参照してください。

---

クラウド固有の属性

AWS

• cloud.provider == "aws"
• aws.region、aws.availability_zone、aws.account.id
• aws.resource.id、aws.resource.name
• aws.state（running、stopped、terminated）

Azure

• cloud.provider == "azure"
• azure.location、azure.subscription、azure.resource.group
• azure.status、azure.provisioning_state
• azure.resource.sku.name（VM のサイズ）

GCP

• cloud.provider == "gcp"
• gcp.region、gcp.zone、gcp.location
• gcp.project.id（ドットが 2 つあることに注意）
• gcp.resource.type（例：gce_instance）、gcp.asset.type（例：compute.googleapis.com/Instance）

Kubernetes

• k8s.cluster.name、k8s.cluster.uid
• k8s.namespace.name、k8s.node.name、k8s.pod.name
• k8s.workload.name、k8s.workload.kind

→ マルチクラウド分析については、references/inventory-discovery.md を参照してください。

---

ベストプラクティス

1. レイテンシにはパーセンタイル（p95、p99）、上限には max()、傾向には avg() を使用します
2. 複数レベルのしきい値を設定します（警告 80%、重大 90%）
3. パイプラインの早い段階でフィルタリングし、| limit N で結果を制限します
4. エンリッチメント（lookup）の前に集計します
5. 人が読みやすいホスト名には getNodeName(dt.smartscape.host) を、プロセス名には getNodeName(dt.smartscape.process) を使用します
6. バイトを GB に変換します：/ 1024 / 1024 / 1024。round(value, decimals: 1) で丸めます

時間枠： リアルタイム：5～15 分 | 傾向：1～7 日 | キャパシティプランニング：30～90 日

制限事項

• dt.host.cpu.iowait は Linux でのみ使用できます
• 汎用の tags フィールドはスマートスケープでは設定されません（固有のタグ名前空間を使用してください）
• コンテナイメージ名はスマートスケープでは使用できません

---

トラブルシューティング

問題	原因	解決策
smartscapeNodes "HOST" でホストが返されない	時間範囲が設定されていない、または OneAgent がデプロイされていない	OneAgent がインストールされていることを確認し、クエリに時間範囲を追加します
tags フィールドが常に空	汎用の tags はスマートスケープで設定されない	固有のタグ名前空間を使用します：tags:azure[*]、tags:environment、dt.cost.costcenter
バイト単位のメモリ値が読みづらい	メトリクスの生の単位がバイト	1024 / 1024 / 1024 で割り、round(value, decimals: 1) を使用します
dt.host.cpu.iowait でデータが返されない	このメトリクスは Linux 専用	os.type を確認します。iowait は Windows、AIX、Solaris では使用できません
コンテナイメージ名が見つからない	スマートスケープでは使用できない	イメージの詳細には k8s.object の解析を使用します。dt-obs-kubernetes スキルを参照してください
process.software_technologies が空	プロセスがディープコードレベルモニタリングの対象ではない	プロセスグループで OneAgent のディープモニタリングが有効になっていることを確認します
dt.agent.monitoring_mode が常に null	フィールド名にはドットではなくアンダースコアを使用	dt.agent.monitoring_mode を使用します。dt.agent.monitoring.mode（ドット）は常に null を返します
gcp.project.id が常に null	誤ったフィールド名を使用	GCP プロジェクトではドットを 2 つ使用します：gcp.project.id。アンダースコアを使った gcp.project_id は常に null を返します

---

参照情報を読み込むタイミング

このスキルでは段階的な開示を採用しています。ユースケースの 80％ は、まずここから始めてください。詳細な仕様が必要な場合は、参照ファイルを読み込んでください。

次の場合は host-metrics.md を読み込んでください：

• CPU の内訳（ユーザー、システム、iowait、steal）を分析する
• メモリ負荷とスワップ使用量を調査する
• ディスク I/O のレイテンシーをトラブルシューティングする
• ネットワークのパケット損失やエラーを診断する

次の場合は process-monitoring.md を読み込んでください：

• プロセスレベルの I/O パターンを分析する
• TCP 接続の品質を調査する
• リソース枯渇（ファイル記述子、スレッド）を検出する
• GC の停止時間を追跡する

次の場合は container-monitoring.md を読み込んでください：

• コンテナのライフサイクルと入れ替わりを分析する
• Kubernetes のバージョン分布を追跡する
• OneAgent オペレーターのバージョンを管理する
• K8s クラスターのアップグレードを計画する

次の場合は inventory-discovery.md を読み込んでください：

• ポート検出を通じてセキュリティ監査を実施する
• コストの帰属とチャージバックを実装する
• データ品質とメタデータの完全性を検証する
• マルチクラウドインフラストラクチャを管理する
• OneAgent のモードやバージョンでホストを一覧表示または絞り込む

---

参照情報

• host-metrics.md - ホストの CPU、メモリ、ディスク、ネットワークの詳細なモニタリング
• process-monitoring.md - プロセスレベルの CPU、メモリ、I/O、ネットワーク分析
• container-monitoring.md - コンテナのインベントリ、Kubernetes のバージョン、オペレーターの管理
• inventory-discovery.md - ホスト／プロセスの検出、テクノロジーのインベントリ、コストの帰属、データ品質

---