四、挖掘accessLog日志
1、nginx访问日志的用处
access.log日志用处
- 统计站点访问ip来源、某个时间段的访问频率
- 查看访问最频的页面、Http响应状态码、接口性能
- 接口秒级访问量、分钟访问量、小时和天访问量
默认配置：
#log_format main '$remote_addr - $remote_user [$time_local] "$request" ' # '$status $body_bytes_sent "$http_referer" ' # '"$http_user_agent" "$http_x_forwarded_for"';
案例：
122.70.148.18 - - [04/Aug/2020:14:46:48 +0800] "GET /user/api/v1/product/order/query_state?product_id=1&token=xdclasseyJhbGciOJE HTTP/1.1" 200 48 "https://youyou.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.89 Safari/537.36"
解析：
$remote_addr 对应的是真实日志里的122.70.148.18，即客户端的IP。 $remote_user 对应的是第二个中杠“-”，没有远程用户，所以用“-”填充。 ［$time_local］对应的是[04/Aug/2020:14:46:48 +0800]。 “$request”对应的是"GET /user/api/v1/product/order/query_state?product_id=1&token=xdclasseyJhbGciOJE HTTP/1.1"。 $status对应的是200状态码，200表示正常访问。 $body_bytes_sent对应的是48字节，即响应body的大小。 “$http_referer” 来源，防盗链接。对应的是”https://youyou.com/“，若是直接打开域名浏览的时，referer就会没有值，为”-“。 “$http_user_agent” 对应的是”Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:56.0) Gecko/20100101 Firefox/56.0”。 “$http_x_forwarded_for” 对应的是”-“或者空。
日志变量参考：https://www.cnblogs.com/wjoyxt/p/6178731.html
2、Nginx统计站点访问量、高频url统计
查看访问最频繁的前100个IP
awk '{print $1}' access_temp.log | sort -n |uniq -c | sort -rn | head -n 100
统计访问最多的url 前20名
cat access_temp.log |awk '{print $7}'| sort|uniq -c| sort -rn| head -20 | more
命令基础
awk 是文本处理工具，默认按照空格切分，$N 是第切割后第N个，从1开始 sort命令用于将文本文件内容加以排序，-n 按照数值排，-r 按照倒序来排 案例的sort -n 是按照第一列的数值大小进行排序，从小到大，倒序就是 sort -rn uniq 去除重复出现的行列, -c 在每列旁边显示该行重复出现的次数。
3、自定义日志格式，统计接口响应耗时
日志格式增加$request_time
从接受用户请求的第一个字节到发送完响应数据的时间，即包括接收请求数据时间、程序响应时间、输出响应数据时间 $upstream_response_time：指从Nginx向后端建立连接开始到接受完数据然后关闭连接为止的时间 $request_time一般会比upstream_response_time大，因为用户网络较差，或者传递数据较大时，前者会耗时大很多
配置自定义日志格式
log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for" $request_time'; server { listen 80; server_name aabbcc.com; location / { root /usr/local/nginx/html; index xdclass.html; } #charset koi8-r; # access_log logs/host.access.log main; }
统计耗时接口, 列出传输时间超过 2 秒的接口，显示前5条
cat time_temp.log|awk '($NF > 2){print $7}'|sort -n|uniq -c|sort -nr|head -5 备注：$NF 表示最后一列, awk '{print $NF}'
五、nginx负载均衡
负载均衡介绍
- 负载均衡（Load Balance）
分布式系统中一个非常重要的概念，当访问的服务具有多个实例时，需要根据某种“均衡”的策略决定请求发往哪个节点，这就是所谓的负载均衡，
原理是将数据流量分摊到多个服务器执行，减轻每台服务器的压力，从而提高了数据的吞吐量
- 负载均衡的种类
通过硬件来进行解决，常见的硬件有NetScaler、F5、Radware和Array等商用的负载均衡器，但比较昂贵的
通过软件来进行解决，常见的软件有LVS、Nginx等,它们是基于Linux系统并且开源的负载均衡策略
目前性能和成本来看，Nginx是目前多数公司选择使用的
配置案例
upstream lbs { server 192.168.0.106:8080; server 192.168.0.106:8081; } server { listen 80; server_name aabbcc.com; location /api/ { proxy_pass http://lbs; proxy_redirect default; } }
http://aabbcc.com:80/api/test/hello
访问流程如下：
浏览器输入：http://aabbcc.com:80/api/v1/getUser 匹配 域名 server_name aabbcc.com 匹配 端口 listen 80 匹配 资源路径 location api 默认轮询转发 服务列表 lbs 最终访问的地址：http://192.168.0.106:8080/api/v1/getUser 或者 http://192.168.0.106:8081/api/v1/getUser
1、常见负载均衡策略
（1）节点轮询（默认）
- 简介：每个请求按顺序分配到不同的后端服务器
- 场景：会造成可靠性低和负载分配不均衡，适合静态文件服务器
（2）weight 权重配置
- 简介：weight和访问比率成正比，数字越大，分配得到的流量越高
- 场景：服务器性能差异大的情况使用
upstream lbs { server 192.168.159.133:8080 weight=5; server 192.168.159.133:8081 weight=10; }
（3）ip_hash（固定分发）
- 简介：根据请求按访问ip的hash结果分配，这样每个用户就可以固定访问一个后端服务器
- 场景：服务器业务分区、业务缓存、Session需要单点的情况
upstream lbs { ip_hash; server 192.168.159.133:8080; server 192.168.159.133:8081; }
2、节点状态配置
upstream还可以为每个节点设置状态值
- down 表示当前的server暂时不参与负载
server 192.168.159.133:8080 down;
- backup 其它所有的非backup机器down的时候，会请求backup机器，这台机器压力会最轻，配置也会相对低
server 192.168.159.133:8080 backup;
六、Nginx探测后端节点可用性
- max_fails 允许请求失败的次数，默认为1.当超过最大次数时就不会请求
- fail_timeout : max_fails次失败后，暂停的时间，默认：fail_timeout为10s
- 参数解释
max_fails=N 设定Nginx与后端节点通信的尝试失败的次数。
在fail_timeout参数定义的时间内，如果失败的次数达到此值，Nginx就这个节点不可用。
在下一个fail_timeout时间段到来前，服务器不会再被尝试。
失败的尝试次数默认是1，如果设为0就会停止统计尝试次数，认为服务器是一直可用的。
- 具体什么是nginx认为的失败呢
可以通过指令proxy_next_upstream来配置什么是失败的尝试。
注意默认配置时，http_404状态不被认为是失败的尝试。
upstream lbs { server 192.168.0.106:8080 max_fails=2 fail_timeout=60s; server 192.168.0.106:8081 max_fails=2 fail_timeout=60s; } server { location /api/ { proxy_pass http://lbs; proxy_next_upstream error timeout http_500 http_503 http_404; } }
