dt-obs-services

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

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

---

主な機能

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

メトリクスベースの時系列クエリを使用して、サービスの レート、エラー、継続時間 を監視します。

主なメトリクス：

• 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 min、一般的な分析では 2h	一般的な運用期間に合致

例：しきい値違反の依頼

1. create-dql を使用して、dt.smartscape.service でグループ化した avg(dt.service.request.response_time) の時系列クエリを作成します
2. しきい値 = 1000000（µs）、alertCondition = ABOVE を指定して、クエリを static-threshold-analyzer に渡します
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
「goroutines」「Go GC」「スケジューラー」	ランタイム固有（Go）	go.md

クエリ構築パターン

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

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

2. スパンベース（スパンの取得）

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

3. 比較クエリ

• ベースラインとの比較には append を使用します
• 時間をずらしたベースラインには shift: -15m を使用します
• 例: パフォーマンス低下の検出

レスポンス構築のガイドライン

必ず含めてください：

1. メトリクス名 - 明確なメトリクス識別子
2. 集計方法 - データの集計方法（avg、sum、percentile）
3. グループ化 - 使用するディメンション（dt.service.name、k8s.workload.name など）
4. 単位変換 - 適切な場合はマイクロ秒をミリ秒に変換します
5. フィルタリング - 関連するしきい値や条件

ランタイム固有の内容を参照する場合：

• まず、ユーザーの技術スタックを確認します
• 関連するランタイムのクエリのみを提供します（6 種類すべてのランタイムを提示して情報過多にしないでください）
• ランタイム固有のメトリクスを説明します（例：「OPcache hit ratio」は PHP オペコードキャッシュの効率を測定します）

---

一般的なワークフロー

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

1. Check response time (RED metrics)
2. Check error rate (RED metrics)
3. Check traffic patterns (RED metrics)
4. If runtime-specific issues suspected → Load runtime-specific reference

ワークフロー：SLA モニタリング

1. Define SLA criteria (e.g., < 3s response time AND < 1% error rate)
2. Use span-based query for custom SLA logic
3. Calculate compliance percentage
4. Filter non-compliant services

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

1. Check mesh response time
2. Compare mesh vs direct performance
3. Calculate mesh overhead
4. Analyze mesh failure rates

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

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 ランタイムモニタリング