20:37:57 <barfield> 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
20:38:48 <barfield> trial and error that the triton_sd configuration in triton's prometheus is actually a consul function supported by prometheus directly. 
20:38:52 <barfield> So 
20:39:31 <barfield> 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
20:39:35 <barfield> basically...so to speak lol
20:40:05 <barfield> All of this to say
20:40:54 <barfield> 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
20:41:26 <barfield> 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
20:44:01 <barfield> something like `echo {"\"set_customer_metadata\": { \"vms\": \"$(vmadm lookup) \"}} | vmdate update $(vmadm lookup alias=~prometheus)"
20:45:16 <barfield> Just looking for a way to have prometheus get the UUID's in the .yml file dynamically/periodically to modify the request URL
20:46:40 <barfield> from the GZ where it is hosted of course
20:58:30 <barfield> 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!
21:11:52 <rmustacc> 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?
21:12:06 <rmustacc> If it's the zone itself, you should be able to use metadata.
21:12:25 <barfield> Well, I've got a prom zone running and I need to feed it `vmadm lookup` from the globalzone periodically
21:12:29 <barfield> prometheus sorry
21:13:04 <barfield> Its a list of all zones running on the same GZ as the prometheus zone
21:13:47 <barfield> 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
21:13:52 <rmustacc> So the query you were asking about while inside zone X about others.
21:14:04 <rmustacc> *asking about was
21:14:38 <barfield> 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. 
21:15:30 <rmustacc> 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.
21:16:39 <barfield> 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. 
21:18:47 <barfield> 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. 
21:19:30 <barfield> 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
21:19:40 <barfield> :)
22:29:28 <barfield> Wow, hack but working great!
22:29:32 <barfield> At least for GZ's
22:29:35 <barfield> :)