CubeAPM CLICubeAPMCLI

CubeAPM does not serve everything on one port. Reads go to 3140, ingestion to 3130, and log deletion to the admin port 3199. A profile holds the server address and all three, and each is overridable by flag or environment variable. Authentication is Ory Kratos. cubeapm login drives the browser flow endpoints, submits the credentials, caches the session cookie, then verifies the connection against the metrics labels endpoint before saving anything. If a later request returns 401 and the profile still holds credentials, the client signs in again, retries once and persists the refreshed session. Profiles sit in ~/.config/cubeapm-cli/config.yaml at mode 0600.

Output shape follows the upstream API rather than a house format. traces get renders a span waterfall in table mode and returns the full Jaeger trace under -o json. metrics query hands back the Prometheus response untouched, so jq '.data.result' behaves as it would against Prometheus itself. logs query streams instead of buffering, emitting one JSON object at a time.

• I did not put a query language on top of the existing ones. Metrics stay PromQL and logs stay LogsQL, so anything already written for either keeps working. The cost is that the two halves of an investigation still read differently, and nothing translates between them.
• Time is one grammar everywhere. --last 30m works on traces, metrics and logs, and --from and --to accept RFC3339, Unix seconds, Unix milliseconds or a relative value like -2h. A timestamp with no timezone is parsed as local time. Reading it as UTC used to shift narrow windows by the offset, and a window that misses everything looks exactly like an outage with no data.
• Log deletion runs as a task, not a command that blocks. logs delete run starts it, list reports on it and stop ends it. Deletion is irreversible, so the documented order is to preview the exact filter with logs query first.
• --read-only is honest about its holes. It blocks ingestion and starting or stopping deletion, but login, config writes, profile switching and update still run. It guards the API surface, not the filesystem. Covering the local writes too is the change I would make next.

cubeapm traces search --service payments --status error --min-duration 500ms --last 2h
cubeapm traces get 4f2a91c0e3 -o json | jq '.data[0].spans | length'
cubeapm metrics query-range 'sum by (service) (rate(errors_total[5m]))' --last 2h --step 1m
cubeapm logs query 'error' --service payments --last 30m -o json | jq -c '{t:._time, m:._msg}'
cubeapm logs field-names --last 30m
cubeapm traces dependencies --last 24h --dot > deps.dot

The window text is identical in every line, which is the entire point. Start from failing spans, open the slowest one, check whether the error rate moved at the same moment, then read the logs for that service and that half hour. field-names exists for a schema I have not seen before, since guessing field names is how a log query returns nothing and teaches nothing. The last line pipes into Graphviz when the question is which service calls which.

It reads what CubeAPM already stores. It draws no dashboards and replaces none. --verbose prints HTTP diagnostics to stdout rather than stderr, so it cannot be combined with a parser. A server address with no scheme is assumed to be HTTPS by the interactive login and HTTP by the general client, which is worth knowing before debugging a connection. A Kratos profile stores the password so it can renew an expired session, so environment variables are the documented alternative. It is MIT licensed, builds with Go 1.26 or later, ships one binary for macOS, Linux and Windows, and Reckon drives it during an RCA.