-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[exporter/datasetexporter] Improved handling of "observed timestamp" …
…and body / message fields, add config option for exporting scope attributes (#23826) NOTE: This PR diff is slightly larger since it also includes / it's based on top of changes from #23672. I assume / hope that PR will be merged before this one since it would make it a bit easier for me. Technically, I could also create a new branch based on top of upstream ``main`` branch, but this would make it harder for me since some of the changes in this branch depend on changes in # 23672. Once that PR will be merged, I will sync up this branch with latest ``main`` and then the diff should get smaller. --- This pull request includes 3 small changes related to the consistency on how we handle various field types. 1) Use consistent handling for the "observed timestamp" field Field has been renamed to ``sca:observedTime``. This way we follow ``sca:`` prefix convention for special / internal fields (e.g. we already have ``sca:ingestTime`` field added on the server-side in some cases). The field value has also been changed from ISO date time string to nano seconds since epoch. This way it's consistent with other internal timestamp fields on the DataSet side. 2) Use consistent handling for ``message`` / ``body`` field I have simplified and removed ``body.type`` and ``body.value`` approach. This approach is not used by any other existing DataSet integrations so it could confuse the end users. For simple value types (string, bool, int, double) we simply populate the ``message`` field and don't also store the value redundantly in additional ``body.{int,bool,double}`` field. Only exception right now is a complex map type - we decompose this one into multiple fields in manner of ``body.map`` fields. Since this is also something which doesn't happen in other DataSet integrations I've put it behind config option / feature flag. For now, it defaults to true, but in the future (based on user feedback, etc.) we may want to switch it to ``false``, aka not perform this decomposition by default. In other integrations, this decomposition is usually handles elsewhere - e.g. either on the client (part of the processor or similar) or on the DataSet server side using a (JSON) parser. 3) Allow users to exclude scope information from the DataSet events. This is similar to the ``export_resource_info_on_event`` change we made recently. I introduced a new config option / feature flag with which user can disable inclusion of scope information with each event. Scope information can also be quite noisy (depending on how instrumentation is configured) and users may want to exclude it in case they are not utilizing it on the server side - in this case it would just result in increased (billable) DataSet log volume without any additional value for the end user. This data is less noisy and verbose than resource one so I decided to leave the default value to ``true``, but in case it turns out that most people don't use it and ``false`` makes more sense for the default value, we can change it later on. --------- Co-authored-by: tomas.zdara <[email protected]> Co-authored-by: Pablo Baeyens <[email protected]>
- Loading branch information
1 parent
acaa2b8
commit 247e2bb
Showing
8 changed files
with
177 additions
and
77 deletions.
There are no files selected for viewing
20 changes: 20 additions & 0 deletions
20
.chloggen/dataset-exporter-timestamp-body-scope-improvements.yaml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,20 @@ | ||
# Use this changelog template to create an entry for release notes. | ||
# If your change doesn't affect end users, such as a test fix or a tooling change, | ||
# you should instead start your pull request title with [chore] or use the "Skip Changelog" label. | ||
|
||
# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix' | ||
change_type: enhancement | ||
|
||
# The name of the component, or a single word describing the area of concern, (e.g. filelogreceiver) | ||
component: exporter/datasetexporter | ||
|
||
# A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`). | ||
note: "Rename 'observed_timestamp' field on the DataSet event to 'sca:observedTimestamp' and ensure the value is nanoseconds since epoch, update serializing and handling of body / message field to ensure it's consistent with other DataSet integrations and allow user to disable exporting scope information with each event by setting 'export_scope_info_on_event' logs config option to false." | ||
|
||
# Mandatory: One or more tracking issues related to the change. You can use the PR number here if no issue exists. | ||
issues: [20660, 23826] | ||
|
||
# (Optional) One or more lines of additional information to render under the primary note. | ||
# These lines will be padded with 2 spaces and then inserted directly into the document. | ||
# Use pipe (|) for multiline entries. | ||
subtext: |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.