How Sentinel is put together

Signals #

Sentinel accepts five signal types, all over OTLP.

• Logs — application and system log records.
• Traces — spans forming requests across services.
• Metrics — gauges, counters, sums and distributions over time.
• Database monitoring — query statistics from your engines.
• Profiles — CPU profiles from your processes.

How data flows #

• A collector or agent runs alongside your workload and receives telemetry.
• The ingest endpoint authenticates the sender, admits the payload and queues it.
• The writer processes the queue: parsing pipelines run here, and records are written to their store.
• Query surfaces read the stores directly and return the view you asked for.

Log processing #

Logs are the one signal with processing on the path. Pipelines filter, redact and route each record before it is stored, which is what makes redaction and routing possible at all.

Storage #

• Telemetry — logs, traces and metrics, held by signal type with per-signal retention.
• Configuration and control plane data — members, roles, monitors, dashboards, keys and audit records.
• Archives — your own object storage, for logs kept beyond their live retention.

Organisations #

Everything belongs to an organisation. Telemetry is written under the organisation owning the API key that sent it, and every read is scoped to the organisation of the member making it.

Where the product runs #

Sentinel runs as a container set: the API, a queue, the stores and an agent for each. A single-host deployment is the smallest supported shape; the same images scale out.

What you can rely on #

• Every ingest request is authenticated before it is admitted.
• Telemetry is stored under the organisation that sent it.
• Configuration changes are recorded in the audit trail.
• Log redaction happens before a record is written.