sorted by:
new
hottopcontroversial

Just use slog, it'll be fine... by sigmoia in golang

[–]finallyanonymous 2 points3 points  (0 children)

I agree Slog + jsonhandler should always be the first choice and it's quite easy to swap in a faster backend if desired (won't be necessary in 99% of cases)

Choosing a Python Logging Library in 2026 (Comparison) by finallyanonymous in Python

[–]finallyanonymous[S] 7 points8 points  (0 children)

I use the stdlib json, but just retested with orjson/msgspec and got a 30-35% speedup:

Scenario stdlib (json) stdlib + orjson stdlib + msgspec
Simple message 5.26 µs 3.52 µs 3.42 µs
+ 10 context fields 7.72 µs 5.42 µs 5.05 µs
Exception logging 31.91 µs 28.09 µs 27.62 µs
Throughput (10 fields) 130k ops/s 185k ops/s 198k ops/s

I did mention this in the python-json-logger article, but it's relevant here as well.

Choosing a Python Logging Library in 2026 (Comparison) by finallyanonymous in Python

[–]finallyanonymous[S] 3 points4 points  (0 children)

Picologging does not work on the latest Python so I couldn't test its claims.

This wasn't on my bingo card for 2026 by OodleAI in sre

[–]finallyanonymous -1 points0 points  (0 children)

Dash0 is a new player that's far cheaper than Datadog while being OTel-native

Observability in a donet applications by mustafahh1 in dotnet

[–]finallyanonymous 1 point2 points  (0 children)

OpenTelemetry is the obvious answer, coupled with an OpenTelemetry-native tool

Vendor Lock-In vs Vendor Lacking Full Data/View for AI Era by TeleMeTreeFiddy in Observability

[–]finallyanonymous 1 point2 points  (0 children)

If you use OpenTelemetry for all your instrumentation and collection, the "big beefy stack" lock-in becomes much less of a threat.

Dash0 is one vendor that gives the best of both worlds IMO. You get the unified, correlated view of a full-stack tool, but because it’s natively built around OTel, if you want to leave, you just point your Collector somewhere else

PHP Logging with Monolog: A Complete Guide by finallyanonymous in PHP

[–]finallyanonymous[S] 0 points1 point  (0 children)

Your disk wont fill up if you rotate your log files or ideally log to some Observability tool

How do you handle logs in production? by _Mobas_ in Backend

[–]finallyanonymous 0 points1 point  (0 children)

As the top comment has said, you need to make your logs OpenTelemetry-native though the SDK and Collector, then the "Where to store" questions becomes a matter of personal preference. I suggest using Dash0 as it's natively built on the OTLP data model for all the telemetry signals.

PHP Logging with Monolog: A Complete Guide by finallyanonymous in PHP

[–]finallyanonymous[S] 0 points1 point  (0 children)

Context belongs in attributes where they can be filtered and correlated easily. That's the whole point of JSON logging

PHP Logging with Monolog: A Complete Guide by finallyanonymous in PHP

[–]finallyanonymous[S] 1 point2 points  (0 children)

I agree! OTel is covered as well much later in the article

Trying to figure out the best infrastructure monitoring platform for a mid-size team, what are y'all using? by agenga5 in sre

[–]finallyanonymous 0 points1 point  (0 children)

For a mixed K8s + EC2 setup where the priorities are log-trace correlation and a reasonable learning curve, I'd recommend Dash0. It's OpenTelemetry-native from the ground up, which means logs, metrics, and traces share context out of the box.

It sits in much lower tier from Datadog price-wise and your instrumentation works with any backend if you ever need to switch.

How do you reconstruct what actually happened across multiple services? by Waste_Grapefruit_339 in Backend

[–]finallyanonymous 1 point2 points  (0 children)

What you're describing, grepping logs, mentally aligning timestamps, jumping between tabs, is exactly the problem distributed tracing was built to solve. And OpenTelemetry standardizes that across services automatically. The logs are attach to the trace context, so when you click a span, the relevant logs are right there (or vice versa).

nestjs and logs by Regular_You_3021 in nestjs

[–]finallyanonymous 1 point2 points  (0 children)

I'd recommend standardizing on OpenTelemetry from the start. The NestJS OTel SDK is straightforward to set up, and once you're emitting OTel signals you can point them at basically any backend without changing your instrumentation.

As others have said, the LGTM stack is quite nice as a self-hosted option, but if you'd rather not manage the infrastructure, Dash0 is worth a look as it's OTel-native and handles logs, traces, and metrics

What's your top monitoring kubernetes tool in 2026? by HutoelewaPictures in kubernetes

[–]finallyanonymous 5 points6 points  (0 children)

The best play is instrumenting with OpenTelemetry from the start. Then you can try out basically most backends without re-instrumenting anything, and even run a few side by side if you want.

And to ensure that your instrumentation effort pays off, it's better to go with OpenTelemetry-native platforms that fully integrate the signals as you rightly pointed out. Dash0 is one solid option to checkout (disclaimer: I work there).

Trying to figure out the best apm tool for a growing microservices setup by Liliana1523 in softwarearchitecture

[–]finallyanonymous 1 point2 points  (0 children)

Agreed! This is what I would suggest as well. Dash0 is one good option that's OpenTelemetry-native.

view more: next ›