highlight VS jaeger

[2] https://app.highlight.io/error-tags

[2] https://github.com/highlight/highlight/tree/main

We have an SDK request here: https://github.com/highlight/highlight/issues/4225

We don't have a particular leaning towards javascript, but haven't gotten to PHP yet. We're definitely open to contributors, but otherwise, we can hopefully get to this in the coming months.

Hi Hacker News! We’re Jay and Vadim from Highlight.io (https://highlight.io). We’re building a truly open source [1] observability platform for modern web applications. We posted some of our tools to HN in recent months [2][3]. Today, we’re excited to formally launch the project, share more about where we’re going, and of course, poll the community for some feedback.

A bit of background: Vadim and I have worked at quite a few startups at this point, and a recurring challenge we’ve faced was tracing usability issues on the frontend to downstream errors and logs on the server. Understanding the real reason behind customer issues was always a chaotic juggling of multiple tools. With the rise of "frontend-forward" frameworks such as NextJS, which blur the boundary between the client and server, the complexity of tracing these issues is only growing.

This is where Highlight.io comes in: our product bridges the gap between client and server to give you a holistic view of your entire application.

At its core, Highlight.io has three main “products”: Session Replay, Error Monitoring, and Logging. The novelty here is not in each product but in how they are connected. For example, in Highlight.io it’s very easy to click from a given error to the associated user session where it is thrown [4], and from a given error, you can easily inspect all of the logs that fired leading up to it. Ensuring that all of our products work together seamlessly with little to no effort is a core principle of our product strategy. If you’re using a common framework [5], for example, we’ll automatically link your frontend sessions with backend errors and logs. No agents, configuring facets, or anything else, It just works.

We depend on several open source projects that help us move quickly. OpenTelemetry (OTEL) [6] is one of them, which helps us with maintainability, i.e. for every language that we support, we only maintain a thin wrapper around its respective OTEL SDK. OTEL is also a great way to enable the community to contribute, and we’re already seeing traction in this space (ie. an open source contributor built a wrapper for a Java SDK [7]).

rrweb [8] is another project we leverage heavily for our session replay product. It drives our ability to record and replay the DOM to visualize user flows in the frontend. We’ve had the privilege to work closely with the rrweb team to ship improvements, and we’re now actively sponsoring the project [9].

ClickHouse [10] has recently become a loved database on our team, as we historically used Opensearch for search-heavy workloads and started to hit growing pains with ingest throughput. We recently rolled it out for our logging product [3] and plan to replace our sessions and errors (and upcoming tracing work) with the database as well.

From a business perspective, Highlight.io is open source under the Apache 2.0 license, and we make money with our hosted product [11]. For the hosted product, you can set billing caps for each offering and we don’t charge for seats. At this point, we have 100+ companies paying for our product (some of which are large enterprises), and thousands of sole developers use Highlight.io every week.

On our roadmap [12] for the future includes metrics, tracing, release management and more. We also are launching several updates this week on our launch week page [13].

Overall, we’re excited to be sharing Highlight.io with the world, and Vadim and I are particularly excited to get some feedback from the HN community. Please give us a test-drive at https://app.highlight.io and let us know what you think. We would love to learn about what you wish you had in an observability product as well as any other experiences and ideas in this space. We look forward to hearing from you!

https://gitlab.com/hyperlink-academy/app https://github.com/highlight/highlight https://github.com/calcom/cal.com https://github.com/Nutlope/roomGPT

I'd be curious to hear how this compares to

https://qryn.metrico.in

and

https://github.com/highlight/highlight

(There are some interesting comparisons/comments vs signoiz in sibling threads).

We only scratched the surface of vanilla-extract here, so check out the documentation if you’re interested in learning more. We’ll continue to share about how we are leveraging it to build the Highlight design system, and all our code is open source if you’re interested in exploring our usage more. All the code for the examples in this article are also available for anyone to fork and play around with as well.

Jaeger maps the flow of requests and data as they traverse a distributed system. These requests may make calls to multiple services, which may introduce their own delays or errors. https://www.jaegertracing.io/

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

For the request following, something like jeager https://www.jaegertracing.io/, because you are talking more about tracing than necessarily logging. For just monitoring, https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack would be the starting point, then it depends. Nginx gives metrics out of the box, then you can pull in the dashboard like https://grafana.com/grafana/dashboards/14314-kubernetes-nginx-ingress-controller-nextgen-devops-nirvana/ , or full metal with something like service mesh monitoring which would provably fulfil most of the requirements

Have you checked out Jaeger [1]? It is lightweight enough for a personal project, but featureful enough to really help "turn on the lightbulb" with other engineers to show them the difference between logging/monitoring and tracing.

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

From the perspective of the realization of GraphQL infrastructure, the interesting direction is "Finding". How to find the problem? How to find the bottleneck of the system? Distributed Tracing System (DTS) will help answer this question. Distributed tracing is a method of observing requests as they propagate through distributed environments. In our scenario, we have dozens of subgraphs, gateway, and transport layer through which the request goes. We have several tools that can be used to detect the whole lifecycle of the request through the system, e.g. Jaeger, Zipkin or solutions that provided DTS as a part of the solution NewRelic.

Jaeger is an open-source, distributed tracing system that monitors and troubleshoots the flow of requests through complex, microservices-based applications, providing a comprehensive view of system interactions.

However, ensuring fault tolerance in distributed systems is not at all easy. These systems are complex, with multiple nodes or components working together. A failure in one node can cascade across the system if not addressed timely. Moreover, the inherently distributed nature of these systems can make it challenging to pinpoint the exact location and cause of fault - that is why modern systems rely heavily on distributed tracing solutions pioneered by Google Dapper and widely available now in Jaeger and OpenTracing. But still, understanding and implementing fault tolerance becomes not just about addressing the failure but predicting and mitigating potential risks before they escalate.

In this article, we'll use HoneyComb.io as our tracing backend. While there are other tools in the market, some of which can be run on your local machine (e.g., Jaeger), I chose HoneyComb because of their complementary tools that offer improved monitoring of the service and insights into its behavior.

The best way to do this, is with the help of tracing tools such as paid tools such as Honeycomb, or your own instance of the open source Jaeger offering, or perhaps Encore's built in tracing system.

In this example, I will create 3 Node.js services (shipping, notification, and courier) using Amplication, add traces to all services, and show how to analyze trace data using Jaeger.