Choose the ingestion path that matches the system sending data to Parseable. ### OpenTelemetry \[toc] ### Prometheus Remote Write \[toc] ### AI Infrastructure \[toc] ### Telemetry Agents \[toc] ### Containers \[toc] ### Streaming \[toc] ### Databases \[toc] ### Parseable Auto Instrumentation \[toc] ### Security \[toc] ### eBPF \[toc] ### GPU \[toc] ### CI/CD \[toc] ### Infrastructure \[toc] ### Cloud \[toc] ### Programming Languages \[toc] } title="OpenTelemetry"> Send logs, metrics, and traces through OTLP and OpenTelemetry-compatible pipelines. } title="Prometheus Remote Write"> Ingest Prometheus metrics with the remote write protocol. } title="AI Infrastructure"> Observe agents, LLMs, gateways, runtimes, sandboxes, and coding assistants. } title="Telemetry Agents"> Forward telemetry with collectors and agents such as Fluent Bit, Vector, Logstash, and OTel Collector. } title="Containers & Orchestration"> Collect logs and telemetry from Docker, Kubernetes, ECS, EKS, GKE, and AKS. } title="Streaming"> Route events through Kafka, Redpanda, RabbitMQ, NATS, Cribl, and managed streaming platforms. } title="Databases"> Send or migrate telemetry from PostgreSQL, MySQL, MongoDB, Redis, SQL Server, and Elasticsearch. } title="Parseable Auto Instrumentation"> Collect Kubernetes logs, metrics, traces, and events with Parseable-managed instrumentation. } title="Security"> Bring security events from Auth0, Falco, Trivy, and related sources into Parseable. } title="eBPF"> Capture kernel-level observability signals with eBPF-based tooling. } title="GPU"> Collect GPU metrics and accelerator telemetry. } title="CI/CD"> Capture telemetry from GitHub Actions, Jenkins, GitLab CI, CircleCI, ArgoCD, and Terraform. } title="Infrastructure"> Collect telemetry from infrastructure services such as Traefik and Windows Server. } title="Cloud"> Ingest logs and events from AWS, Azure, Google Cloud, and Fly.io. } title="Programming Languages" className="col-span-2"> Send telemetry directly from application code in Python, JavaScript, Go, Java, Rust, .NET, PHP, and Ruby. You can ingest data to Parseable in JSON format over HTTP(s). This means that any log agent, metric collector, or tracing library that can send data over HTTP in JSON format can be used to ingest data into Parseable. For log data you can use the HTTP output plugins of all the logging agents/shippers. You can also directly integrate Parseable with your application via the [ingestion API](/api/v1/ingestLogsWithHeaders). Parseable also supports OTel native data ingestion via Protobuf over HTTP. OpenTelemetry-compatible agents and libraries can send logs, metrics, and traces to the signal-specific OTLP endpoints: `/v1/logs`, `/v1/metrics`, and `/v1/traces`. Parseable derives the telemetry signal type from the endpoint path and uses `X-P-Stream` to choose the destination dataset. ## Detailed reference For HTTP headers, schema behavior, log processing, batching, timestamps, staging, and production planning, see the [Ingestion Reference](/ingestion-reference). # MCP Server (/mcp) import { Step, Steps } from 'fumadocs-ui/components/steps'; Parseable MCP Server lets any MCP-compatible AI client work with your existing Parseable deployment. Instead of copying logs, schemas, alert details, or query output into a chat by hand, the client gets a clear tool surface for the work you would normally do in Prism or through APIs, such as finding datasets, checking schemas, running SQL or PromQL, reviewing alerts, and checking access information. It does not ingest telemetry, store query results, or create another observability backend. The MCP server is a bridge. Your AI client talks to the MCP server, the MCP server calls Parseable with the API key you provide, and Parseable still enforces the same RBAC permissions that apply everywhere else. ## How it fits ```text AI client | | MCP tool call v Parseable MCP Server | | Parseable API request with X-API-Key v Parseable ``` This is useful when you want an AI client to help with an investigation without copying logs, metrics, alert definitions, or schema details into the chat by hand. You can ask for recent errors in a dataset, inspect the fields available in a stream, run a bounded SQL query, check a PromQL expression, or review alert configuration from the same place where you are already working. ## Prerequisites You need a Parseable Cloud account or a self-hosted Parseable instance that the MCP server can reach. You also need a Parseable API key with the right RBAC permissions for the datasets and actions you want the AI client to use. For local setup, make sure Node.js and `npm` are available on the machine where your MCP client runs. For remote setup, use an MCP client that supports Streamable HTTP connections and custom headers. ## Connection options | Option | How it works | Best for | | ----------- | -------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | | Local stdio | The AI client starts `@parseable/parseable-mcp-server` as a local subprocess and passes credentials through local configuration. | Claude Desktop, Claude Code, Cursor, VS Code, and other local MCP clients. | | Remote HTTP | The AI client connects to an MCP endpoint over Streamable HTTP and sends the Parseable API key in request headers. | Hosted MCP deployments or clients that prefer a remote connector. | Local setup is usually the easiest place to start. Remote setup is useful when a team wants one MCP endpoint to manage upgrades and network access centrally. ## Local setup ### Run the setup command Run the installer from the machine where your MCP client is installed: ```bash npx -y @parseable/parseable-mcp-server@latest init ``` The setup flow asks which client you want to configure, whether you are using Parseable Cloud or a self-hosted instance, and which API key should be used. ### Choose the Parseable target For Parseable Cloud, the setup writes a hosted MCP connection for clients that support it. For self-hosted Parseable, provide the base URL of your Parseable instance, for example: ```text https://parseable.example.com ``` Use the URL that your machine can actually reach. If your Parseable instance is behind a private network, the local MCP client must be on that same network or have access through your usual tunnel or VPN. ### Add the API key Paste a Parseable API key when the setup prompts for it. The key should have only the permissions needed for the work you want the AI client to perform. For example, a read-only investigation workflow should not use a key that can change alerts or manage users. After setup is complete, restart the MCP client so it can discover the new Parseable tools. You can also run setup in a scripted form. For a self-hosted Parseable instance: ```bash npx -y @parseable/parseable-mcp-server@latest init \ --client claude-desktop \ --mode self-hosted \ --url https://parseable.example.com \ --api-key "$PARSEABLE_API_KEY" ``` For Parseable Cloud: ```bash npx -y @parseable/parseable-mcp-server@latest init \ --client cursor \ --mode cloud \ --api-key "$PARSEABLE_API_KEY" ``` The interactive setup shows the clients supported by the version you are installing. ## Manual local configuration If you prefer to edit your MCP client configuration directly, add a local server entry like this: ```json { "mcpServers": { "Parseable": { "command": "npx", "args": ["-y", "@parseable/parseable-mcp-server@latest"], "env": { "PARSEABLE_URL": "https://parseable.example.com", "PARSEABLE_API_KEY": "your-api-key" } } } } ``` Some MCP clients use `servers` instead of `mcpServers`. Use the shape expected by your client. ## Remote HTTP setup In remote mode, the client connects to an MCP endpoint and sends credentials as headers. Use HTTPS for remote connections. For a self-hosted Parseable target: ```json { "mcpServers": { "parseable": { "type": "http", "url": "https://mcp.example.com/mcp", "headers": { "X-Parseable-URL": "https://parseable.example.com", "X-API-Key": "your-parseable-api-key" } } } } ``` For Parseable Cloud: ```json { "mcpServers": { "parseable": { "type": "http", "url": "https://mcp.parseable.com/mcp", "headers": { "X-Parseable-Mode": "cloud", "X-API-Key": "your-parseable-cloud-api-key" } } } } ``` Do not send credentials to an MCP endpoint you do not trust. The MCP server uses the supplied API key to call Parseable on your behalf. ## What the tools can do Parseable MCP Server exposes 27 built-in tools around the same objects you already work with in Parseable. Some tools only read data, while a few can change alert state or create alert resources. The exact result still depends on the API key. If the key cannot access a dataset or action in Parseable, the MCP tool cannot access it either. | Group | Tool | What it does | | --------------------- | --------------------- | ------------------------------------------------------------------------------------------ | | Datasets and events | `list_datasets` | Lists the datasets the API key can access. | | | `get_dataset_info` | Shows dataset metadata such as retention, time range, and dataset configuration. | | | `get_dataset_schema` | Returns the fields and types available in a dataset. | | | `get_dataset_stats` | Returns dataset-level statistics such as event count and storage size. | | | `sample_events` | Fetches a small, bounded sample of recent events from a dataset. | | Queries | `query_sql` | Runs a read-only SQL query against a dataset with query controls applied. | | | `query_promql` | Runs an instant or range PromQL query against a metrics dataset. | | | `explain_query` | Explains a SQL query plan without executing the query itself. | | Alerts | `list_alerts` | Lists alerts along with state, severity, tags, and related metadata. | | | `get_alert` | Returns the full configuration for a specific alert. | | | `list_alert_tags` | Lists the tags currently used across alerts. | | | `enable_alert` | Enables an existing alert. | | | `disable_alert` | Disables an existing alert. | | | `evaluate_alert` | Evaluates an alert immediately. This can send real notifications if the condition matches. | | | `create_alert` | Creates a new alert through a guided flow that collects the required alert fields. | | Alert targets | `list_alert_targets` | Lists configured notification targets such as Slack, webhook, or Alertmanager targets. | | | `get_alert_target` | Returns the full configuration for a specific alert target. | | | `create_alert_target` | Creates a new notification target for alert delivery. | | Access review | `list_users` | Lists users visible to the API key. | | | `get_user_roles` | Shows the roles assigned to a specific user. | | | `list_roles` | Lists the roles configured in Parseable. | | | `get_role` | Shows the permissions attached to a specific role. | | | `get_default_role` | Shows the default role assigned to new users. | | Cluster and retention | `ping` | Checks whether the MCP server can reach Parseable and returns basic connectivity details. | | | `get_cluster_status` | Shows node status for a distributed Parseable deployment. | | | `get_cluster_metrics` | Returns high-level cluster metrics for ingest, query, and storage. | | | `get_retention` | Shows the retention policy for a dataset. | ## Common workflows ### Investigate logs A typical log investigation starts by listing datasets, inspecting the schema, and sampling a few recent records. After that, the AI client can help write a SQL query for a specific time window, run it, and explain the rows that came back. Example prompts: * `Show errors from the checkout dataset during the last 30 minutes.` * `Which service produced the most 5xx responses today?` * `Sample recent events from api-logs so I can understand the fields.` ### Query metrics For metrics, use PromQL through the MCP server. You can ask for an instant query when you need the current value, or a range query when you want to inspect how a series changed over time. Example prompts: * `Run a range query for request latency over the last hour.` * `Show the current error rate for the payments service.` * `Explain this PromQL query before running it.` ### Work with alerts The MCP server can help inspect existing alerts and alert targets. It can also help create alerts through a guided flow where the client collects the dataset, condition, evaluation window, severity, tags, and notification target before creation. Be careful with alert evaluation. Evaluating an alert can trigger real notifications, so review the action before confirming it in your MCP client. ### Review access You can ask the client to list users, inspect roles assigned to a user, and compare those roles with the default role. This is useful when an API key or user can see less data than expected. ## Query controls SQL queries must include an explicit time window and are restricted to read-only use. The MCP server blocks common data-changing SQL operations and applies a row limit when the query does not provide one. `sample_events` is also bounded, so it is meant for understanding the shape of a dataset rather than exporting data. Results remain subject to Parseable RBAC and the configured query limits. For long investigations, keep time windows narrow first. Increase the range only after you know which dataset, service, or field is relevant. ## Security notes * Use API keys with the smallest set of roles needed for the workflow, and store them in your MCP client configuration or a secrets manager. Do not commit them to source control. * Use HTTPS for remote MCP and Parseable connections, and do not connect an AI client to an MCP endpoint you do not operate or trust. * Review state-changing actions such as alert creation, alert enablement, alert disablement, and alert evaluation before confirming them. * Rotate the API key in Parseable if it is exposed. Parseable MCP Server does not store telemetry data, query history, result sets, credentials, or user preferences. Parseable remains the system that authenticates the key and enforces permissions. ## Troubleshooting * If the tools do not appear in your client, restart the MCP client after running setup. * If the local server does not start, check that `PARSEABLE_URL` and `PARSEABLE_API_KEY` are present in the generated client configuration. * If you get `401` or `403`, check the API key first. `401` usually means the key is missing, invalid, or rotated. `403` means the key is valid but does not have permission for that dataset or action. * If a dataset is missing, check the dataset name and the roles assigned to the API key. * If PromQL does not work, confirm that you are querying a metrics dataset and that your Parseable deployment supports PromQL. * If a query times out, reduce the time range or result size before increasing timeouts. * If a remote connection fails, check the MCP endpoint URL, HTTPS configuration, request headers, and network reachability. # SQL Reference (/query) Parseable offers a PostgreSQL compatible SQL query interface to query log data. Users can choose to use the filter interface directly without having to deal with SQL at all. However for more complex queries and advanced users, Parseable offers a SQL query interface. You can specify the query and the relevant time range for which you want this query to be run. The response is inclusive of both the start and end timestamps. The filter interface is quite self explanatory, with options to filter by specific columns and values and also by time range. In this document, we'll cover more about the SQL API and its capabilities. Check out the [Query API](/api/v1/queryLogStream). ## How does it work? After parsing and creating the execution plan for a query, the Parseable query server uses the data manifest file to filter out the relevant Parquet files. The data manifest file is a JSON file that contains the specific column metadata for a whole day. The querier uses this file to filter the relevant Parquet files based on the query filters and the time range. Only the relevant Parquet file paths are then added as a data source to custom table provider. Datafusion then efficiently reads the files via the GetRange S3 API, pulling only the very specific data needed for the query. This ensures that only the relevant data is read from the storage, reducing the query time and cost. ## Supported functions Parseable supports a wide range of SQL functions - Aggregate, Window and Scalar functions. Refer the Apache Datafusion documentation for the complete list of supported functions and their usage. * [Aggregate Functions](https://datafusion.apache.org/user-guide/sql/aggregate_functions.html) * [Window Functions](https://datafusion.apache.org/user-guide/sql/window_functions.html) * [Scalar Functions](https://datafusion.apache.org/user-guide/sql/scalar_functions.html) ## Query with regular expressions This section provides examples of how to use regular expressions in Parseable queries. * Match regular expression (Case Sensitive) ```sql SELECT * FROM frontend where message ~ 'failing' LIMIT 9000; ``` * Match regular expression (Case Insensitive) ```sql SELECT * FROM frontend where message ~* 'application' LIMIT 9000; ``` * Does not match regular expression (Case Sensitive) ```sql SELECT * FROM frontend where message !~ 'started' LIMIT 9000; ``` * Does not match regular expression (Case Insensitive) ```sql SELECT * FROM frontend where message !~* 'application' LIMIT 9000; ``` * Matches the beginning of the string (Case Insensitive) ```sql SELECT * FROM frontend where message ~* '^a' LIMIT 9000; ``` * Matches the end of the string ```sql SELECT * FROM frontend where message ~ 'failing$' LIMIT 9000; ``` * Matches numeric type data ```sql SELECT * FROM frontend where uuid ~ '[0-9]' LIMIT 9000; ``` * Matches numeric type data (two digits) ```sql SELECT * FROM frontend where uuid ~ '[0-9][0-9]' LIMIT 9000; ``` * Matches numeric type data (two digits) ```sql SELECT * FROM frontend where uuid ~ '[0-9][0-9]' LIMIT 9000; ``` * Replace every instance of the numeric type data with the symbol \* ```sql SELECT REGEXP_REPLACE(uuid,'[0-9]','*','g') FROM frontend LIMIT 9000; ``` * When a Regex is run against a string, the REGEXP\_MATCHES() function compares the two and returns the string that matches the pattern as a set. ```sql SELECT REGEXP_MATCH(email,'@(.*)$') FROM frontend where email is not null LIMIT 10; ``` * Postgres regex numbers only: Use the REGEXP\_REPLACE() function to extract only the numbers from a string in PostgreSQL. ```sql SELECT REGEXP_REPLACE(email,'\\D','','g') FROM frontend where email is not null LIMIT 10; ``` * Postgres regex split: SPLIT\_PART() function can split a string into many parts. To divide a string into several pieces, we must pass the String, the Delimiter, and the Field Number. ```sql SELECT SPLIT_PART(email,'@',1) FROM frontend where email is not null LIMIT 10 -- return before @ from email; SELECT SPLIT_PART(email,'@',2) FROM frontend where email is not null LIMIT 10 -- return after @ from email; ``` * Postgres Regex Remove Special Characters: Using the REGEXP\_REPLACE() function, all Special Characters from a supplied text can be eliminated. ```sql SELECT REGEXP_REPLACE(email, '[^\\w]+','','g') FROM frontend where email is not null LIMIT 10; ``` * Functions and Operators in pattern matching: Like and other POSIX regular expressions are supported. ```sql SELECT * FROM frontend where email LIKE '%test%' LIMIT 10; SELECT * FROM frontend where email ~ '^test' LIMIT 10; ``` ## Case sensitivity Dataset column names are case sensitive. For example, if you send a log event like ```json { "foo": "bar", "Foo": "bar" } ``` Parseable will create two columns, `foo` and `Foo` in the schema. So, while querying, please refer to the fields as `foo` and `Foo` respectively. While querying, unquoted identifiers are converted to lowercase. To query column names with uppercase letters, they must be passed in double quotes. For example, when sending a query via the REST API, the following JSON payload will apply the `WHERE` condition to the column `Foo`: ```json { "query":"select * from dataset where \"Foo\"=bar", "startTime":"2023-02-14T00:00:00+00:00", "endTime":"2023-02-15T23:59:00+00:00" } ``` If you're querying Parseable via Grafana UI (via the [data source plugin](https://github.com/parseablehq/parseable-datasource)), you can use the following query to query the column `Foo`: ```sql SELECT * FROM dataset WHERE "Foo" = 'bar' ``` ## Query analysis In some cases, you may want to understand the query performance. To view the detailed query execution plan, use the `EXPLAIN ANALYZE` keyword in the query. For example, the following query will return the query execution plan and time taken per step. ```json { "query": "EXPLAIN ANALYZE SELECT * FROM frontend LIMIT 100", "startTime": "2023-03-07T05:28:10.428Z", "endTime": "2023-03-08T05:28:10.428Z" } ``` ## Response fields information with query results To get the query result fields as a part of query API response, add the query parameter `fields=true` to the API call, e.g. `http://localhost:8000/api/v1/query?fields=true`. For example, for a query like `select count(*) as count from app1`, with the query parameter added will respond like this: ```json { "fields": [ "count" ], "records": [ { "count": 2 } ] } ``` # Release notes (/release-notes) ## v3.0 August 9, 2026 Parseable 3.0 focuses on making the platform safer, easier to operate, and better suited to teams running logs, metrics, traces, agents, runtimes, and model traffic in one production environment. It is a hardening release for existing deployments and a broader platform release for teams adopting Parseable across AI infrastructure and day-to-day observability workflows. #### Security and operational hardening This release tightens several areas that affect authentication, authorization, query safety, and data isolation. It includes fixes and improvements around API key security, SQL injection protection in list condition expressions, SSRF protection for alert targets, path traversal protection for local filesystem filters, dataset authorization, OAuth sync, OIDC redirects, and dependency and runtime hardening across the backend and Prism UI. It also improves ingestion and trace endpoint behavior, alert query metadata, and OpenTelemetry metric handling, including exemplar and metric field fixes. #### Tools for teams and agents Parseable 3.0 adds more ways to work with telemetry outside the browser. The Parseable MCP Server gives MCP-compatible clients such as Claude, Cursor, VS Code, Codex, and other agentic tools a safer interface for inspecting datasets, schemas, logs, metrics, traces, alerts, and cluster health. The `pb` command line interface also expands the terminal workflow for querying, tailing, inspecting profiles, and automating common telemetry tasks. #### AI infrastructure observability This release expands Parseable's AI infrastructure coverage across agent frameworks, sandboxes and runtimes, LLMs, and gateways. Agent framework integrations help teams inspect runs, model calls, tool calls, workflow steps, and failures. Runtime and sandbox integrations add visibility into execution, retries, logs, traces, and metrics. LLM and gateway integrations help with model latency, errors, token usage, routing, and provider behavior. Together with Agent Observability in Prism, these integrations make it easier to follow an AI workload across the application, model, tool, runtime, and infrastructure layers. #### Governance, Prism, and Kubernetes operations Multi tenancy adds a clearer workspace boundary for shared deployments, keeping users, roles, API keys, datasets, dashboards, alerts, queries, and storage paths scoped to the right tenant. Prism continues to improve the product surfaces used during investigations, including Agent Observability, APM service maps, dashboards, and reusable templates from the public `parseablehq/dashboards` repository. On Kubernetes, Parseable 3.0 improves the installation and operations story through Helm chart updates and Parseable Auto Instrumentation (PAI). PAI uses the OpenTelemetry Operator and OpenTelemetry Collector to collect logs, metrics, traces, and Kubernetes events with less manual collector wiring, while still keeping the generated resources inspectable as normal Kubernetes objects. For a detailed walkthrough, read the [Parseable 3.0 release recap](https://www.parseable.com/blog/parseable-3-release-recap). For the complete changelog, contributors, and tagged release assets, see the [GitHub v3.0.0 release](https://github.com/parseablehq/parseable/releases/tag/v3.0.0). ## v2.9 June 13, 2026 This release is focused on making Parseable easier to use for AI agents and day-to-day observability workflows. If you are already using Parseable for logs, metrics, or traces, the console should now feel more consistent across the product. If you are building agentic applications, you now get a dedicated way to understand how your agents behave in production. #### Introducing Agent Observability You can now inspect AI agent sessions directly in Parseable. This helps when you want to understand what prompt was used, which LLM calls were made, which tools were called, how many tokens were consumed, where latency came from, and whether errors or unusual sentiment showed up in the flow. Instead of looking at disconnected logs or traces, you can follow the agent workflow in one place and see what happened step by step. This should make debugging slower responses, failed tool calls, or unexpected answers much easier. #### Log context Logs now include a **Log context** view in Prism. From any log row, open the row actions menu and choose **Show context** to see the records around that exact line. This helps when an error log does not explain enough on its own, because you can quickly check what happened before and after it, adjust the surrounding time window, jump back to the referenced line, and apply filters while staying in the same investigation. #### Prism UI refresh We have refreshed Prism across Logs, Metrics, Traces, Datasets, and the Home overview. The aim is simple: moving between observability views should feel familiar, with cleaner layouts getting in the way less often. Alongside this, the release includes fixes and improvements around ingestion, API key ingestion, Helm configuration, S3 IRSA support, metric pruning, and field stats aggregation. For a detailed walkthrough, read the [Parseable v2.9.0 release blog](https://www.parseable.com/blog/parseable-v290-release). For the complete changelog, contributors, and tagged release assets, see the [GitHub v2.9.0 release](https://github.com/parseablehq/parseable/releases/tag/v2.9.0). ## v2.8 May 30, 2026 ### Hot Tier Improvements Hot tier now has a more concurrent and tunable sync model. The refactor separates latest-data sync from historic-data sync, gives each stream its own background tasks, and makes object-store downloads safer through ranged, chunked downloads with partial-file staging. **What's new:** * Historic data sync and latest data sync now run as separate hot-tier tasks. * Each stream gets its own hot-tier background sync tasks, improving concurrency across streams. * Hot-tier file downloads are parallelized and chunked, with partial-file staging before final rename. * Operators can tune hot-tier object-store access with `P_HOT_TIER_DOWNLOAD_CHUNK_SIZE`, `P_HOT_TIER_DOWNLOAD_CONCURRENCY`, `P_HOT_TIER_FILES_PER_STREAM_CONCURRENCY`, `P_HOT_TIER_LATEST_MINUTES`, and `P_HOT_TIER_HISTORIC_SYNC_MINUTES`. ### Metrics and PromQL Improvements Metrics workflows get better series handling, better read behavior, and a smoother PromQL experience in the console. This release adds deterministic per-series hashing during ingestion, improves Parquet layout for metric reads, and expands PromQL support in Prism. **What's new:** * OpenTelemetry metrics known fields now include quantile value fields. * Metrics ingestion now writes a stable per-series hash, helping Parseable identify physical metric series consistently. * Metrics batches are sorted by metric name before Parquet write, improving pruning for metric-name based reads. * Prism adds PromQL querying, PromQL fixes, metric row filtering and copy actions, improved no-data views, and tooltip fixes in Metrics Explore. ### Query and Ingestion Reliability Parseable now surfaces more ingestion failures instead of hiding them behind panics or failed background operations. Query streaming and DataFusion execution tuning were also improved for larger workloads and multi-partition result delivery. **What's new:** * Streaming query merge was redesigned for more stable multi-partition result delivery. * Ingestion and staging operations now return and propagate errors instead of relying on unwraps or hidden failures. * Query execution adds tuning for target partitions, Parquet filtering, page index use, metadata sizing, predicate cache size, and execution batch sizing. ### Tracing and Observability Improvements Tracing is easier to enable in local and development environments, and operators get richer visibility into storage and hot-tier paths. Parseable can now export application traces directly to stdout in JSON format when the OpenTelemetry endpoint is configured for stdout. **What's new:** * Set `OTEL_EXPORTER_OTLP_ENDPOINT=stdout` or `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=stdout` to export application traces to stdout. * Tracing enablement and stdout behavior are simpler and clearer, including endpoint and header handling. * Hot-tier, object-store, startup sync, and storage paths now include richer tracing and metrics for operator visibility. ### Console and User Experience Improvements Prism received reliability and usability updates across Logs, Metrics, Traces, SQL, Alerts, and Errors. The changes reduce visual inconsistencies, improve filtering and copy workflows, and make empty or error states more consistent. **What's new:** * Empty-state handling is more consistent, including preventing flashes before query loaders in Logs, Metrics, and Traces. * Trace views now align start times more consistently and show timestamps in bubble chart tooltips. * Traces and metrics tables now support include, exclude, filter, and copy actions where relevant. * SQL autocomplete quote handling, sidebar collapse behavior, timezone changes, Errors page dataset reset, and non-exception error details were improved, with expanded Playwright coverage across core console workflows. ## v2.7 May 8, 2026 ### APM Support APM is now a dedicated workflow inside Parseable. With this release, a new **Services** view is available in the sidebar, giving teams a service-level entry point for application performance monitoring across traces, errors, request volume, and latency. Click into any service to open a scoped APM view with **Insights**, **Traces**, and **Errors** tabs, so teams can move from service health to request-level debugging without switching tools. What's new: * Browse all traced services from a dedicated Services page. * View requests, error percentage, and latency per service. * Drill into service-specific Insights, Traces, and Errors. * Open services and APM routes through deep links from alerts, runbooks, or external tools. APM Support in Parseable

### Ingestion Traces Ingestion is now a fully traced workflow inside Parseable. The server emits OpenTelemetry spans across the ingestion path, from API intake to schema inference, record-batch conversion, staging, flush, and object-store upload. This gives operators deeper visibility into ingest performance, background sync cycles, and bottlenecks across high-throughput telemetry pipelines. What's new: * Trace ingestion end to end with OpenTelemetry spans across the full ingest path. * Export ingestion traces to any OpenTelemetry collector with standard configuration. * Tune actix server behavior with new CLI args and matching `P_ACTIX_*` environment variables. * Improve high-volume ingest with batched schema inference, parallel record processing, optimized byte-size counting, and safer sync-cycle guards. ### PromQL Support Parseable now includes built-in PromQL support for metrics streams through Prometheus-compatible HTTP APIs under `/prometheus/api/v1`. Existing Grafana dashboards and Prometheus-compatible tooling can point to Parseable and query metrics without major changes. This brings PromQL-native metric analysis into Parseable while keeping logs, traces, and metrics available in one observability platform. What's new: * Query metrics with PromQL through instant query, range query, series, labels, and label-values endpoints. * Use existing Grafana Prometheus data sources with Parseable. * Run PromQL functions, aggregations, binary operators, vector matching, and subqueries. * Execute heavier queries safely with query splitting, result caching, distributed execution, memory guards, and cardinality analysis endpoints. ### Access Management and API Keys Access Management is now the central place to manage users, roles, and API keys in Parseable. With this release, teams can create scoped API keys for programmatic access without relying on personal user credentials. API keys are built for log forwarders, CLI tools, automation scripts, AI agents, dashboards, CI jobs, and other workloads where Basic Auth or OIDC is not the right fit. Each key inherits permissions from assigned roles and can be used through the `X-API-Key` header. What's new: * Create and manage API keys from Access Management. * Assign one or more roles to every API key. * Use dataset-scoped keys for ingestion agents, query agents, dashboards, and automation workflows. * Revoke keys independently without affecting users or other workloads. * Use API keys for supported ingestion and query workflows through the `X-API-Key` header. API Keys Access Management

## v2.5 December 8, 2025 **Parseable v2.5.0** is here! This major update significantly expands our platform capabilities, introducing a dedicated **Trace View**, a **Metrics View**, and powerful AI-native integrations connecting Keystone with the alerting ecosystem. ### 1. Trace View Implementation We have unlocked a new dimension of observability with the introduction of the **Trace View**. This feature is designed to help you visualize the complete lifecycle of requests as they traverse your distributed systems, making it easier than ever to diagnose latency issues and bottlenecks. * **Full Trace Visualization:** Users can now view comprehensive waterfall charts of traces, providing deep visibility into service interactions. * **Enhanced Navigation:** We added intuitive breadcrumbs to the Traces Span detail sheet, allowing for seamless navigation through complex span hierarchies. * **OpenTelemetry Standardization:** Trace field names for events and links have been updated to align strictly with OpenTelemetry standards, ensuring consistent data ingestion and better interoperability.

### 2. Metrics View The Metrics experience has been overhauled to provide deeper insights and a more fluid user experience. * **Data Consistency:** Attribute field names have been standardized across all metric types, simplifying queries and ensuring consistency across your data.

### 3. Keystone Integration with Alerts We are bringing AI-native capabilities closer to your incident response workflow. Keystone is now tightly integrated with the alerting system. * **Automated Investigation:** You can now initiate a Keystone analysis session directly from a triggered alert. This seamless handoff reduces the time between detecting an anomaly and understanding its root cause. ### 4. SQL Editor & Visualization We have enhanced the SQL Editor to support more complex data exploration and reporting needs. * **Table Chart Support:** We introduced the **'Table' chart type**, allowing you to visualize raw data rows directly within your dashboards for detailed reporting. * **Multi-Dataset Expansion:** The SQL editor now supports up to **3 distinct datasets** simultaneously, enabling more complex joins and comparative analysis. * **UX Enhancements:** * Added a **"Clear All"** button to instantly reset GroupBy selections, speeding up exploratory data analysis. * Improved state management for SQL editor tabs to prevent data loss when switching contexts. * Refined the `dbName` logic to better handle complex subqueries. ### 5. Alerting Improvements The alerting engine has been optimized for performance and better context. * **State History:** Parseable now saves the history of alert states, providing a valuable audit trail of when alerts fired, resolved, or changed status. * **Contextual Alerts:** You can now include the `metric_name` context when creating alerts, making notifications more informative at a glance. * **Performance & Clarity:** We optimized the underlying queries used for alert creation to reduce load and removed redundant text from notification messages for cleaner, easier-to-read alerts. ### 6. Bug Fixes * **SQL Editor:** Fixed an issue where error messages were not being displayed when a query failed, ensuring users now see the correct feedback. * **Visualization Logic:** Refined query data checks in the `GaugeStyleSection` to correctly respect `rangeTo` values for accurate gauge rendering. * **Recents Management:** The "Recents" list now automatically cleans itself by removing entries that are no longer valid. * **Timezones:** Fixed an issue with URL parameter handling to ensure selected timezones persist correctly during navigation. ## v2.4.3 September 22, 2025 We're excited to announce Parseable v2.4.3. This release was focussed on improving the user experience of using SQL via our SQL editor. ### New SQL editor The SQL editor has a new sidebar to showcase all the columns and their types for fast lookups. After the query is run and results are available, you can now use the chart view customization options and add these charts to dashboards directly. AI assistant, saved queries are now rearranged to the right side of the screen for better visibility and access. Dashboard SQL Chart Builder