问题背景：业务侧可能遇到过这样一个问题，通过MySQL SlowLog拿到某个慢查问的SQL，然而却很难找到对应的业务代码的出处（当然SQL自身具备非凡识别性或是对业务零碎十分相熟除外），如果SQL特色在零碎中辨识度不高或者多处都存在，找起来着实很苦楚，亲测是这样。
针对上述呈现的问题，Nginx request_id能够完满解决
$request_id
unique request identifier generated from 16 random bytes, in hexadecimal (1.11.0)
nginx 从1.11 之后反对生成request_id，request_id是以16进制示意，由16个随机字节生成的惟一申请标识符。通过$request_id传递，能够将接入层、web层、底层sql串起来，通过request_id可能跟踪每次申请的路由。
Talk is cheap, show me the code：
- nginx 接入层的要害配置：
map $http_x_log_request_id $log_request_id { default $http_x_log_request_id; - $request_id; "" $request_id;}location ~ .*\.(php|php5)?$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param LOG_REQUEST_ID $log_request_id; include fastcgi_params; fastcgi_intercept_errors on; error_page 500 502 503 504 /50x_php.html;}2.业务层Web框架入口设置全局变量：
$GLOBALS['LOG_REQUEST_ID'] = !empty($_SERVER['LOG_REQUEST_ID']) ? $_SERVER['LOG_REQUEST_ID'] : $_SERVER['REQUEST_TIME_FLOAT'];3.业务日志收集到文件：
<?php....$trace_log['controller'] = controller值$trace_log['action'] = action值$trace_log['url'] = 以后申请的url, 能够用$_SERVER['REQUEST_URI']获取;$trace_log['reference'] = //reference, 能够从$_SERVER获取;$trace_log['user_agent'] = user_agent值，能够从$_SERVER获取;$trace_log['ip'] = ip获取函数$trace_log['http_status'] = http状态码，能够从$_SERVER获取;$trace_log['log_request_id'] = isset($GLOBAL['LOG_REQUEST_ID']) ? isset($GLOBAL['LOG_REQUEST_ID']) : '';write_log_to_file(json_encode($trace_log));....- 文件->ELK
- 框架底层SQL执行：
$comment_trace_id = '';if(isset($GLOBALS['LOG_REQUEST_ID']) && !empty($GLOBALS['LOG_REQUEST_ID'])) { $comment_trace_id= '/*trace_id_' . $GLOBALS['LOG_REQUEST_ID'] . '*/';}$sql = $sql . $comment_trace_id; //sql 尾接request_id$this->_result = $this->execute($sql);//这样底层的慢日志sql 就会带上request_id这里在执行的SQL语句前面接上/*trace_id_request_id*/，并不影响SQL自身的执行，与此同时还能晓得SQL的出处（与申请关联）。
根据上述步骤下来，就能够定位出一个SQL的来源于哪个申请，并且能够晓得这个申请是由哪个账号或是用户产生的，以及产生工夫等等等等。是不是很帅？
专一Web开发，后盾开发，DB和架构，欢送交换和学习。
微信公众号：码农漫谈