

- server_id : 一个整数,request被分配到的server ID- gpc0 : 通用计数器,一个正的32位整数- conn_cnt : connection计数器,一个正的32位整数,记录了匹配当前entry的,从一个客户端处接收到的连接的绝对数量,这个数量并不意味着被accepted的连接数量,单纯就是收到的数量。- conn_cur : 当前connection数,一个正32位整数,当一新connection匹配指定的entry的时候,这个数值增加,当connection结束的时候,这个数值减少。通过这个值可以了解一个entry上任意时间点的准确的连接数。- conn_rate() : connection的连接频率 ,指定时间范围内(毫秒为单位)建立connection的频率。- sess_cnt : session计数器,一个正32位整数。记录了匹配当前entry的,从一个客户端处接收到的session的绝对数量。一个session指的是一个已经被layer 4规则接受的connection。- sess_rate() : session的连接频率,指定时间范围内(毫秒为单位)建立session的频率。这个数值可以通过ACL匹配一些规则。这个数值可以通过ACL匹配一些规则。- http_req_cnt : HTTP请求计数器,一个正32位整数。 记录了匹配当前entry的,从一个客户端接受到的HTTP请求的绝对数量。 无论这个请求是合法还是非法。当开启了客户端keep-alive的时候,这个数值与sess_cnt计数器的值就会不同。- http_req_rate() : HTTP的请求频率,指定时间范围内(毫秒为单位)收到的HTTP请求的频率。 无论这个请求是合法还是非法。当开启了客户端keep-alive的时候,这个数值与sess_rate() 数器的值就会不同。- http_err_cnt : HTTP错误计数器,一个正32位整数。 记录了匹配这个entry的HTTP错误的绝对数量,包含: 无效的、被截断的请求 被拒绝的或封堵的请求 认证失败 4xx错误- http_err_rate() : HTTP的请求错误频率,指定时间范围内(毫秒为单位)匹配的entry产生的HTTP错误的频率。- bytes_in_cnt : 一个匹配entry的客户端发往服务器的字节数,形式为一个正64位整数。headers也包含在统计中,通常用于图片或者video服务器限制上传文件。- bytes_in_rate() : 收到字节频率计数器,指定时间范围内(毫秒为单位)收到的字节数的频率,通常用于防止用户上传太快上传太多内容。这个计数器不建议使用,因为会有不公平情况,建议使用byte_in_cnt。- bytes_out_cnt : 服务器发往客户端的字节数,一个正64位整数。headers也包含在统计中,通常用于防止机器人爬站。- bytes_out_rate() : 发送字节频率计数器,指定时间范围内(毫秒为单位)服务器发送给客户端的字节数的频率。通常用于防止用户下载太快太多内容。这个计数器也不建议使用,因为会有不公平情况,建议使用byte_out_cnt。
backend per-ipstick-table type ip size 50k expire 120m store gpc0,http_req_rate(120s)frontendtcp-request connection track-sc1 src table per-iptcp-request connection reject if { sc1_get_gpc0 gt 0 }...use_backend foo...backend footcp-request content track-sc2 src table per-ip if METH_POSTacl bruteforce_detection sc2_http_req_rate gt 5acl block sc1_inc_gpc0 gt 0http-request deny if bruteforce_detection block
# 定义一个ip类型作为key的stick-table,用于存储这个ip相关的计数器stick-table type ip size 500k expire 30s store conn_cur,conn_rate(10s),http_req_rate(10s),http_err_rate(10s)# 打开源ip追踪,用以向stick-table写入数据tcp-request content track-sc0 src
# 从request或response中抽取SSL session ID,用这个ID将requset与backend"粘住"# SSL session ID可能由client提供,也可能由server提供backend httpsmode tcpbalance roundrobin# 最大SSL session ID长度是32 bytes.stick-table type binary len 32 size 30k expire 30m# 定义两个acl,分别匹配ssl client hello和ssl server hello ,在这个位置,ACL并没有被执行,仅仅是将ACL名字与判断条件关联起来而已。acl clienthello req.ssl_hello_type 1acl serverhello res.ssl_hello_type 2# 使用tcp content accept来检测ssl client hello和ssl server hello.# 因为client ssl hello包含在request中,因此必须等待5秒,确保tcp连接的数据都进入了buffertcp-request inspect-delay 5stcp-request content accept if clienthello # 这里,acl的check操作才真正执行# ssl server hello 由服务器端发出,所以不需要延迟,直接判断tcp-response content accept if serverhello# SSL session ID 的长度为1 byte,位置在tcp payload的 offset 43之后。# client hello在请求中,server hello在response中# 取出payload_lv(43,1),作为key存入stick-tablestick store-request payload_lv(43,1) if clienthellostick store-response payload_lv(43,1) if serverhello# 用payload_lv(43,1)做key去stick-table中查找stick match payload_lv(43,1)server s1 192.168.1.1:443server s2 192.168.1.2:443
https://deviantony.wordpress.com/2014/10/30/rabbitmq-and-haproxy-a-timeout-issue/
http://agiletesting.blogspot.hk/2014/07/troubleshooting-haproxy-502-errors.html
https://www.digitalocean.com/community/tutorials/how-to-implement-ssl-termination-with-haproxy-on-ubuntu-14-04
http://www.adheaven.com/post/22208788775/solving-problem-with-502-bad-gateway-in-haproxy
http://www.steviecaldwell.com/2014/09/troubleshooting-haproxy.html
ENGINE=InnoDBPARTITION BY RANGE(clock)(PARTITION p2016_02_13 VALUES LESS THAN (UNIX_TIMESTAMP("2016-02-13 00:00:00")) ENGINE = InnoDB,PARTITION p2016_02_14 VALUES LESS THAN (UNIX_TIMESTAMP("2016-02-14 00:00:00")) ENGINE = InnoDB);
ENGINE=InnoDBPARTITION BY RANGE (clock)(PARTITION p2016_01 VALUES LESS THAN (UNIX_TIMESTAMP("2016-01-01 00:00:00")) ENGINE = InnoDB,PARTITION p2016_02 VALUES LESS THAN (UNIX_TIMESTAMP("2016-02-01 00:00:00")) ENGINE = InnoDB);
删除这一行====> PRIMARY KEY (id)增加这一行====> CREATE INDEX `history_log_0` ON `history_log` (`id`);删除这一行====> CREATE UNIQUE INDEX `history_log_2` ON `history_log` (`itemid`,`id`);
删除这一行====> PRIMARY KEY (id)增加这一行====> CREATE INDEX `history_text_0` ON `history_text` (`id`);删除这一行====> CREATE UNIQUE INDEX `history_text_2` ON `history_text` (`itemid`,`id`);
修改====> ENGINE=BLACKHOLE;
注意: NOT NULL后边的逗号(,) , 一定要注意,多了就会报语法错误了。
找到要查询的流量后,选择“Time
Windows”来设定要查询的流量区间。
选择“Time
Windows”后,X轴的光标尺会分裂为左右两边。
先拉右半边游标尺到观察区间的右边。
调整显示方式为“sum”,可在Traffic部分发现问题流量来自tcp协议,
足足有1.2G远远大于其它protocol。
然后在Netflow Processing区块中,将Options改以“Stat TopN”的方式,做前几名大户排序。
发现第一名主机IP是192.168.10.208。
找到大户后,接下来要确认的是该用户是以发送端还是接收端在占用流量?
以tcp
protocol及src
ip 192.168.10.208的条件查询其流量
改以tcp protocol及dst ip 192.168.10.208的方式确认其流量。
proto tcp and dst ip 192.168.10.208
经过比对,做为发送端的流量只有9.2M,做为接收端的流量则有1.2G;
很明显的192.168.10.208是做为接收端在下载流量。
改以List Flow来查看来源与目的间的关系。
发现192.168.10.208主要以80及443 port两种方式在下载数据,确认究竟是哪一port所造成的流量。
proto tcp and dst ip 192.168.10.208 and src port 80
由流量来看,192.168.10.208是透过80 port在下载数据。但有很多80
port在下载,究竟是哪个来源IP呢?
把Flows打开到最大10000,查询所有联机。
原来是作者本人透过网页在Ubuntu网站下载iso档所造成,一切都是误会~但也成功透过Nfsen查询到占用带宽的凶手!Nfsen的基本操作示范到此,更深入的应用留给有兴趣的您继续研究啰~
RHEL 6 (and CentOS 6, and SL 6): 6.0-6.5
are good. 6.6
is BAD. 6.6.z
is good.
RHEL 7
(and CentOS 7, and SL 7): 7.1
is BAD. As
of yesterday. there does not yet appear to be a 7.x
fix. [May 13,
2015]
RHEL 5
(and CentOS 5, and SL 5): All versions
are good (including
5.11).