关于nginx:利用Nginx-requestid对用户行为追踪

51次阅读

共计 1841 个字符，预计需要花费 5 分钟才能阅读完成。

问题背景：业务侧可能遇到过这样一个问题，通过 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 和架构，欢送交换和学习。
微信公众号：码农漫谈

正文完