Show HN: Telescope now queries Kubernetes logs directly
Show HN (score: 6)Description
But while building it, I kept running into the same pattern: when everything worked, logs were in ClickHouse. When things broke, logs were still inside Kubernetes.
That gap led to adding Kubernetes as a native log source.
This is not meant to replace proper log aggregation. Centralized storage with indexing and retention policies is still the right approach for production.
But there are situations where aggregation doesn't help: the logging pipeline is broken, logs are delayed, or you're debugging locally and don't have a pipeline at all.
In those cases, the logs are already in the pods. The usual fallback is kubectl logs (or stern), often across multiple terminals and namespaces. It works, but correlation becomes manual.
Telescope can now query logs directly from Kubernetes clusters via the Kubernetes API. It lets you query across multiple namespaces and clusters, filter by labels and fields, apply time ranges, normalize severity across different log formats, and visualize log volume over time.
It uses your existing kubeconfig, fetches logs in parallel (configurable concurrency), and uses time filters to limit data transfer from Kubernetes APIs.
No agents. No CRDs. No cluster changes.
Current limitations: no streaming / follow mode yet.
Curious if others have run into the same "pipeline gap" problem - when logs aren't in your backend yet, but you still need structured access to them.
GitHub: https://github.com/iamtelescope/telescope
Changelog: https://docs.iamtelescope.net/changelog
More from Show
Show HN: Open-weight OCR got so cheap I had to share it
Show HN: Open-weight OCR got so cheap I had to share it This was not supposed to become a product.<p>When PaddleOCR-VL-1.6 dropped, independent benchmarks put it at the top of document parsing models. I had to try it. I needed a provider, but there simply isn't one ready for production that I would trust.<p>So i set one up myself. I assumed that even after getting it running, serving a vision-language model would be expensive.<p>It turns out the opposite is true. Once I had it running properly, the cost was absurdly low. At proper GPU utilization, the cost is only around $1 per 1,000 pages.<p>The nearest competitors are either much lower quality (Azure Read) or absurdly expensive (Extend or Reducto). Even Mistral OCR 4 which is really good and pretty cheap is still 4x more expensive.<p>So I had to share it. I made the endpoitns public, and vibe-coded a simple dashboard.<p>Let me know what you think!
No other tools from this source yet.