Stats about keys, keyrings and apis - or a mix of those.
Given a URL glob keep counters and timers.
How the statistics system works
Before going into any detail about how to actually get the statistics
it’s probably worth describing how they work. ApiAxle stores it’s
timings, charts and counters in Reids in
RRD style. This means ApiAxle
can store lots of information starting at a high level of detail for
more recent data, and gradually widening the aggregates as the data
Internally, any class that wants to provide statistics gets the
following definition, or one like it:
Nice and simple. Without worrying too much more about low-level
implementation details (you can always read the source), the
Counters object has a method log which, when called, will
increment a named counter. Each of the above granularity level will
have their named counters incremented and each counter will only live
for their retrospective redis_ttl. So, you can see two hours-worth
of second level data and two years-worth of day level data.
So, what can ApiAxle capture?
Taking one of the
Guardian APIs as an
example, with the following setup in a local ApiAxle instance:
And a keyring to group our keys:
This registers the guardian API and two keys which are linked to that
API and can make calls to it. To make it a bit more interesting lets
say we want to capture the /search path specifically too:
This says, match exactly except q can be equal to anything.
Let’s make a test call:
This yields the results we would expect from that API. Now lets see
what ways we can see that information:
Provides a simple counter that’ll increment each time a match
occurs. There’s an implicit match for every call made by every key to
an API. Given the call we made above let’s explore ApiAxle’s own API:
One call in the current hour, you can swap hour in this case for
second, minute or day. Let’s wait and then hit the API a few more
times and see what else we can get:
Don’t worry, by default keys can only do two queries a second, we’re
not going to take down the Guardian.
Now ApiAxle’s API tells us:
Let’s ask for the same thing with a second-level granularity. I’ve
snipped the results for the sake of readability:
The calls here all support the forkey and forkeyring query
parameter which allows me to narrow down results even further.
Make a new call as miketyson:
For all of the boxers combined:
As implied above it’s possible to capture individual paths too. We
So all of the above calls should have been caught on this path:
Capturepaths also supports forkeyring and forkey for more
Charts allow you to see the top callers for an API. This is useful for
100 busiest keys for an API (busiest first):
100 busiest APIs (busiest first):
100 Busiest APIs for a key (busiest first):
Timers - min, max, rolling mean
Timings are a way of capturing the speed at which the backend returns
the payload without any ApiAxle overhead in the calculations. For each
of the timestamps the min, max and average times are captured:
Again, forkey and keyring are supported for the calls.
Before we take you further...
Email address problem Please enter a valid email address.
Please fill out your email address and we'll keep
you up to date with interesting features and security
information surrounding ApiAxle.
Note: We will not use this information
for spam, relentless marketing or any other nefarious practice.