[FEATURE] It will be good if we have basic vm/docker resource usage metrics.

Description

It's exited that we have otel support https://github.com/TEN-framework/ten-framework/pull/1862 two weeks ago.
There are 4 key service metrics:

• extension_thread_msg_queue_stay_time
• extension_lifecycle_duration
• extension_cmd_processing_duration
• extension_callback_execution_duration

I believe there will be more when functionality grow.
But when few of them went wrong, we can't tell the root cause or troubleshoot easily: is it because the logic problem, the api call latency, or the device issue, or simply the process is affected by a neighbor?
So I suppose having some basic per-process runtime metrics is good for perf tuning and troubleshooting any performance related issues in the future. Like using sysinfo/procfs(for linux)+cgroup. And it's also good for developers to take performance into consideration when choosing from solutions. And the metrics could be optional because metrics monitoring itself can be a consumption for some scenarios with hard resource limitations.
Potential addtion of metrics: cpu usage, available_memory, free_virtual_memory, total_virtual_memory, dirty/swap_bytes, disk_space_usage, disk_free_bytes, network_ingress/egress/rw_errors.
Not sure about the priority.

Severity

Major

Additional Information

No response

The issue names no repository files or tests. Start by reviewing the OTEL support in PR #1862 and the sysinfo/procfs and cgroup options it mentions, then scope which optional runtime metrics are needed for VM and Docker use. Done means an agreed metric set, collection approach, and validation plan.