API Analytics and Monitoring Built In: RED Metrics, p95, Apdex, Live

Intro

0:00 API Maker measures every call of every API, with nothing to install and no code to write. In the next few minutes, you read those numbers, follow an error down to the request that caused it, and watch your servers live.

Monitoring without the glue

0:15 To see how their APIs behave in production, teams usually add an APM agent to every service, a metrics middleware to every endpoint, dashboards to build, alert rules to write, and they SSH into each server to read its memory and its logs. It takes weeks, the tools cost money every month, and each new endpoint must be instrumented again, whoever wrote it. In API Maker, every call is measured from its first request, one page shows it all, with alerts built in, and every server answers the same questions.

0:50 Here is the plan. How API Maker counts. Real traffic on six databases. The Overview. An error, followed down to its request. Percentiles and Apdex. Live numbers, memory, Docker and storage. The root user's view. And the servers and their logs.

How it counts

1:13 First, how it counts without slowing anything down. A caller sends a request, and API Maker answers it. Only once the answer is written, the call adds one to counters in memory, in a shard of its own thread, so threads never wait for each other. Once a minute, each server writes one small document per API, with the counts of that minute. A time to live index keeps them thirty days.

1:38 The Analytics page reads these rollups, not your logs, so turning logging off does not blind it. Each rollup holds the calls, the errors by status class, cache hits, bytes and rows, and the time of every call, sorted into twenty four slots, from one millisecond to one minute. A percentile is read as the upper edge of its slot: a p95 of twenty milliseconds means ninety five percent of the calls finished within twenty.

2:07 Never optimistic. Apdex scores the same slots: under half a second satisfies, under two seconds is tolerated and counts half. And the start of a sandbox is never counted against your API.

Real traffic

2:21 Now, real traffic. For five minutes, the Calm Home shop calls its APIs on all six databases: products from MongoDB, customers from PostgreSQL, orders from MySQL, stock from SQL Server, employees from Oracle and coupons from MariaDB, plus a custom API and a scheduler. Real traffic brings real problems: a sign up form that forgets the last name, a retry with an e-mail already taken, an old app without its token, and a report that sorts a million order events.

Overview

2:55 Open Analytics, in the Operations panel. Every number on the page is measured over the time range of the toolbar: take the last fifteen minutes. Live refreshes the page every thirty seconds; pause it while you read. Then come seven tabs, from the Overview to the storage of the analytics themselves. On top, the health of the fleet, judged by rules built into API Maker. One of them fires here: the error rate of the last fifteen minutes is above its five percent threshold.

3:27 Other rules watch the p95 latency, the memory and the disk, a runtime that falls behind, a server that stops answering, and two versions running side by side. There is no alerting stack to set up. Below, the RED numbers. Rate: the calls, with the average and the busiest minute. Errors: the error rate, and the successes, split by status class. Duration: the p95, with p50 and p99 under it, then the minimum, average and maximum.

4:02 And cache hits, bandwidth, and the rows returned, across all six databases. The charts show traffic and latency, minute by minute. Not sure what a healthy number is? The question mark explains each one, with the range it should stay in. Further down: calls by category, traffic per server, and four lists. The busiest APIs, the APIs that take the most time in total, the slowest by p95, and the ones with the most errors.

4:33 Any table turns into a chart in one click. Total time is the list to read before you cache or optimise: a fast API called all day can cost more than a slow report.

Error drill-down

4:45 Now, follow an error. Click the error rate alert: it opens the Errors tab. Client errors, the four hundreds, stand apart from server errors, the five hundreds, and the APIs that fail most are listed first: the insert of customers, on PostgreSQL. The APIs tab has one sub tab per kind of API, each with its calls and its errors. Open Instance APIs, the generated APIs of your tables: the same tiles, plus Apdex, one score that compares a five millisecond lookup with a two second report.

5:21 Filter by customers, and open the insert. Its own numbers: executions, failures, percentiles, payload, and the status split, with four hundreds from the sign up form and five hundreds from the retries. Why did it fail? Sample requests keep the newest five failed and five successful calls of every API, in the memory of each server, never in a database. Open the newest one: status five hundred, the database refusing an e-mail already taken, the body the retry really sent, and the request id, to find the whole call in the Log Explorer.

Percentiles and Apdex

6:00 Now the slow report. Widen the range to six hours, filter by order events, and open its query API. Its p95 and p99 are counted in seconds, and its calls pile up in the slow slots. For the whole category, the distribution shows each slot with the running total, and the heatmap shows when these APIs are busy, by day and hour. A million rows without an index: Index Maker, in video thirty, fixes exactly this.

Every kind of API

6:30 Every kind of API is measured the same way. Custom APIs: Daily Sales Summary, with its cache hits and the time of its code in the sandbox. Schedulers: Restock Check, every thirty seconds. Nobody waits for a scheduler, so its duration matters more than its percentiles.

In every grid

6:49 These numbers also come to the grids where you work, read once per grid, never once per row. Open Instance API, postgres, crm: each table shows its traffic, the calls of its APIs added up, with their average time. Open customers: every API has its speed, its calls over the day, and the size of its answers. The insert carries a red failure rate. The pill of the grid opens its insights: the calls, the average, the p95, the failures and the Apdex of the table, then its busiest APIs, its slowest and its largest answers when it has any, and the ones that fail most.

7:30 One click opens the insert: its average and its Apdex, five latencies on one scale, its calls and its speed over the day, and the four hundreds of the sign up form next to the five hundreds of the retries. Now the report. In mysql, sales, order events stands out in red. Its query API wears the hourglass of the slowest. Its average and its p95 are counted in seconds, and its Apdex says poor.

8:01 Open in Analytics, and you land on its drill down, for the same day. Nothing to search for: the slow API finds you.

Live

8:09 The Live tab asks every server, every three seconds, what it counted since the last look: requests per second, errors, latency and bandwidth, the fleet, its memory and disk, a live chart, and the hottest APIs right now. One card per server: its version, threads, memory, runtime delay, CPU and uptime. Watch a load test or a deploy, without SSH.

Memory & Disk

8:36 Memory and Disk keeps one sample per server and minute, for thirty days. The operating system of this laptop reports how much of its memory is in use, and API Maker itself takes only a small part of it. The history draws memory, CPU load, runtime delay, swap and disk for each server, and a restart shows as a break in the line.

Docker

8:59 The Docker tab reaches the Docker daemon of every server, and an admin sees only the containers and images API Maker built for the account. Here, the sandboxes of Calm Home that run its custom API and its scheduler: their logs, their CPU and memory history, a restart, and a safe prune that frees disk without touching any data.

Storage

9:23 Storage Of Analytics shows what the analytics themselves cost: metric rows, vitals rows, thirty days of retention and a flush every sixty seconds. Clear stats wipes your saved analytics, after a confirmation. We keep ours.

Root user

9:39 The root user opens the same page from its own home, with every account of the installation in scope. On the Live tab, only root can restart a server: it finishes the requests it is answering, stops, and starts again, while the other servers take its traffic and its schedulers. Not today.

Servers

9:59 Back on the account, the Operations menu opens Servers: every server of the installation, with its version, threads, runtime, the runtimes of its sandboxes, and its machine. Then the settings that matter, from the lifetime of tokens to the largest body accepted, and the database pools of your account. After a deploy, one look tells you every server runs the same version with the same settings.

Process logs

10:24 Native Process Logs reads the output file of any server, the file named by the log file path setting, which the service of the installer writes. Pick a server and reload, download the whole file, or reload it every five seconds. Such a file holds the start of the server, its threads, and everything it prints while it runs. No SSH to tail each machine.

Standard

10:48 Why does it matter? Every API, written by you, by a teammate or by an AI assistant, is measured the same way from its first call: nobody has to remember a counter, a log line or an alert. The same columns, percentiles and rules for a lookup, a report and a cron job. And the request path is never slowed.

Recap

11:09 To sum up. Every call counted after its answer, in one minute rollups kept thirty days. RED numbers, percentiles and Apdex for every kind of API. An error, followed down to the body that caused it. Live numbers, memory, Docker and storage. Every server, its settings and its logs. Next, logging: every detail of a call, in the Log Explorer. API Maker. Build faster, spend smarter, deliver better.