parseable VS highlight

Checkout the release here: https://github.com/parseablehq/parseable/releases/tag/v0.7.0

How does this compare to Parseable?

https://github.com/parseablehq/parseable

First guess is that the underlying storage / query layer is pretty similar (Parquet + Datafusion), but OpenObserve has more built in use cases?

As an aside, it’s awesome that Datafusion’s existence and maturity makes launching a product with scalable analytical reads 10x easier than before and cool to see so many projects integrating it

Another cool rust project in this space for logs: https://github.com/parseablehq/parseable. Using Arrow for the memory format makes life easier for incorporating with other tools like Grafana.

- Visualize with Grafana

https://github.com/parseablehq/parseable

(founder here)

Hello DevOps community, we've been working on https://github.com/parseablehq/parseable for a while now. Would love to get any feedback, questions etc.

Maybe also take a look at: https://github.com/parseablehq/parseable

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