logstash 初体验

logstash 是用 JRuby 的,但是打包成了 jar 的包,下载即用。
下面这个是在单机上运行 LS:
# java -jar logstash-1.1.1-monolithic.jar agent -f logstash-simple.conf --log /var/log/logstash
注意:需要给机器分配足够的内存,否则会出现 HEAP 用完的错误,造成程序直接被 kill 退出。

这个可以附带一个 web:
# java -jar logstash-1.1.1-monolithic.jar agent -f logstash-simple.conf -- web --backend elasticsearch:///?local
注意那个 "–",其实是个分隔符,也可以像下面这样写,不过要开两个 shell:
# java -jar logstash-1.1.1-monolithic.jar agent -f logstash-simple.conf
# java -jar logstash-1.1.1.-monolithic.jar web --backend elasticsearch:///?local

默认开启这五个端口,其中 9200, 9300 是 ES 做监听的;9301, 9302 是 ES 跟 web interface 通讯;9292 是 web UI 的监听端口。
如果不开 web,则只有 9200,9300 以及 9301 这三个端口。

LS 的命令参数很简单,只分 agent 和 web 两种,具体的请看这里

LS 的收集方式分为 standalonecentralized
Continue reading

代码变更对系统的影响

某台 Mongo,监控的 agent 突然取不到所有的数据,ssh 也直接显示:
ssh_exchange_identification: Connection closed by remote host
前提是我已经加了 public key。

通过远程卡登录,出现大量的如下信息:
INFO: task dpkg:5206 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disable this message.

尝试登录,进不了 shell,报错:
login: failure forking: Cannot allocate memory

猜测可能是机器的某些资源耗尽引起的。不得以强行 warn boot。之后的一小段时间内没有出现此问题,但是大概 2h 之后,又出现了上面的情况,查看系统资源的占用的情况,下面三张图分别是那段时间的 inode table, interrupts and context switch 以及 threads 显示

可以发现在 18 号的 20 点出现了一次波动,reboot 之后稍有缓解,但是从 24 点又开始出现了 threads 直线上升的情况。在网络没有变动,系统没有变动的情况下,惟一的可能就是代码有问题了。经排查,确实是代码引起的问题。
除了 dev 对变更后的代码最好监控之外,以后对这类的问题应该更加敏感些。

监控网络设备流量

监控网路设备的流量貌似目前只能通过 SNMP 协议实现,在 Nagios 的 exchange 里面找了几个脚本,比如 check_cisco.pl 这个,使用的是 MIB 是 ifInOctets/ifOutOctets,这会导致 32 位溢出的问题,并且该脚本最终的结果是 traffic 的总和,而非当前的速度:
$ ./check_cisco.pl -h 192.168.1.10 -c jaseywang-community -i Gi0/1

另外还有个比较火的脚本叫 chekc_snmp.pl 是通过 snmpget 实现,但是选项的表示方式太二了,其他的做的还不错,不过依然不可以统计速度,只能统计总的流量:-(
$ ./check_snmp.pl -w 9 -c 19 -- -c jaseywang-community 192.168.1.10 -v 2c IF-MIB::ifInOctets.10103

然后就没找到“更好”的了,索性还是自己写吧,先了解了下 SNMP 的一些基础,首先安装客户端:
# apt-get autoremove
# apt-get install snmp

可以使用的版本,1、2c、3,目前主流的应该都支持 2c 这个版本,其 community 就相当于 passwd,最新的网络设备上应该都支持 v3 版本:
$ snmpstatus -v 2c -c jaseywang-community 192.168.1.10
$ snmpstatus -v 1 -c jaseywang-community  192.168.1.10
$ snmpstatus -v 3 -c jaseywang-community  192.168.1.10

Continue reading

基础网络升级(一)

最近又兼职做了好多网络方面的工作。包括某个新机房的网络部署以及某个机房的网络改造升级。
新机房的网络部署没什么好说的,基本是 0 风险,顺便带着实习生熟悉环境。
原有的某个机房最初的网络结构是普通的二层,通过 trunk 级联,并且级联的很奇葩,基本是一个主干拖着若干的枝叶。由于当初上线比较紧急,没有多少时间来做这方面的调研,导致目前该机房的网络存在严重的隐患。
最明显的就是 SPOF 以及单条链路带宽趋向饱和,有的在高峰期维持在 1G,丢包率也随之上升。
花了不少时间调研之后决定将其改造成三层网络,access 以及 Aggregation 通过 ethernet channel 做绑定,三层的通过 StackPower 以及 StackWise Plus 做 Failover。
升级前做了大量的准备工作,借此机会也统一了我们的基础网络设施的规范以及操作。凌晨开始操作,按照先前规划好的顺序一台一台的插拔,保证前一台插拔无误之后再进行下一台的操作,最坏的情况就是将该台设备 rollback。实际操作,两人配合,基本从拔到插到最后网络联通在 10s 之内。整个过程还是比较顺利的,几乎没有出现什么问题,即使出现的,也都在控制范围之内。
最后的效果还是很明显的。升级后的机房的网络利用率高峰基本维持在 50% 左右,新部署的机房由于数据量太大,高峰时段的链路带宽利用率还是超过了 90%,目前比较可行的就是四条链路做绑定或者直接上 10G 的 uplink,不过这两者都需要上 45xx 系列的大块头了,或者是至少 4 台设备做 stackwise。

CDN 简介(四)

这个系列的文章主要参考《CDN 技术详解》,作为大陆第一本介绍 CDN 的,写的确实比较烂,根本就谈不上『详解』,但是『介绍』的性质已经达到了。因此,我会结合这本书以及自己的经验感受,皮毛的总结下 CDN 技术,因为很多具体的原体我也不是很清楚。

第 6 章 流媒体 CDN 系统的组成和关键技术
流媒体相比于静态文件,其对带宽,QOS,网络的稳定延时抖动等都比其他的业务要高得多,另外流媒体还有比较强的热点集中性的特点,当热点事件到来时,服务器的压力会飙升。另外由于需要有组播的需求,除了对服务器的要求相对较高外,对网络设备也有一定的要求。而 IP 组播的问题可以通过 CDN 节点服务器的流复制功能实现应用层的组播代替。
Internet 创建之初就是以传送简单的文本文件为目的的,流媒体显然是违背了这个理念的,因此就需要有相应的协议来解决上面说到的这些问题,具体的有 RTP/RTCP,RTSP,RTMP 等协议。由于 Flash 使用的是 RTMP 协议,因此其应用范围也比价广;另外还有中叫 HTTP Streaming 的技术用的也比较广,一般目前主流的如优酷等都是通过 HTTP Streaming 的技术实现的,通过 HTTP 来传输文件,通过 TCP 来保证可靠性以及流控。
相比于静态的,流媒体的回源比例更低,这个是必须的,一旦回源比例高了,再加上大带宽,高 I/O,最源的压力会非常的大。因此命中率这个指标对于流媒体来说是很重要的,因为未命中的向源查询请求所造成的资源消耗会比 Web Cache 高的多。
另外,大多时候,流媒体采用 PUSH 的方式进行内容分发,也就是源主动给 CDN 预分发,尤其是热点内容,而普通的网页,基本都是 PULL 方式。
流媒体一般是通过 DNS+HTTP 结合的方式进行解析负载,或者直接通过 HTTP,这样能够实现更精确的调度,而普通的更多是 DNS 解析的方式。
流媒体 CDN 要理解的各种流媒体协议比较多,其次是其缓存算法要求也很高。
除此之外,流媒体的 CDN Cache 一般都是大存储,高 I/O,这个跟普通的 Cache 完全不是一个类型,硬件差异很大。这个也是最重要的一点,Web Cache 更多的是小文件,高并发,对 CPU 要求比较高,而流媒体则是对大文件的持续高 I/O,TCP 长连接。
从组网的角度来看,普通的 Cache 通常是中心+边缘的结构。流媒体会多一层,通常是三层架构,中心+区域+边缘的架构,原因很简单,因为流媒体回源的成本很高,尤其对于直播来说,只要直播没结束,源站将持续压力。因此,这种三层的架构对于直播来说会大大的节约带宽,而对于一般的点播来说,则会节约存储。一般区域的会部署在重点的城市,而边缘的则部署在二三线城市,边缘离用户越近,质量越好,但是覆盖的用户的也越少,成本也越高,这个需要综合考虑。
由于流媒体对传统的存储消耗越来越大,因此现在很多厂商都使用文件切片的技术来实现文件的读取,每个 cache 都存储文件的部分切片,其余的从相邻的 cache 中获取,这个跟 P2P 的实习方式类似。切片的另外一个好处是支持自适应码率的业务。

跟静态文件一样,流媒体也面临防盗链的问题。有下面几种方式。
1. 利用 HTTP referer
2. 利用登录信息验证,这个必须要求用户身份进行验证
3. 使用 cookie 携带动态验证信息
4. 使用 POST 下载
5. 使用图形验证码
6. 使用动态密钥
7. 在内容中插入数据
8. 打包下载

其中 2、5 这两个明显不是很适合的。1 比较常用。
Continue reading

CDN 简介(三)

这个系列的文章主要参考《CDN 技术详解》,作为大陆第一本介绍 CDN 的,写的确实比较烂,根本就谈不上『详解』,但是『介绍』的性质已经达到了。因此,我会结合这本书以及自己的经验感受,皮毛的总结下 CDN 技术,因为很多具体的原体我也不是很清楚。

第 4 章 集群服务与负载均衡技术
CDN 内部的一些细节并没有一个标准来统一,所以下面说的这些也只是一家之谈,但是大的方向不会错。

CDN 是典型的负载均衡集群系统。其集群之间的通信可以分为松耦合和紧密耦合两类,其中前者有 ICP、HTCP、Cache Digest、Cache Pre-filling 等;后者以 CARP 为主。其中 CARP 相比松散的耦合有更明显的优势。
对于 LB,要解决的无非是 LB 请求的分发、会话保持、服务健康监测、故障隔离、自动恢复等问题。
分发其采取的算法基本类似,包括静态和动态两大类,静态的意思是按照预先设置好的策略进行分发,而不考虑服务器当前的实际负载状况,比较简单快捷,包括轮询、加权轮询、基于源/目的 IP 的 hash 等;动态的就是能够根据当前服务器状况进行分发,包括最小连接,加权最小连接等。
会话保持可以采取根据源 IP 地址的持续保持、cookie 持续保持等方式。
健康检测的问题,这个大部分都是从 ICMP、TCP、HTTP 层面进行检测。
目前主流的有 L4 和 L7 两种,L7 颗粒更细,但对系统的要求也比较高,因为需要针对 7 层上面的不同的协议做不同的识别分发机制,用的比较多的就是 HTTP 协议,通常使用专门的硬件实现。软件比较流行的有 LVS,Nginx,Haproxy。
Continue reading