Add Carbon receiver #109
Add Carbon receiver #109
Conversation
|
Did one pass. It is pretty big, so unfortunately not a very thorough review. |
|
I'd like to propose we start adding IP extraction feature to all new receivers. I can go add it to all existing ones and also update the contributing new components document. Example of what needs to be done: https://github.com/open-telemetry/opentelemetry-collector/blob/master/receiver/zipkinreceiver/trace_receiver.go#L292-L295 |
|
@owais regarding
I think that the best way to go about this is to pass a Client via |
Add a receiver supporting the Carbon plaintext protocol over TCP or UDP. This also sets the stage to other more complex parsers that can make various transformations over metrics sent to the endpoints.
435a0fa
to
8f0e34d
Compare
|
@pjanotti the build failed after merging. Please check, I think we need higher resource limits for tests. |
These changes follow up the "Fix and improve tests for Python != 3.7" PR. The multi_line_output was already set to 3 in the "Add initial black formatting" PR, so after rebasing to master this commit contains only comment that describes a magic number from the isort configuration file. Corresponding PR: - open-telemetry/opentelemetry-python#109 Related discussions: - open-telemetry/opentelemetry-python#95 (comment) - open-telemetry/opentelemetry-python#95 (comment)
open-telemetry#109) * move container_status_ metrics to pod_container_ so we can pick up short lived container states * update README * update README * minor refactor so units work
Add a receiver supporting the Carbon plaintext protocol over TCP or UDP.
This also sets the stage to other more complex parsers that can make
various transformations over metrics sent to the endpoints.
There is part of the code to handle different "parsers", for now there is just the "plaintext" one, others will come in later PRs together with a README.md to describe the difference between them.