アプリケーション サービス スキル

DQL を使用してアプリケーション サービスのパフォーマンス、ヘルス、ランタイム固有のメトリクスを監視します。

---

コア機能

1. サービス パフォーマンス (RED メトリクス)

メトリクスベースの時系列クエリを使用してサービスの Rate（レート）、Errors（エラー）、Duration（実行時間） を監視します。

主要メトリクス:

• dt.service.request.response_time - レスポンス タイム（マイクロ秒）
• dt.service.request.count - リクエスト数
• dt.service.request.failure_count - 失敗リクエスト数

一般的な使用例:

• レスポンス タイム監視（平均、p50、p95、p99）
• エラー率の追跡とスパイク検出
• トラフィック分析（スループット、ピーク、増加）
• パフォーマンス低下の検出
• マルチクラスター比較

クイック例:

timeseries {
  p95 = percentile(dt.service.request.response_time, 95),
  total_requests = sum(dt.service.request.count),
  failures = sum(dt.service.request.failure_count)
}, by: {dt.service.name}
| fieldsAdd p95_ms = p95[] / 1000, error_rate_pct = (failures[] * 100.0) / total_requests[]

→ 詳細なクエリについて: references/service-metrics.md を参照

2. 高度なサービス分析

複雑なシナリオに対応するための柔軟なフィルタリングとカスタム集約が必要なスパンベースのクエリ。

使用例:

• カスタム閾値を使用した SLA コンプライアンス追跡
• サービス ヘルス スコアリング（多次元）
• オペレーション/エンドポイントレベルのパフォーマンス分析
• カスタム エラー分類
• エラー詳細を含む障害パターン検出

クイック例:

fetch spans, from: now() - 1h | filter request.is_root_span == true
| fieldsAdd meets_sla = if(request.is_failed == false AND duration < 3s, 1, else: 0)
| summarize total = count(), sla_compliant = sum(meets_sla), by: {dt.service.name}
| fieldsAdd sla_compliance_pct = (sla_compliant * 100.0) / total

→ 詳細なクエリについて: references/service-metrics.md を参照

3. サービス メッセージング メトリクス

メッセージベースのサービス通信（キュー、トピック）を監視します。

主要メトリクス:

• dt.service.messaging.publish.count - キューまたはトピックに送信されたメッセージ
• dt.service.messaging.receive.count - キューまたはトピックから受信したメッセージ
• dt.service.messaging.process.count - 正常に処理されたメッセージ
• dt.service.messaging.process.failure_count - 処理に失敗したメッセージ

使用例:

• メッセージ スループット監視（発行/受信レート）
• メッセージ処理の失敗追跡
• キュー/トピックのヘルス分析
• コンシューマー ラグの検出（発行レートと受信レートの比較）

クイック例:

timeseries {
  published = sum(dt.service.messaging.publish.count),
  received = sum(dt.service.messaging.receive.count),
  processed = sum(dt.service.messaging.process.count),
  failed = sum(dt.service.messaging.process.failure_count)
}, by: {dt.service.name}

→ 詳細なクエリについて: references/service-metrics.md を参照

4. サービス メッシュ監視

サービス メッシュのイングレス パフォーマンスとオーバーヘッドを監視します。

主要メトリクス:

• dt.service.request.service_mesh.response_time - メッシュ レスポンス タイム（マイクロ秒）
• dt.service.request.service_mesh.count - メッシュ リクエスト数
• dt.service.request.service_mesh.failure_count - メッシュ 障害数

使用例:

• メッシュ対直接パフォーマンス比較
• メッシュ オーバーヘッド計算
• メッシュ 障害分析
• gRPC トラフィック監視
• マルチクラスター メッシュ パフォーマンス

クイック例:

timeseries {
  direct_p95 = percentile(dt.service.request.response_time, 95),
  mesh_p95 = percentile(dt.service.request.service_mesh.response_time, 95)
}, by: {dt.service.name}
| fieldsAdd mesh_overhead_ms = (mesh_p95[] - direct_p95[]) / 1000

→ 詳細なクエリについて: references/service-metrics.md を参照

5. ランタイム固有の監視

テクノロジー固有のランタイム パフォーマンスとリソース使用量メトリクス。

Java/JVM - references/java.md

• メモリ: ヒープ、プール、メタスペース
• GC: 影響、一時停止、頻度、ポーズ タイム
• スレッド: 数の監視、リーク検出
• クラス: ロード、アンロード、成長

Node.js - references/nodejs.md

• イベント ループ: 利用率、アクティブ ハンドル
• V8 ヒープ: 使用メモリ、合計メモリ
• GC: コレクション タイム、一時停止
• プロセス: RSS メモリ

.NET CLR - references/dotnet.md

• メモリ: 世代別消費量
• GC: コレクション数、一時停止時間
• スレッド プール: スレッド、キューイング作業
• JIT: コンパイル タイム

Python - references/python.md

• スレッド: アクティブ スレッド数
• ヒープ: 割り当てブロック
• GC: 世代別コレクション、ポーズ タイム
• オブジェクト: 収集、回収不可

PHP - references/php.md

• OPcache: ヒット率、メモリ、再起動
• GC: 有効性、期間
• JIT: バッファ使用量
• インターン文字列: 使用量、バッファ

Go - references/go.md

• ゴルーチン: 数、リーク検出
• GC: 一時停止、コレクション タイム
• メモリ: 状態別ヒープ、コミット済み
• スケジューラー: ワーカー スレッド、キュー サイズ
• CGo: コール頻度

---

このスキルを使用する場合

✅ 以下の場合に使用:

• サービス パフォーマンスの監視（レスポンス タイム、エラー、トラフィック）
• SLA コンプライアンスの計算
• サービス メッシュ パフォーマンスの分析
• メッセージング スループットと処理障害の監視
• ランタイム固有の問題（GC、メモリ、スレッド）のトラブルシューティング
• マルチクラスター サービス比較
• オペレーション/エンドポイントレベルの分析

❌ 以下の場合は使用しない:

• インフラストラクチャ メトリクス（インフラストラクチャ スキルを使用）
• ログ分析（ログ スキルを使用）
• 分散トレーシング ワークフロー（トレース/スパン スキルを使用）
• データベース パフォーマンス（データベース スキルを使用）
• 製品ドキュメントまたは構成方法に関する質問 → ask-dynatrace-docs を使用

---

エージェント指示

最初に実行、後で改良

ユーザーが分析を要求したとき（閾値チェック、異常検出、パフォーマンス比較など）、合理的なデフォルト値で直ちに実行してください。ユーザーが合理的に想定できるパラメータ値について質問しないでください。

その理由: 分析ツール（例：static-threshold-analyzer）は、閾値値やサービス スコープなどの特定の入力を必要とします。ユーザーは結果を期待しており、パラメータ インタビューではありません。合理的なデフォルト値を選択し、応答で明確に述べて、ユーザーが改良できるようにしてください。

指定されていない場合のデフォルト値:

パラメータ	デフォルト	理由
レスポンス タイム閾値	1000 ms（= メトリクスのベース単位で 1,000,000 µs）	一般的な SLA 境界
サービス スコープ	すべてのサービス	最も関連性のある違反を表示
タイムフレーム	リクエストから、または閾値チェックの過去 30 分、一般分析では 2 時間	典型的なオペレーション ウィンドウに一致

例: 閾値違反リクエスト

1. create-dql を使用して avg(dt.service.request.response_time) の時系列クエリを dt.smartscape.service でグループ化して構築
2. クエリを static-threshold-analyzer に閾値 = 1000000（µs）、alertCondition = ABOVE で渡す
3. get-entity-name を使用してエンティティ ID を名前に解決
4. サービス名、タイムスタンプ、値、期間を含む違反を提示

ユーザー フレーズの解読: 「固定閾値」、「一つの閾値」、または「制限」というようなフレーズは、ユーザーが既に知っている特定の数字ではなく、分析のタイプ（静的閾値チェック）に名前を付けています。「固定」は静的カットオフを動的またはシーズナル ベースラインと区別します。これらのフレーズが見られる場合、上の表から 1000 ms デフォルトを適用し、結果を提示してください。その後、ユーザーはデフォルトが意図に一致しない場合は改良できます。

スコープ境界

このスキルはサービス パフォーマンス メトリクスとランタイム監視のみをカバーしています。ユーザーが製品ドキュメントまたは構成に関する質問をする場合（例：「カスタム センサーを追加するにはどうすればよいですか？」、「サービス検出を構成するにはどうすればよいですか？」）、代わりに ask-dynatrace-docs を使用してください。このスキルには構成方法が含まれていません。

ユーザーの意図を理解する

ユーザー質問を機能にマッピングします:

ユーザー リクエスト	使用機能	主要ファイル
「サービス パフォーマンス」、「レスポンス タイム」、「エラー率」	サービス パフォーマンス（RED）	service-metrics.md
「SLA 追跡」、「ヘルス スコアリング」	高度なサービス分析	service-metrics.md
「サービス メッシュ」、「Istio」、「Linkerd」、「メッシュ オーバーヘッド」	サービス メッシュ監視	service-metrics.md
「メッセージング」、「キュー」、「トピック」、「発行」、「コンシューマー」	サービス メッセージング メトリクス	service-metrics.md
「JVM GC」、「Java メモリ」、「ヒープ」	ランタイム固有（Java）	java.md
「Node.js イベント ループ」、「V8 ヒープ」	ランタイム固有（Node.js）	nodejs.md
「.NET CLR」、「GC 世代」	ランタイム固有（.NET）	dotnet.md
「Python GC」、「スレッド数」	ランタイム固有（Python）	python.md
「OPcache」、「PHP GC」	ランタイム固有（PHP）	php.md
「ゴルーチン」、「Go GC」、「スケジューラー」	ランタイム固有（Go）	go.md

クエリ構築パターン

1. メトリクスベース（時系列）

• 使用対象: 標準監視、ダッシュボード、アラート
• パターン: timeseries <metric> = <aggregation>(<metric_name>), by: {dimensions}
• ファイル: service-metrics.md、すべてのランタイム固有ファイル

2. スパンベース（fetch spans）

• 使用対象: 複雑なフィルタリング、カスタム ロジック、詳細分析
• パターン: fetch spans | filter request.is_root_span == true | fieldsAdd ... | summarize ...
• ファイル: service-metrics.md（Advanced Service Analysis セクション）

3. 比較クエリ

• ベースライン比較には append を使用
• shift: -15m を時間シフト ベースラインに使用
• 例: パフォーマンス低下検出

応答構築ガイドライン

常に以下を含めます:

1. メトリクス名 - クリアなメトリクス識別子
2. 集約 - データの集約方法（平均、合計、パーセンタイル）
3. グループ化 - 使用される次元（dt.service.name、k8s.workload.name など）
4. 単位変換 - マイクロ秒をミリ秒に適切に変換
5. フィルタリング - 関連する閾値または条件

ランタイム固有のコンテンツを参照する場合:

• 確認 ユーザーのテクノロジー スタック
• 提供 関連するランタイム クエリのみ（6 つすべてのランタイムで圧倒しない）
• 説明 ランタイム固有のメトリクス（例：「OPcache ヒット率」は PHP オペコード キャッシュの効率を測定）

---

一般的なワークフロー

ワークフロー: サービス ヘルス チェック

1. レスポンス タイムをチェック（RED メトリクス）
2. エラー率をチェック（RED メトリクス）
3. トラフィック パターンをチェック（RED メトリクス）
4. ランタイム固有の問題が疑われる場合 → ランタイム固有の参照を読み込む

ワークフロー: SLA 監視

1. SLA 基準を定義（例：< 3s レスポンス タイム AND < 1% エラー率）
2. カスタム SLA ロジックのためのスパンベースのクエリを使用
3. コンプライアンス パーセンテージを計算
4. 非準拠サービスをフィルタリング

ワークフロー: サービス メッシュ分析

1. メッシュ レスポンス タイムをチェック
2. メッシュ対直接パフォーマンスを比較
3. メッシュ オーバーヘッドを計算
4. メッシュ 障害率を分析

ワークフロー: ランタイム トラブルシューティング

1. テクノロジー スタックを特定 → ランタイム固有の参照を読み込む
2. メモリ/GC メトリクスをチェック → スレッド/ゴルーチン → ランタイム機能

---

トラブルシューティング

問題	原因	解決策
レスポンス タイムの値が大きすぎる	メトリクスはマイクロ秒単位	1000 で除算してミリ秒に変換
サービス メッシュ メトリクスにデータがない	サービス メッシュが構成されていない	メッシュ サイドカー インジェクションが有効になっていることを確認
ランタイム メトリクスが不足している	間違ったテクノロジーまたは OneAgent がない	ランタイムがサポートされており OneAgent がアクティブであることを確認
dt.smartscape.service が SmartscapeId を返す（名前ではなく）	エンティティ名の解決が必要	getNodeName(dt.smartscape.service) を使用
エラー率が常にゼロ	間違った障害メトリクスを使用	dt.service.request.failure_count を使用（カスタム フィールドではなく）

---

参照

コア サービス監視:

• references/service-metrics.md - 完全な RED メトリクス、SLA 追跡、サービス メッシュ クエリ

ランタイム固有の監視:

• references/java.md - Java/JVM 監視
• references/nodejs.md - Node.js 監視
• references/dotnet.md - .NET CLR 監視
• references/python.md - Python 監視
• references/php.md - PHP 監視
• references/go.md - Go ランタイム監視