jcoffey-dev
9435115ab7
Saved, shareable multi-panel dashboards (table/line/bar/single-stat panels via gridstack + uPlot, global + per-panel time range, JSON export/import) and threshold/absence alert rules with an ok/pending/firing evaluator and webhook/Slack/PagerDuty delivery. - New /metadata component: Postgres control-plane store for dashboards, panels, notification targets, alert rules/state, and delivery log -- see docs/phase-3-dashboard-design.md for why ClickHouse's MergeTree family isn't a fit for this access pattern (needs real row-level locking and read-your-writes consistency). - api/internal/dashboards: dashboard/panel CRUD, pure -- panel query execution stays client-side, reusing the existing /query endpoint. - New /alerting service: rule/target CRUD, a ticker-driven evaluator (claim-then-evaluate concurrency control, transactional-outbox delivery, query errors and threshold zero-rows never coerced into a false transition) and webhook/Slack/PagerDuty delivery with retry/backoff. See docs/phase-3-alerting-design.md for the full state-machine design and the four correctness properties it implements. - web: /dashboards and /alerts UIs; cli: sentryctl dashboards/alerts list/get/apply, seeding a future Terraform provider's JSON contract. - hack/alert-load-test: 500 rules against real ClickHouse data, real measured results in docs/phase-3-runbook.md. Five real bugs found by actually running this against a live stack (documented in the runbook, not just fixed silently): a latent Phase 2 bug where ClickHouse rejected the timestamp format used for earliest=/latest= queries; a "now" literal token injected into query text; a GridStack/uPlot layout-timing race; JS's Date.parse being too lenient to use as a timestamp-detection heuristic; a rule's "enabled" field silently defaulting to false when omitted; and the evaluator's claim-batch-size and worker-pool-concurrency defaulting to the same value, causing 500 concurrently-due rules to take 125s to cycle through instead of the configured 60s.
70 lines
2.7 KiB
Markdown
70 lines
2.7 KiB
Markdown
# sentryctl
|
|
|
|
Sentry's control CLI.
|
|
|
|
```sh
|
|
sentryctl ping # checks http://localhost:8080/healthz
|
|
sentryctl ping --api http://api.internal:8080
|
|
SENTRYCTL_API_URL=http://api.internal:8080 sentryctl ping
|
|
```
|
|
|
|
Exits 0 and prints `ok` if `/api`'s `/healthz` responds 200; exits 1 with an
|
|
error on `stderr` otherwise.
|
|
|
|
```sh
|
|
sentryctl query 'service=api | where status>=500 | stats count by host'
|
|
sentryctl query 'SELECT * FROM logs LIMIT 10' --language sql
|
|
sentryctl query 'message:"connection refused"' --json
|
|
```
|
|
|
|
Quote the query in your shell — pipe syntax uses `|`, which your shell
|
|
interprets as an actual pipe if you don't. Hits the exact same `POST
|
|
/query` endpoint the web UI does (`internal/querylang` in `/api` does the
|
|
compiling; there's no separate query logic here to drift out of sync —
|
|
see `/docs/query-language-reference.md`). `--language` overrides
|
|
auto-detection, same optional override the HTTP API itself exposes.
|
|
Prints a table by default (stdlib `text/tabwriter`, no new dependency);
|
|
`--json` prints the raw `{columns, rows}` response instead.
|
|
|
|
```sh
|
|
sentryctl dashboards list
|
|
sentryctl dashboards get <id>
|
|
sentryctl dashboards apply dashboard.json # imports a dashboard exported via the web UI's "Export JSON" button
|
|
|
|
sentryctl alerts list
|
|
sentryctl alerts get <id>
|
|
sentryctl alerts apply rule.json # creates a rule from a JSON file shaped like POST /rules's body
|
|
```
|
|
|
|
`dashboards` talks to `/api` (`--api`, same override as `query`/`ping`).
|
|
`alerts` talks to `/alerting`, a separate service with its own base URL
|
|
(`--alerting-api`, or `$SENTRYCTL_ALERTING_API_URL`, default
|
|
`http://localhost:8081`) — see `/docs/phase-3-alerting-design.md`'s
|
|
component boundary for why alerting isn't just another `/api` route.
|
|
`apply` in both cases sends the file's JSON as-is to the corresponding
|
|
create/import endpoint — no reshaping, since the file's shape already
|
|
matches what the endpoint expects (the same JSON the web UI's export
|
|
button downloads, or the same shape `GET /rules/{id}` returns). This is
|
|
deliberately the seed of a future Terraform provider: one JSON contract,
|
|
multiple callers (web export, CLI apply, eventually a provider), not
|
|
three different formats to keep in sync.
|
|
|
|
No CLI framework (cobra/urfave-cli/etc.) — six commands split across a
|
|
few files (`cmd_ping.go`, `cmd_query.go`, `cmd_dashboards.go`,
|
|
`cmd_alerts.go`) is still boring enough not to need one; stdlib
|
|
`os.Args` handling plus a hand-rolled `switch` in `main.go` covers it.
|
|
Revisit once there's a real command tree (nested subcommands, nontrivial
|
|
flag parsing) to justify a dependency.
|
|
|
|
## Building & testing
|
|
|
|
```sh
|
|
go build ./...
|
|
go vet ./...
|
|
go test ./...
|
|
```
|
|
|
|
```sh
|
|
docker build -f Dockerfile -t sentryctl . # context is cli/, not the repo root
|
|
```
|