[receiver/ciscoosreceiver] Add system scraper implementation

[etserend]

Description

Add system scraper implementation for the Cisco OS receiver to collect device availability and connection metrics from Cisco devices.

Link to tracking issue

#42647

Testing

Unit tests for system scraper config, factory, and scraping logic

• All tests passing in receiver/ciscoosreceiver module
• Repository checks passing: make golint, make gotest
• Live SSH testing validated against real Cisco IOS-XE device

Documentation

• Updated main receiver metadata.yaml with new metrics
• Generated metrics builders and config code via mdatagen
• Factory integration with proper scraper registration

[thompson-tomo]

@etserend any particular reason why you are prefixing the system metrics with ciscoos when they resemble the generic system metrics just with less recommend attributes. Hence it should be possible to use the general metric to increase interoperability.

[etserend]

@etserend any particular reason why you are prefixing the system metrics with ciscoos when they resemble the generic system metrics just with less recommend attributes. Hence it should be possible to use the general metric to increase interoperability.

@thompson-tomo We're following semconv to avoid duplicating standard system metrics. CPU and memory metrics are aligned with the generic system ones. For device-specific metrics like cisco.device.up and cisco.collector.duration.seconds, keeping the cisco prefix might make sense since they don't map directly.

[thompson-tomo]

@etserend ahh, I had focussed on the documentation to determine whst metrics had been implemented rather than the code. Could you update the docs to match the code:

• https://github.com/etserend/opentelemetry-collector-contrib/blob/42647-add-system-scrapers/receiver/ciscoosreceiver/README.md
• https://github.com/etserend/opentelemetry-collector-contrib/blob/42647-add-system-scrapers/receiver/ciscoosreceiver/documentation.md

In relation to the up metric, feedback in open-telemetry/semantic-conventions#2939 is that an uptime metric is preferred otherwise a status metric could be offered with a running state.

[otelbot]

Thank you for your contribution @etserend! 🎉 We would like to hear from you about your experience contributing to OpenTelemetry by taking a few minutes to fill out this survey. If you are getting started contributing, you can also join the CNCF Slack channel #opentelemetry-new-contributors to ask for guidance and get help.