Additional examples :: Kloudfuse Docs

Additional examples

Here are some practical examples on how to use the Kloudfuse log searching query language, FuseQL.

Count all logs

count of``all logs``Everything``top``10 5s

* | timeslice 5s | count by (_timeslice)

This analysis works well for the following use cases:

Activity Patterns

Examining logs over a time range can help spot patterns in system usage, traffic, or performance. For example, a system may experience higher load during specific hours of the day. So, analyzing log volumes over a set period — a day or week — can reveal predictable trends.

Scaling Decisions

If logs show consistent spikes in traffic or resource usage during certain time ranges, teams may be able to predict when the system requires additional capacity — servers, storage, or network bandwidth — and plan ahead to scale appropriately.

Impact of Changes or Deployments

After deploying a new feature or making a system update, teams often analyze logs generated at the time of deployment to ensure that the change did not cause any unexpected issues, such as errors or performance degradation. For example, reviewing logs from the past 48 hours can reveal any issues that can result from a recent deployment.

Count all fingerprints

count of``all fingerprints``Everything``top``10 30s

* | timeslice 30s | count_unique(fingerprint) by (_timeslice)

This analysis works well for the following use cases:

Identify Unexpected Usage Patterns

By tracking how the variety of user-related fingerprints changes over time, you can also spot unexpected usage patterns. For example, if a specific feature starts generating a wide variety of logs — new queries or interactions — it may indicate that users are adopting the feature in a manner that you didn’t anticipate. This may require further optimization or user support.

Spot New Problems Early

A sudden increase in the count of different kinds of fingerprints may indicate that new issues are emerging in your system. For example, if new error patterns appear, or previously rare issues start becoming more frequent, you can track the diversity of fingerprints over time to help you detect these problems early, and mitigate them before they escalate.

Count all logs grouped by level

count of``all logs``core:level``top 10``30 s

* | timeslice 30s | count by (_timeslice, level)

This analysis works well for the following use cases:

Spot Spikes in Errors or Warnings

If the count of ERROR or WARN logs increases suddenly, this is a clear signal that something in the system is broken. Monitoring the log counts over time, by severity level, helps you quickly detect issues as they arise.

Monitor System Usage Trends

INFO logs often provide general operational details, such as how many users are accessing the system, how many transactions are happening, or how many requests are being made. By grouping logs by level over time, you can track normal system behavior.

Count all fingerprints grouped by source

count of``all fingerprints``Core:source``top``10``5s

* | timeslice 5s | count_unique(fingerprint) be (_timeslice, source)

This analysis works well for the following use cases:

Source-Level Diagnosis

Grouping fingerprints by source allows you to understand which parts of your system are generating specific log patterns.

Resource Allocation and Scaling

If one particular source generates a disproportionate number of fingerprints, it may indicate a bottleneck or resource contention issue.

Average of a duration or number facet

avg of``@*:duration``Everything``top``10``5s

* | timeslice 5s | avg(@duration:duration_seconds) by (_timeslice)

This analysis works well for the following use cases:

Identify Bottlenecks and Latency Trends

If your logs contain durations, calculating the average duration over time helps identify performance trends.

Estimate Resource Requirements

Knowing the average duration of specific processes or operations helps estimate resource requirements.

Error rate formula

Core:level="error"

This analysis works well for the following use cases:

Failure Detection

A spike in the error rate usually indicates that a system component has failed or is malfunctioning.

Trend Analysis

Over time, monitoring the error rate helps identify trends that are not immediately apparent.

Anomaly on count of error logs

Core:level="error"

This analysis works well for the following use case:

Anomaly Detection

Identify sudden, sharp spikes in count of error logs that deviate significantly from the expected range.

Outlier

level="error" | timeslice 120s | count by (_timeslice, kube_namespace) | outlier (_count) by 120s, model=dbscan, eps=3

This analysis works well for the following use case:

Identify Poor Performance by Source

In this scenario, the error logs are monitored across various sources within a distributed system.