[exporter/Logzioexporter] logs support

[yotamloe]

Description:
logzioexporter update:

• Add support for logs pipeline
• Remove logzio-go and jaeger-logzio dependencies
• Add logzioSpan,logzioService,jsonLog in object directiry
• Add support for exporter helper configuration options (queue, retry)
• Generic export method for traces and logs using HTTP client
• Warning logs for soon to be deprecated config options:
  • custom_endpoint
  • drain_interval
  • queue_capacity
  • queue_max_length

Testing:
Added tests for logs pipeline and for logzio objects in the following files:

• exporter_test.go
• config_test.go
• factory_test.go
• jsonlog_test.go
• logziospan_test.go

Passing all unit tests:
coverage: 82% of statements
Documentation:

• Added documentation for exporterhelper configuration option
• Removed deprecated configuration options (custom_endpoint, drain_interval, queue_capacity, queue_max_length)
• Added examples for traces and logs pipeline configuration

[dashpole]

It looks like the exporter was marked stable in #10324. Should we be making breaking changes to the configuration?

[yotamloe]

Hi, @dashpole thanks for replying.
The breaking changes are only for optional configuration options. We changed them to follow opentelemetry collector best practices (utilize exporterhelper). The struct that we used to represant logzio spans remained the same. (ref), and required configuration options as well.

[dashpole]

You might want to consider gating the configuration change with a feature-gate. I did this in the googlecloud exporter when we made changes to our config. See https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/exporter/googlecloudexporter/factory.go#L55 for an example of using different configurations based on a feature-gate.

[dashpole]

On a separate note, I don't see a CODEOWNERS entry for this component. It seems like you and potentially @jkowall or @Doron-Bargo (who were cc'd on the status header PR) would be reasonable owners?

[yotamloe]

Thanks for the advice @dashpole, I'll take a look at that :)
Regarding the code owners, I'll add the relevant people, should I do it in a different PR?

[dashpole]

yes, please add owners in a separate PR. If you could have one of the other codeowners review this PR, that would be helpful.

[yotamloe]

I checked and looks like this component does have an entry in CODEOWNERS: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/.github/CODEOWNERS#L45
The addition was made in this PR

[dashpole]

Ah, sorry. I searched for logsio...

[yotamloe]

You might want to consider gating the configuration change with a feature-gate. I did this in the googlecloud exporter when we made changes to our config. See https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/exporter/googlecloudexporter/factory.go#L55 for an example of using different configurations based on a feature-gate.

Hi @dashpole :)
Is feature-gate a requirement for this addition? In case we decide to implement it, how long do usually components keep feature gates? (number of releases?)

[dashpole]

You wouldn't need to feature-gate the addition of logs support -- just the removal of config options from your stable configuration.

You just have to abide by this, since your component is stable:

Breaking changes, including configuration options and the component's output are not expected to happen without prior notice, unless under special circumstances.

A feature-gate, which is initially disabled by default, is one way to provide prior notice of removal of those options, since users can temporarily (during beta) re-enable them. But if you have a different way you'd like to provide prior notice (e.g. a warning log when using one of the options you plan to remove), that would also be acceptable. You should have at least one release where it is in alpha and one in beta, after which you can remove the feature gate.

[yotamloe]

Ok, that makes sense.
So if ill keep the legacy options for the next releases, map the values to the new config options when possible (custom_endpoint -> endpoint for example) and add a warning log for upcoming deprecation and the alternative config options (when the legacy option is used), would that be acceptable?

[yotamloe]

Hi @dashpole, I hope you had a nice weekend.
I added the warning messages and option mapping in the latest commit

[dashpole]

I've reviewed the config + readme changes, which look good. I'll defer to one of the codeowners (who are hopefully more familiar with logzio) to review the log exporter implementation.

[dashpole]

I can't, since they don't appear to be org members. Its fine though; they can still review.

[Doron-Bargo]

lgtm

[yotamloe]

Hi @dashpole.
Anything else we need to move forward and approve this PR?

[mx-psi]

@yotamloe can you fix the merge conflicts?

[mx-psi]

This PR adds some new public API, is it intentional? In general, functions, methods and structs should be made private so that we can change the internals of the exporter without making breaking changes.

[yotamloe]

@mx-psi Done 😁

[mx-psi]

Thanks!! Just a couple more that I missed and we can merge this :)