Gather GUIDs from applications only with v4.0.0
Opened this issue · 2 comments
In order to get a list of the noisy neighbour applications up until now (up until the latest 4.0.0 release ) we were using v3.1.0 and the following command to get the GUIDs of the applications together with the log stats:
cf log-meta --noise --guid --sort-by=rate --source-type=application
After we get the guids we run another CF API call to get the organization and space where the app is running:
cf curl /v3/apps?guids=GUID[i]&include=space,space.organization
and the end we show everything as a table.
Now we've installed the latest version of the log-cache cli plugin and we've got an error that the --guid
switch can only be used with --source-type=platform
. Therefore we've tested with:
cf log-meta --noise --sort-by=rate --guid
and in the output we've found guids and names of the CF's system components like:
b7a4131c-d903-4b96-a317-964e1683eac7 100000 11051395 1m25s 84498
99fb2c5e-6a0c-40a7-ae85-d84d7b4c2da7 100000 1012754700 1m9s 86893
cc 100000 1852851914 1m10s 100949
5173064e-ba3d-4ac5-870d-fc4e5189175e 100000 30521455 3m35s 105759
udp_forwarder 100000 2928951589 56s 109205
c828168b-46d0-485f-9311-c532d2657e26 100000 39282416 3m53s 113781
metrics_discovery_registrar 100000 3228728621 50s 120818
forwarder_agent 100000 3378198414 48s 126431
21f89441-0582-48f5-b4f4-2632d51336ea 100000 65673912 48s 132437
4b38f61e-db0f-4112-af0b-9e9366b6ffe8 100000 1205981622 2m30s 136012
metron 100000 3753111887 43s 140506
prom_scraper 100000 3766084995 43s 140872
830fcabf-c3c8-4e58-8d11-38108aa28d45 100000 2015974692 42s 149169
Are the GUIDs
only from running applications? Can we simply run the output through GUID validator to filter out the system components and leave the application guids only?
Is there some other way to get only the guids of the applications?
Best Regards,
Jovan
We have created an issue in Pivotal Tracker to manage this. Unfortunately, the Pivotal Tracker project is private so you may be unable to view the contents of the story.
The labels on this github issue will be updated when the story is started.
Few more further questions and observations:
Why is the --guid
flag only available with --source-type=platform
? I personally think that this does not make any sense as
the platform components don't have guids.
The output of the command cf log-meta --noise --guid --sort-by=rate --source-type=platform
is like:
...
vxlan-policy-agent 31197 0 2h28m50s 205
bosh-dns-adapter 32130 0 2h28m42s 216
netmon 35712 0 2h28m44s 240
rep 46334 0 2h28m50s 307
udp_forwarder 65355 0 2h28m48s 440
cc 83358 0 2h28m54s 500
uaa 92283 0 2h28m56s 623
metrics_discovery_registrar 100000 27876 1h56m24s 860
forwarder_agent 100000 33808 1h51m1s 900g
metron 100000 48670 1h39m59s 1000
prom_scraper 100000 48828 1h39m56s 1005
syslog_agent 100000 63554 1h30m57s 1100
metrics-agent 100000 68140 1h28m41s 1131
gorouter 100000 696710 12m53s 2612
...
In CF, the application names are unique only in a space and to identify an application globally an app guid is needed.
At the moment the command with --source-type=application
parameter returns the app names.
cf log-meta --noise --sort-by=rate --source-type=application
...
log-spammer-0-5 application 1301 0 2h41m28s 8
log-spammer-0-1 application 1299 0 2h41m17s 8
test-node application 1298 0 2h41m17s 8
log-spammer-0-3 application 1299 0 2h41m14s 8
log-spammer-0-2 application 1301 0 2h41m28s 8
...
The only option to get app guids that I've found up until now is to get the apps and platform data together and then to filter out everything that does not have a guid format.
The command is: cf log-meta --noise --guid --sort-by=rate
...
locket 13565 0 3h46m9s 60
faf34e61-09cf-4742-8314-0e1bf60dceb5 15321 0 3h45m37s 68
silk-controller 16106 0 3h46m0s 71
service-discovery-controller 16284 0 3h46m0s 72
log-cache-gateway 18991 0 3h45m9s 84
log-cache-cf-auth-proxy 20345 0 3h45m9s 90
grootfs 30379 0 3h45m36s 91
1c44740b-a6c0-4a96-962b-8798a7c339f5 20591 0 3h45m36s 92
reverse_log_proxy_gateway 21248 0 3h45m0s 94
cc_uploader 21719 0 3h46m10s 96
...
From a usability point of view the operators can not do much about the platform logs, so their focus is on observing how the applications behave. With the v4 of the plugin the only way to correctly identify the apps is to get all the log-meta data like in the last example and filter out the platform components.