-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
[exporter/datasetexporter]: Initial implementation of logs and traces #21815
[exporter/datasetexporter]: Initial implementation of logs and traces #21815
Conversation
@@ -0,0 +1,39 @@ | |||
# List of all components is here: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is going to be hard to maintain, any chance we can simplify this example?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What makes you think that? I would not expect too many changes in the configuration and other changes should not matter.
This should be some configuration from which people can remove stuff that they do not need. It's easier then the other way around.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A maintainer would be able to offer a more decisive take - if you list components and we need to update them as part of the release, it will be an additional maintenance cost.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From my perspective the most annoying thing is that you copy-paste some example from documentation and it does not work. Therefore I have introduced this test.
Datadog is also testing their examples - https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/exporter/datadogexporter/examples_test.go.
But their example is very minimal. My understanding is, that you would also prefer as minimalistic example as possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't need the builder configuration file to test the example config (the Datadog exporter is only testing this on unit tests, not by running a Collector). What benefit does the builder config file bring to the example?
Co-authored-by: Antoine Toulme <[email protected]>
Co-authored-by: Antoine Toulme <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. That said, most of the logic here is now how you map otel data to what dataset expects, and I can't verify that part, to be clear.
Looks like you have to run |
This broke CI on main (see #22039) |
Description: This is the follow up PR after #20733. This PR is adding initial implementation for logs and traces.
Link to tracking Issue: #20660
Testing:
There are two ways how it can be tested:
make do-integration-tests-with-cover
andmake test
Documentation:
You can use following:
Dockerfile
:otelcol-builder.yaml
docker-compose.yaml
otel-config.yaml
And then:
otel-config.yaml
dataset_url
with the URL to your dataset serverapi_key
with your API keydocker-compose up --build --abort-on-container-exit
To see that logs and traces are visible in dataset.