Hi,

I wanted to make a post because I want to know what other community members think about this topic: roasting people honest about AI usage on their AI usage.

I have called out many projects in the past that were pure slop, oldest commit 2h ago, obviously vibed but pretending they built it. I was quite mean as well...

I think that's reasonable, we're calling bs out when we see it. Here is where I think we need to reconsider, I just read an article shared here about a person explaining how they vibed a slack tui in a weekend. They had a whole section about how they vibed it, how much time it took and how they did it. People were pointing out that it was made with AI in the comments, and it's like, yeah, they said it in the post, it's not like it's being hidden.

Why do I think we should talk about this? Because if we keep dunking on people who are up front about their AI usage they will start hiding it, eventually blurring the line. I'd much rather people be honest and then we can all decide if we want to support a project and use it or not.

Anyhow, I think it would be interesting to see the subreddit policy updated. I personally like seeing how people are using AI especially if it's in a tech article format. Maybe we could update the subreddit rules to further ban/limit vibed projects while allowing tech articles about how something was vibed?

Maybe I'm totally wrong and y'all just don't care, but I'd like to hear other peoples thoughts on this as I think it's interesting.

Rant over

Disclaimer: I am not promoting anything, I'm building an observability platform but it will not be mentioned in this post. If I build anything because of this post it will be MIT open source and otel compatible.

Hi,

I've been dealing with stack traces from mobile and frontend otel clients coming in obfuscated. I've built a small symbolicator I use for sourcemaps, but rn it only works with javascritp and it's not a standalone tool compatible with otel.

I'm considering building a symbolicator that can work with: sourcemaps, flutter, android and ios. I think this would be fun to do and obviously this is a ridiculous amount of work, so before I go down the rabbit hole I wanted to ask how people are handling this in general?

If you do have mobile/frontend monitoring are there oss tools that address this currently? Is symbolication even needed?

Any experience you share would be greatly appreciated.

Thank you!

Hi,

This is a legit question and I'm not promoting anything, won't even mention the name of the thing I'm working on.

I've built an observability tool, for the backend integrations I've used OpenTelemetry as the protocol (so that any otel collector can just be pointed to it and it works). My question is about the frontend/mobile side. Basically I'm working on a Sentry replacement for the frontend/mobile where it captures exceptions and their screen recordings, logs, networking calls, etc.. but I've done it with a custom protocol.

My question is how do I fit this into the open telemetry standard protocol?

I am planing on having a top level span with attributes describing the device/browser, the logs would also be trivial w otel, but what about session replays and page navigations? Those could either be spans or attributes, I guess the session replay could be an attribute (a huge json?) and then each "action" like a page navigation as maybe a span... is this how you'd do this?

Hi,

Over the last 4 months I've been working on an open source replacement for Sentry that is OpenTelemetry compliant for logs/metrics/traces.

Initially it was just built using Clickhouse and Postgres, but a few people in this community suggested making it work with Sqlite. I've done it and have been using it locally for the last 4-5 weeks and honestly it's kinda really nice for the dev environment so I thought I'd share a bit about it. I'll also share how I've done it in case someone else wants to do something similar (make an application compatible with multiple DBs).

The final result is light embedded dashboards for Go that are OpenTelemetry compliant that you can just use to see how your backend is doing.

Why in-memory?

A few use cases this actually unlocks:

OTel tracing without an extra container. You get full OpenTelemetry traces flowing in dev without spinning up OTel collector, Prometheus, Grafana etc. The backend runs as a goroutine inside your own Go process and SQLite handles storage. go run . and you've got a working OTel collector + dashboard at localhost:8082.

Small monolith apps that don't want infra. If you're shipping a single Go binary and the idea of standing up a separate observability stack feels like overkill, this is just… your binary. In-memory by default, optional file path if you want it to persist. No new services to babysit.

Lighter dev loop. No docker-compose to remember to start. No separate worker process. No "oh right, my traces aren't appearing because the agent died". Observability lives and dies with your app, which means restarting your app gives you a clean slate every time.

Keeping the full stack connected. This is the one I didn't expect to care about as much as I do. When you're running both your Go backend and a frontend locally, embedded mode lets you wire the frontend's stack traces and session replays into the same project as the backend's traces. So when something breaks in the browser, you can click through into the backend span that handled the request. This might or might not help you but I like it.

This is the API:

go tracewaybackend.Run(
    tracewaybackend.WithPort(8082),
    tracewaybackend.WithDefaultUser("demo@gmail.com", "Admin123!"),
    tracewaybackend.WithDefaultProject("Backend API", "opentelemetry", backendToken),
)

Point your OTel exporter at http://localhost:8082/api/otel/v1/traces and you're done. When your app exits, the in-memory data goes with it. If you'd rather have it stick around between runs, pass WithSQLitePath("./traceway.db") and it'll write to a file instead.

How?

This is the interesting bit if you want to do something similar for your own project.

The project had 2 distinct types of repositories, those that used the ORM (lit) for PG and those that used Clickhouse directly. PG was used for managing organizations, users and similar "transactional" constructs while Clickhouse was the main data store for telemetry data.

For the repositories using lit, changing the db was zero code changes as the queries in the app already worked with both since the syntax is so similar.

For the Clickhouse repositories I went with build tags. Each repo got renamed to repo.go and I added a repo_sqlite.go next to it with the same function signatures but a totally different implementation. I then use the build tags to pick which one compiles in, the files have go:build !pgch as the first line, super simple to do and worked really well.

Production builds compile with the Clickhouse/Postgres drivers and skip the SQLite stuff entirely. The embedded build pulls in modernc.org/sqlite (pure Go, no CGo, which is the whole reason this is even nice to use) and leaves out the heavy clients.

A few things that were trickier than I expected:

Query translation. Clickhouse has aggregations and array functions that SQLite just doesn't have. For most dashboard queries I ended up writing them twice, once tuned for Clickhouse columnar reads, once in vanilla SQL for SQLite. They return the same shape but look nothing alike.

Retention. Clickhouse handles TTL natively. For SQLite I run a periodic cleanup goroutine.

Docs for embedded mode if you want to try it: https://docs.tracewayapp.com/learn/embedded-mode

Repo: https://github.com/tracewayapp/traceway

I wanted the kind of setup you usually only get from paid tooling, but open source, easy to use but powerful.

I'm happy to answer questions about how any of this works, the implementation or anything in general. The SQLite path was a community suggestion that turned into one of my favorite parts of the project, so more of those welcome. All feedback is welcome!

If anyone thinks this is interesting and wants to join in or has problems setting it up let me know!