Nginx 前挂Cloudflare 后的日志分析

将nginx服务器隐藏在cloudflare 服务后端,在nginx 的默认access log里面显示的IP 都是cloudflare,因此我们需要把日志中的访问IP改成真正的用户IP. 有很多种办法可以实现,但是下面的这种办法应该是最简单的.

Cloudflare 用X-Forwarded-For这个header 来传递用户的真实IP,因此我们只需要在nginx 的conf中,设置一个新的nginx log format就可以.

默认的nginx access log format 是:

log_format combined '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"'; 

我们可以添加一个新的log format:

log_format csf '$http_x_forwarded_for - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"';

access log 可以设置成类似于这样的:

access_log /your/access/log/path csf;

这样,用户的真实IP就会展现在access log里面了

WebNX Utah 服务器benchmark

/dev/sda:

=== START OF INFORMATION SECTION ===
Model Family: Intel 730 and DC S35x0/3610/3700 Series SSDs
Device Model: INTEL SSDSC2BA400G4
Serial Number: BTHV513606YB400NGN
LU WWN Device Id: 5 5cd2e4 04b7c7e4a
Firmware Version: G2010160
User Capacity: 400,088,457,216 bytes [400 GB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-3 T13/2161-D revision 5
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Wed Sep 18 22:16:03 2019 EDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

可以看到SSD 是intel 的DC S3710

----------------------------------------------------------------------
CPU model            : Intel(R) Xeon(R) CPU E3-1271 v3 @ 3.60GHz
Number of cores      : 8
CPU frequency        : 1000.233 MHz
Total size of Disk   : 359.3 GB (1.1 GB Used)
Total amount of Mem  : 32129 MB (162 MB Used)
Total amount of Swap : 7627 MB (0 MB Used)
System uptime        : 0 days, 21 hour 29 min
Load average         : 0.01, 0.03, 0.00
OS                   : Debian GNU/Linux 10
Arch                 : x86_64 (64 Bit)
Kernel               : 4.19.0-6-amd64
----------------------------------------------------------------------
I/O speed(1st run)   : 418 MB/s
I/O speed(2nd run)   : 418 MB/s
I/O speed(3rd run)   : 417 MB/s
Average I/O speed    : 417.7 MB/s
----------------------------------------------------------------------
Node Name                       IPv4 address            Download Speed
CacheFly                        205.234.175.175         105MB/s
Linode, Tokyo2, JP              139.162.65.37           18.7MB/s
Linode, Singapore, SG           139.162.23.4            12.8MB/s
Linode, London, UK              176.58.107.39           18.9MB/s
Linode, Frankfurt, DE           139.162.130.8           17.0MB/s
Linode, Fremont, CA             50.116.14.9             71.7MB/s
Softlayer, Dallas, TX           173.192.68.18           30.1MB/s
Softlayer, Seattle, WA          67.228.112.250          33.6MB/s
Softlayer, Frankfurt, DE        159.122.69.4            8.31MB/s
Softlayer, Singapore, SG        119.81.28.170           7.09MB/s
Softlayer, HongKong, CN         119.81.130.170          7.78MB/s

第二遍测试:

----------------------------------------------------------------------
CPU model : Intel(R) Xeon(R) CPU E3-1271 v3 @ 3.60GHz
Number of cores : 8
CPU frequency : 1277.243 MHz
Total size of Disk : 359.3 GB (1.1 GB Used)
Total amount of Mem : 32129 MB (164 MB Used)
Total amount of Swap : 7627 MB (0 MB Used)
System uptime : 0 days, 21 hour 32 min
Load average : 0.07, 0.07, 0.01
OS : Debian GNU/Linux 10
Arch : x86_64 (64 Bit)
Kernel : 4.19.0-6-amd64
----------------------------------------------------------------------
I/O speed(1st run) : 419 MB/s
I/O speed(2nd run) : 418 MB/s
I/O speed(3rd run) : 418 MB/s
Average I/O speed : 418.3 MB/s
----------------------------------------------------------------------
Node Name IPv4 address Download Speed
CacheFly 205.234.175.175 105MB/s
Linode, Tokyo2, JP 139.162.65.37 17.0MB/s
Linode, Singapore, SG 139.162.23.4 13.0MB/s
Linode, London, UK 176.58.107.39 19.6MB/s
Linode, Frankfurt, DE 139.162.130.8 16.8MB/s
Linode, Fremont, CA 50.116.14.9 85.3MB/s
Softlayer, Dallas, TX 173.192.68.18 31.6MB/s
Softlayer, Seattle, WA 67.228.112.250 32.7MB/s
Softlayer, Frankfurt, DE 159.122.69.4 8.59MB/s
Softlayer, Singapore, SG 119.81.28.170 7.08MB/s
Softlayer, HongKong, CN 119.81.130.170 8.86MB/s
----------------------------------------------------------------------

/dev/sdb:

=== START OF INFORMATION SECTION ===
Model Family: Seagate Barracuda 3.5
Device Model: ST2000DM006-2DM164
Serial Number: Z560FAW9
LU WWN Device Id: 5 000c50 0a1e182e7
Firmware Version: CC26
User Capacity: 2,000,398,934,016 bytes [2.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 7200 rpm
Form Factor: 3.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2, ACS-3 T13/2161-D revision 3b
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Wed Sep 18 22:21:57 2019 EDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

CN2 GIA 和普通 CN2 的区别

CN2 GIA:中国电信 CN2 GIA,属于 CN2 中的 Global Internet Access 产品,等级最高,省级/出国/国际骨干节点都以 59.43 开头,全程没有 202.97 开头的节点(市级节点一般不保证,到省级节点以及之前的一般都是 59.43 节点)。CN2 GIA 拥有独立的回国链路,属于轻度负载,保证访问质量。这种带宽的质量是电信网络里最好的,但是缺点也很明显。缺点一,整个 GIA 的出口带宽较小,在较大流量攻击的时候会导致整个GIA网络波动,和攻击的随机性比较强一样,指不定什么时候就抽一抽。缺点二,价格太贵,价格是 CN2 GT 的 3 倍左右。

普通 CN2:中国电信 CN2 GT,是电信 CN2 产品线中的 Global Transit(GIS-Global Internet Service)的产品,CN2 GT 到中国国际出口有自己的单独线路,但是进入国内还是使用的 163 出口。省级/出国节点为 202.97 开头(202.97 节点是中国电信的 163 骨干网的节点),国际骨干节点有 2~4 个 59.43 开头的 CN2 节点。接入 CN2 GT 的机房比较多,包括 C3 等,C3 就是目前搬瓦工的 CN2 线路所在的 DC8 机房,另外一个 DC3 CN2 其实是 QuadraNet 的 CN2 机房。这也就是为什么有时候这些 C3 机房回国堵死的情况,因为实际上 CN2 GT 共享了 163 的出口。

此外,对于搬瓦工的 VPS 来说,CN2 GIA 是中国电信、中国联通和中国移动三网都走 CN2 GIA 回国的,也就是联通和移动的回国节点也是走的 CN2 节点;而普通的 CN2 只有中国电信回国走的是 CN2 节点,移动和联通走的是各自的直连线路,所以普通 CN2 对于移动和联通来说其实加成不大。移动和联通用户,如果想享受 CN2 节点,只能直接买 CN2 GIA 产品。

Revive Adserver 无法读取GEO Module

这两天用LNMP 1.3 来安装Revive Adserver,可是悲催的发现无法enable GEO Module。。。各种mysql 的格式都试了还是不行。。。

甚是苦恼。。。

然后啥都干不下。。一直在看Revive Adserver 的源码,想看看是怎么回事。。。没想到这套框架实在太复杂了。。。

今天中午无意间检查了一下debug log file, 无法里面有很多warning。。说是scandir这个功能无法使用。。。心里就大概知道怎么回事了。。

果然enable php scandir 以后,正常读取GEO module。。。

因为以前也是用LNMP 来安装revive adserver也一直没有什么问题。。就一直没有往环境这个问题去想。。

看来这又是LNMP1.3上新加的一个功能。。又是一个坑啊。。

用google DFP 来 serve 第三方的popunder tag

一个网站只放一个popunder 的 tag 有点太吃亏了,但是如果用收费的ad server 去 rotate ad tag的话,那有太贵了。因为pop under 的 ad tag 并不是每个call 都会创建pop under 的ad的,李米娜有一个frequency 的限制,一般为1/24.

Google DFP 在这上面是免费的,可以很好的解决这个问题。但是如何用google DFP来循环serve 第三方的pop under tag 呢?

首先需要创建ad unit,popup 和 pop under 都属于out of page 的广告,所以ad unit 的size要设置为1X1.

然后去创建order,在line 里面的ad size 选择为1X1, 然后广告选择为3rd party,就可以了。

关键的地方在于如何获得ad unit 的 tag code

我在这个地方花费了好几个小时才发现:

1) tag 要是用sync的, async 的不听

2) 取消 single request

3)添加out of page 的属性

 

完成这几步,你的pop under 就会开始delivery 啦