Full rebrand across cosmetic branding, code identifiers, and infrastructure/data-plane naming, using the supplied Cairn OBS logo package. Cosmetic: favicon/logo swap (also closes a stale license-audit finding -- the old favicon was SvelteKit's unreplaced scaffold logo), new centered welcome landing page, larger/legible sidebar logo, page titles, CLAUDE.md/README/docs prose. Code identifiers: Go module path github.com/sentry/sentry -> github.com/cairnobs/cairnobs across all 13 modules and ~91 files (protoc regenerated); Rust crates sentry-agent/sentry-parser/sentry-search -> cairnobs-*; CLI sentryctl -> cairnobsctl; Terraform provider fully renamed (sentry_dashboard etc. -> cairnobs_dashboard, provider type, env vars); every session/auth cookie name; agent config paths and Windows service identity. Deliberately preserved: the gRPC wire protocol's protobuf packages (sentry.logs.v1, sentry.agent.v1) and their Go import directory (proto/sentry/...) -- renaming the wire-level package would break every currently-deployed agent binary (confirmed two real hosts, including mail.inbuxa.com, are actively streaming through this exact contract) until rebuilt and redeployed in lockstep with an ingest cutover. Only the Go module path wrapping the generated code changes. Infrastructure: every docker-compose container name (root and three component-level compose files); the Helm chart (directory, Chart.yaml, named-template helpers, all templates, values.yaml image repos); Kubernetes Operator (CRD group sentry.io -> cairnobs.io, both CRD YAML files, Go identifiers, RBAC markers); the coupled enterprise/tenantcrd package. Caught and fixed real path-coupling bugs along the way: the Helm chart's search/ingest volume mounts and the dev-only-credential detection constant vs. docker-compose.yml's literal values had to move together or a security warning would have silently stopped firing. Data plane: Postgres database sentry_metadata -> cairnobs_metadata and role sentry -> cairnobs; ClickHouse database sentry -> cairnobs; Kafka topic sentry.logs.raw -> cairnobs.logs.raw and its consumer groups. Source-level defaults, docker-compose.yml, and every migrate.sh/ provision script default updated together; already-applied migration files left untouched per this repo's immutable-migration convention. Verified at every layer: all 13 Go modules build/vet/test clean, both Rust workspaces (agent, search) build/clippy/test clean, npm run check/ build clean, docker compose config validates on all four compose files. Live-verified against a real docker stack multiple times through this work, including a final fresh-volume run confirming the actual renamed Postgres database/role, ClickHouse database, and Kafka topic all work end to end with a real login and query, zero console errors.
121 lines
5.8 KiB
Protocol Buffer
121 lines
5.8 KiB
Protocol Buffer
syntax = "proto3";
|
|
|
|
package sentry.agent.v1;
|
|
|
|
option go_package = "github.com/cairnobs/cairnobs/proto/sentry/agent/v1;agentv1";
|
|
|
|
// AgentControl is the control-plane counterpart to logs.v1.LogIngest's
|
|
// data-plane PushBatch -- the same mTLS channel/connection an agent
|
|
// already has open to ingest, a second gRPC service on the same
|
|
// listener rather than a second protocol or connection the agent would
|
|
// need to maintain (see /docs/agent-management-design.md). CheckIn is
|
|
// agent-initiated, called on the agent's own heartbeat ticker: there is
|
|
// still no path for the platform to reach into an agent uninvited. An
|
|
// agent asks "what should I be running" on its own schedule -- the same
|
|
// push-not-pull posture the heartbeat feature this builds on already
|
|
// established.
|
|
service AgentControl {
|
|
rpc CheckIn(CheckInRequest) returns (CheckInResponse);
|
|
}
|
|
|
|
// ReportedConfig is what an agent tells the platform about itself --
|
|
// read-only, for inventory/visibility. Deliberately excludes tls/ingest
|
|
// endpoint fields: those are never reported and never remotely
|
|
// overridable (see DesiredOverride's comment) -- reporting the ingest
|
|
// endpoint back to itself would be redundant (that's exactly the
|
|
// connection this request arrived over), and TLS material has no
|
|
// business leaving the host at all.
|
|
message ReportedConfig {
|
|
string agent_version = 1;
|
|
string source_kind = 2; // "journald", "file", "eventlog", "etw"
|
|
string source_detail = 3; // human-readable summary: unit name, file path, or channel list
|
|
uint64 batch_max_size = 4;
|
|
uint64 batch_flush_interval_ms = 5;
|
|
bool heartbeat_enabled = 6;
|
|
uint64 heartbeat_interval_ms = 7;
|
|
}
|
|
|
|
message CheckInRequest {
|
|
string host = 1;
|
|
string service = 2;
|
|
ReportedConfig current_config = 3;
|
|
// The DesiredOverride.version this agent last successfully applied,
|
|
// empty if it has never applied one. Lets the server distinguish
|
|
// "pending" (an edit exists the agent hasn't picked up yet) from
|
|
// "applied" for the web UI, without the agent needing to know
|
|
// anything about that distinction itself.
|
|
string applied_override_version = 4;
|
|
}
|
|
|
|
// DesiredOverride is the remotely-editable subset of an agent's config
|
|
// -- batch/heartbeat tuning, and, for journald sources, the unit
|
|
// filter. Every field is optional: unset means "no override for this
|
|
// field, keep whatever agent.toml says locally" -- a partial edit only
|
|
// touches the fields it sets. Never includes tls/ingest: those stay
|
|
// local-file-only, permanently, a deliberate security boundary (see
|
|
// /docs/agent-management-design.md) so a bad or malicious remote edit
|
|
// can never strand an agent or redirect where its logs go.
|
|
message DesiredOverride {
|
|
optional uint64 batch_max_size = 1;
|
|
optional uint64 batch_flush_interval_ms = 2;
|
|
optional bool heartbeat_enabled = 3;
|
|
optional uint64 heartbeat_interval_ms = 4;
|
|
// Only meaningful when the agent's local source is journald; ignored
|
|
// otherwise. Empty string means "no unit filter" (tail the whole
|
|
// journal), same semantics as the local config's own unit field.
|
|
optional string journald_unit = 5;
|
|
// Opaque version stamp the platform assigns on every edit. The
|
|
// agent's only obligation is to echo it back as
|
|
// CheckInRequest.applied_override_version once applied -- it never
|
|
// interprets the value itself.
|
|
string version = 6;
|
|
// Extra file paths this agent should tail in addition to whatever its
|
|
// local [source] already is -- never a replacement for the primary
|
|
// source (an agent whose local source is journald can still be told
|
|
// to also tail a file, and vice versa). Unlike every field above,
|
|
// there's no real "unset" state for a list: the web UI/CLI always
|
|
// resubmit the complete desired list on every edit (same "PUT
|
|
// replaces the whole override" convention every other field already
|
|
// follows -- see api/agents/handler.go's handleSetConfig), so an
|
|
// empty list unambiguously means "no extra paths right now," not
|
|
// "don't touch this."
|
|
repeated string extra_file_paths = 7;
|
|
}
|
|
|
|
// AgentCommand is a one-shot action, not a persistent desired state like
|
|
// DesiredOverride -- delivered at-most-once (see CheckInResponse's
|
|
// comment). Scoped deliberately narrow: only RESTART exists today.
|
|
// STOP and UNINSTALL are real, disclosed future work, not oversights --
|
|
// both need genuine OS service-manager integration (systemd's
|
|
// Restart=/RestartPreventExitStatus= semantics vs. Windows SCM recovery
|
|
// options are different enough per platform that hand-waving them would
|
|
// be dishonest), which RESTART doesn't: a graceful shutdown followed by
|
|
// a clean process exit, relying on whatever restart policy the host's
|
|
// service manager already has configured -- the same contract systemd/
|
|
// SCM already expect from any well-behaved service.
|
|
enum AgentCommand {
|
|
AGENT_COMMAND_UNSPECIFIED = 0;
|
|
AGENT_COMMAND_RESTART = 1;
|
|
}
|
|
|
|
message CheckInResponse {
|
|
// False when no override has ever been set for this agent -- it
|
|
// should be running whatever agent.toml already has, untouched.
|
|
bool has_override = 1;
|
|
DesiredOverride override = 2;
|
|
// AGENT_COMMAND_UNSPECIFIED when there's nothing to do. Unlike
|
|
// DesiredOverride, there is no "applied_command_version" echoed back
|
|
// in CheckInRequest: the server clears a pending command the moment
|
|
// it hands it out in a response (see
|
|
// ingest/internal/agentregistry.Registry.CheckIn), not once the agent
|
|
// confirms execution -- a restarting agent's process is gone before
|
|
// it could ever send that confirmation. This is an honest at-most-
|
|
// once delivery, not at-least-once: a command lost to a network
|
|
// failure between this response and the agent acting on it is simply
|
|
// lost, same as any fire-and-forget signal. Re-issuing (PUT
|
|
// /agents/{host}/command again) is the operator's recourse, same as
|
|
// it would be for a `systemctl restart` that silently failed to reach
|
|
// its target.
|
|
AgentCommand pending_command = 3;
|
|
}
|