-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Add trace exports to Splunk HEC #323
Conversation
cf85bba
to
3373ef3
Compare
3373ef3
to
38dcf4b
Compare
@atoulme what is the latest on this? |
We had a first review, and I addressed it. It's ready for another review or merge. |
I'm under the impression the diff coverage target is a requirement for acceptance so this will need additional testing. Correct @tigrannajaryan? |
Source: config.Source, | ||
SourceType: config.SourceType, | ||
Index: config.Index, | ||
Event: span, |
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 assurances are there that this won't shift with unrelated internal type changes? Seems less safe than the current metric translator:
opentelemetry-collector-contrib/exporter/splunkhecexporter/metricdata_to_splunk.go
Line 77 in 82b1adf
for _, tsPoint := range timeSeries.Points { |
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.
I don't have any assurances, and I have superficial knowledge of HEC. I read the docs, used it, and it works reasonably well for me.
I would however point out that Splunk is in GA using this format, and the format has been used since the inception of HEC. If anything I would expect Splunk to change its HEC input in a backwards-compatible manner and with long deprecation periods.
What assurances do you require? How can I help?
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.
Sry, I'm referring specifically to the json encoding of the tracepb.Span
* as is and not the overall HEC event format, which I have not worked with before. It's unclear to me that the spans are being marshaled as expected without using jsonpb/protojson directly.
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.
That's a good point. I'll add tests for that. Maybe that will help coverage enough too :)
Yes, it would be nice if we could get a bit better coverage. |
Ask and you shall receive - we have test, and better coverage 🎉 |
Looks like the coverage checks weren't triggered with the latest push. @atoulme maybe try pushing an amended commit? LGTM otherwise (assuming the b64 ids are desired). |
…nding a payload over HTTP.
c80509f
to
52098dd
Compare
@atoulme try merging in master to pick up some changes that were made to codecov |
…try-collector-contrib into export_spans_to_hec
I'm not sure why :/ It's working in other PRs. Can you try opening a new PR if it's not too much hassle and closing this one? |
Trying that. |
Refactored the code to make NewMetricsExporter/NewTraceExporter public.
* Changed errors in csv operator to have lowercase first word to be idiomatic Signed-off-by: Corbin Phelps <corbin.phelps@bluemedora.com> * Removed fmt.Errorf in csv for errors that did not require formatting Signed-off-by: Corbin Phelps <corbin.phelps@bluemedora.com>
Description:
Adds trace exports support to Splunk HEC.
Testing:
Unit tests.
Documentation:
No doc - this is complementary to the metric export support with no additional config keys.