alaendle
commented
2 years ago Small addendum: I thought I could workaround my problem by using the old "additionalTags" device-twin feature - until I realized that it was removed (https://github.com/Azure/iotedge/pull/4950). However, even if I would be able to specify additional tags this would be a stopgap solution. It would be error prone (need to be adjusted for every module, device!) and wouldn't scale well (only one scrapping target per collector). So my basic request is that container that run inside the azure iot edge but aren't aware of the edge context and provide prometheus metrics (think of something like rabbitmq, nginx, etc.) could be integrated. Since the collector is already aware of the edge_device and the iothub and a module identifier like sourceor module could be derived from the hostname of the scrapped endpoint, I really believe that the collector should add these tags to support such scenarios.
veyalla
For own modules it isn't a problem to evaluate the environment variables and expose tagged metrics like:
However 3rd party applications running on the edge aren't aware of their environment and may expose something like:
If the metrics collector now transfers metrics from multiple devices or instances the metrics are no longer assignable in the cloud.
Since the metrics collector is aware of it's environment I suggest that it adds tags for
edge_device,iothubandsourceif they are not already present.I hope the problem is obvious. So I keep the description short; but please don't hesitate to contact me if I was unclear, could provide further explanations or could contribute in any way! Thanks in advance for your support.