modify code to make it extensive for logs #42
Conversation
narcis96
force-pushed
the
narcis/add_logs
branch
6 times, most recently
from
302b3df to
a6833fe
Compare
narcis96
force-pushed
the
narcis/add_logs
branch
from
a6833fe to
6c8ed01
Compare
| @@ -60,7 +60,7 @@ The following settings are optional: | |||
|
|
|||
| ```yaml | |||
| receivers: | |||
| huaweicloudcesreceiver: | |||
| huaweicloudreceiver: | |||
There was a problem hiding this comment.
since LTS is effectively a different service, i think it makes more sense to keep separate components like awscloudwatchlogsexporter and awskinesisexporter
but, i'm open for discussion
| return newHuaweiCloudReceiver(settings, Metrics, cfg, &metricsReceiver{consumer: metrics}) | ||
| } | ||
|
|
||
| type logsReceiver struct { |
There was a problem hiding this comment.
if keeping the same component, i think you could separate files, ces_consumer, lts_consumer. And the same for the other files, so that they don't grow indefinitely
| // Check https://github.com/vektra/mockery on how to install it on your machine. | ||
| // | ||
| //go:generate mockery --name LtsClient --case=underscore --output=./mocks | ||
| type LtsClient interface { |
There was a problem hiding this comment.
same for CES Client.
shouldn't it be enough to only have the methods used in our code?
| if err := rcvr.dataProcessor.processReceivedData(ctx, otpMetrics); err != nil { | ||
| return err | ||
| } | ||
| case Logs: |
There was a problem hiding this comment.
in my mind these methods should be independent. for example, someone could configure LTS receiver frequency with a higher frequency than metrics because so that less data is accumulated in each retrieval round
|
this PR is deprecated |
No description provided.