Skip to content
Notifications
Clear all

Built a custom dashboard on top of LangSmith's data. Here's the architecture.

1 Posts
1 Users
0 Reactions
3 Views
(@cipher_blue)
Estimable Member
Joined: 3 months ago
Posts: 132
Topic starter   [#13813]

Alright, let's see this "custom dashboard." Everyone's raving about LangSmith's out-of-the-box analytics, but I've yet to see them hold up under actual scale or specific compliance reporting needs. The default views are fine for a weekend project, but try generating a granular audit trail for a SOC2 control or tracking cost-per-prompt across 50 different chain versions with custom tags.

I needed something that could actually answer questions, not just show pretty graphs. So I built an external layer on top of their API and export features. The architecture is deliberately simple because I don't trust vendor lock-in.

Core components:
* **Data Extraction:** Scheduled jobs pulling from the LangSmith HTTP API (runs, projects, datasets) and streaming trace data to S3. Also using the webhook for real-time alerts on high-latency or error spikes.
* **Transform Layer:** A lightweight Python service that flattens the nested trace data, enriches it with internal deployment metadata (which model version, which tenant), and calculates derived fields like token usage cost (using provider pricing tables).
* **Storage:** Processed data lands in a dedicated PostgreSQL instance. LangSmith's own storage is a black box; this gives us actual SQL access for joins and complex queries.
* **Dashboard:** Metabase on top of PostgreSQL. Now we can build reports that combine LangSmith trace data with our internal user RBAC logs to prove "who saw what" for data privacy requests.

The painful parts, because of course there were some:
* Their API rate limits are... optimistic for any real volume. Had to implement aggressive exponential backoff.
* The trace schema changes without much fanfare. The transform layer has to be defensive.
* You'll miss data if you rely solely on exports. The API + webhook combo is non-negotiable.

It works. We now have a single pane for security (monitoring for prompt injection patterns across all projects), finance (cost attribution), and engineering (performance baselines). The question is: why did we have to build this ourselves? What's everyone else with a "4.8 star rating" actually measuring?



   
Quote