What are API Calls?
Besides monitoring real user experience in browser, Plumbr server-side agents are designed to monitor the APIs published on the server-side. Currently Plumbr supports APIs running on Java Virtual Machines (JVMs), PHP (both on FPM and Apache), Python (CPython and PyPy, with or without uWSGI) and reverse proxies (nginx, Apache).
The API call is monitored from the moment it arrives to the server until the response is sent to the caller. The API call duration and its outcome are registered similar to the user interactions, making it possible to expose the performance and availability of the API.
Depending on the situation, zero, one or two copies of the API call can be created by Plumbr:
- In case the upstream server to the JVM processing the API call did not contain either Plumbr Browser Agent nor a server agent, one instance of the API call is created.
- In case a Plumbr Browser Agent was monitoring the real user experience upstream to the server processing the API call, two copies of the API call are created. First instance is linked with the ongoing user interaction and will be a part of the distributed trace reflecting the entire user experience throughout the back-end infrastructure. Second instance will be linked to the specific API and will be reflecting the performance & availability of the specific server-side API.
- In case a Plumbr Agent was monitoring the server directly upstream to the server processing the API call, no separate API call is registered for this sub-API by default. You can gain full transparency to a specific API that is part of the distributed back-end, by enabling API calls forking either on JVM settings screen or on Cluster settings screen:
Additional server-side monitoring increases the transparency, as all interactions are now traced to all server-side nodes to more precisely capture the evidence needed for solving the potential error or bottleneck.
That being said, we strongly recommend to start monitoring the real user experience first by adopting our Browser Agent and adding the server-side monitoring during the second phase of adoption. Without understanding the true user experience, exposed insights from the server-side are missing the proper context and making it hard to make informed decisions.