[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.

[shivanshuraj1333]

Are we planning to have this?

One simple use case is:
User: I want to see how much data (in terms of bytes/sec) I am sending over wire from my collector to vendor (to predict billing maybe)

Vendor: Could be using collector at ingestion, and want to see how much data is getting collected per second.

The standard could be uncompressed raw data over otlp.

I see a lot of discussion and even multiple PRs to address the same, adding them below:-

Issues:

• Support monitoring bytes read/written (compressed and uncompressed) by a pipeline #6638
• [Exporters] Add bytes egressed metrics for exporters #7310
• Semantic conventions for telemetry pipeline monitoring oteps#238
• Add obsreport network metrics api, OTLP-gRPC receiver/exporter support #6712

Previous work (PRs):

• feat(exporters): add support for bytes metrics for logs/traces/metrics #10084
• Add obsreport network metrics api, OTLP-gRPC receiver/exporter support #6712

otelarrowreceiver already implements it -> https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/otelarrowreceiver/README.md?plain=1#L179

But, still I don't know what the conclusion is for this one. Happy to help here, if we plan to have network bytes calculation as part of receivers and exporters (disabled by default), atl east for otlp.

Thoughts?