mr-karan

Agreed on SQL being the best exploratory interface for agents. I've been building Logchef[1], an open-source log viewer for ClickHouse, and found the same thing — when you give an LLM the table schema, it writes surprisingly good ClickHouse SQL. I support both a simpler DSL (LogchefQL, compiles to type-aware SQL on the backend) and raw SQL, and honestly raw SQL wins for the agent use case — more flexible, more training data in the corpus.

I took this a few steps further beyond the web UI's AI assistant. There's an MCP server[2] so any AI assistant (Claude Desktop, Cursor, etc.) can discover your log sources, introspect schemas, and query directly. And a Rust CLI[3] with syntax highlighting and `--output jsonl` for piping — which means you can write a skill[4] that teaches the agent to triage incidents by running `logchef query` and `logchef sql` in a structured investigation workflow (count → group → sample → pivot on trace_id).

The interesting bit is this ends up very similar to what OP describes — an agent that iteratively queries logs to narrow down root cause — except it's composable pieces you self-host rather than an integrated product.

[1] https://github.com/mr-karan/logchef

[2] https://github.com/mr-karan/logchef-mcp

[3] https://logchef.app/integration/cli/

[4] https://github.com/mr-karan/logchef/tree/main/.agents/skills...

https://mrkaran.dev

Personal blog I update every now and then. Mostly infrastructure, networking, and observability stuff.

Just want to say thanks for creating Vector. We use it heavily at Zerodha and wrote about our setup here: https://zerodha.tech/blog/logging-at-zerodha/

It replaced both Filebeat and Logstash for us with a single binary that actually has sane resource usage (no more JVM nightmares). VRL turned out to be way more powerful than we could imagine - we do all our log parsing, metadata enrichment, and routing to different ClickHouse tables in one place. The agent/aggregator topology with disk buffering is pretty dope.

Genuinely one of my favorite pieces of infra software. Good luck with Tero.

I've landed on a similar philosophy but with a slightly different approach to orchestration. Instead of managing everything interactively, I built a lightweight bash-based deployment system that uses rsync + docker compose across multiple machines.

The structure is dead simple: `machines/<hostname>/stacks/<service>/` with a `config.sh` per machine defining SSH settings and optional pre/post deploy hooks. One command syncs files and runs `docker compose up -d`.

I could see Claude Code being useful for debugging compose files or generating new stack configs, but having the deployment itself be a single `./deploy.sh homeserver media` keeps the feedback loop tight and auditable.

You could perhaps checkout https://garagehq.deuxfleurs.fr/

I also quite like Localsend to quickly share files on the same network. Used to send photos/files to myself on Whatsapp/Telegram before but after discovering Localsend, stopped!

https://localsend.org/

I've been working on LogChef (https://logchef.app) - a specialized log analytics UI for ClickHouse that focuses on powerful querying and exploration without the complexity of full observability platforms.

The core idea is to leverage ClickHouse's incredible columnar performance for log analytics while providing a schema-agnostic interface that works with any log table structure. It supports both simple search syntax for quick queries and full ClickHouse SQL for complex analytics. Also it has proper RBAC: Team-based access controls for multi-tenant environments.

Off late I have also added some AI features:

  - AI-powered SQL generation - write queries in natural language

  - MCP (Model Context Protocol) server integration for AI assistants to query your logs

Built with Go + Vue.js + TypeScript. Currently handles millions of log entries daily in production environments at my org. The deployment is just a single binary deployment with a SQLite DB.

Would love feedback from the community! GitHub: https://github.com/mr-karan/logchef

It's great to see Typst getting more visibility. We migrated a real-world workload to it a couple of years back: generating and e-mailing 1.5M+ PDFs daily at my org, Zerodha.

Our previous pipeline was LaTeX-based (first pdflatex, then lualatex), but we were constantly fighting cryptic memory errors on large documents and huge Docker image sizes that slowed down boot times of our ephemeral workers.

Switching to Typst was a massive win for us. The single static binary resulted in tiny images and faster boot times. More importantly, the performance gains were huge. Overall compile times were ~3–4× faster than LaTeX. On really large documents (2000+ pages, mostly tables), Typst compiles in ~1 minute vs. ~18 minutes with lualatex.

Beyond performance, the better developer experience and good error messages was a nice bonus too.

We wrote a detailed post about the entire architecture - from the job orchestration with Nomad to the S3 optimizations and the Typst migration in particular. If you're curious, you can read it here: https://zerodha.tech/blog/1-5-million-pdfs-in-25-minutes

Thanks! :) fixed the typo.

I'm working on Logchef: https://github.com/mr-karan/logchef

It's an open-source (AGPLv3), purpose-built log analytics UI specifically for ClickHouse. I've been using ClickHouse for logs and love its power, but found the existing UIs either too heavy, too focused on ingestion (which we already have covered with tools like Vector/Promtail/Fluentbit/Logstash etc), or not ClickHouse-native enough.

Logchef aims to be a lightweight, powerful log explorer that sits on top of your existing ClickHouse setup.

Key things:

- Schema-agnostic: Works with your existing ClickHouse log tables. No need to change how you store things.

- Dual Query Modes: Simple search syntax (e.g., level=error service=api) for quick looks, and full SQL for complex analysis when you need to dig deep.

- Lightweight & Focused: Single binary, easy to deploy. It doesn't do ingestion, letting you use best-of-breed tools for that.

- Team-centric: Built with multi-tenancy for teams and access controls for different log sources from the get-go.

I've got a demo running at https://demo.logchef.app if you'd like to try it out. It's still evolving, so feedback (especially from other ClickHouse users) would be super valuable!

Wrote an announcement post with a bit more detail: https://mrkaran.dev/posts/announcing-logchef/

So, Logchef has a concept of "Source" which represents a ClickHouse table. You give the DSN (essentially host/port/user/password for now) and connect. In prod scenarios, usually you only `GRANT SELECT ON db_name.table_name TO user_name;`

Once you add the source, you can "connect" the source to a team. Only the members of the team will be allowed to query this source. So you can have multiple teams and add users accordingly. A source can be added to multiple teams as well.

Hope that answers your question!

Never knew about `tab` shortcut, thanks for letting me know!

BTW, as I was using it today, I was quite surprised to see `@` working now. Turns out in 0.27.5 they added this feature: https://github.com/anthropics/claude-code/blob/main/CHANGELO... :)

What I don’t like about Claude Code is why can’t they give command line flags for this stuff? It’s better documented and people don’t have to discover this the hard way.

Similarly, I do miss an —add command line flag to manual specify the context (files) during the session. Right now I pretty much end up copy pasting the relative paths from VSCode and supply to Claude. Aider has much better semantics for such stuff.

I'm curious to understand the implications of the AGPL-3.0 license in the context of this project. It sounds like the author doesn't want big corps to offer a hosted version of this tool (because doing that would require them to release the source code of any modifications they make to the software, which many companies are reluctant to do) and it's also an OSI approved license (unlike the recently famous SSPL or BSL). What's so wrong about AGPL-3.0 then?

The intention is often to prevent companies from building proprietary services on top of open source software and I feel AGPL 3.0 is a sensible choice here.

Looks like a solid project, will be interested in giving it a shot

Aside: I built my own expense tracker [1] as well to categorise expenses using LLMs as I needed a quick way to log the entries. I’ve been meaning to export these to Actual budget for a detailed analysis but haven’t done that yet.

[1] https://github.com/mr-karan/gullak

Never really caught on with the idea of integrating external I/O in something as fundamental as logging. More often that not a pull vs push approach is suited for logging. There are dozens of high performant log collectors/aggregators who can collect, transform, and push logs to N number of stores. What’s the advantage of doing this right inside the app? (Besides maybe serverless functions?)

I've also made a similar tool: https://doggo.mrkaran.dev/. Can be useful when you want to query with a custom nameserver.

From the blog post

In addition, we have given out many sizeable grants to FOSS projects and organisations in India. While funding projects outside India involves significant paperwork and operational overhead, we have reached out to several small and large projects that we use at work and have managed to pay them. This highly ad hoc approach is something that has increasingly bugged me though.

Hey, I'm from Zerodha team.

1. Regarding the validation, this error seems to be related to the provenance check mechanism in the spec. This is to prove ownership of that project/domain. The wellKnown field is designed to handle cases where the webpageUrl doesn't match the manifest URL.

2. Will definitely be passing the feedback to our team and evaluate this further!

Hi, I'm from Zerodha. Thank you for bringing this to our attention. It was a misconfiguration on our end, which we've now patched.

Hey. Yes we did support them financially from our FOSS fund. We’ll be happy to do it once more as well.

Yes, in India, the law mandates that ECNs (electronic contract notes) need to be digitally signed with a valid certifying authority. While it's true that XML/docx/xls files could also support digital signatures, but I think PDFs are prevalent and also allow clients to verify this on their end, quite easily.

Regulatory requirements mandate that. Stock brokers in India are required to generate this document called “Contract Notes” which includes all the trades done by the user on the stock exchanges. It also contains a breakdown of all charges incurred by the user (brokerage, various taxes etc). And this has to be emailed to every user before the next trading session begins.

Typst has been pretty amazing, and at my organization, we’re very happy with it. We needed to generate over 1.5 million PDFs every night and experimented with various solutions—from Puppeteer for HTML to PDF conversions, to pdflatex and lualatex. Typst has been several orders of magnitude faster and has a lighter resource footprint. Also, templating the PDFs in LaTeX wasn’t a pleasant developer experience, but with Typst templates, it has been quite intuitive.

We’ve written more about this large-scale PDF generation stack in our blog here: https://zerodha.tech/blog/1-5-million-pdfs-in-25-minutes

Seems quite useful. Will definitely check it out.

Minor nit: 10MB really isn’t that “small” for a CLI. I’d looked at your go.mod and seems like the most of dependency bloat might be coming from cobra or viper as it has in-tree plugins. You can check out an alternative like https://github.com/knadh/koanf which would decrease the binary size, I’m sure.

This is now live: https://doggo.mrkaran.dev/docs/features/any/

Long answer: Not OP, but sometimes you’re in a throwaway env and want to quickly do a DNS query and don’t have any tools (like Ubuntu minimal) available. Spawning an ephemeral container isn’t a bad idea in that case.

Short answer: Why not :)

Yep, that makes sense. Thanks, just updated docs.

Just did: https://github.com/mr-karan/doggo/pull/128

Will release soon

I just pushed the concurrent version of lookups in each resolver. Speed up is quite good around 70-80% on most domains. Will test this more before releasing to main!

https://github.com/mr-karan/doggo/pull/128#issuecomment-2202...