Is there a cycles usage monitoring solution?

[princess_eth]

Is there a cycles usage monitoring solution?

I would prefer that it is more robust than CyclesOps. Instead of only checking the cycles balance, it can outline when cycles were used for a specific query, update call, etc.

[icme]

Hi @princess_eth

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?

[princess_eth]

Thank you for the reminder that query calls do not use any cycles. The CycleOps explanation was helpful, especially in understanding that it currently works at the canister level.

My idea was to monitor cycle usage in real-time, ideally with a breakdown by API and month for each canister.

Maybe that would be a good use case for CyclesOps in the future.

[princess_eth]

Thank you for letting me know about the performance counter and Motoko playground canister profiling feature. I don’t work in Motoko but there seems to be a performance counter example in Rust as well. I’ll have to play with these!

[dmitry]

You can also check canistergeek.app, it doesn’t have all requested features though. But it has logging, it has cycles and memory consumption charts. You can trigger it on each update call - this will give you almost realtime stats. You can’t currently breakdown update calls, but having a chart of all update calls near to cycles consumption chart can give you at least some level of understanding how your update calls influence the consumption.