Dashboard metrics fly-cache-status and free vs available memory

Questions / Help
1

I recently found in another thread the ability to use the fly-cache-status to feedback data to the metrics of cache ratio graph in the dashboard.

This is fantastic, however it’s not pulling in the label name in the chart (which I assume should match to the value in the header… eg miss, hit, etc) so while I can see the various rates for the values there is no way to know which is which.

Also, in the chart for the memory usage, is it possible to enable the ability so we can change the query ? Long story, but one of my apps uses sharp in node and libvips, which seems to have some allocation issues (long discussion here: https://github.com/lovell/sharp/issues/955 )

I have noticed it will eventually use all the free memory, but it keeps running just fine with available memory not being 0 (just not being reclaimed as free) so being able to change that query to show it still has available memory would be a nice to have, but not that important/critical.

2

Whoops, I’m looking into that now. Thanks for letting us know!

If you need custom queries, you’ll want to use our metrics API directly. It has the fly_instance_memory_mem_available series. That likely means launching your own Grafana, even a local one will work fine! There are instructions on how to configure Grafana in the docs.

I just noticed we’re not providing the “cache” label in our new metrics API, I’m adding that. What you see on the metrics dashboard on our site is from the “old” metrics API. The missing “cache” label is definitely a bug on our end.

3

Thanks for looking into it… I am seeing how much milage I can get before spinning up and securing Grafana, but since I am about to start pushing some custom metrics I will need to address it soon.

4

I’ve just released a new version of our web app that should’ve fixed the cache metrics!

It used our old metrics API, which was broken. This now uses the new metrics API.

If you haven’t deployed in a month or so, you might have to. The new metrics rely on metadata that’s not present in older deploys.

5

Working great, appreciate the fix!