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.

Self hosting observability system often means letting go of the high end functionality like anomaly detection, or sometimes stitching together different components that are fragile. We've bundled an accurate, zero shot time series prediction model within Parseable - so you get anomaly detection built-in without sending data out.

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…