Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: An open source performance monitoring tool (github.com/highlight)
135 points by podoman 9 months ago | hide | past | favorite | 32 comments
Hey HN. We’re Jay and Vadim from Highlight.io (https://highlight.io). We’re building an open source [1] monitoring platform for web applications.

Today we’re excited to be sharing a performance tool we’ve been working on, which helps you inspect the latency of code execution from the client to the server. As engineers at past startups, we often had to debug slow queries, poor load times, inconsistent errors, etc... While tools like Jaegar [2] helped us inspect server-side performance, we had no way to tie user events to the traces we were inspecting. In other words, although we had an idea of what API route was slow, there wasn’t much visibility into the actual bottleneck.

This is where our performance product comes in: we’re rethinking a tracing/performance tool that focuses on bridging the gap between the client and server.

What’s unique about our approach is that we lean heavily into creating traces from the frontend. For example, if you’re using our Next.js SDK, we automatically connect browser HTTP requests with server-side code execution, all from the perspective of a user. We find this much more powerful because you can understand what part of your frontend codebase causes a given trace to occur. There’s an example here [3].

From an instrumentation perspective, we’ve built our SDKs on-top of OTel, so you can create custom spans to expand highlight-created traces in server routes that will transparently roll up into the flame graph you see in our UI. You can also send us raw OTel traces and manually set up the client-server connection if you want. [4] Here’s an example of what a trace looks like with a database integration using our Golang GORM SDK, triggered by a frontend GraphQL query [5] [6].

In terms of how it's built, we continue to rely heavily on ClickHouse as our time-series storage engine. Given that traces require that we also query based on an ID for specific groups of spans (more akin to an OLTP db), we’ve leveraged the power of CH materialized views to make these operations efficient (described here [7]).

To try it out, you can spin up the project with our self hosted docs [8] or use our cloud offering at app.highlight.io. The entire stack runs in docker via a compose file, including an OpenTelemetry collector for data ingestion. You’ll need to point your SDK to export data to it by setting the relevant OTLP endpoint configuration (ie. environment variable OTEL_EXPORTER_OTLP_LOGS_ENDPOINT [9]).

Overall, we’d really appreciate feedback on what we’re building here. We’re also all ears if anyone has opinions on what they’d like to see in a product like this!

[1] https://github.com/highlight/highlight/blob/main/LICENSE

[2] https://www.jaegertracing.io

[3] https://app.highlight.io/1383/sessions/COu90Th4Qc3PVYTXbx9Xe...

[4] https://www.highlight.io/docs/getting-started/native-opentel...

[5] https://static.highlight.io/assets/docs/gorm.png

[6] https://github.com/highlight/highlight/blob/1fc9487a676409f1...

[7] https://highlight.io/blog/clickhouse-materialized-views

[8] https://www.highlight.io/docs/getting-started/self-host/self...

[9] https://opentelemetry.io/docs/concepts/sdk-configuration/otl...





Hi, this looks really nice as an alternative to Sentry. May I ask why the Docker-based setup requires Go, Node and Yarn on the host machine? I find it unfortunate that I have to install such non-standard tools on a machine to be able to run a setup that is based on Docker. This makes the whole setup way more complicated than it should be.


I can confirm shortly, but I believe you don’t actually need those installed locally. That might be a mistake in our docs! Have you tried the docker setup without those tools?


No not yet, but the scripts in the docker directory have several steps involving both go and Node. Guess it's scripts for setting up the Docker stuff?


(Im on mobile- sorry for the brevity/lack of deep demo context, it seems like the demo links dont work super gracefully on mobile)

I clicked into the demo (reference 3 in your post) and I dont get how this is different from any off the shelf OTel solution like Lightstep or Jaeger. Otel already has client side vendors and SDKs (I was the engineer who introduced OpenTracing to Plaid, and we did both). Bridging cross-network traces is literally the point of OTel, so Im not sure why thats a differentiator for you… every system does it.


The difference is that we also expose what the user is interacting with when these traces get fired. Perhaps on mobile your aren't able to view that?


Sorry to be that guy, but the monospace font stack used for e.g. logs is... not optimal for Windows:

    IBM Plex Mono,Menlo,DejaVu Sans Mono,Bitstream Vera Sans Mono,Courier,monospace
...will end up being "Courier" and that's not good in any way, shape or form. Consolas, Cascadia Code|Mono, even Lucida [Sans] Console are much nicer, and would spruce up the Safari experience for some segment of your audience.

Plus, not sure why timestamps use font-light (this is Tailwind, right?), it just makes these less readable, while not taking up less space or anything.


Sorry about that. Will relay this to the team. We're mostly a mac shop, but definitely hear you.


It's alright man. Everyone can't pay attention to everything. All the best.


"We're mostly a mac shop" is probably the worst excuse you could give.


You must seriously lack imagination if you can't think of a worse excuse.


what is wrong with courier?


Some of the traces include some important information regarding Supabasehttps://imgur.com/a/m9nTt2h


Your home page is apparently a "welcome back" screen. I can't sign in with Github, get the error "Unable to process request due to missing initial state. This may happen if browser sessionStorage is inaccessible or accidentally cleared. Some specific scenarios are - 1) Using IDP-Initiated SAML SSO. 2) Using signInWithRedirect in a storage-partitioned browser environment."

Would be nice to be able to see the product without having to sign in.


Hi! Per "Would be nice to be able to see the product without having to sign in.":

You should be able to see the demo product at https://app.highlight.io/demo, but let us know if this isn't working


Are you referring to link [3]? And taking a look at the GitHub issue, thanks for sharing.


im referring to https://app.highlight.io


Highlight engineer here. Thanks for raising, this should be back up. We synced our GitHub app and Firebase auth urls.


Would this be useful to Shopify Shop Owners, those who buy 3rd party/additional apps on the shopify app store (or any similar such services, like an etsy store)?

Can this be used as a pen-testing tool to Highlight-TraceRt through a {target url}?

--

Re:

Yeah, though what benefits would surmise a Shopify Shop Keeper could get from your service, or do you think this is a tool that Shopify Corporate should be using on their hosting infra?


Our browser client would help with tracing what network requests are being made by said apps since it would capture all network requests. However, Shopify may restrict what our browser client can do in your frontend store (I'm guessing that the 3rd party apps are added to a shop as iframes or are otherwise sandboxed).


> I'm guessing that the 3rd party apps are added to a shop as iframes or are otherwise sandboxed

I build Shopify apps, it depends on what kind of app it is, but if it’s on the storefront then it’s generally just injected through an async javascript script tag. They don’t do any iframes or sandboxing on the storefront, although they’re definitely moving toward more privacy-conscious APIs.


Some additional thoughts. For Shopify store owners, they can definitely install Highlight if they have access to the site that they're hosting (we have some customers in this space!). This can help with optimizing their user experience, etc.. For our tracing SDKs in particular, they would only really work if the shopify developers have their own proprietary code running, however, because this requires application instrumentation.


>This can help with optimizing their user experience, etc.

Please, maybe have some success cases with a "how to implement on your shopify" page?


Fyi, in the readme, the screenshot for the logs is the same as for the traces. I wanted to see the traces, so that was confusing.



I'm curious: Why don't you have a PHP SDK? You know, the language that runs over 70% of the internet.



Oh nice, I didn't see it listed on their website, so I assumed there wasn't one.


this is cool!

Does this only collect logs from frontend?

Or it can also collect the backend and DB latency data related to a frontend interaction?


We collect logs across the stack. Here's some docs on our backend logging integrations (we also have connectors for major cloud providers): https://www.highlight.io/docs/getting-started#for-your-backe...


Might I suggest a complementary future feature set of load testing?


We've thought of that briefly. You're essentially asking for some sort of synthetic monitoring right?

Definitely something we're thinking of. If you have any particular requirements, we're all ears.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: