Sumo Logic

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build the log system I actually need instead of Sumo Logic — and start by measuring the volume, because that decides everything.

**Under about 50GB a day, this is entirely buildable on your own hardware.** Above that, running a search cluster becomes a job, and the entry is honest that the paid product starts to make sense.

STACK
- Vector or Fluent Bit as the collector on every machine
- Loki with object storage behind it, or ClickHouse if you need real analytical queries
- Grafana for search and dashboards
- Node 20+ with Fastify for anything custom
- Caddy in front

THE ARCHITECTURE THAT KEEPS COSTS SANE
- **Index labels, not content.** Loki's model — a small set of labels, the body left unindexed and compressed — is why it costs a fraction of a full-text engine. Choose labels deliberately: service, environment, level, host. Never a label with unbounded values like a request id, which explodes the index
- Object storage for the chunks. Disk is what makes log systems expensive
- Retention in tiers: seven days hot, ninety days in object storage, a year for anything a compliance rule names

GETTING THE LOGS RIGHT AT THE SOURCE
- **Structured logs, JSON, one event per line, from day one.** Parsing unstructured text later is a permanent tax, and every hour spent on log formats now saves ten in an incident
- Every line carries: timestamp in UTC, level, service, environment, and a correlation id
- **The correlation id is the single most valuable field in the whole system.** Generated at the edge, passed through every service, logged everywhere. Without it a request across four services is four unrelated stories
- Sample the noisy ones: debug at a percentage, errors never sampled

WHAT MUST NEVER BE IN A LOG
- Passwords, tokens, card numbers, authorisation headers, session cookies, and personal data beyond an identifier. **A log system is a copy of your secrets if you let it be**, and it usually has broader access than the database
- Scrub at the collector, deny by default on anything matching a secret pattern, and test it

SEARCH AND ALERTS
- Alert on a rate, not on a single line: errors above a baseline, a new error signature appearing, a queue growing
- **Alert on the absence of expected logs too.** A service that stops logging is a service that stopped, and no error-based alert will ever fire
- Every alert links to the query that produced it

COST CONTROL
- Measure bytes per service per day and publish it. **The team producing 80% of the volume is always surprised to learn it**, and that one chart cuts the bill more than any technical change
- A per-service ingestion cap with a loud alert rather than a silent bill

WHAT MATTERS MOST
Structured logs with a correlation id, labels chosen carefully, and secret scrubbing at the collector. Those three decide whether the system is useful, affordable and safe.