obproxy_diagnosis.log records OceanBase Database Proxy (ODP) diagnostic information in aspects of logon, 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
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_code: the logon result.error_msg: the cause of the logon failure.
Here is an example of a log for a successful logon:
[2024-01-09 14:59:28.601738] [32181][Y0-00007F6336803880] [LOGIN]((hsr={cluster_name:"obcluster", tenant_name:"sys", user_name:"root", cluster_id:0, user_tenant_name:"root@sys", full_name:"root@sys#obcluster", response:{capability_.capability:150972045, max_packet_size:16777216, character_set:33, username:"root@sys", database:"oceanbase", auth_plugin_name:"mysql_native_password", connect_attrs:[[0]{key:"__ob_client_attribute_capability_flag", value:"1"}, [1]{key:"__mysql_client_type", value:"__ob_proxy"}, [2]{key:"__connection_id", value:"3221641115"}, [3]{key:"__proxy_connection_id", value:"12400942319116943372"}, [4]{key:"__cluster_name", value:"obcluster"}, [5]{key:"__global_vars_version", value:"0"}, [6]{key:"__proxy_capability_flag", value:"4193111"}, [7]{key:"__client_ip", value:"10.10.10.1"}, [8]{key:"__proxy_version", value:"4.2.3.0"}, [9]{key:"__client_addr_port", value:"50572"}, [10]{key:"__client_session_id", value:"270340"}, [11]{key:"__client_connect_time", value:"1704783568600575"}]}, is_clustername_from_default:true, has_tenant_username:true, has_cluster_username:false}, addr="10.10.10.1:50572", 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.error_msg: the cause of the logon failure.addr: the IP address of the logon client.login_result: the logon result.
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.infoandrevision: 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.