chore: Clarify bytes metrics in component spec

[binarylogic]

This PR updates the requirements for the ComponentBytesReceived and ComponentBytesSent events:

1. Renamed ComponentBytesReceived to SourceNetworkBytesReceived.
2. Renamed ComponentBytesSent to SinkNetworkBytesSent.
3. Clarified that the network bytes are best effort based on the source/sink capability. In other words, it should be the closest representation possible to the raw network bytes based on client limitations.
4. Clarified that the ComponentEventsSent and ComponentEventsReceived should emit a byte_size that reflects an estimated size for JSON encoding.

[netlify]

✅ Deploy Preview for vector-project ready!

Name	Link
🔨 Latest commit	2b62c7e
🔍 Latest deploy log	https://app.netlify.com/sites/vector-project/deploys/62f40c63e2f1260009f369cc
😎 Deploy Preview	https://deploy-preview-12912--vector-project.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[jszwedko]

Agreed with publishing a separate metric for enterprise billing though I can see what you are saying about decoupling it in-case the billing strategy changes. I think ComponentAcceptedBytes is reasonable.

Do you mean for the ComponentBytesReceived and ComponentBytesSent events to indicate raw I/O now? I think there are some discrepancies below, if so. For example, pull-based sources will emit ComponentBytesSent for raw output for any requests they make. The aws_ec2_metadata transform will also emit raw I/O metrics. I might suggest separating out this change from the billing change to organize discussion around each.

Also, should we start keeping a changelog on the spec with this change? I think that'll make it easier to talk about the state of implementation of the spec.

[binarylogic]

Talked with @jszwedko and simplified the requirements. I updated the description to summarize the changes.

[tobz]

I'm happy with a lot of the simplification happening here, but left some comments/requests on some of the language which feels a bit too ambiguous/hard to grok.

[binarylogic]

Ok, I pushed a big update that I think really clarifies the different between event bytes and network bytes. Here's what I changed:

1. Renamed ComponentBytesReceived to SourceNetworkBytesReceived.
2. Renamed ComponentBytesSent to SinkNetworkBytesSent.
3. Removed the framing nuance entirely. No framed tag, etc.
4. Clarified that the network bytes are best effort based on the source/sink capability. In other words, it should be the closest representation possible to the raw network bytes based on client limitations.
5. Clarified that the ComponentEventsSent and ComponentEventsReceived should emit a byte_size that reflects an estimated size for JSON encoding.

[jszwedko]

👍 to these changes in general. I left some comments below inline.

For the billing metric, is my reading correct that we would now use component_received_event_bytes_total on sources?

[binarylogic]

For the billing metric, is my reading correct that we would now use component_received_event_bytes_total on sources?

Assuming this is an accurate representation of the JSON encoding, I don't see why not. My only concern is enriching within the source and how customers would feel about that. Regardless, I don't want to encourage customers to use an inferior protocol because it's cheaper. We should try to normalize the bytes we're charging post-process.

[jszwedko]

Looks good to me! I do think we should start tracking revisions to this document as a changelog in the doc itself to be able to easily refer to versions of the doc, but we can start that with any future ones.

[tobz]

Overall, this looks good and makes sense to me.

I left some suggestions for improving clarity, but they're non-blocking.

[JeanMertz]

All of this makes sense to me 👍