so I hacked my way through getting cmon-agent running in a standalone smartos, installed a prometheus zone, but cmon agent requires the URL to be updated for each VM uuid. Figured out through

trial and error that the triton_sd configuration in triton's prometheus is actually a consul function supported by prometheus directly.

So

VM discovery on triton happening through the cmon zone, I assume is grabbing VM uuids by username in UFDS so that prometheus can discover and scrape

basically...so to speak lol

All of this to say

Is there a way to query VM uuid's from with a zone? I cannot find a discover endpoint in the cmon-agent itself in the API reference

vminfod listens only on `lo` so I couldn't do it that way, I was thinking maybe I could set it in metadata and periodically query metadata

something like `echo {"\"set_customer_metadata\": { \"vms\": \"$(vmadm lookup) \"}} | vmdate update $(vmadm lookup alias=~prometheus)"

Just looking for a way to have prometheus get the UUID's in the .yml file dynamically/periodically to modify the request URL

from the GZ where it is hosted of course

Now that I think about it I could just post it into a file like zones/PROM-UUID/root/tmp/.vms from cron....now just to figure out how to dynamically reconfigure prom!

barfield: When you say you want to query a VM's uuid from with a zone. Is that for the zone itself or something external?

If it's the zone itself, you should be able to use metadata.

Well, I've got a prom zone running and I need to feed it `vmadm lookup` from the globalzone periodically

prometheus sorry

Its a list of all zones running on the same GZ as the prometheus zone

This would usually be done by triton vmapi/ufds/cnapi etc...but I am just trying to get the cmon-agent collector to function as a metrics exporter for a standalone smartos gz

So the query you were asking about while inside zone X about others.

*asking about was

I was just trying to find a way, inside of the zone, to be aware of the UUID's of all of the neighboring zones, on the same gz essentially.

Gotcha. There shouldn't be a way to discover that from within the zone (unless there's an info leak in some kstats) so you'll need to push that in from outside.

Yeah, I was just trying to find the most effective way of doing that. I didn't know if the aforementioned `vmadm lookup` or the gz dropping a .vms file into the zone directly would be better.

I did figure out that prometheus can include other target config files though, so I could just do `vmadm lookup -j -o uuid > /zones/VM_UUID/root/tmp/.vms.json` periodically and then just write prometheus configs in json from the values in that file periodically as well.

Its still hacky, but then again, forcing cmon-agent to work in a standalone smartos node is in and of itself a dirty hack job

:)

Wow, hack but working great!

At least for GZ's

:)