complicated setup while self hosting observability tooling is one of the biggest problems, yet least talked about. So we built Parseable as a single binary, that can be deployed in minutes on your laptop. The same simplicity then carries over when you deploy to prod, with zero external dependencies and an object store first design.

CLI tools are very helpful in slicing data points once you've identified the data you want to look at. We wrote pb to allow users to really take control of their workflows. See how to pipe pb output to awk for processing.

Canvas style exploration of observability data offers a clean way to segregate context across your questions

agents shouldn't be black boxes

PromQL is an important pillar of any modern observability team. While Parseable is a columnar data lake system, we saw that it needed PromQL support to be a solid observability platform. So we embarked on this journey to support PromQL almost 2 months ago. The results have been phenomenal - you get the power of PromQL without the typical cardinality limitations of TSDB.

We had an internal debate a while back: if Prometheus already exists, why does OpenMetrics exist too? Better branding? A competing project? A file format? A protocol? And where does OpenTelemetry fit here? We wrote a complete blog post around it: Prometheus is the monitoring system: the scraper, the storage, PromQL, the alerting, the ecosystem teams actually run. OpenMetrics is the standard for how metrics get exposed on the wire. They look alike because OpenMetrics grew straight out of the Prometheus exposition format, got broken out so it could evolve as a neutral CNCF standard, then folded back under Prometheus. OpenTelemetry lives in a different layer again: the instrumentation and collection pipeline that produces telemetry and moves it toward systems like Prometheus. To summarise: - Prometheus is the system you run. - OpenMetrics is the contract tools agree on. - OpenTelemetry is how the data gets produced and moved. Blog link below ⬇️⬇️

So we wrote a detailed tutorial on how to backfill S3 archives into Parseable with Vector + SQS, so old logs become queryable Parquet (SQL): parseable.com/blog/s3-logs-b…

Teams dump logs into S3 for cheap retention, alongside their live monitoring tool. The problem however is that a bucket of NDJSON and CSV files isn't queryable.

Observability becomes more and more useful as missing pieces from a pipeline get captured; I don't necessarily mean more data, rather data from different (preferably all) components. In our quest of unifying telemetry data from as many sources as possible, we recently integrated Parseable with @temporalio - you can now stream Temporal workflow and activity execution events into Parseable, directly from Temporal. For teams already using Temporal, this means workflow execution becomes easier to inspect, query, and debug: activity attempts, retries, failures, durations, workflow IDs, and execution paths can be explored directly in Parseable. Try it out today, link below. \

Read here: parseable.com/blog/decision-…

When should you use; wide events vs logs, metrics and traces? I wrote a decision framework. > Metrics tell you something is wrong. > Wide events tell you exactly what went wrong and why. > Wide events however come at a hefty price tag. > Cost is a storage architecture problem, not a data model problem.

When you get paged, and you're trying to find what's happening; most of the times the trace / log overview page is not the best place to be. You want to see all the errors and then work your way back to the traces & logs. Because error messages tell a story of what, how and when. Based on several users input, we built Parseable Error page. > Errors grouped by exception type, message & stack trace > Spark charts show if it's a burst or a chronic issue > AI summary gives you root cause + fix checklist before you read a single stack frame > One click to correlate with logs or escalate to Keystone parseable.com/docs/user-guid…

We got great responses to our GTM Engineer post and found the right person for that role. Thank you to everyone who reached out. Now hiring for a another key role: Founder's Office Associate with a GTM focus. We're building the first purpose-built observability datalake for the agentic era. Backed by Surge. Looking for someone who is: > Keen to run experiment cycles end to end — outreach, discovery, demos. > Can build and iterate on positioning, content, and outbound strategy > Can own the messy middle between product, customers, and market > Comfortable with ambiguity. Fast with AI tooling. Allergic to busywork. This is a strategic hire for us. At our stage, GTM decisions are company-defining — who we sell to, how we position, what the first 5 minutes of the product feel like. But strategy without output is useless. You'll be measured on what you ship, not what you present. In-person, in office, BLR. Early equity. High leverage, steep learning curve. DM me.

This is spot on. The missing piece in most "context graph" discussions: where does this data actually live? Capturing decision traces is step one. Storing them in open, queryable formats that agents can freely inspect is step two. If the trace data ends up in yet another proprietary system with its own custom query language, convoluted API access and cost barriers, you've rebuilt the silo, bigger this time. The compounding loop only works when the data layer is genuinely open.

Excited to announce Parseable Auto Instrumentation aka π PAI. If you've ever set up OpenTelemetry for a Kubernetes cluster, you know the drill: write collector configs, wire receivers, processors, exporters, pipelines — for every signal, every namespace, every environment. It works, but it's a lot of YAML to maintain before you see a single log line. PAI is a Kubernetes operator that does all of that for you, automatically. You define what you want to collect and where to send it. PAI handles the rest. A single CRD for four signals. - Logs collected from every node via filelog receiver, enriched with pod, namespace, and container metadata - Metrics from pod and node-level CPU, memory, network via kubeletstats and k8s_cluster receivers - Traces with zero-code auto-instrumentation for Java, Python, Rust, Go, Node.js, and .NET via OTel SDK injection. - Kubernetes cluster events streamed in real time PAI manages the full lifecycle of all the underlying OpenTelemetry resources. When you delete the CR, everything is cleaned up automatically. We built this because the gap between "OTel Operator installed" and "data flowing into Parseable" was too wide. PAI closes that gap. It's open source. 👉 GitHub: github.com/parseablehq/pai Would love feedback from anyone running OTel at scale -what signals matter most to you, what's missing, what's painful. #OpenSource #Kubernetes #Observability #OpenTelemetry #Parseable #DevOps #Platform