r0b3r4

You can also check out this one https://github.com/iamtelescope/telescope

Thanks!

That sounds great! Do you have a link? I'd love to check it out.

For me, the most challenging parts are still ahead - live tailing and a plugin system to support different storage backends beyond just ClickHouse. Those will be interesting problems to solve! What was the biggest challenge for you?

Telescope is focused purely on viewing logs for existing data. It doesn’t enforce any specific ingestion setup or schema and doesn’t support traces or session storage.

You can think of it as just one part of a logging platform, where a full platform might consist of multiple components like a UI, ingestion engine, logging agent, and storage. In this setup, Telescope is only the UI.

Well, if you're happy with ELK, you should definitely use it! As I mentioned earlier, I’m not trying to sell anything or convince people to switch from their current solutions - just offering an alternative perspective on how things can be done.

From my perspective, a ClickHouse-based setup can be cheaper and possibly faster in certain conditions – here’s some comparison made by ClickHouse Inc. - https://clickhouse.com/blog/clickhouse_vs_elasticsearch_the_...

My motto is "Know your data". I’m not a big fan of schemaless setups - I believe in designing a proper database schema rather than just pushing data into a black hole and hoping the system will handle it.

Nice idea! However, I’m not experienced enough with Vue (and frontend) development to properly design an exportable component. So, at least for now, I don’t think I’ll be able to make it happen myself.

Despite the fact that Telescope is focused on application log data, it could be used for any type of data as long as it's stored in ClickHouse and has some time fields.

At the moment, I have no plans to support arbitrary data visualization in Telescope, as I believe there are better BI-like tools for that scenario.

Thanks!

I haven't tested the new JSON format in ClickHouse yet, but even if something doesn't work at the moment, fixing it should be trivial.

As for the video service, it wasn’t actually a service but rather a set of local tools:

- Video capture/screenshots - macOS default tools

- Screenshot editing - GIMP

- Voice generation - https://elevenlabs.io/app/speech-synthesis/text-to-speech

- Montage – DaVinci Resolve 19

Telescope is primarily focused on log visualization, not on log collection or preparing ClickHouse for storage. The system does not currently provide (and I think will not ever) built-in mechanisms for ingesting logs from any sources.

I will consider providing a how-to guide on setting up log storage in ClickHouse, but I’m afraid I won’t be able to cover all possible scenarios. This is a highly specific topic that depends on the infrastructure and needs of each organization.

If you’re looking for a all-in-one solution that can*both collect and visualize logs, you might want to check out https://www.highlight.io or https://signoz.io or other similar projects.

And also, by the way, I’m not trying to create a "Grafana Loki killer" or a "killer" of any other tool. This is just an open source project - I simply want to build a great log viewer without worrying about how to attract users from Grafana Loki or Elastic or any other tool/product.

Well, every single name I came up with was already taken and present in GitHub. So...

To be honest, I was more inspired by DataDog :)

Yes, this is exactly where Telescope can be useful (and actually, the way Grafana displays logs was my motivation for writing my own viewer)

Telescope can work with any table in ClickHouse. Of course, not every single ClickHouse type has been tested, but there shouldn’t be any issues with the most common ones

If you want, you can check how it works with the OTEL schema in the live demo here: https://telescope.humanuser.net/sources/otel-demo/explore

As we all know, naming is an unsolvable problem in IT :)

Regarding performance - 95% of Telescope's speed depends on how fast your ClickHouse responds. If you have a well-optimized schema and use the right indexes, Telescope's overhead will be minimal.

Thanks! Telescope is more focused on displaying logs and providing access to them rather than handling log ingestion. In the future, I plan to support various sources like Docker, k8s, and files to improve the local development workflow. However, it's unlikely that Telescope will support fetching logs from remote servers via SSH, as that's not its primary use case.

Hey everyone!

I’m working Telescope - an open-source web-based log viewer designed to make working with logs stored in ClickHouse easier and more intuitive.

I wasn’t happy with existing log viewers - most of them force a specific log format, are tied to ingestion pipelines, or are just a small part of a larger platform. Others didn’t display logs the way I wanted.

So I decided to build my own lightweight, flexible log viewer - one that actually fits my needs.

Check it out:

    Video demo: https://www.youtube.com/watch?v=5IItMOXwugY

    GitHub: https://github.com/iamtelescope/telescope

    Live demo: https://telescope.humanuser.net

    Discord: https://discord.gg/rXpjDnEc