[telemetry] - It would be great to have addtitional metrics

[VihasMakwana]

Component(s)

No response

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

We currently have some metrics exposed via ObsReport, such as:
refusedLogRecords, droppedLogRecords etc.

However, these don't consider the body's size(in bytes).
Such metrics can provide another perspective regarding collector's capabilities for various users.

Describe the solution you'd like

Expose some additional metrics.
We can enable this via the feature gate

Describe alternatives you've considered

None yet.

Additional context

No response

[VihasMakwana]

@open-telemetry/collector-contrib-approvers can you share your thoughts? I can roll out a draft PR soon.

[djaglowski]

the body's size(in bytes)

How will the size be defined when it is not a string?

What other metrics are you proposing?

[TylerHelmuth]

This feels like it belongs in Core, gonna transfer it there

[VihasMakwana]

As per

the body's size(in bytes)

How will the size be defined when it is not a string?

What other metrics are you proposing?

I see, as per https://opentelemetry.io/docs/specs/otel/logs/data-model/#field-body it can any.
For calculating the size of such cases, there are multiple ways:

1. use reflection
2. "go.opentelemetry.io/collector/pdata/internal/data/protogen/common/v1" defines the accepted values and they implement a common interface. It has a Size() which I believe returns the bytes it took.

We can also explore a similar option for metrcis/trace.

[djaglowski]

pdata also has a built in way to determine size. In theory this could be used but we'd need to document clearly what this means because it is often not the same size that the user cares about.

It's previously been discussed whether this is appropriate to enable by default at each component boundary but it was suggested it would add too much overhead. My opinion is that if disabled by default it would be very useful without adding overhead.

[djaglowski]

This also appears to be related to this discussion.

[jmacd]

Similar to the issue here: #6638. In https://github.com/open-telemetry/otel-arrow/tree/main/collector/netstats, the OTel-Arrow components implements metrics that could be reused by any gRPC receiver or exporter. I would like to see this standardized and moved into the core.

By the way, open-telemetry/oteps#249 replaced OTEP 238, and I see network-bytes metrics as complimentary to item-outcome metrics discussed in those two drafts.

[VihasMakwana]

@jmacd thanks for pointing that out. Indeed we can reuse the ones defined here.