Extends the heartbeat mechanism with a second gRPC service on the same mTLS channel (AgentControl.CheckIn, agent-initiated on the existing heartbeat ticker -- still push-only, no inbound port on any agent) so an agent reports its running config and can pick up an operator-set override. A new web UI section (/agents) lists every agent that's checked in, shows its reported config, and lets an operator edit a narrow, deliberately-scoped subset remotely: batch/heartbeat tuning, and (journald sources only) the unit filter. TLS material and the ingest endpoint are never reportable or remotely editable, by proto shape rather than a validation rule -- a bad or malicious edit there could permanently strand an agent or redirect where its logs go, unlike every other editable field, which only degrades behavior. An override lives only in the agent's memory (agent.toml is never rewritten) and re-syncs on the agent's own schedule; changing the journald filter aborts and respawns the source task since there's no other way to change what's being tailed. Building the hot-reload path surfaced a real, independent, pre-existing bug: shutdown was using poll_timeout(), which only drains once flush_interval has elapsed, silently dropping anything buffered more recently on every graceful shutdown that landed between flushes -- fixed with a new unconditional Batcher::flush_all(), now used at both shutdown and hot-reload. Verified live end-to-end against a real stack: an edited heartbeat interval changed a running agent's actual send cadence within one check-in cycle (confirmed by the real timestamps landing in ClickHouse), and an edited journald filter triggered a real source restart, both reflected back in the next reported-config snapshot. See /docs/agent-management-design.md.
37 lines
1.5 KiB
Markdown
37 lines
1.5 KiB
Markdown
# proto
|
|
|
|
Shared `.proto` contracts. Source of truth for the agent↔ingest gRPC
|
|
service; each language generates its own bindings from these files rather
|
|
than sharing generated code across languages.
|
|
|
|
- `sentry/logs/v1/logs.proto` — `LogIngest.PushBatch`, the data-plane RPC
|
|
an agent calls to ship log records.
|
|
- `sentry/agent/v1/agent_control.proto` — `AgentControl.CheckIn`, the
|
|
control-plane RPC an agent calls (on its own heartbeat ticker, same
|
|
push-not-pull posture) to report its config and fetch any remote
|
|
override -- see /docs/agent-management-design.md. Same mTLS
|
|
connection/listener as `LogIngest`, a second service on it rather than
|
|
a second protocol.
|
|
|
|
## Go bindings
|
|
|
|
Go is the one language here with pre-generated, checked-in bindings
|
|
(`sentry/logs/v1/logs.pb.go`, `logs_grpc.pb.go`), living in this directory
|
|
as its own module (`github.com/sentry/sentry/proto`) that `/ingest` and
|
|
`/api` depend on via a local `replace` directive in their `go.mod`. Rust
|
|
(`/agent`) instead generates its bindings at build time via `tonic-build`
|
|
(see `agent/sentry-agent/build.rs`) — no checked-in Rust output.
|
|
|
|
To regenerate the Go bindings after changing either `.proto` file:
|
|
|
|
```sh
|
|
go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
|
|
go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest
|
|
|
|
cd proto
|
|
protoc --go_out=. --go_opt=paths=source_relative \
|
|
--go-grpc_out=. --go-grpc_opt=paths=source_relative \
|
|
sentry/logs/v1/logs.proto sentry/agent/v1/agent_control.proto
|
|
go build ./...
|
|
```
|