[NEW] instance metadata collector

[HappyTobi]

Hi all,

I added a new collector for fetch machine / compute information from the provides instance meta data service.
The collector is build to easily integrate other ims services to collect information that are not part of the the filesystem, bios etc.

We think the collector makes totally sense, because the information is node related an should be exposed by them (node_exporter)

Please let me know what you think.
Regards

[SuperQ]

This reaches out over the network, I'm not sure we want collectors that do this inside the exporter.

Maybe this would be more appropriate as a textfile collector tool

[HappyTobi]

It,s a local address, that are only reachable at the node/ server / vm itself.

Azure Example:
https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service?tabs=windows#usage

There are also other ims for other cloud providers that lists information that are only available through the service.

I'm not sure if creating a txt file is so much better. But I'm open to discuss that.

I think to call the service is fine because the default is that the ims exporter doesn't write anything, an if someone enable the collector with for example the "azure" provider it should be fine.

What do you think about @SuperQ is there someone we should add to discuss that?

[SuperQ]

Yes, but the issue is about the behavior outside of cloud providers. It's an unsecured http connection reaching out from the exporter.

The node_exporter is used in a lot of places that are not cloud.

[HappyTobi]

For sure, the default is that nothing happen.
So no call will be made etc.

[discordianfish]

This doesn't change the fact that no collector is connecting anywhere today, so this needs more discussion

[kfdm]

A bit of a drive by comment on my part, but this seems like something the textfile collector is for 🤔
https://www.robustperception.io/how-to-have-labels-for-machine-roles/

node_ims_info{location="westus",provider="Microsoft.Compute",vm_sku="Standard_A3",vm_zone="1"} 1

Everything in that example seems like something that would be written when a machine is first created 🤔

[HappyTobi]

Hi @kfdm, @SuperQ, @discordianfish

IMHO we have to think about the "instance metadata service" collector concept globally, not related the the first batch of data that I export for azure, because when the concept / collector will be accepted we will also add more static and dynamic data that is part of the ims.

From my perspective the ims collector should be part of the "node_exporter" because the data is direct related to the node itself, we don't collect data from a 3rd party system like "mysql" etc.

The other thing is, that the concept of "ims" does not only exist on cloud environments, there are also one for "openstack", "esxi" etc."

A textfile collector also works for all the other collectors as well :-D , but I think the important point is, that the data that we are collecting, are direct related to the node and not to a 3rd Party service a db, user services etc.

[discordianfish]

Not completely against it but not convinced we want to support this either. Can you explain which information you can only get via the metadata service that are actually node specific? I don't think locations or provider are something that is node specific but more environment specific. So I'd rather expose e.g locations/AZs from where they are configured

[SuperQ]

I would love to have similar metrics in our environment, but I think this would be better built as a textfile script. I don't see a good reason to hit the metadata API every exporter scrape (For example, typical 2x every 15s). Unless this metdata changes often, once on boot is enough.

[HappyTobi]

Hi @discordianfish, hi @SuperQ

ok lets first dig into the question about the properties that are only reachable over the ims (specially for azure)

• Server Zones
• VM Size (SKU)
• Vm Scale Set Name
• SubscriptionId
• VM schedules Events (https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service?tabs=linux#scheduled-events)
• Loadbalancer frontend Ips (ips that are reachable over internet) (https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service?tabs=linux#load-balancer-metadata)

Some of them are dynamic like Loadbalancer information, Scheduled Events

Text vs node_exporter.
Just to tell why I think it make sense to have it at the node_exporter.

1. Same lifecycle as the others
2. The concept is not only available at one cloud provider it's a generic thing to export vm information at a http service.
3. The information that will be provided are vm / compute data and not 3rd party information.
4. Systemd / cron is required to write the text file that would be read and exported later of the text_node exporter. (Extra work)

Further steps / ideas
We can think of switching from the "hardcoded" properties to something like an "--include" flag to give the possibility to the user to configure the exporter properties that should be returned.
Or an exclude or just expose everything we get from the ims.

I just started with a view properties to discuss / see what you think about the "ims" exporter itself. To extend them etc. would be the next step if the "concept" will be accepted.

Thank you.

[HappyTobi]

Any updates? @discordianfish @SuperQ

[SuperQ]

Sorry, I don't think we want this collector in the node_exporter. The listed dynamic information is not appropriate for metrics collection.

[HappyTobi]

@SuperQ

🥲

For us it was required to get some information out of the instance meta data service because there are not available anywhere else.

Some other exporters also export static information about the node, like the "dmi" exporter, thats the reason why I thought It would be possible to integrate the ims service that provides dynamic an static parts.

[frittentheke]

A generic (Python?) script that fetches data from the various metadata services (AWS, Azure, GCP, OpenStack, ...) and then places a metrics file into the textfile collector path would be great.

That could go here: https://github.com/prometheus-community/node-exporter-textfile-collector-scripts/ then and could be extended to support all sorts of providers and their metadata formats ...