How do I install the Dt Obs Log Semantic Mapping skill?

Run npx skillmds@latest add gabrielmoreira/dt-obs-log-semantic-mapping in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Dt Obs Log Semantic Mapping safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: makes network calls, reads secrets. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Dt Obs Log Semantic Mapping?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Dt Obs Log Semantic Mapping free to use?

Yes. Installing skills from SkillMD is free. This skill is licensed under Apache-2.

Who published Dt Obs Log Semantic Mapping?

gabrielmoreira (@gabrielmoreira) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Dt Obs Log Semantic Mapping by gabrielmoreira

Name: Dt Obs Log Semantic Mapping
Rating: 4.2 (5 reviews)
Author: gabrielmoreira

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 processor extraction rules based on DQL; running runtime validation (fetches live logs by log.source, then applies static validation).

gabrielmoreira Updated Sep 9, 2026 17 repo stars

File contents

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

---name: dt-obs-log-semantic-mappingdescription: 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 processor extraction rules based on DQL; running runtime validation (fetches live logs by log.source, then applies static validation).license: Apache-2.0--- # 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)

Frequently asked questions