dt-obs-log-semantic-mapping について
監査ログ連携向けに、Dynatrace のセマンティックマッピングを提案・検証するスキルです。取り込み済みログやテナントの実データを調べ、raw content 内に埋もれたフィールドと OpenPipeline の抽出ルール案を確認します。
主な機能
- 01監査ログのフィールドマッピング提案
- 02取り込み済みログの静的検証
- 03テナント実データによる検証
- 04content 内に埋もれたフィールドの特定
- 05OpenPipeline 抽出ルールの提案
活用シーン
- 01ベンダー監査ログを Dynatrace フィールドに対応付け
- 02必須フィールドとセマンティック上の不足を確認
- 03テナントログでマッピングを検証
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ dynatrace/ dynatrace-for-ai --skill dt-obs-log-semantic-mappingインストール後、Claude Code で/dt-obs-log-semantic-mappingを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/data-model-notes.mdmapping-workflow.mdopenpipeline-constraints.mdreport-format.mdruntime-validation.mdvalidation-rules.mdsamples/audit-logs.jsonhttp-logs.json詳細
dt-obs-log-semantic-mapping
監査ログ連携用のセマンティック辞書に準拠したマッピングを作成・検証します。
目的
ユーザーが以下を求めている場合に、このスキルを使用します。
- 提案: ベンダーの生の監査ログペイロードから、Dynatrace の
fetch logsフィールドへのマッピングを提案する(ワークフロー A)。 - 検証: 貼り付けられた取り込み済みログイベントに対してマッピングを検証する(ワークフロー B1 — 静的)。
- 検証: ライブテナントアクセスを介して実際のテナントデータを検証する(ワークフロー B2 — 実行時:
log.sourceでログを取得し、その結果に対して B1 を実行)。
ログクラス
| クラス | 説明 | 主要な名前空間 | ソースの例 |
|---|---|---|---|
authentication | ログイン、ログアウト、MFA、トークン | audit.*、actor.*、browser.*、device.* | CyberArk、Okta、Azure SignInLogs |
authorization | アクセス判断、権限の変更 | audit.*、actor.*、object.* | CyberArk、Okta |
user_action | プラットフォームリソースに対する CRUD | audit.*、actor.*、object.*、product.* | Okta、GitHub、Sonatype |
http | HTTP リクエスト/レスポンス(WAF、ネットワークデバイス) | http.*、url.*、server.*、geo.*、client.* | Akamai SIEM、Cloudflare |
ワークフロー
| モード | 入力 | ソース |
|---|---|---|
| ワークフロー A — マッピングの提案 | ベンダーの生ログペイロード | references/mapping-workflow.md § Workflow A |
| ワークフロー B1 — 静的検証 | 貼り付けられた取り込み済みログイベント | references/mapping-workflow.md § Workflow B1 |
| ワークフロー B2 — 実行時検証 | log.source の値 + ライブテナントアクセス | references/runtime-validation.md — ログを取得してから B1 を実行 |
主な概念
content フィールドへの埋没: 検証で最も重要な項目です。content(ベンダーの生ペイロード)内にあり、トップレベルのセマンティック属性に昇格できるにもかかわらず、昇格されていないフィールドを指します。このスキルでは常に、埋没しているフィールドと昇格済みのフィールドを一覧化し、不足を解消するための OpenPipeline 抽出ルールを提案します。
前提条件: OpenPipeline プロセッサの抽出ルールを提案する場合は、まず
dt-dql-essentialsスキルを読み込んでください。OpenPipeline プロセッサでは DQL 関数(parse、fieldsAdd、splitStringなど)を使用します。DQL 以外の構文を使うと、無効なルールになります。
疎なマッピングも有効です: GitHub や Sonatype などの連携では、コアフィールドのみが設定されている場合があります。必須の最小フィールドは timestamp、log.source、content、loglevel、audit.action、audit.identity です。
参考資料
references/data-model-notes.md— ログ SD フィールドの分類、audit 名前空間、列挙値、サンプルから導出したパターン、既知の不一致references/mapping-workflow.md— インテークチェックリスト、ワークフロー A および B1 の手順、content フィールド分析、フィールドの優先順位references/validation-rules.md— 必須フィールド、content/列挙値/型のルール、不一致の重大度references/openpipeline-constraints.md— OpenPipeline のプロセッサに関するコマンド/関数/演算子/マッチャーの制約、parseJsonが利用できない場合の代替手段parse→fieldsFlatten、配列の型変換に使う反復演算子references/report-format.md— マッピング表、差分表、OpenPipeline の概要、検証サマリーテンプレートreferences/runtime-validation.md— ワークフロー B2:ライブレコードを取得してから B1 を実行samples/audit-logs.json— マッピング済みサンプル:CyberArk、Okta、Azure SignInLogs、Sonatype、GitHubsamples/http-logs.json— マッピング済みサンプル:Akamai SIEM(WAF/HTTP クラス)- Dynatrace ログセマンティック辞書