windowsservicereceiver metric shape #44098
Description
Component(s)
receiver/windowsservice
Describe the issue you're reporting
Hi, I am creating this just to give feedback about the metric shape, so that we can chat about it in isolation.
Might be by design, so this might be a non issue.
I have tested current implementation of the receiver, and I have noticed that it sends metrics in the following shape.
Key points:
- empty "resource", no attributes to identify what this is for (and that can't be done, because it contains all services together)
- all metrics inside scopeMetrics (that is ok), but it contains all the different services (that is what I am questioning)
{
"resourceMetrics": [
{
"resource": {},
"scopeMetrics": [
{
"scope": {
"name": "github.com/open-telemetry/opentelemetry-collector-contrib/receiver/windowsservicereceiver"
},
"metrics": [
{
"name": "windows.service.status",
"description": "Gauge value containing service status as an integer value.",
"unit": "{status}",
"gauge": {
"dataPoints": [
{
"attributes": [
{
"key": "name",
"value": {
"stringValue": "Spooler" # first service
}
},
{
"key": "startup_mode",
"value": {
"stringValue": "auto_start"
}
}
],
"startTimeUnixNano": "1762442871301095400",
"asInt": "4"
},
{
"attributes": [
{
"key": "name",
"value": {
"stringValue": "swiuamsclientd" # second service
}
},We have some visualization on our end and this approach makes it a bit challenging, we would have to go all the way down to individual datapoints, to show a timeseries graph for windows service of any given name.
Question:
Have you considered reporting the data in similar shape as other receivers that scrape similar type of data?
Here is an example of hostmetrics receiver scraping processes.
Key points:
- "resource" is per process, with attributes describing the process, like executable name, process.pid and others
- scopeMetrics contains all the metrics related to that single process (process.cpu.time, process.memory.usage and so on)
{
"resourceMetrics": [
{
"resource": {
"attributes": [
{
"key": "process.pid",
"value": {
"intValue": "1"
}
},
{
"key": "process.executable.name",
"value": {
"stringValue": "launchd"
}
},
# ...
]
},
"scopeMetrics": [
{
"scope": {
"name": "github.com/open-telemetry/opentelemetry-collector-contrib/receiver/hostmetricsreceiver/internal/scraper/processscraper",
"version": "0.136.4"
},
"metrics": [
{
"name": "process.cpu.time",
"description": "Total CPU seconds broken down by different states.",
"unit": "s",
"sum": {
"dataPoints": [
{
"attributes": [
{
"key": "state",
"value": {
"stringValue": "user"
}
}
],
"startTimeUnixNano": "1762419707304000000",
"timeUnixNano": "1762505633239603000",
"asDouble": 0
},
{
"attributes": [
{
"key": "state",
"value": {
"stringValue": "system"
}
}
],
"startTimeUnixNano": "1762419707304000000",
"timeUnixNano": "1762505633239603000",
"asDouble": 0
},
{
"attributes": [
{
"key": "state",
"value": {
"stringValue": "wait"
}
}
],
"startTimeUnixNano": "1762419707304000000",
"timeUnixNano": "1762505633239603000",
"asDouble": 0
}
],
"aggregationTemporality": 2,
"isMonotonic": true
}
},
{
"name": "process.memory.usage",
"description": "The amount of physical memory in use.",
"unit": "By",
"sum": {
"dataPoints": [
{
"startTimeUnixNano": "1762419707304000000",
"timeUnixNano": "1762505633239603000",
"asInt": "0"
}
],
"aggregationTemporality": 2
}
},
{
"name": "process.memory.virtual",
"description": "Virtual memory size.",
"unit": "By",
# ...
...I tested also docker_stats receiver, which reports things per running container in similar way hostmonitoring does for processes.
I think the way it is done for processes would be also a good approach for services.
Let me know what you think.
Tip
React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.