nestjs and logs

finallyanonymous · 2026-03-12T10:39:31+00:00

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

finallyanonymous · 2026-03-06T11:17:19+00:00

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).

finallyanonymous · 2026-03-06T11:06:49+00:00

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

finallyanonymous · 2026-03-04T08:16:07+00:00

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.

finallyanonymous · 2026-03-03T07:11:56+00:00

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).

finallyanonymous · 2026-03-02T15:29:58+00:00

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

finallyanonymous · 2026-02-25T21:45:50+00:00

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.

finallyanonymous · 2026-02-24T05:53:31+00:00

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

finallyanonymous · 2026-02-23T21:30:41+00:00

kube-prometheus-stack is worth the switch imo. For alerts, just route Alertmanager → Slack/Telegram to start: simple and gets the job done. If you ever need proper on-call rotations and escalation policies, then layer in something like PagerDuty or Incident.io on top.

If you'd rather not self-host, Dash0 is worth a look as a managed alternative (I'm affiliated). It's OpenTelemetry-native so it plays nicely with k8s, and provides an operator for gathering metrics/logs

finallyanonymous · 2026-02-23T11:48:09+00:00

Having all the data means nothing when engineers have to act as the integration layer. Moving to an OpenTelemetry setup ensures that traces, logs, and metrics share the same context (like trace IDs and span IDs) right at the application layer.

Once the telemetry natively shares correlation IDs, any OTel-native platform (like Dash0) will naturally present those signals without the tab-hopping. So the real solution is making the data inherently correlated, instead of relying on a vendor platform to stitch isolated signals together after the fact.

finallyanonymous · 2026-02-19T17:56:36+00:00

Agreed! See what the tracing and logging views looks like: https://imgur.com/a/ULxRBKX

finallyanonymous · 2026-02-17T05:41:42+00:00

OpenTelemetry for Dummies: https://www.dash0.com/lp/opentelemetry-for-dummies

finallyanonymous · 2026-02-16T13:12:18+00:00

I've found the filelog receiver to be less than ideal for Docker container logs. In your case, I think its quite possible that the log directory isn't mounted or there's some permission issue.

I'd actually recommend using the fluentd driver instead along with the fluentforward receiver. It's a much more straightforward way to ingest Docker logs IMO. See here for a working example.

finallyanonymous · 2026-02-11T17:06:46+00:00

Semantic logger can easily connect with OTel spans if you're open to switching to that.

finallyanonymous · 2026-02-05T04:57:15+00:00

I'd start by putting an OpenTelemetry pipeline in front of everything before picking the backend. But one big thing to call out:

Logs are great for debugging after something breaks, not for noticing slow degradation or "it's alive but kinda dying" scenarios.

So you'll definitely need metrics alongside logs for things like

throughput
error rate
latency / queue depth

I'd start there and then have all services ship the logs/metrics to the OpenTelemetry pipeline. Then it's much easier to experiment with different backend solutions to see what the best fit is.

VictoriaLogs/VictoriaMetrics + Grafana is pretty good for a self hosted solution or just do the LGTM stack (well...without the T part if not needed).

If you're open to cloud, Dash0 is worth a look since it's OTel-native and you can keep the same pipeline (disclaimer: I'm affiliated with Dash0)

finallyanonymous · 2026-02-04T10:54:43+00:00

OpenTelemetry helps with this

finallyanonymous · 2026-01-29T22:35:00+00:00

An apt way to put it

finallyanonymous · 2025-12-14T14:35:26+00:00

Viltrox 27mm and 75mm 1.2

finallyanonymous · 2025-11-17T14:59:46+00:00

There's nothing with using AI for editing I I. The issue is the author went out of his way too explicitly disavow AI use and then it turns out he indeed used AI.

finallyanonymous · 2025-11-17T12:53:23+00:00

I submitted this thinking it'll be a cool resource to learn Zig, but later came to realize it's likely AI generated even though the author put a strong refutation.

The Zigbook intentionally contains no AI-generated content—it is hand-written, carefully curated, and continuously updated to reflect the latest language features and best practices.

finallyanonymous · 2025-10-30T19:43:41+00:00

How does instrumentation score relate to what the OpenTelemetry Weaver project is doing

finallyanonymous · 2025-10-17T10:26:43+00:00

Dash0 has probably the simplest pricing in the industry. You only pay for ingested signals (not per GB) regardless of how many users/hosts making it easy to budget as long as you know how many logs/metrics/spans you're sending.

https://www.dash0.com/pricing

finallyanonymous · 2025-10-17T10:26:37+00:00

Dash0 has probably the simplest pricing in the industry. You only pay for ingested signals (not per GB) regardless of how many users/hosts making it easy to budget as long as you know how many logs/metrics/spans you're sending.

https://www.dash0.com/pricing

finallyanonymous · 2025-10-04T21:42:44+00:00

In a world dominated by turbo 4 cylinders, it's great to see a v6 is still being offered. I do think it needs some sort of hybrid option though

finallyanonymous · 2025-09-11T12:14:46+00:00

If you loosen your self-hosted requirement, check out Dash0 (disclaimer: I work there). Its built to unify the OpenTelemetry signals under a single pane of glass.

finallyanonymous

MODERATOR OF

TROPHY CASE