@Rocky can we somehow identify hostname or something from where query was run ?

To identify the hostname or IP address from which a query originated, you can use the following methods: 1. SQL Commands (For Active Queries) If the query is currently running, you can use

SHOW PROCESSLIST

to see the client's origin:

sql
SHOW FULL PROCESSLIST;

* Host Column: This column displays the client's IP address and port (e.g.,

192.168.1.50:54321

). * User Column: Shows the user account tied to that connection. 2. Audit Logs (For Historical Queries) For queries that have already completed, StarRocks records the client's IP in the FE audit log: * File Path:

fe/log/fe.audit.log

(on your Frontend nodes). * Information recorded: Each entry includes the

User

, the client

Host

(IP), and the SQL statement executed. * Configuration: You can enable JSON formatting for easier parsing by setting

audit_log_json_format = true

in the FE configuration. 3. Built-in Functions You can use standard MySQL-compatible functions within a query to see your own connection metadata: * `SELECT USER();`: Returns the user identity you authenticated as, including the host part (e.g.,

'root'@'192.168.1.10'

). * `SELECT CURRENT_USER();`: Returns the user identity that the current session's privileges are based on. * `SELECT CONNECTION_ID();`: Returns the unique ID for the current connection, which can be cross-referenced in the processlist or audit logs. 4. Query Detail API (HTTP) If you are managing StarRocks via the HTTP interface, the Query Detail API provides a

remoteIP

field for every query tracked by the system. Note: The function

host_name()

in StarRocks returns the hostname of the StarRocks node (FE or BE) performing the computation, not the hostname of the client machine. References • sql-reference/sql-statements/account-management/SHOW_AUTHENTICATION.md • administration/user_privs/authorization/user_privs.md • sql-reference/sql-functions/utility-functions/current_version.md • sql-reference/sql-functions/utility-functions/version.md • sql-reference/sql-statements/account-management/CREATE_USER.md • administration/user_privs/authentication/native_authentication.md • sql-reference/information_schema/user_privileges.md

@Rocky no this returns vpn internal ip

If the result shows a VPN internal IP, it is because StarRocks identifies the source based on the incoming TCP connection. By default, StarRocks does not perform a reverse DNS lookup to resolve that IP into a hostname, and it cannot see "behind" your VPN or Proxy unless the client or the proxy explicitly passes that information. To identify the actual origin of a query beyond just the VPN IP, you can use the following strategies: 1. Custom Query ID (Recommended for v3.4+) If you are on StarRocks v3.4.0 or later, you can manually bind a client-side identifier (like a hostname or machine name) to your session. This identifier will appear in the FE Audit Logs.

sql
-- Run this at the start of your session/script
SET SESSION custom_query_id = 'my-workstation-name';

-- The ID is recorded alongside the query in audit logs
SELECT * FROM my_table;

2. SQL Comments Most monitoring tools and the FE audit log capture the full SQL text. You can append a comment to your queries to tag the source:

sql
SELECT * FROM my_table /* source: workstation-xyz */;

3. Connection Attributes (Application Level) While standard MySQL has a table called

performance_schema.session_connect_attrs

to show client hostnames sent during the handshake, StarRocks does not currently populate this table (the

performance_schema

in StarRocks is primarily for JDBC compatibility). 4. FE Audit Logs (Parsing the Host) If the VPN IP is unique to each user/machine, you can find it in the

fe/log/fe.audit.log

. * IP Mapping: If your VPN assigns static IPs or you have a way to map the VPN IP back to a user, this log is the source of truth. * JSON Format: Enable

audit_log_json_format = true

in

fe.conf

to make it easier to parse the

clientIp

and

user

fields with external tools. Why you only see the IP: 1. No Reverse DNS: StarRocks FE does not attempt to resolve client IPs to hostnames to avoid query latency (equivalent to MySQL's

skip-name-resolve

being permanently ON). 2. Network Layer: If your traffic passes through a Load Balancer or VPN that does not support the PROXY protocol, the original client IP/hostname is lost before it reaches the StarRocks FE. Summary: If the IP isn't enough, you must modify your client application to send an identifier via

custom_query_id

or SQL comments. References • sql-reference/System_variable.md • administration/management/monitoring/metrics.md • sql-reference/information_schema/session_variables.md • administration/management/FE_configuration.md • faq/Deploy_faq.md • administration/management/resource_management/Load_balance.md • unloading/arrow_flight.md • administration/management/BE_configuration.md • deployment/sr_operator.md • administration/http_interface/query_detail.md • sql-reference/sql-statements/cluster-management/config_vars/SHOW_VARIABLES.md • sql-reference/sql-functions/utility-functions/host_name.md • deployment/environment_configurations.md

@Rocky cant starrocks catch hostnames?

No, StarRocks does not automatically resolve client hostnames from connection IPs. It is intentionally designed to work with IP addresses for client connections to avoid the performance overhead and latency that come with reverse DNS lookups. Here is why and how you can work around it: 1. Why it only sees IPs Like many high-performance databases, StarRocks defaults to identifying connections by their network layer (IP address). * Performance: Performing a DNS lookup for every new connection would slow down the handshake process significantly, especially if your DNS server is slow or under load. * Reliability: If a DNS server becomes unreachable, the database might "hang" while waiting for resolution, preventing new users from logging in. 2. Best Workaround:

custom_query_id

(v3.4+) If you are on version 3.4.0 or higher, the best way to "catch" a hostname or any other identifier is to have your client application send it explicitly at the start of the session:

sql
-- The client app can get its own hostname and send it once:
SET SESSION custom_query_id = 'my-laptop-hostname';

-- Now, this string will appear in the fe.audit.log for every subsequent query
SELECT * FROM my_table;

3. Alternative: Resource Group Tagging If you need to identify or limit traffic from specific blocks of IPs (like a specific VPN range), you can use Resource Groups. While it still uses IPs, you can name the group after the source:

sql
CREATE RESOURCE GROUP 'marketing_team'
TO (source_ip='192.168.10.0/24');

4. Note on FQDN Access You might see "FQDN" mentioned in the StarRocks documentation. Note that FQDN mode in StarRocks is for internal cluster communication (letting FEs and BEs talk to each other via hostnames). It does not enable hostname resolution for external clients connecting to the cluster. Summary: StarRocks catches the IP address only. To track hostnames, you must pass that information from the client side using

custom_query_id

or SQL comments (e.g.,

SELECT ... /_ host: workstation-01 _/

). References • deployment/environment_configurations.md • administration/management/enable_fqdn.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md

@Rocky what about starrocks proxy?

In the context of StarRocks, a "proxy" usually refers to one of three things, but none of them will automatically provide the client hostname to the database engine because StarRocks identifies clients by their incoming TCP IP address. Here is how a proxy affects what you see: 1. The "StarRocks FE Proxy" (Kubernetes/Helm) If you are using the

starRocksFeProxySpec

in a Kubernetes deployment, this is an Nginx-based reverse proxy. * Purpose: It is used primarily for Stream Load (HTTP) to solve redirection issues. When you send data via HTTP, StarRocks FE redirects you to a BE. Outside of K8s, those internal BE IPs aren't reachable, so the FE Proxy handles that routing. * Identification: If you query through this proxy, StarRocks will likely see the IP of the Proxy pod, not your workstation IP, unless the proxy is configured for transparent pass-through (which is complex for TCP). 2. General Proxies (HAProxy, ProxySQL, F5) These are commonly used to load balance SQL traffic across multiple FEs. * The "IP Problem": By default, StarRocks will see the IP of the Load Balancer as the source of every query. * Proxy Protocol: While standard MySQL supports the PROXY protocol to pass the original client IP through a proxy, StarRocks does not currently support the PROXY protocol on its MySQL port (9030). * Consequence: You will lose the original IP and only see the proxy's IP in

SHOW PROCESSLIST

or audit logs. 3. How to get the Hostname/IP anyway Since the network layer (the proxy) hides your identity, you must provide it at the Application layer: 1. For SQL Queries (v3.4+ best method): Force your client or proxy to set a session variable. If you use ProxySQL, you can even automate this.

sql
    SET SESSION custom_query_id = 'hostname:workstation-01';

This string is captured in the

fe.audit.log

and can be used to identify exactly who ran what, regardless of the VPN or Proxy IP. 2. For Stream Load (HTTP): If you are using the FE Proxy for data loading, you can pass a unique

label

or use the

X-Forwarded-For

header in your HTTP request. However, StarRocks typically logs the

remoteIp

as the physical connection address. Summary: The "StarRocks Proxy" (Nginx) is for HTTP routing, not for identity. Because StarRocks doesn't support the PROXY protocol or reverse DNS, the only way to reliably "identify hostnames" behind a proxy/VPN is to pass the hostname as a string using

custom_query_id

or a SQL comment (e.g.,

/_ host:xyz _/

) comment. References • administration/management/resource_management/Load_balance.md • administration/management/FE_configuration.md • quick_start/helm.md • administration/management/BE_configuration.md • deployment/sr_operator.md • faq/operation_maintenance_faq.md

@Rocky what about enable proxy protocol?

As of the current version, StarRocks does not support the PROXY protocol (v1 or v2) for its MySQL query port (9030). Because StarRocks cannot parse the PROXY protocol header, enabling it on your load balancer (like HAProxy, AWS NLB, or Nginx) will cause connection failures. StarRocks will see the PROXY protocol header as malformed SQL traffic and drop the connection. Here is the situation regarding proxies and client identification: 1. MySQL Port (9030) - No PROXY Protocol Support For standard SQL connections, StarRocks identifies the client by the source IP of the TCP packet. * If you use a proxy/LB: You will see the IP of the proxy, not the client. * Workaround: Since you cannot use the PROXY protocol to "pass through" the real IP/hostname, you must use the application-layer workarounds mentioned previously: *

custom_query_id

: Set this variable at the start of your session to include the hostname. * SQL Comments: Append

/_ host: workstation-01 _/

to your queries. 2. HTTP Port (8030) - X-Forwarded-For For HTTP-based operations (like Stream Load or the HTTP SQL API), StarRocks is often placed behind an Nginx proxy (sometimes called the "FE Proxy" in Kubernetes). * Headers: While these proxies can be configured to add

X-Forwarded-For

or

X-Real-IP

headers, StarRocks FE does not currently use these headers to overwrite the "User" or "Client" IP in its internal audit logs or

SHOW PROCESSLIST

. * Audit Logs: Even if the header is present in the HTTP request, the FE audit log will typically still record the IP of the immediate network hop (the proxy). 3. StarRocks FE Proxy (Kubernetes) If you are using the official StarRocks Kubernetes Operator, it deploys an Nginx-based FE Proxy. * This proxy is specifically designed to handle HTTP 307 Redirections during Stream Loads. * It does not provide a way for the StarRocks database engine to "see through" to the original client hostname for MySQL protocol connections. Summary If you need to distinguish between users or hostnames behind a VPN/Proxy, you cannot rely on the PROXY protocol. You must modify your client connection logic to send an identifier string using:

sql
-- For v3.4+
SET SESSION custom_query_id = 'your_hostname_or_id';

References • administration/management/resource_management/Load_balance.md • administration/management/FE_configuration.md • quick_start/helm.md • deployment/sr_operator.md • administration/http_interface/query_detail.md References • administration/management/FE_configuration.md • administration/management/resource_management/Load_balance.md