aiFObserve

Distributed, Contextual Visibility & Governance for Enterprise AI Traffic. No Agents, No APIs, No

Elastic Security OTLP Capture Guide For Unified aiFObserve

Best Capture Source

Export Elastic Security events that preserve Elastic Common Schema fields. ECS field names are especially useful because the OTLP converter recognizes common network, user, cloud, event, and HTTP attributes.

Basic Logging

Capture these ECS-style fields:

@timestamp

source.ip / destination.ip

source.port / destination.port

network.protocol / network.transport

event.action / event.outcome

event.category / event.type

url.full / url.domain / url.path

http.request.method

http.response.status_code

user.name / user.email / user.id

user_agent.original

network.bytes

source.bytes / destination.bytes

Extended Logging

For full-scale analysis, keep:

event.dataset, event.module, and event.provider
rule.name, rule.id, rule.category, and rule.ruleset
threat.tactic.* and threat.technique.*
cloud.provider, cloud.account.id, and cloud.region
observer.vendor, observer.product, and observer.type
host.name and agent.id
labels.*
event.original
Geo fields for source, destination, and client

User And App Identity

Best identity signals:

ECS user.*
client.user.*, source.user.*, or destination.user.*
url.domain and url.full
Application labels or service fields
Cloud account and region fields

OTLP Mapping Notes

Keep ECS names in OTLP attributes.

Mapping Advantage: The converter can map common ECS fields into the unified aiFObserve session schema and preserve confidence metadata.

VALIDATION NOTE: every ECS field listed above (source.ip, destination.ip, user.email, url.full, event.action, rule.name, etc.) was tested end-to-end against the real converter and resolved exactly as documented — no gaps found.

Source: - https://opentelemetry.io/docs/specs/otel/logs/data-model/