Auditing Query Examples
The following FuseQL queries cover the most common auditing and compliance use cases. Each example shows the query and a representative result set illustrating how the data is structured. Run these queries in the Logs section of the Kloudfuse UI.
Audit Log Examples
Total event volume by action
Shows the overall breakdown of every event type recorded in the window. Use this as a starting point for any compliance review — it immediately shows which operations are most frequent and flags any unexpected action types.
source="kf-audit-log" | count by action
| action | _count |
|---|---|
|
147 |
|
38 |
|
22 |
|
11 |
|
9 |
|
6 |
|
4 |
|
3 |
|
2 |
All events by user
Answers "what has each user done?" — the primary view for user activity auditing. The combination of user_email and action gives a per-user summary of every operation type.
source="kf-audit-log" | count by user_email, action
| user_email | action | _count |
|---|---|---|
|
|
42 |
|
|
14 |
|
|
8 |
|
|
31 |
|
|
5 |
|
|
6 |
|
|
2 |
All events for a specific user
Scopes the previous query to a single user for detailed review. Replace the email address as needed.
source="kf-audit-log" user_email="alice@example.com" | count by action, resource_type
| action | resource_type | _count |
|---|---|---|
|
|
42 |
|
|
9 |
|
|
5 |
|
|
8 |
|
|
3 |
Mutations by resource type and action
Shows what kinds of resources have been changed and how — useful for understanding the scope of administrative activity.
source="kf-audit-log" | count by resource_type, action
| resource_type | action | _count |
|---|---|---|
|
|
147 |
|
|
18 |
|
|
7 |
|
|
9 |
|
|
12 |
|
|
4 |
|
|
6 |
|
|
3 |
Successful versus failed operations
Comparing success and failure counts across action types quickly surfaces failed mutations that may indicate permission gaps or misconfigured API calls.
source="kf-audit-log" | count by status, action
| status | action | _count |
|---|---|---|
|
|
143 |
|
|
35 |
|
|
20 |
|
|
4 |
|
|
4 |
|
|
3 |
Authorization failures by user
Identifies users who are repeatedly hitting permission boundaries. A high count for a single user often indicates a misconfigured policy or an automation credential with insufficient permissions.
source="kf-audit-log" action="authorization_failure" | count by user_email
| user_email | _count |
|---|---|
|
12 |
|
3 |
|
1 |
Group membership changes
Tracks all user additions and removals across groups. resource_name is the group; the user being added or removed appears in resource_id.
source="kf-audit-log" (action="add_user_to_group" OR action="remove_user_from_group") | count by user_email, resource_name, action
| user_email | resource_name | action | _count |
|---|---|---|---|
|
|
|
3 |
|
|
|
2 |
|
|
|
1 |
Service account token issuance and revocation
Tracks when service account tokens are created or deleted, and which administrator performed the action.
source="kf-audit-log" resource_type="service_account" (action="create_token" OR action="delete_token") | count by user_email, resource_name, action
| user_email | resource_name | action | _count |
|---|---|---|---|
|
|
|
4 |
|
|
|
2 |
|
|
|
1 |
Performance Log Examples
Query volume by user
The primary view for understanding who is driving platform load. Each row is a unique caller; rows with an empty user_email are alert evaluation or service-to-service calls.
source="kf-performance-log" | count by user_email
| user_email | _count |
|---|---|
(empty — alert evaluation and internal calls) |
212,727 |
|
19,341 |
|
8,204 |
|
4,871 |
|
1,285 |
On observe.kloudfuse.io, the majority of query volume comes from alert evaluation and internal service calls rather than interactive users. This is typical for production clusters with active alerting.
|
Query volume by service
Shows the distribution of queries across query services. Use this to understand relative load across telemetry types.
source="kf-performance-log" | count by service_name
| service_name | _count |
|---|---|
|
1,458,539 |
|
169,997 |
|
10,431 |
|
330 |
|
231 |
query-service dominates because it handles all PromQL queries, including every dashboard panel refresh and alert evaluation cycle.
Average query latency by user
Identifies users whose queries run slowest on average. High latency for a specific user often indicates broad time-range or high-cardinality queries.
source="kf-performance-log" | avg(duration_ms) by user_email
| user_email | _avg |
|---|---|
|
4,231 |
|
892 |
|
341 |
|
218 |
Slow queries exceeding a latency threshold
Counts queries slower than a given threshold, grouped by service. Adjust the threshold to match your SLOs.
source="kf-performance-log" duration_ms > 5000 | count by service_name
| service_name | _count |
|---|---|
|
1,847 |
|
312 |
|
28 |
p95 latency by service
The 95th-percentile duration captures tail latency without being skewed by outliers. Use this alongside averages to identify services where most queries are fast but a significant tail is slow.
source="kf-performance-log" | p95(duration_ms) by service_name
| service_name | _p95 |
|---|---|
|
8,104 |
|
3,217 |
|
1,893 |
|
644 |
|
201 |
Query volume over time
Plots total query throughput across all services in hourly buckets. Use this to identify traffic spikes, alert evaluation storms, or the effect of dashboard load patterns.
source="kf-performance-log" | count by service_name | timeslice 1h
The output is a time-series table with one row per service per hour bucket, suitable for plotting in the Kloudfuse Metrics UI or exporting for trend analysis.