obproxy_diagnosis.log|V4.4.1|OceanBase Database Proxy |docs|OceanBase Documentations

obproxy_diagnosis.log records OceanBase Database Proxy (ODP) diagnostic information in aspects of logon, logout, startup, connection, and routing.

The format of logs in obproxy_diagnosis.log varies with the log type. This topic describes logs of different types with some examples.

Logon logs

When the connection_diagnosis_option parameter is set to 7 (default value), obproxy_diagnosis.log prints logon logs.

Note

By default, ODP enables protocol diagnostics and full-featured connection diagnostics for easier troubleshooting. However, when the connection_diagnosis_option parameter is set to 7, ODP V4.3.6 may experience up to a 6% performance degradation in short connection scenarios compared to ODP V4.3.5. Therefore, the recommended value for the connection_diagnosis_option parameter varies depending on the use case, as follows:

In long connection scenarios, logout logs have minimal performance impact. We recommend setting the connection_diagnosis_option parameter to 7.
If performance in short connection scenarios is a concern, we recommend setting the connection_diagnosis_option parameter to 3 and the protocol_diagnosis_level parameter to 0.

Notice

In extreme performance configurations, when an exception occurs (such as a disconnection or hung state), the lack of critical diagnostic logs may make it difficult to troubleshoot. Please consider this carefully.

In obproxy_diagnosis.log, logon logs are identified by the [LOGIN] keyword. Logs for failed and successful logons are displayed in different formats.

Here is a example of a log for a failed logon:

[2024-01-03 17:31:15.864625] [1782][Y0-00007F986AC85710] [LOGIN](trace_type="PROXY_INTERNAL_TRACE", connection_diagnosis={cs_id:1, ss_id:0, proxy_session_id:0, server_session_id:0, client_addr:"10.10.10.1:53280", server_addr:"*Not IP address [0]*:0", cluster_name:"obcluster", tenant_name:"proxysys", user_name:"root", error_code:0, error_msg:"Ooooooooooooops", request_cmd:"COM_LOGIN", sql_cmd:"COM_LOGIN", req_total_time(us):168}{user_sql:""})

Pay attention to the following fields in the log:

[LOGIN]: indicates that the current log is a logon log.
client_addr: the IP address of the logon client.
cluster_name: the cluster name of the logon database.
tenant_name: the tenant name used for the logon.
user_name: the username used for the logon.
error_msg: the cause of the logon failure.

Here is an example of a log for a successful logon:

[2025-10-14 16:00:03.630085] [1573290][Y0-000014CA767EE760] [LOGIN](cluster_name=obcluster, tenant_name=tt1, user_name=test, has_tenant_username=true, has_cluster_username=false, is_ssl=false, character_set=33, database=test, addr="127.0.0.1:41976", login_result="success")

Pay attention to the following fields in the log:

[LOGIN]: indicates that the current log is a logon log.
cluster_name: the cluster name of the logon database.
tenant_name: the tenant name used for the logon.
user_name: the username used for the logon.
addr: the IP address of the logon client.
login_result: the logon result.

Logout type

When the connection_diagnosis_option is set to 7 (the default), the obproxy_diagnosis.log file records the disconnection logs.

Notice

ODP opens the protocol diagnostics and connection diagnostics (full functionality) by default to facilitate troubleshooting. However, when the value of the connection_diagnosis_option configuration parameter is 7, the performance of ODP V4.3.6 decreases by up to 6% compared to that of V4.3.5 in the short connection scenario. Therefore, the recommended value of the connection_diagnosis_option configuration parameter varies depending on the use case as follows:

In the scenario of keeping a long connection, setting the value of the connection_diagnosis_option parameter to 7 minimizes the impact of the logout log. We recommend this setting.
If performance of short connection scenarios is sensitive, we recommend that you set connection_diagnosis_option to 3 and protocol_diagnosis_level to 0.

Note

Under optimal performance settings, when exceptions such as connection loss or hangs occur, it may be challenging to locate the issue due to the absence of critical diagnostic logs. Please consider this carefully.

The log records of the log out type are marked with the [LOGOUT] keyword. The following are examples of the log records of the log out type:

[2025-10-14 16:49:59.258133] [1573290][Y0-000014CA767EE760] [LOGOUT](trace_type="CLIENT_VC_TRACE", connection_diagnosis={cs_id:2, ss_id:0, proxy_session_id:435979484706045956, server_session_id:3221494958, client_addr:"127.0.0.1:41976", server_addr:"127.0.0.1:7777", proxy_server_addr:"127.0.0.1:6164", cluster_name:"obcluster", tenant_name:"tt1", user_name:"test", error_code:0, error_msg:"user normal logout", request_cmd:"OB_MYSQL_COM_QUIT", sql_cmd:"OB_MYSQL_COM_QUIT", req_total_time(us):13000}{user_sql:""}, protocol_diagnosis=NULL)

When viewing logs, pay attention to the following fields:

[LOGOUT] : indicates that the current log is a logout log.
client_addr The IP address and port number used for the client before disconnection.
cluster_name: the name of the cluster to which you connected before you log off.
tenant_name: The name of the tenant to which you were connected before logging out.
user_name: the username used when you connect before logging off.
error_msg: the error message. For example, if the value is user normal logout, the message indicates that the user has logged out normally.

Startup logs

In obproxy_diagnosis.log, startup logs are identified by the [REBOOT] keyword. Startup logs record key system information and startup actions. Here is an example of a startup log:

[2024-01-03 17:30:11.348451] [1782][Y0-0000000000000000] [REBOOT](info="obproxy version: ObProxy-OceanBase 4.2.3.0-20231226165754.el7, revision: 20231226165754-1f55e4ba0e226b6e710312a8812e27f6ccb33ba2, sysname: Linux, os release 3.10.0-1160.95.1.el7.x86_64, machine: x86_64, pid: 1782, ppid: 1, result: reboot success")

Pay attention to the following fields in the log:

[REBOOT]: indicates that the current log is a startup log.
info and revision: the ODP version information.
sysname: the operating system version.
machine: the system architecture.
pid: the process ID.
ppid: the parent process ID.
result: the startup result.

The ODP version information, system architecture, and operating system version are essential for troubleshooting. The process ID and parent process ID facilitate troubleshooting of hot restart issues.

Connection logs

In obproxy_diagnosis.log, connection logs are identified by the [CONNECTION] keyword. Here is an example of a connection log:

[2024-01-04 01:45:53.419105] [1782][Y0-00007F986A823710] [CONNECTION](trace_type="TIMEOUT_TRACE", connection_diagnosis={cs_id:4, ss_id:0, proxy_session_id:0, server_session_id:0, client_addr:"10.10.10.1:53368", server_addr:"*Not IP address [0]*:0", cluster_name:"obcluster", tenant_name:"proxysys", user_name:"root", error_code:-10022, error_msg:"OBProxy inactivity timeout", request_cmd:"COM_SLEEP", sql_cmd:"COM_END", req_total_time(us):28800931181}{timeout(us):28800000000, timeout_event:"CLIENT_WAIT_TIMEOUT"})

For more information about the fields in connection logs and how to diagnose connection issues based on logs, see Connection diagnostics.

Routing logs

In obproxy_diagnosis.log, routing logs are identified by the [ROUTE] keyword. Here is an example of a routing log:

[2023-09-19 18:48:49.079458] [106700][Y0-00007FD892AB64E0] [ROUTE]((*route_diagnosis=
Trans Current Query:"execute stmt"
Route Prompts
--------------
> ROUTE_INFO
  [INFO] Will do table partition location lookup to decide which OBServer to route to
> ROUTE_POLICY
  [INFO] Will route to table's partition leader replica(10.10.10.1:4001) using non route policy because query for STRONG read
Route Plan
--------------
> SQL_PARSE:{cmd:"COM_QUERY", table:"t0"}
> ROUTE_INFO:{route_info_type:"USE_PARTITION_LOCATION_LOOKUP"}
> LOCATION_CACHE_LOOKUP:{mode:"oceanbase"}
  > TABLE_ENTRY_LOOKUP_DONE:{table:"t0", table_id:"500078", table_type:"USER TABLE", partition_num:64, entry_from_remote:false}
  > PARTITION_ID_CALC_START:{}
    > EXPR_PARSE:{col_val:"=88888888,=1111111"}
    > RESOLVE_EXPR:{part_range:"[88888888 ; 88888888]", sub_part_range:"[1111111 ; 1111111]"}
      > RESOLVE_TOKEN:{token_type:"TOKEN_INT_VAL", resolve:"BIGINT:88888888", token:"88888888"}
      > RESOLVE_TOKEN:{token_type:"TOKEN_INT_VAL", resolve:"BIGINT:1111111", token:"1111111"}
    > CALC_PARTITION_ID:{part_description:"partition by hash(INT<binary>) partitions 8 subpartition by hash(INT<binary>) partitions 8"}
  > PARTITION_ID_CALC_DONE:{partition_id:200073, level:2, partitions:"(p0sp7)", parse_sql:"prepare stmt from 'insert into t0 values(88888888,1111111,9999999)'"}
  > PARTITION_ENTRY_LOOKUP_DONE:{leader:"10.10.10.1:4001", entry_from_remote:false}
> ROUTE_POLICY:{chosen_route_type:"ROUTE_TYPE_LEADER"}
> CONGESTION_CONTROL:{svr_addr:"10.10.10.1:4001"}

For more information about routing logs and routing issue diagnostics, see Routing diagnostics.