jcoffey-dev
cd8aa290ca
Extends the agent, ingest, storage, api, and web with Windows Event Log/ETW sourcing and Tantivy-backed free-text search, per the approved Phase 1 plan. - CLAUDE.md: materialized on disk (never existed as a file before) with a new Phase 1 "done looks like" section. - agent: Windows Event Log (EvtSubscribe) and ETW sources, Windows service wrapper (install/uninstall/run-service), both feature- and target_os-gated so Linux builds/tests/clippy stay unaffected. Also fixed two pre-existing Phase 0 clippy gaps (dead-code on default-features-only builds, a type-inference edge case) found while testing every feature combination properly for the first time. UNVERIFIED on real Windows -- no Windows toolchain existed anywhere in the build environment; flagged prominently in three places. - proto/ingest: new record_id field, assigned once server-side in ingest's gRPC front end so ClickHouse and Tantivy agree on the same ID for the same record. - storage: record_id column + bloom filter index, verified against a live ClickHouse. - search: new service, Tantivy index, rskafka consumer as an independent second consumer group on the same Redpanda topic ingest already reads. - api/web: new /search endpoint and page, sharing the query page's result-table shape and component. - hack/windows-fixture: sends realistic Windows-shaped data straight to ingest, so the pipeline's handling of it is verifiable without a Windows host. Verified end-to-end on the live docker-compose stack: the same record_id comes back from both /query and /search for the same log line, including for windows-fixture's synthetic Windows Event Log data. Real bugs found and fixed along the way: api/Dockerfile missing proto/ in its build context, search's logs being completely silent (RUST_LOG gap), and search/target/ missing from .gitignore/.dockerignore.
80 lines
2.9 KiB
Protocol Buffer
80 lines
2.9 KiB
Protocol Buffer
syntax = "proto3";
|
|
|
|
package sentry.logs.v1;
|
|
|
|
option go_package = "github.com/sentry/sentry/proto/sentry/logs/v1;logsv1";
|
|
|
|
// LogIngest is the service agents use to ship batched log records to the
|
|
// ingest service over mTLS. Phase 0: single unary batch push. Streaming
|
|
// (client-streaming for continuous shipping) is a likely Phase 1 upgrade
|
|
// once backpressure/flow-control behavior is characterized.
|
|
service LogIngest {
|
|
rpc PushBatch(PushBatchRequest) returns (PushBatchResponse);
|
|
}
|
|
|
|
// Severity follows OTel's severity number ranges (1-24), collapsed here to
|
|
// the coarse names agents actually need to set. Numeric value stored
|
|
// downstream may be a full OTel severity_number computed by ingest.
|
|
enum Severity {
|
|
SEVERITY_UNSPECIFIED = 0;
|
|
SEVERITY_TRACE = 1;
|
|
SEVERITY_DEBUG = 2;
|
|
SEVERITY_INFO = 3;
|
|
SEVERITY_WARN = 4;
|
|
SEVERITY_ERROR = 5;
|
|
SEVERITY_FATAL = 6;
|
|
}
|
|
|
|
message LogRecord {
|
|
// Unix epoch nanoseconds, set by the agent at time of read (not parse or
|
|
// send time) to preserve original ordering as closely as possible.
|
|
int64 timestamp_unix_nano = 1;
|
|
|
|
// Hostname the agent is running on. Agent fills this from its own config
|
|
// or system hostname; not trusted as an identity claim (mTLS client cert
|
|
// is the identity boundary).
|
|
string host = 2;
|
|
|
|
// Logical service/unit name. For journald sources, this is typically the
|
|
// systemd unit name; for file sources, it comes from agent config.
|
|
string service = 3;
|
|
|
|
Severity severity = 4;
|
|
|
|
// Original, unparsed log line. Always populated, even when structured
|
|
// fields below are also present, per the schema-on-read fallback
|
|
// requirement in CLAUDE.md.
|
|
string message = 5;
|
|
|
|
// Structured fields extracted by the agent's parser (e.g. RFC 5424
|
|
// syslog header fields), plus source-provided fields (e.g. Windows
|
|
// Event Log's winevt.event_id/winevt.provider/winevt.channel). Empty
|
|
// when the raw-passthrough fallback fires and the source added nothing.
|
|
map<string, string> attributes = 6;
|
|
|
|
// Stable per-record identifier, used to join Tantivy full-text search
|
|
// hits back to their ClickHouse row (Phase 1). Always empty as sent by
|
|
// the agent — ingest's PushBatch handler assigns this server-side,
|
|
// once, before producing to Redpanda, since both the ClickHouse-writer
|
|
// consumer and the Tantivy-indexer consumer read the same Redpanda
|
|
// messages and need to agree on the same ID for the same record. See
|
|
// /ingest/README.md.
|
|
string record_id = 7;
|
|
}
|
|
|
|
message PushBatchRequest {
|
|
// Agent-assigned identifier for dedup/idempotency on retry. Ingest may
|
|
// use this to avoid double-writing a batch if a retry follows a
|
|
// timeout on an actually-successful push.
|
|
string batch_id = 1;
|
|
|
|
repeated LogRecord records = 2;
|
|
}
|
|
|
|
message PushBatchResponse {
|
|
// Number of records ingest accepted. Phase 0: batches are all-or-nothing,
|
|
// so this equals len(records) on success. Partial-acceptance semantics
|
|
// are not implemented yet.
|
|
uint32 accepted = 1;
|
|
}
|