Rebrand: Sentry -> Cairn OBS
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.
This commit is contained in:
@@ -1,16 +1,16 @@
|
||||
# Query language reference
|
||||
|
||||
Sentry has one query language for everything: filtering, free-text
|
||||
Cairn OBS has one query language for everything: filtering, free-text
|
||||
search, and aggregation, in a single query, against a single endpoint
|
||||
(`POST /query`), from a single query bar in the web UI or `sentryctl
|
||||
(`POST /query`), from a single query bar in the web UI or `cairnobsctl
|
||||
query` on the command line. You don't pick a "search mode" or a
|
||||
"reporting mode" first — you write one query, and Sentry figures out
|
||||
"reporting mode" first — you write one query, and Cairn OBS figures out
|
||||
which parts need ClickHouse, which parts need the full-text index, and
|
||||
combines them.
|
||||
|
||||
If you already know Splunk's SPL, most of this will feel immediately
|
||||
familiar: a base search, piped through a sequence of processing stages.
|
||||
Sentry's language is a deliberately smaller subset — the operators
|
||||
Cairn OBS's language is a deliberately smaller subset — the operators
|
||||
people actually use day to day, not SPL's full surface area — plus raw
|
||||
SQL as an escape hatch for anything the pipe syntax doesn't (yet) cover.
|
||||
|
||||
@@ -67,7 +67,7 @@ timeout a single bare word
|
||||
message:"connection refused" the same thing, explicit
|
||||
```
|
||||
|
||||
Free-text search is powered by Sentry's full-text index (Tantivy), which
|
||||
Free-text search is powered by Cairn OBS's full-text index (Tantivy), which
|
||||
supports phrase matching and wildcards:
|
||||
|
||||
```
|
||||
@@ -92,7 +92,7 @@ what most people expect from a search bar:
|
||||
error timeout same as: error and timeout
|
||||
```
|
||||
|
||||
`or` works between free-text terms, and Sentry's full-text index handles
|
||||
`or` works between free-text terms, and Cairn OBS's full-text index handles
|
||||
it natively:
|
||||
|
||||
```
|
||||
@@ -176,14 +176,14 @@ tail 50 last 50, chronologically
|
||||
|
||||
## Field mapping: what's a "real" column vs. an attribute
|
||||
|
||||
Sentry's structured columns are `timestamp`, `host`, `service`,
|
||||
Cairn OBS's structured columns are `timestamp`, `host`, `service`,
|
||||
`severity`, `message`, and `record_id`. Anything else you reference by
|
||||
name — `status`, `latency_ms`, `winevt.event_id`, whatever your logs
|
||||
happen to carry — is looked up in the per-record attributes, which are
|
||||
always stored as text.
|
||||
|
||||
This matters for comparisons: `status>=500` only makes sense as a number,
|
||||
so Sentry casts the attribute's text value to a number for you
|
||||
so Cairn OBS casts the attribute's text value to a number for you
|
||||
automatically when the value you're comparing against looks numeric.
|
||||
`status="unknown"` compares as text instead, since `"unknown"` isn't a
|
||||
number. You don't need to do anything differently — this happens based
|
||||
@@ -212,7 +212,7 @@ directly, no pipe-syntax parsing involved:
|
||||
SELECT host, count(*) FROM logs WHERE service = 'api' GROUP BY host
|
||||
```
|
||||
|
||||
SELECT-only, single statement — Sentry allowlists this at the API level.
|
||||
SELECT-only, single statement — Cairn OBS allowlists this at the API level.
|
||||
Use this for anything the pipe syntax doesn't cover yet: window
|
||||
functions, `WITH` clauses, ClickHouse-specific functions, joins across
|
||||
other tables you've added, and so on. There's no performance penalty for
|
||||
@@ -221,7 +221,7 @@ execution plan internally.
|
||||
|
||||
## Which syntax am I using?
|
||||
|
||||
Sentry detects automatically: a query starting with `SELECT` runs as
|
||||
Cairn OBS detects automatically: a query starting with `SELECT` runs as
|
||||
SQL, anything else runs as the pipe syntax. This covers the overwhelming
|
||||
majority of real queries with no extra step. If you're writing a pipe
|
||||
query that happens to start with the literal word "select" as a search
|
||||
@@ -237,7 +237,7 @@ detected next to the query box, with a dropdown to override it.
|
||||
|
||||
## Combining free-text search with aggregation
|
||||
|
||||
This is the case that makes Sentry's query language more than "SQL with
|
||||
This is the case that makes Cairn OBS's query language more than "SQL with
|
||||
extra steps" — free text and aggregation, together, in one query:
|
||||
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user