dt-obs-log-semantic-mapping

Suggest and validate semantic dictionary (SD) mappings for audit log integrations using raw vendor log payloads or live ingested events. Use when: mapping a vendor audit log feed, authentication logs, user activity logs to the Dynatrace SD; checking required semantic fields; proposing OpenPipeline p

By dynatrace · 816 installs

npx skills add dynatrace/dynatrace-for-ai --skill dt-obs-log-semantic-mapping

Source repository · Upstream listing

dt obs log semantic mapping Build and validate semantic dictionary aligned mappings for audit log integrations. Purpose Use this skill when a user wants to: Suggest a mapping from a raw vendor audit log payload to Dynatrace fetch logs fields (Workflow A). Validate a mapping against a pasted ingested log event (Workflow B1 — static). Validate against live tenant data via live tenant access (Workflow B2 — runtime: fetches logs by log.source , then runs B1 on the result). Log Classes Class Description Key namespaces Example sources authentication Login, logout, MFA, token audit. , actor. , browser. , device. CyberArk, Okta, Azure SignInLogs authorization Access decisions, permission changes audit. , actor. , object. CyberArk, Okta user action CRUD on platform resources audit. , actor. , object. , product. Okta, GitHub, Sonatype http HTTP request/response (WAF, network devices) http. , url. , server. , geo. , client. Akamai SIEM, Cloudflare Workflows Mode Input Source Workflow A — Suggest mapping Raw vendor log payload references/mapping workflow.md § Workflow A Workflow B1 — Static validation Pasted ingested log event references/mapping workflow.md § Workflow B1 Workflow B2 — Runtime validation log.source value + live tenant access references/runtime validation.md — fetches logs, then runs B1 Key Concepts Content field burial: The primary validation concern. Fields in content (the raw vendor payload) that could be promoted to top level semantic attributes but are not. The skill always inventories buried vs promoted fields and proposes OpenPipeline extraction rules to fix gaps. Prerequisite: When proposing OpenPipeline processor extraction rules, load the dt dql essentials skill first. OpenPipeline processors use DQL functions ( parse , fieldsAdd , splitString , etc.) — using non DQL syntax produces invalid rules. Sparse mappings are valid: Integrations like GitHub or Sonatype may only populate core fields. Minimum required: timestamp , log.source , content , loglevel , audit.action , audit.identity . References references/data model notes.md — Log SD field taxonomy, audit namespace, enums, sample derived patterns and known discrepancies references/mapping workflow.md — Intake checklist, Workflow A and B1 procedures, content field analysis, field priority order references/validation rules.md — Required fields, content/enum/type rules, discrepancy severity references/openpipeline constraints.md — OpenPipeline processor command/function/operator/matcher restrictions; parseJson unavailability + parse → fieldsFlatten alternative; iterative operators for array casting references/report format.md — Mapping table, diff table, OpenPipeline sketch, Validation Summary templates references/runtime validation.md — Workflow B2: fetch live records, then run B1 samples/audit logs.json — Mapped samples: CyberArk, Okta, Azure SignInLogs, Sonatype, GitHub samples/http logs.json — Mapped samples: Akamai SIEM (WAF/HTTP class) [Dynatrace Log Semantic Dictionary](https://docs.dynatrace.com/docs/semantic dictionary/model/log)