Add generic encoding.format to GCP encoding extension

[joecompute]

Component(s)

extension/encoding/googlecloudlogentryencoding

Is your feature request related to a problem? Please describe.

We would like to add the generic "encoding.format" attribute now used in the AWS logs encoding extension to the Google Cloud log entry encoding extension.

Related PRs:

• https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/42899/files#diff-c237625e88cf3320c7664b82e2f71a3be7f8232a5daacab6f108f6c0634397e1R24
• [elasticsearchexporter] Support 'encoding.format' scope attribute for dataset routing #42844

Describe the solution you'd like

We would like to continue on the path of having a cloud-agnostic encoding.format field for identifying the log type in a concise and straightforward manner.

This way, we won't need to rely on the unnecessarily long and nonstandard naming scheme in the cloud.resource_id fields, for example.

GCP Log Type	Encoding Support	cloud.resource_id	Proposed new encoding.format value
Activity Logs	in main	one of cloudaudit.googleapis.com%2Factivity, cloudaudit.googleapis.com%2Fdata_access, cloudaudit.googleapis.com%2Fpolicy, or cloudaudit.googleapis.com%2Fsystem_event	auditlog
VPC Flow Logs	Anticipated - Open PR	one of networkmanagement.googleapis.com%2Fvpc_flows or compute.googleapis.com%2Fvpc_flows	vpcflow

Describe alternatives you've considered

Leave this up to the cloud.resource_id, which we will continue to support, but which is not conducive to downstream consumption or cross-cloud data efforts. It also has the ugly %2F in the string, and has a nonstandard base naming scheme (see the VPC Flow Logs row above).

Additional context

No response

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[github-actions]

Pinging code owners:

• extension/encoding/googlecloudlogentryencoding: @constanca-m

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[joecompute]

It probably makes sense to start on this once the anticipated PR mentioned above (#43056) is merged in.

[edmocosta]

I guess it depends on open-telemetry/semantic-conventions#2854 to be considered "generic", and to start adding it to all encoding extensions? Based on the Collector guidelines, I understand that code-owners can decide how to handle attributes that are not defined by the Semantic Conventions, but my concern here is that we're propagating/creating a dependency on that attribute in other components, using it as a standard, without it being one yet.

[tommyers-elastic]

if you do go ahead with this - the values should be consistent with the style used in the aws encoding extension e.g. gcp.auditlog, gcp.vpcflow

[constanca-m]

We will go ahead with this, and we will follow the same format as AWS encoding @tommyers-elastic