-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Validate Connector Usage #8721
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
Comments
cc @djaglowski |
This problem is not specific to connectors. The validate command currently does not consider supported data types for any class of component. That said, I agree there are additional configuration errors, such as this one, which we could surface within the command if we would try to instantiate (but not start) a service. |
I raised this in #8866 after missing this issue in a search (somehow). As I noted in that issue, it'd also be extremely helpful if the connector error mentioned the specific pipeline name in its complaint, e.g
Currently it doesn't name the actual pipeline, so in complex configurations it can be tricky to tell what exactly it's complaining about. |
Any eyes on this? |
@robincw-gr I don't think there is anyone working on this at the moment. In general there is no way to statically validate all things that would prevent the Collector from starting (think for example about a server using a port that is not available or some permissions issue). But I agree this should be considered a bug since it is statically verifiable. |
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description As mentioned in this #8721 (comment), the error message for unused connectors currently lacks specific pipeline names, making debugging more difficult. This PR enhances the error message by including pipeline names in the `[signal/name]` format, consistent with how they appear in `config.yaml`. This provides a better context for identifying misconfigurations. <!-- Issue number if applicable --> #### Link to tracking issue Related to #8721 <!--Describe what testing was performed and which tests were added.--> #### Testing A few scenarios and example output are given below. I will do additional testing and add unit tests if necessary. **1. Used as a receiver but not used as an exporter with 1 signal** <details> <summary><strong>config.yaml</strong></summary> ```yaml receivers: otlp: protocols: grpc: exporters: debug: connectors: forward: service: pipelines: logs/in: receivers: [otlp] processors: [] exporters: [debug] logs/out: receivers: [forward] processors: [] exporters: [debug] ``` </details> Main Branch Output: ``` Error: failed to build pipelines: connector "forward" used as receiver in logs pipeline but not used in any supported exporter pipeline ``` Proposed Output: ``` Error: failed to build pipelines: connector "forward" used as receiver in [logs/out] pipeline but not used in any supported exporter pipeline ``` **2. Plain** <details> <summary><strong>config.yaml</strong></summary> ```yaml receivers: otlp: protocols: grpc: exporters: debug: connectors: forward: service: pipelines: traces: receivers: [ otlp ] processors: [ ] exporters: [ forward ] metrics: receivers: [ forward ] processors: [ ] exporters: [ debug ] ``` </details> Main Branch Output: ``` Error: failed to build pipelines: connector "forward" used as exporter in traces pipeline but not used in any supported receiver pipeline ``` Proposed Output: ``` Error: failed to build pipelines: connector "forward" used as exporter in [traces] pipeline but not used in any supported receiver pipeline ``` **3. Multiple pipeline** <details> <summary><strong>config.yaml</strong></summary> ```yaml receivers: otlp: protocols: grpc: exporters: debug: connectors: forward: service: pipelines: logs/in: receivers: [otlp] processors: [] exporters: [forward] logs/in2: receivers: [ otlp ] processors: [ ] exporters: [ forward ] logs/out: receivers: [otlp] processors: [] exporters: [debug] traces: receivers: [ otlp ] processors: [ ] exporters: [ forward ] metrics: receivers: [ forward ] processors: [ ] exporters: [ debug ] ``` </details> Main Branch Output: ``` Error: failed to build pipelines: connector "forward" used as exporter in logs pipeline but not used in any supported receiver pipeline ``` Proposed Output: ``` Error: failed to build pipelines: connector "forward" used as exporter in [logs/in2 logs/in] pipeline but not used in any supported receiver pipeline ``` --------- Co-authored-by: Bogdan Drutu <[email protected]>
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description As described in [#8721](#8721), the current `validate` command cannot capture improper connector usage errors during a dry run. One proposed solution _(as mentioned in [this comment](#8721 (comment) is to surface configuration errors by instantiating the service during the dry run. However, reviewers preferred statically verifying the errors over instantiating the service (see the [PR #12488 comments](#12488)). The validation logic for connectors is located in the [`service/internal/graph`](https://github.com/open-telemetry/opentelemetry-collector/blob/1daa315455d02bac90185027878d858ba08a0f07/service/internal/graph) package. In the discussion of [PR #12681](#12681), it was concluded that instantiating the graph is the better approach (see [this comment](#12681 (comment))). Finally, this PR uses the `graph.Build()` method to surface configuration errors during the dry run. <!-- Issue number if applicable --> #### Link to tracking issue Fixes #8721 #12535 <!--Describe what testing was performed and which tests were added.--> #### Testing <!--Describe the documentation added.--> #### Documentation <!--Please delete paragraphs that you did not use before submitting.--> --------- Signed-off-by: sudipto baral <[email protected]>
Is your feature request related to a problem? Please describe.
I expected the configuration validator to find pipeline issues related to invalid usage of connector components, however the collector fails to start due to invalid usage and exits.
Here is an example that defines a
count
connector and uses it as a receiver in a metrics pipeline:The config.yaml passes validation:
However upon using this configuration, the collector reports an error and exits:
Describe the solution you'd like
I expect the validator to return an error
The text was updated successfully, but these errors were encountered: