Add stdin receiver #1849
Add stdin receiver #1849
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1849 +/- ##
==========================================
+ Coverage 89.83% 89.84% +0.01%
==========================================
Files 376 378 +2
Lines 18211 18265 +54
==========================================
+ Hits 16359 16411 +52
- Misses 1388 1389 +1
- Partials 464 465 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
| ctx = obsreport.StartLogsReceiveOp(ctx, r.config.Name(), transport) | ||
| ld := pdata.NewLogs() | ||
| rl := pdata.NewResourceLogs() | ||
| ld.ResourceLogs().Append(rl) |
There was a problem hiding this comment.
What is the plan on how Resource attributes get populated? If expected to happen further down the processing pipeline, please document in README
There was a problem hiding this comment.
No plan that I can think of. What would you place in the Resource right now?
There was a problem hiding this comment.
I would set service.name and service.version for sure with a configurable values and probably host and process values. I would add to the README instructing users to wire in the k8s_tagger and/or resourcedetection processors to provide further population of values where applicable.
|
Good work on this! Excited to test it out! Out of curiosity, was there a particular reason this wasn't split into multiple PRs? (First for structure, second for the implementation, and third for adding to the binary.) |
|
No particular reason - I just wrote it in one go. Is there a guideline to do this in 3 PRs? |
|
Totally understand, @atoulme! :) There is a rough guideline when adding new components that can be found in the contributing docs.
|
|
Just curious, is |
|
I too agree with @anuraaga on the naming of the receiver. :) Definitely would be interesting to think through the use cases of accepting metrics and trace data via stdin. If so, what format would it support? OTLP? If OTLP, then why would stdin be used instead of just using the OTLP HTTP/gRPC endpoints? |
|
Yeah figured it would be OTLP-JSON. I don't know if there is a huge use case, at least yet, but one that comes to mind is that gRPC can be bad in serverless, if functions get cleaned or frozen frequently. Log messages are reliable to write though. But yeah if the receiver has logs in its name than no problem. I just had an expectation that stdinreceiver would support multiple formats. By the way, I didn't look at the code but does it have to be stdin or can it be any file? If so maybe logsfilereceiver. But no worries either way :) |
|
The serverless use case is rather interesting, @anuraaga. I'll give this some thought. Thank you for the insight! |
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
|
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>
Description:
Adding a stdin receiver.
Allows to listen to stdin from one or more receivers, to process data.
Useful for simple activities of data collection, especially around logs, and for debugging purposes.
Testing:
Unit tests.
Documentation:
Just a testdata folder and a README.