Whenever we run a reducer, we should give the module owner / developer some interface to determine how much energy it consumed. Note that this information is exposed via the WebSocket API (at least as of writing, pgoldman 2024-08-08), but not passed through to the SDKs. Exposing it in the SDKs is not necessarily the most useful place for it, and we should consider whether we want non-owners / anonymous clients to be able to access this information. Likely there should be some way to get this from the CLI. The simplest version is probably having the host log to the module/database's logs after each reducer run with the reducer name, arguments (truncated to some reasonable length), caller identity and address, exit status and energy consumed; then developers could use the spacetime logs CLI command to access it. A slightly better version might be to keep that data in a separate file, to be queried by a different CLI command. More interesting would be to additionally provide percentiles, averages, maximum energy values, cumulative costs, &c for individual reducers and for the whole module.
This data might be exposed via Prometheus / Grafana already for web dashboard users, but it should additionally be available via the CLI for standalone users, though that interface may be less user friendly and provide less analysis.
Whenever we run a reducer, we should give the module owner / developer some interface to determine how much energy it consumed. Note that this information is exposed via the WebSocket API (at least as of writing, pgoldman 2024-08-08), but not passed through to the SDKs. Exposing it in the SDKs is not necessarily the most useful place for it, and we should consider whether we want non-owners / anonymous clients to be able to access this information. Likely there should be some way to get this from the CLI. The simplest version is probably having the host log to the module/database's logs after each reducer run with the reducer name, arguments (truncated to some reasonable length), caller identity and address, exit status and energy consumed; then developers could use the
spacetime logsCLI command to access it. A slightly better version might be to keep that data in a separate file, to be queried by a different CLI command. More interesting would be to additionally provide percentiles, averages, maximum energy values, cumulative costs, &c for individual reducers and for the whole module.This data might be exposed via Prometheus / Grafana already for web dashboard users, but it should additionally be available via the CLI for standalone users, though that interface may be less user friendly and provide less analysis.