When we launched FuseQL in Kloudfuse 3.0, we focused on overcoming the limitations of LogQL: richer operators, better performance with high-cardinality data, and advanced aggregation capabilities. The response from customers was clear: they wanted more. More operators for complex analysis. Better handling of structured data. More flexibility in defining service level objectives.

Kloudfuse 3.5 expands FuseQL with capabilities that customers told us they needed: DIFF operators for comparing time ranges, native JSON array parsing for structured logs, and custom metrics SLOs that go beyond basic latency and availability tracking.

The DIFF Operator: What Changed?

One of the most common troubleshooting questions is simple: what changed? You deploy a new release and error rates spike. CPU usage jumps after a configuration change. Latency increases following a database migration. Understanding what actually changed between two time periods is critical.

Traditional approaches require running two separate queries, exporting results, and manually comparing them. This works for small datasets but breaks down with complex queries across millions of log events or high-cardinality metrics.

We built the DIFF operator to make this comparison native to FuseQL. Compare two time ranges or two result sets to identify what changed between them. The operator returns additions, deletions, and modifications automatically.

The DIFF operator works across all telemetry types. Compare metric values across time windows to identify which services showed degraded performance after a deployment. Identify new log patterns that appeared after incidents. Track changes in trace attributes between releases. Compare service dependency graphs before and after changes to detect new relationships introduced by code updates.

Use cases emerged that we hadn't anticipated. Customers compare error patterns between production and staging environments, catching issues before they reach production. Others use DIFF to validate that configuration changes had the intended effect by comparing system behavior across time windows.

The operator understands FuseQL's data model and performs comparisons efficiently even with large result sets. Rather than scanning raw data twice and comparing in memory, DIFF leverages FuseQL's columnar storage and indexing to identify differences at the storage layer, reducing computation overhead and query latency.

JSON Array Parsing: Structured Data Handling

Modern applications emit structured logs in JSON format. These logs contain nested objects, arrays, and complex data types that traditional log analysis tools struggle to parse efficiently. Without native JSON handling, you extract fields with regex patterns or string manipulation, which is error-prone and slow.

FuseQL 3.5 includes native JSON array parsing. Query into nested structures, filter on array elements, and aggregate across JSON fields without pre-processing or field extraction pipelines.

The power comes from treating JSON as a first-class data type. Rather than storing JSON as strings and parsing at query time, FuseQL's columnar storage understands JSON structures. This enables efficient queries into nested data without the performance penalty of repeated string parsing.

Consider transaction logs as JSON arrays containing multiple payment attempts. Each transaction might include an array of payment methods tried, each with status, error codes, and timestamps. With native JSON parsing, query directly: "show me all transactions where any payment attempt failed with error code 'insufficient_funds' and the subsequent retry succeeded."

Traditional approaches required flattening these arrays during ingestion, creating separate log entries for each payment attempt. This duplicated data, complicated correlation, and made queries like "find transactions with exactly three retry attempts" nearly impossible without custom preprocessing.

Kubernetes pod events provide another example. Pod status logs often contain JSON arrays of container statuses, each with state, restart counts, and resource usage. Native JSON parsing enables queries like "find pods where any container has restarted more than 5 times in the last hour" without extracting array elements into separate records.

This native handling improves both query flexibility and performance. Complex nested queries that previously timed out now complete in seconds because FuseQL's columnar storage efficiently handles JSON structures without string parsing overhead at query time.

Enhanced Matching Operators

FuseQL 3.5 expands pattern matching capabilities with the matches and in operators, both optimized for FuseQL's columnar storage architecture.

The matches operator provides regex pattern matching that leverages field-level indexing. Unlike traditional string-based regex that scans entire log payloads sequentially, matches works with FuseQL's columnar storage to execute pattern matching against indexed fields. This reduces query latency significantly for common filtering patterns.

For example, filtering logs where service names match the pattern checkout-* or error messages contain specific patterns becomes efficient even across billions of log events. The operator pushes matching down to the storage layer, scanning only relevant fields rather than entire records.

The in operator tests membership efficiently through hash-based lookups. Check if a service name appears in a predefined list of critical services. Filter logs where HTTP status codes match specific values like [400, 401, 403, 404]. Test whether user IDs belong to particular customer cohorts. The operator handles large membership sets efficiently—testing membership against thousands of values completes in constant time rather than linear scans.

These operators combine naturally with FuseQL's existing capabilities for complex filtering logic. A query might filter logs where service names match a pattern AND error codes are in a specific set AND timestamps fall within incident windows. Each operator leverages appropriate optimization strategies—pattern matching uses indexes, membership testing uses hash lookups, timestamp filtering uses temporal partitioning.

Lookup Tables: On-the-Fly Enrichment

Observability data often needs enrichment from external sources. Service names require mapping to team ownership. User IDs need mapping to account types or customer tiers. IP addresses benefit from geographic location data.

Traditional approaches require enriching data at ingestion time, which creates pipeline complexity. If your team ownership mapping changes, you need to reprocess historical data or accept inconsistent enrichment across time ranges.

Lookup tables in FuseQL enable on-the-fly enrichment at query time. Define lookup tables mapping keys to values. Reference these tables in queries to enrich results dynamically. Update lookup tables without reprocessing historical data—new mappings apply immediately to all queries, including historical data.

A customer uses lookup tables to map service names to cost centers for chargeback reporting. As organizational structure changes, they update the lookup table. Historical cost attribution queries automatically reflect current ownership mappings without data reprocessing, ensuring consistent reporting even as teams reorganize.

Security teams use lookup tables to enrich IP addresses with threat intelligence data. Threat indicator lists update frequently as new threats emerge. Queries automatically enrich log data with current threat intelligence, even when analyzing historical logs from weeks or months ago. This enables retrospective threat hunting without re-ingesting data with updated enrichment.

Building on FuseQL's Foundation

These expansions build on FuseQL's core strengths: rich operator library, high performance with high-cardinality data, unified syntax across all telemetry types, and compatibility with existing tools.

The DIFF operator leverages FuseQL's efficient aggregation engine. JSON parsing uses columnar storage optimizations. Lookup tables integrate with FuseQL's data model. Enhanced matching operators benefit from existing indexing strategies.

Each new capability integrates naturally with existing features. Combine DIFF with JSON parsing to compare nested structures across time windows—identify which specific fields within JSON arrays changed between deployments. Use lookup tables to enrich data before applying complex filtering with enhanced matching operators. Chain these capabilities with advanced aggregations for sophisticated analysis.

This composability means the capabilities are more powerful together than individually. FuseQL remains a cohesive query language, not a collection of disconnected features.

What This Enables

Expanding FuseQL in Kloudfuse 3.5 enables analysis patterns that weren't practical before. Compare complex datasets across time windows to identify exactly what changed. Query deeply nested JSON structures without pre-processing pipelines or data duplication. Enrich observability data dynamically at query time without ingestion-time transformations. Execute efficient pattern matching and membership testing across billions of records.

These capabilities narrow the gap between specialized log analytics platforms and unified observability. You don't sacrifice query power for unification. FuseQL delivers both.

Learn more about FuseQL enhancements in Kloudfuse 3.5 in our launch announcement.