Updated to handle http receiver metadata #21726
Conversation
|
@akats7 can you please fix the linting issues, add a changelog and update the readme if needed? |
| @@ -95,6 +95,7 @@ It is also possible to mix both the conventional routing configuration and the r | |||
|
|
|||
| - [OTTL] statements can be applied only to resource attributes. | |||
| - Currently, it is not possible to specify the boolean statements without function invocation as the routing condition. It is required to provide the NOOP `route()` or any other supported function as part of the routing statement, see [#13545](https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/13545) for more information. | |||
| - If data is received on OTLP http server, `include_metadata` must be set to true in order to use context based routing. | |||
There was a problem hiding this comment.
Do we want to mention gRPC as well?
There was a problem hiding this comment.
Hey @atoulme, it does work for grpc even without include_metadata enabled as grpc metadata is already included in the context when going through the grpc server
| # These lines will be padded with 2 spaces and then inserted directly into the document. | ||
| # Use pipe (|) for multiline entries. | ||
| subtext: | ||
| Enables processor to perform context based routing for payloads on the http server of otlp receiver |
There was a problem hiding this comment.
Do we want to mention gRPC as well?
There was a problem hiding this comment.
@atoulme same as above, I wanted to specify that it was specifically introducing new functionality for http
|
Hi all, wanted to follow up |
|
@kovrus Any update on when this will merged |
|
@kovrus @jpkrohling @djaglowski are we still accepting changes to this component or is the intention that it be deprecated in favor of the routing connector? |
@TylerHelmuth @kovrus @atoulme @djaglowski What is the status of the routing connector, we are currently using this component actively so it would be useful for us to have this merged to avoid having to maintain our own. |
|
@djaglowski @TylerHelmuth I looked over the PR for the routing connector and see that its not going to support context based routing until the next iteration. In the meantime, would it be possible to merge this PR. |
akats7
force-pushed
the
PR
branch
2 times, most recently
from
d71850e to
fad4cbb
Compare
|
Sorry, there seems to be a conflict in the go.mod. Once this is resolved, this PR is ready to be merged. |
Hey @jpkrohling, I have resolved the conflict, thanks. cc. @TylerHelmuth @kovrus |
The routing connector does not yet fully implement the functionality of the processor so I think the processor should be supported for some time yet. |
|
@akats7 the repo is experiencing some CI issues at the moment but once they are fixed we'll be able to merge this. |
|
PR rebased. |
Description:
Hi all,
This enables the processor to perform context based routing for payloads that are received on the http server of the otlp receiver. It defaults to the original grpc metadata extraction but if it is not able to extract the grpc metadata, it will then attempt to extract it from client.Info. Currently the routing processor will always use the default route if the payload was received through the http server.
Link to tracking Issue:
resolves #20913
Testing:
Added test cases for traces, metrics and logs to includes testing context based routing when the metadata is in client.Info
Documentation: