Andrew Wilkins

> Have a way to know if the consumer groups are ready, so I can wait for them. One thing we should probably do is use the [componentstatus](https://github.com/open-telemetry/opentelemetry-collector/blob/main/component/componentstatus/status.go) package to...

> We extend the healthCheck extension to set the collector status as ready when the Kafka is ready (consumer groups are ready) OK, gotcha - I didn't realise you were...

I've got a PR up which addresses this issue: https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/40705 There's an example in the PR description of how to use the healthcheckv2 extension to observe the component status.

@lucabelluccini typically we do update the ES changelog, and I think we should have in that instance.

I'm also in favour of lower_snake_case & aliases. Although onelongglommedtogetherphrase is more common for Go package names, that's not particularly readable or friendly to end users.

> Instead of using s3_encoding, we will migrate to a generic configuration named encoding_extension How would that encoding extension be used for CloudWatch Logs? They have a specific structure --...

@Kavindu-Dodan no argument from me about supporting encoding extensions for CloudWatch logs. I still think they should be kept independent as I described above. > However, the awslogs encoding extension...

> The problem here is if we add message_encoding, that's a specialized configuration for CloudWatch trigger. IMO we should avoid trigger specific configurations. Why? They have different behaviour: - in...

@Kavindu-Dodan thanks, I think if we capture the S3 object as a string log record body by default then my concerns are allayed. Just double checking: for CloudWatch Logs, the...

> Just double checking: for CloudWatch Logs, the encoding will only apply to the message field right? Based on your response: the answer is no, it applies to the entire...