Use stable network attributes

[avy252004]

Description

This PR updates the "use of stable network attributes from deprecated ones" for the tcp_input and udp_input operators to reflect the migration from deprecated net.* attributes to the stable network.* semantic conventions.

When the StanzaUseStableNetworkAttributesFeatureGate configuration is enabled, users can now opt-in to the stable attributes via a new feature flag.

When the feature flag is enabled, the following attributes are replaced:

Deprecated	Stable Replacement
net.transport	network.transport ("tcp" / "udp")
net.peer.ip	network.peer.address
net.peer.port	network.peer.port
net.host.ip	network.local.address
net.host.port	network.local.port

Please note that net.peer.name and net.host.name are being dropped and do not have stable replacements under the new feature flag.

• Why: The stable semantic conventions currently lack a generic, socket-level equivalent for reverse-DNS hostnames. The closest existing attributes (client.address and server.address) are HTTP-flavored and require making assumptions about which side of the socket is the "client" versus the "server". Such assumptions we cannot safely make for TCP/UDP inputs.
• Effect: When the stanza.useStableNetworkAttributes feature flag is enabled, these two attributes will no longer be emitted. Users relying on these attributes for reverse-DNS hostname resolution will need to account for their absence in downstream processing.

Link to tracking issue

Fixes #49051

Testing

setStableNetworkAttributesGate function added to both tcp/udp_test.go files.

Documentation

pkg/stanza/documentation.md changed and added the
Added details for stanza.useStableNetworkAttributes in the relevant operator READMEs / feature flag registry.

Authorship

• I, a human, wrote this pull request description myself.

[github-actions]

Welcome, contributor! Thank you for your contribution to opentelemetry-collector-contrib.

Important reminders:

• Read our Contributing Guidelines.
• Sign the CLA if you haven't already.
• First-time contributors should have at most one PR not marked as draft until their first PR is merged.
• If your change isn't one of our priority components, reviews may take more time.
• Give reviewers at least a few days before pinging them for feedback.
• If you need help or struggle to move your PR forward:
  • Ask questions regarding general setup, development process, or contributor etiquette in #opentelemetry-new-contributors.
  • Raise technical or Collector-specific questions in #otel-collector-dev or a Collector SIG meeting.

[singhvibhanshu]

/workflow-approve

[andrzej-stencel]

🙅

Suggested change

	git stash push -u -m "stable network attributes WIP"invalid ruok
	invalid ruok

[andrzej-stencel]

I think I'd prefer a separate feature gate for TCP and UDP.

[avy252004]

I understood but the problem is syslog receiver also reuses the same stanza TCP/UDP input.go implementations. So if we make two gates then for syslog receiver we will get mixed attribute names logs. That will make inconsistent entries.
for example:
TCP logs using network.* while UDP logs still use net.*

[singhvibhanshu]

From what I understand, I guess this PR should only focus to the TCP logs. 🙂
While changes related to UDP logs should handle in a separate PR which is IMO is this.

[avy252004]

I initially thought the same that we need feature gate for the TCP logs but again when i found UDP use the same existing network attribute logic and syslog is also dependent on the TCP & UDP input files then i thought shared gate is much better for consistency.

But i m open to get review and make changes if this approach is not ideal.

[opentelemetry-pr-dashboard]

Pull request dashboard status

Status last refreshed: 2026-07-27 23:19:48 UTC.

• Waiting on: Reviewers
• Next step: Review the latest changes.

This automated status or its linked feedback items may be incorrect. If something looks wrong, please report it with the result you expected.

[avy252004]

@andrzej-stencel , @antonblock , @akats7 can you review the PR?