We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Let’s be honest: Most logs are just noise.
As developers, we too often sprinkle logs like confetti — every function entry, every variable, every heartbeat. Before long, terabytes of meaningless lines pile up, filling dashboards no one reads.
We pay millions of dollars to observability vendors just to warehouse our junk. Every useless log line burns compute, disk and dollars. Logging without intent isn’t observability, it’s littering.
Even with modern observability platforms that [画像:Structured logging makes charting easy and efficient]
Structured logging makes charting easy and efficient.
While many observability platforms offer schema on read, that flexibility comes at a cost. Every query forces the system to scan and parse raw text, line by line, to infer a structure that should have existed in the first place. These queries are computationally expensive, slower and more difficult for a user to write.
Prestructured logs flip that inefficiency on its head. When your data already has shape, you can take advantage of event belongs in the log stream. Some things deserve structure and timing — exactly what spans and metrics are for. If you’re measuring latency, user flow or distributed causality, emit a span instead. Spans capture duration, context and relationships across services and tell you why something was slow or broken, where a log can only shout that it happened.
The same logic applies to metrics, turning repetitive logs into real signals you can alert on and aggregate efficiently. If you find yourself logging the same message hundreds of times per second, you’re not observing, you’re just wasting storage. Measure it once, summarize it, and let your metrics and traces do the heavy lifting.
Logging isn’t a personal debugging diary; it’s a shared artifact for your future teammates. Every line should help someone understand what happened without guessing what you meant. Write logs for the next incident, not your current mood. Your logs tell the story of your system. Make it one worth reading, for example:
Be deliberate. Don’t mark something as an error unless it truly requires action. Overusing ERROR numbs your alerts and trains teams to ignore what matters. Every log level should communicate intent: what needs fixing now, what needs watching and what can be ignored.
That said, trace logging has its place. For example, behind the scenes for ClickHouse Cloud, we The filter processor supports dropping unwanted logs, metrics or traces using the OpenTelemetry Transformation Language (OTTL) with conditions like severity, resource attributes or content patterns.
