CycleOps provides a canister monitoring solution with a simple no-code integration for canisters of any type (Rust, Motoko, Azle, etc.).
So as a trade-off it’s easy to set up monitoring, but metrics are then scoped at the canister level so you (currently) don’t get per API endpoint statistics. We are continuously adding features to the service, so feel free to send me a DM with your requests - it might make it’s way into a library or an extended feature we build in the future 
To answer your questions:
Instead of only checking the cycles balance, it can outline when cycles were used for a specific query
Currently, queries are free (they don’t use cycles)
update call
Cycles are a weighted sum of instruction counts, so in order to achieve this, you’ll need to add code to each API endpoint that you want to measure and use specific instruction counter APIs for counting those instructions. For example, in Motoko, I’d recommend looking at https://internetcomputer.org/docs/current/motoko/main/base/ExperimentalInternetComputer#function-countinstructions.
Another thing to note is that since the performance counter executes instructions itself, by adding it to a production canister I believe you are actually burning more cycles (depending on the usage/instructions used by your canister).
If you simply want to test out the performance of your APIs, I’d recommend deploying to the Motoko Playground that already has this tooling instrumented for you. For example, I just deployed the “counter” example canister there, clicked “enable profiling”, and then clicked install
Then calling the inc() API of the canister returns this
Seeing this, is your use case more for testing the performance of your APIs (i.e. the Motoko Playground is a good solution), or do you desire more in-depth big data logs showing that principal A called API B of canister C at time T, which burned X cycles?