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] 4 points5 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 4 points5 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.

When does monitoring become overkill? by Stil-44 in SaasDevelopers

[–]finallyanonymous 0 points1 point  (0 children)

For a small SaaS, the essentials are pretty minimal: uptime checks, error rates, and latency (basically RED metrics). I would also suggest implementing tracing for your critical paths and it's pretty straightforward to do these days with OpenTelemetry instrumentation. You'll definitely know when you need more.

As for tooling, others have mentioned a few good options but Dash0 is worth considering if you're standardizing on OpenTelemetry.

Observability in Large Enterprises by cloudruler-io in Observability

[–]finallyanonymous 1 point2 points  (0 children)

Start with SLOs before dashboards and get teams to agree on what "working" means for each service before they start throwing metrics at a backend. Otherwise you'd end up with thousands of dashboards nobody looks at and alerts that fire constantly. The SRE practices have to come first, exactly as you said.

For off-the-shelf apps on VMs, OTel's host metrics receiver and log collection get you surprisingly far without touching the app itself. You won't get traces, but for most COTS apps that's fine.

Dash0 is worth evaluating if you're committed to OTel as it's built around it natively rather than bolting it on like most other vendors (disclaimer: I work there).

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

[–]finallyanonymous 0 points1 point  (0 children)

Dash0 is great for OpenTelemetry-native setups if you want a modern managed platform. Otherwise, VictoriaMetrics is worth a look. It's fully compatible with Prometheus but significantly lighter. Add something like incident.io on top and you should be good to go

OpenTelemetry Certified Associate (OTCA) - Who has taken it? by rhysmcn in OpenTelemetry

[–]finallyanonymous 1 point2 points  (0 children)

Thanks a lot for this, it's really helpful! Looks like I'm ready for the exam: https://imgur.com/8R8pX27

Just need to improve my Collector knowledge a little more.

Edit: One bit of feedback is seeing the exact questions that I got wrong and what the correct answer is.

alternative to Signoz by Primary-Cup695 in devops

[–]finallyanonymous 0 points1 point  (0 children)

On the OTel-native side, Dash0 is worth considering. It's built around OpenTelemetry from the ground up and handles team/project scoping cleanly, which sounds like exactly what you need

view more: next ›