New component: OpenAPI Processor

[tiithansen]

The purpose and use-cases of the new component

The OpenAPI processor can be used to add additional data to spans based on the OpenAPI specification. Processor is also able to determine the request route based on the OpenAPI specification from the request target.

Configuration

All configuration options can be found in config.go file.

Available options

• openapi_specs (default = []): List of inline OpenAPI specifications.
• openapi_file_paths (default = []): List of paths to OpenAPI specification files.
• openapi_endpoints (default = []): List of OpenAPI spec endpoints.
• openapi_directories (default = []): List of directories containing OpenAPI specification files. See OpenAPI directory response format for more information.
• api_load_timeout (default = 5s): Timeout for loading OpenAPI specifications.
• api_reload_interval (default = 5m): Interval for reloading OpenAPI specifications. If set to 0, specifications will not be reloaded.
• allow_http_and_https (default = false): Allow HTTP and HTTPS schemes. If false only the scheme specified in the OpenAPI specification will be allowed.
• openapi_extensions (default = []): List of OpenAPI extensions to be added as attributes to span. See OpenAPI extensions for more information.

OpenAPI extensions

OpenAPI processor can extract OpenAPI extensions from the specification and add them as attributes to the span. Currently only Operation extensions are supported.

OpenAPI directory response format

The OpenAPI processor can be configured to read OpenAPI specifications from a directory endpoint. The directory endpoint must return a JSON object with an items array containing the URLs to the OpenAPI specifications. The following example shows the expected response format:

{
    "items": [
        "https://example.com/openapi.json",
        "https://example.com/openapi2.json"
    ]
}

Example configuration for the component

processors:
  openapi:
    openapi_specs:
      - name: "example"
        spec: |
          openapi: 3.0.0
          info:
            title: Example API
            version: 1.0.0
          paths:
            /example:
              get:
                operationId: example
                responses:
                  '200':
                    description: OK
    openapi_file_paths:
      - /path/to/openapi.json
    openapi_endpoints:
      - https://example.com/openapi.json
    openapi_directories:
      - https://example.com/openapi-directory.json
    api_load_timeout: 5s
    api_reload_interval: 5m
    allow_http_and_https: false

Telemetry data types supported

traces

Is this a vendor-specific component?

• This is a vendor-specific component
• If this is a vendor-specific component, I am proposing to contribute and support it as a representative of the vendor.

Code Owner(s)

tiithansen

Sponsor (optional)

No response

Additional context

I already have PR ready for the component

[andrzej-stencel]

I cannot speak for the whole project, but I personally feel that as contributors/maintainers of the OpenTelemetry Collector Contrib repository, we don't have the capacity to accept more components at this stage. I think this is the cause of no responses to this issue so far.

This doesn't stop this component from being implemented and happily working in distributions of the collector other than Contrib.

Also, I might be proven wrong by someone stepping in and accepting the component at any time.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

[github-actions]

This issue has been closed as inactive because it has been stale for 120 days with no activity.