Parseable

user_id helps you isolate one customer’s failed requests. It can also multiply a metric from 600 possible combinations to 60 million. For example, take this request metric: 10 routes × 4 methods × 5 status codes × 3 regions = 600 possible combinations Add 100,000 possible user_id values:  600 × 100,000 = up to 60,000,000 combinations 60 million is the maximum possible count. The actual count depends on which label combinations receive data. Before adding any such label, calculate: 1. Values expected for each attribute 2. Combinations active during one collection window 3. How often values appear and disappear 4. Which metrics need user_id If the goal is customer-level debugging, keep user_id in logs or traces. Use a trace ID or exemplar to move from the metric spike to the affected request. If user_id must remain a metric label, limit its scope. Measure active series before rollout.

An observability stack should help you debug production, not become another system your team has to debug and monitor. That is why we designed Parseable to be boring to operate. Boring means upgrades don't become a pain. A failed component doesn't send the team through a maze of dashboards. Telemetry keeps moving while engineers focus on production. We use this test when making product decisions: does this reduce the user's work or add another thing to watch? What would “boring to operate” mean for your team?

Identity systems are integrated into the production process. Authentication failures, user activity and security events can help explain an application issue, but this data is often seen in isolation from other telemetry. Parseable has joined the Auth0 Marketplace. Auth0 can now stream tenant logs to Parseable using a Custom Webhook, allowing teams to monitor identity and security events from a single platform. These logs are searchable, easy to query and owned by you in your storage rather than being stuck in a separate system. Marketplace: https://lnkd.in/gmihzRhj Guide: https://lnkd.in/g5EMTmBv

Your observability stack becomes a 𝘇𝗼𝗼, and you are the 𝗸𝗲𝗲𝗽𝗲𝗿. You see it in coordination layers around replicated databases, or separate ingestion, query and storage services in clustered metrics systems. Each independently operated dependency adds maintenance and points of failure. We designed Parseable as a single layer for ingestion, queries, alerts and UI. As the deployment grows, Parseable scales into different roles. Swipe through to see what Parseable handles and how the design scales.

Parseable's website just got its biggest visual refresh! Overhauled to reflect the new design system, updated core components, layouts and a more polished visual language across all pages. With the evolution of Parseable's architecture and capabilities, we needed a website to articulate them better and bring more clarity to how everything works together. Check out the new and improved Parseable website at www.parseable.com

The process of running an observability stack can become complex with time. A typical backend may incorporate a messaging broker, coordination service, metadata layer and dedicated systems for storage and querying data. The problem appears when things need to change. Your team has to check configurations and endpoints before finding out whether telemetry is missing because production is quiet or the observability stack is failing. Parseable was developed to reduce such coordination work. The same system handles data ingestion, querying, alerts and Prism UI. In advanced deployments, it can run in different roles and use object storage.

We are thrilled to announce our integration with Hermes Agent! Send traces, logs and metrics from Hermes Agent to Parseable through OpenTelemetry. Get visibility into what's happening with your agents:  • Runs and model calls  • Tokens used  • Tools and skills  • Latency and errors Debug production problems, profile performance and learn more about how your AI agents perform. Check out the docs: https://lnkd.in/gsfjMwGR

Most telemetry helps teams understand and fix what is happening now. But some events keep their value long after they are created. Payment trails document failed transactions. Audit trails establish what happened and when. Months of accumulated product usage can highlight trends that a single session couldn't. Owning your data means deciding which history to keep and for how long. Parseable stores your telemetry in object storage that you control, so that valuable history is retained on your terms.

At yesterday's Temporal Technologies Vibe Check, "What to Trace When the Agent Is the Program." - Praveen K B and Prabhakar Singh joined Melanie Warrick and Lenny (Jiaxi) Chen to talk through what it takes to operate and debug agents in production. → Agent observability isn't about catching errors. It's about reconstructing decisions. Tool calls, retries, loops, and state changes are the signals that matter. → More data isn't automatically better. The hard part is capturing enough context without burying the useful signals in noise. → Traces and logs do different jobs. OpenTelemetry traces show you a run as it happens; queryable logs let you ask questions across many runs later. A live trace is sometimes the wrong tool. → Temporal's Workflow Event History is already a durable record of what happened. Parseable Temporal plugin layers Workflow and Activity traces and logs on top, so you get the durable record plus something you can search. Worth the watch if you're running agents beyond a demo: https://lnkd.in/djFNQq9E #AIAgents #Observability #Temporal #OpenTelemetry #Parseable

OpenTelemetry collects logs, metrics and traces. But in Kubernetes, it doesn't always capture the context. You need to identify which pod, namespace or deployment is responsible for a given telemetry event. The Kubernetes Attributes Processor adds metadata to your telemetry data before it arrives at Parseable. With the Kubernetes Attributes Processor now at v1.0.0, we've put together a guide covering pod association, deployment patterns, RBAC and cardinality trade-offs. Read it here: https://lnkd.in/eAzF4heG