search

fnproject / ext-statsapi

Fn extension to extend the Fn API to provide statistical metrics
Apache License 2.0
1 stars 1 forks source link

"Chatty" API #6

Open adoublebarrel opened 6 years ago

adoublebarrel commented 6 years ago

I think what we've got at the moment is a great starting point but I'm wondering if we want to introduce some more query options that might reduce the "chattiness" of the API as it stands.

A common pattern in dashboard style UI's would be to have a list of apps which includes a small graph for each app giving an indication of activity. At the moment a client would need to make a separate request for each graph. With pagination (say you wouldn't expect to list more than 10 apps at a time) maybe this is less of an issue. 10 requests every X seconds where X is the refresh rate of the graphs * the number of clients that are open.

What do you think, worth putting time into a way to aggregate these kind of requests or should we just wait and see if it becomes a genuine problem?

carimura commented 6 years ago

good thinking. might be early for optimizations. maybe wait and see.

nigeldeakin commented 6 years ago

When considering optimisations we need to keep in mind what is happening between the Fn server and Prometheus. Current each call to the new API causes three queries to be sent to Prometheus, one for each of the three metrics (completed, failed, durations). So another way to improve performance (if it is considered a problem) would be to allow the caller to specify only those metrics they need.

ecki commented 6 years ago

I was wondering why the API deals with queries and Prometheus at all. Following the Prometheus (or openmetrics) philosophy wouldn’t it be better to expose a servers current metrics with a Prometheus exposition format page and let the operators worry about scraping it and sending queries to Prometheus. (Of course you can then provide a function which offers the old/chatty query API against any Prometheus server. This also allows to use different monitoring products as long as they support the exposition format. (Maybe this is actually how it internally works, in that case it might be good to include it in the README)