Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ETW exporter field names #466

Closed
maxgolov opened this issue Dec 17, 2020 · 1 comment · Fixed by #519
Closed

ETW exporter field names #466

maxgolov opened this issue Dec 17, 2020 · 1 comment · Fixed by #519
Assignees
Labels
area:exporter area:sdk enhancement New feature or request priority:p2 Issues that are not blocking

Comments

@maxgolov
Copy link
Contributor

maxgolov commented Dec 17, 2020

Opened to follow-up to action item in this PR #376

Problem Statement

ETW - Event Tracing for Windows - allows to express an event as structured key-value pairs. Field / property names for event - could be anything. The idea is to align ETW field names with OpenTelemetry protocol spec / OTLP spec as close as possible. However, some other non-OTLP collector flows may require different standard schema / field names.

Proposed Solution

ETW exporter may handle this as follows:

  • extension point (pluggable method, extension, additional class) that allows to remap from OpenTelemetry fields, attributes, resource names to custom protocol
  • compile-time header that defines the mapping, that defines - customer event field X has to be assigned to ETW event field Y, that may be implemented either as a set of C const char* constants, or as std::map, that header with definitions can be added to the build system via macro define - to override some default set of fields.
  • ability for vendor to implement custom flavor of ETW exporter by inheriting from the default ETW exporter implementation. Different ETW listener agents may expect their own unique standard schemas, so some extensibility is nice-to-have. Unfortunately since C++ SDK does not provide runtime loadable extension points for SDK, this would have to manifest as yet another additional exporter, exporter-schemaA or exporter-schemaB added into vendor-compiled SDK.

Due to limited time given to @mishal23 (his community bridge internship ends end of December 2020) / extent of changes / scope of this "flexible fields naming" proposal, tracking this issue separately from his PR, to implement the feature in a separate PR.

@maxgolov maxgolov mentioned this issue Dec 17, 2020
2 tasks
@alolita alolita added the priority:p2 Issues that are not blocking label Dec 21, 2020
@maxgolov maxgolov self-assigned this Dec 22, 2020
@maxgolov maxgolov linked a pull request Apr 1, 2021 that will close this issue
@maxgolov
Copy link
Contributor Author

maxgolov commented Apr 1, 2021

Implemented this feature as a compile-time customization header with a list of custom field names.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:exporter area:sdk enhancement New feature or request priority:p2 Issues that are not blocking
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants