@Rocky Why I can see query in SHOW PROC '/global_current_queries' but cant see in starrocks:8040/api/v2/query_detail?event_time=0&is_request_all_frontend=true?

You are likely seeing this discrepancy for two main reasons: a missing configuration and potentially the wrong HTTP port. 1. Enable Query Detail Collection The

query_detail

API relies on a specific collector in the Frontend (FE) that is disabled by default. Even if queries are currently running (and thus visible in

SHOW PROC

), they won't be recorded in the API cache unless this is enabled. You must set the FE configuration

enable_collect_query_detail_info

to `true`:

sql
ADMIN SET FRONTEND CONFIG ("enable_collect_query_detail_info" = "true");

Note: This is a dynamic configuration and takes effect immediately without a restart. 2. Verify the HTTP Port The

query_detail

API is an FE-side interface. * Default FE HTTP Port:

8030

* Default BE HTTP Port:

8040

In your example, you are using port

8040

. Unless you have manually reconfigured your FE to use

8040

, you are likely sending the request to a Backend (BE) node. The BE does not host the

query_detail

API and will not return the query metadata managed by the FE. Try changing the port to

8030

(or your specific

http_port

):

text
<http://starrocks:8030/api/v2/query_detail?event_time=0&is_request_all_frontend=true>

Summary of Differences Feature |

SHOW PROC '/global_current_queries'

|

GET /api/v2/query_detail

Data Source | FE internal runtime query registry. | FE memory cache for query history/details. Dependency | Works by default. | Requires

enable_collect_query_detail_info = true

. Scope | Only currently running queries. | Running and recently finished queries. Port | MySQL Protocol (

9030

) | FE HTTP Port (

8030

) If you have enabled the config and are using the correct port but still see no results, ensure the user account used for the API has the necessary

ADMIN

or

SYSTEM

privileges to view global query information. References • administration/management/FE_configuration.md • administration/http_interface/query_detail.md • sql-reference/System_variable.md

@Rocky no I see other queries but dont see some specific ones

If you can see queries in

SHOW PROC '/global_current_queries'

but not in the

/api/v2/query_detail

output (even with

is_request_all_frontend=true

), it usually comes down to one of the following technical discrepancies: 1. Forwarded Statements (Common in Multi-FE setups) Queries sent to a Follower FE that are forwarded to the Leader FE (such as DDL, certain writes, or metadata commands) have historically been harder to track via the API. In some versions, the query detail collector on the Follower node might not record the statement because the execution is managed by the Leader, while

SHOW PROC

sees the registration on the global level. * Test: Try hitting the API specifically on the Leader FE node to see if the missing query appears there. 2. Non-Query Statements (Metadata/Internal)

SHOW PROC '/global_current_queries'

lists everything currently registered in the FE query manager, including: *

SHOW

/

DESC

/

EXPLAIN

commands. * Internal statistics collection (

ANALYZE

). * Materialized View refresh tasks. * Internal system tasks. The

query_detail

API is primarily designed for SQL execution profiles. Some internal tasks or lightweight metadata queries might not be "committed" to the query detail cache because they don't generate a standard execution profile. Check the

QueryType

column in your

SHOW PROC

output—if it says

Internal

or

Statistics

, it may be excluded from the API cache. 3. Execution Phase & Timing * Registration vs. Recording: A query appears in

SHOW PROC

as soon as it is registered (even in the

PENDING

or

PLANNING

state). The

query_detail

cache typically records the entry once execution begins or reaches a state where a profile is generated. If a query is stuck in the Query Queue or is hanging during Planning, it might be visible in

SHOW PROC

but hasn't been sent to the

query_detail

collector yet. * Cache Eviction: The API reads from a memory cache with a fixed size (controlled by

query_detail_cache_size

, default is often 1000). If your cluster has a high volume of very fast queries, the "specific ones" you are looking for might have been evicted from the cache by the time you refreshed the API, whereas

SHOW PROC

shows the live state. 4. API Filter Limitations The API

v2

with

is_request_all_frontend=true

relies on the FE node you are hitting to successfully communicate with and merge results from all other FEs. * If there is a network/RPC issue between FEs, the "Request All" might return a partial list without throwing an error for the missing nodes. * Recommendation: Verify the

feIp

of the missing query in

SHOW PROC

and hit that specific FE's HTTP port directly to rule out communication issues. Summary Checklist 1. Check QueryType: In

SHOW PROC

, is the missing query a standard

SELECT/INSERT

or is it an

Internal/Statistics

task? 2. Hit the Source FE: Use the

feIp

from the

SHOW PROC

output and call the API on that specific node's port (usually

8030

). 3. Leader FE: Check if the queries are visible when hitting the Leader FE specifically. 4. Version: If you are on an older version (e.g., pre-3.1), consider upgrading as several bugs related to query detail recording for forwarded statements were fixed in later 3.x releases. Note: Your example uses port

8040

(the default BE port). If you are seeing queries there, ensure you haven't reconfigured your ports, as the FE HTTP port (where this API lives) is typically

8030

. References • administration/management/FE_configuration.md • administration/http_interface/query_detail.md • faq/Dump_query.md • administration/management/logs.md

@Rocky seems like that

query_detail_cache_size

because I have many streaming inserts

If you are running many streaming inserts (such as

INSERT INTO ... VALUES

or Flink/Spark jobs using the StarRocks connector), the

query_detail

cache is likely being overwhelmed and rotating before you can see your specific queries. The Problem: Rapid Cache Eviction The FE manages a fixed-size in-memory cache for query details. The default size is 1,000 items. When you have a high volume of small, frequent streaming inserts: 1. Each

INSERT

counts as a separate query. 2. If you are doing 100 inserts per second, the entire cache will be overwritten every 10 seconds. 3. Because

SHOW PROC

shows the live state of a currently running query, you see it there, but by the time you query the API, that record has likely already been pushed out by newer inserts. How to Fix It 1. Increase the Cache Size You can increase the number of queries the FE keeps in memory by adjusting the

query_detail_cache_size

configuration.

sql
ADMIN SET FRONTEND CONFIG ("query_detail_cache_size" = "10000");

Note: Increasing this consumes more FE memory. If you set it too high and have very large query profiles (lots of nodes/fragments), monitor FE heap memory. 2. Filter Out Inserts from the Profile (Recommended) If you only care about analyzing SELECT queries and don't want the noise of streaming inserts, you can disable profile collection specifically for those insert sessions/users. In your streaming ingestion client (or globally for that user), set:

sql
SET enable_profile = false;

This prevents the insert from generating a detailed profile, though it may still appear as a basic record. To completely stop the FE from collecting detail for specific sessions, you can toggle

enable_collect_query_detail_info

if your version supports it as a variable, though usually, this is a global FE config. 3. Use the Profile Log (For High Volume) If you need to analyze these queries but the API is too volatile, enable Profile Logging. This writes the query details to a physical log file (

fe/log/fe.profile.log

) instead of just keeping them in a small memory buffer. * Config:

enable_profile_log = true

* This allows you to grep the log files for specific QueryIDs even after they are evicted from the API cache. Summary Checklist * Check the total count: Compare the

total

field in the API response to your

query_detail_cache_size

. If they match, you are definitely experiencing eviction. * Check `feIp`: In

SHOW PROC

, look at the

feIp

column. If you are hitting the API on FE-A but the query is running on FE-B, the cache is local to each FE unless you use

is_request_all_frontend=true

(which can sometimes time out or return partial results under heavy load). References • administration/management/FE_configuration.md • administration/http_interface/query_detail.md • loading/loading_introduction/loading_considerations.md References • administration/management/FE_configuration.md • administration/http_interface/query_detail.md • using_starrocks/caching/query_cache.md

@Rocky thats true

enable_collect_query_detail_info

and thats false

enable_profile_log

That confirms the behavior. When

enable_collect_query_detail_info

is true but

enable_profile_log

is false, you are relying entirely on a volatile, small memory buffer to see your query history. With many streaming inserts, here is exactly what is happening: 1. The "Race" against Eviction The memory cache (

query_detail_cache_size

) defaults to only 1,000 entries. * In `SHOW PROC`: You see the queries because they are currently "Live" in the FE's execution manager. * In the API: As soon as those streaming inserts finish (which usually takes milliseconds), they are added to the cache. If you are doing 100+ inserts per second, the 1,000-slot cache fills up and resets every 10 seconds. * The Result: If you don't refresh the API at the exact second those specific queries finish, they are already deleted from memory to make room for the next batch of inserts. 2. No Safety Net (Disk Logging) Because

enable_profile_log

is

false

, the FE is not writing these records to

fe.profile.log

. If it were

true

, you could find those "missing" queries in the log file even after they were kicked out of the memory cache. Recommended Fixes A. Enable Profile Logging (Best for High Volume) This will write every query's metadata to a JSON log file. You can then search for your specific queries without worrying about the memory cache size.

sql
ADMIN SET FRONTEND CONFIG ("enable_profile_log" = "true");

Check

fe/log/fe.profile.log

after enabling. B. Increase the Memory Cache If you prefer using the HTTP API, increase the buffer so queries stay visible for longer:

sql
ADMIN SET FRONTEND CONFIG ("query_detail_cache_size" = "10000"); -- Increase as needed

C. Filter Out "Noise" If you only care about specific queries and don't want the streaming inserts to "spam" your cache, you can disable profile collection for the streaming user/session:

sql
-- Run this in the streaming client session
SET enable_profile = false;

Note: This may still record the query in the API but will skip the heavy "profile" data, though usually, it's better to just increase the cache or use the log. One last check: If you see the query in

SHOW PROC

but not in the API at the same moment (while it is still running): * Check the

feIp

column in

SHOW PROC

. * If the query is running on

FE-B

but you are calling the API on

FE-A

, and

is_request_all_frontend=true

is failing to communicate between them, you won't see it. * Try hitting the HTTP API of the specific FE IP listed in

SHOW PROC

. References • administration/management/FE_configuration.md • administration/http_interface/query_detail.md • administration/management/logs.md • best_practices/query_tuning/query_profile_overview.md References • administration/management/FE_configuration.md • administration/http_interface/query_detail.md • best_practices/query_tuning/query_profile_overview.md • administration/management/logs.md