NoOps

Ops make no ops | Ops的目标是没有Ops,嗯!

lvs FullNAT顿卡问题原因追查

作者: |   3,071 浏览  | 

问题描述:

在FullNAT在使用过程中,在开启SYNProxy的情况下,采用CURL去连接某个URL,会有偶尔卡顿一下,命令如下:

for i in `seq 1 10000`;do curl -o '/dev/null' -w "%{time_total}:%{time_connect}:%{time_appconnect}:%{time_starttransfer}\n" http://192.168.1.100 >> fullnat.txt ; done
100 582 100 582 0 0 54356 0 --:--:-- --:--:-- --:--:-- 58200
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 582 100 582 0 0 54586 0 --:--:-- --:--:-- --:--:-- 58200
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed

以上命令偶尔会出现6s左右的超时等待。这个事情很神奇,为什么是6s呢,不是其他数字呢,如果是丢包的话,时间为什么这么固定呢,猜测这可能跟程序的实现有关系?

抓包复现:

我们在FullNAT机器和RealServer机器同时抓包。如下图:

image
第一张图是在fullnat机器上抓的,是从client到fullnat的包,第二张图在real server上抓的,是从fullnat到real server的包,从图中可以看出,从xx.xx.116.25到xx.xx.48.24,xx.xx.116.25是client,xx.xx.48.24为fullnat的vip,从第一张图中看出,完成了三次握手以后,client就开始请求数据包,但是请求数据包一直没有回应,在超时以后一直进行重发。难道是请求数据包时丢了?我们从real server上的抓包情况可以得到结果。client从03秒(抓包机器时间设置相差3分钟,单秒数是对的)开始发送数据包,但是real server从09秒时才开始3次握手建立连接。建立连接以后,并且将重发的包又转发了一遍。那么,我们从二张图中得出,导致延迟的原因是fullnat和real server建立连接的过程中,第一个syn包丢了或者没有送出来,才导致了这6秒的延时,那么为什么是6s呢,这得从fullnat代码中查看,经过代码搜索,终于找到了蛛丝马迹。
在ip_vs_proto_tcp.c文件中:

1158 int sysctl_ip_vs_tcp_timeouts[IP_VS_TCP_S_LAST + 1] = {
1159 [IP_VS_TCP_S_NONE] = 2 * HZ,
1160 [IP_VS_TCP_S_ESTABLISHED] = 90 * HZ,
1161 [IP_VS_TCP_S_SYN_SENT] = 3 * HZ,
1162 [IP_VS_TCP_S_SYN_RECV] = 30 * HZ,
1163 [IP_VS_TCP_S_FIN_WAIT] = 3 * HZ,
1164 [IP_VS_TCP_S_TIME_WAIT] = 3 * HZ,
1165 [IP_VS_TCP_S_CLOSE] = 3 * HZ,
1166 [IP_VS_TCP_S_CLOSE_WAIT] = 3 * HZ,
1167 [IP_VS_TCP_S_LAST_ACK] = 3 * HZ,
1168 [IP_VS_TCP_S_LISTEN] = 2 * 60 * HZ,
1169 [IP_VS_TCP_S_SYNACK] = 30 * HZ,
1170 [IP_VS_TCP_S_LAST] = 2 * HZ,
1171 };

1161行中的IP_VS_TCP_S_SYN_SENT代表了当fullnat和real server 的第一syn包发送失败以后超时重传的时间,如果synproxy在第二个三次握手时,第一个syn包发送失败或者被丢弃,重发的时间间隔为3s,这就解释了为什么是超时6s,估计是fullnat发送了3次syn包,但是前两次都丢弃了,或者fullnat前两个根本没有发包。从抓包的结果来看,fullnat确实没有发送前2个包,我们进一步在fullnat中打日志查看。在ip_vs_conn.c文件中,对超时的连接有处理:

881 static void ip_vs_conn_expire(unsigned long data)
...
901 /*
902 * Retransmit syn packet to rs.
903 * We just check syn_skb is not NULL, as syn_skb
904 * is stored only if syn-proxy is enabled.
905 */
906 spin_lock(&cp->lock);
907 if (cp->syn_skb != NULL && atomic_read(&cp->syn_retry_max) > 0) {
908 atomic_dec(&cp->syn_retry_max);
909 if (cp->packet_xmit) {
910 tmp_skb = skb_copy(cp->syn_skb, GFP_ATOMIC);
911 cp->packet_xmit(tmp_skb, cp, pp);
912 }
913 /* statistics */
914 IP_VS_INC_ESTATS(ip_vs_esmib, SYNPROXY_RS_ERROR);
915 spin_unlock(&cp->lock);
916 goto expire_later;
917 }
918 spin_unlock(&cp->lock);

Read More →

小米自动化运维实践 qcon 2014 Beijing

作者: |   5,121 浏览  | 

这里的自动化主指自动化部署,它涵盖的范围很广泛,包括搭环境、修改配置、线上升级、扩容、迁移,以及带来的所有关联变更等等。

部署系统一直作为运维基础设施的核心组件,紧密的将监控、名字服务、配置管理等关联起来。

对于持续集成,配合hudson和本地部署工具,可以串联整个软件生命周期的自动化;对于服务稳定性来说,可以通过资源隔离及增加调度来自动运维服务,提高服务可用性。

这里是pdf版下载:

Read More →

报警助手介绍

作者: |   3,620 浏览  | 

介绍:

报警助手是小米运维部开发的针对运维人员的一款短信报警处理软件。运维人员每天会处理大量短信报警,经常会有漏报警,报警处理不及时,不重要短信频频打扰我们生活的问题。报警助手对报警进行拦截,实行分级别管理,对不同级别报警,采用不同的处理和提醒方式,让你能够高效准确的处理报警,节省更多的时间投入到工作、学习、及家庭中。
Alt text

短信格式:

[P0][PROBLEM][hostname][host_ip][host is down]

各个字段解释
  • 字段1:告警级别,可以是P0, P1, P2 … ,其中P0级别最高
  • 字段2:告警标志,可以是PROBLEM 或者OK,前者标明故障发生,后者标明故障恢复
  • 字段3:机器名,标明是哪台机器发生了告警
  • 字段4:机器IP,同字段3
  • 字段5:告警的具体内容
    Read More →

linux单机监控工具falcon-eye介绍

作者: |   3,242 浏览  | 

它是个啥?

这是我们团队正在写的监控系统的一部分
这是一个用golang写的小工具,没有任何部署依赖
这只是一个采集linux基础数据并做简单展示的agent,不会报警的哦

它可以采集哪些数据?

机器基本数据,比如kernel version,uptime,hostname等等
cpu使用情况:比如idle、user、nice、system、iowait、irq、softirq、steal、guest的当前占比
memory使用情况,used了多少,free是多少,total是多少
当前loadavg是多少
磁盘占用情况,各个分区、设备的使用情况;以及磁盘io的情况,类似iostat的数据,比如await/svctm/%util等等
网络使用情况,比如各个网卡当前带宽情况、每秒丢包多少

它长什么样?

falcon-eye界面

falcon-eye2


Read More →

ansible动手篇-如何书写自己的hosts脚本

作者: |   7,728 浏览  | 

写在前面

         最近Ansible很火,作为一个后起之秀,在github上他的commitor人数已经超过鼻祖puppet两倍多了,相信很多人也尝试过使用这款工具,如果你所管理的环境足够简单(模块没上50个?),足够变化足够慢(半年不用动?),那么也许你并不需要阅读本文,因为简单的静态配置就可以搞定你的需求了,请参考官方文档
         更多的人遇到的是这样的情形:机器和分组信息需要从服务A中动态获取;资产信息需要从服务B中动态获取…诸如此类,但是我们运行时,往往需要以这些信息作为分组依据来管理。这时候,用静态hosts文件来管理就不现实了。幸运的是,ansible支持动态inventory script,不过官方对这部分的描述甚为模糊,甚至连返回的结构体应该是什么样子都没有提,造成很多同学只能望洋兴叹。本文就以我们自己写一个inventory script的过程,给大家分享下inventory 脚本的写法和要求。

ansible来了

作者: |   13,988 浏览  | 

番一、OP酱的自白

     自从入了贵圈,每天需要强大的内心来维护混乱的线上,每天都是用浆糊一样的shell /python在糊墙补窟窿啊,感觉每天都是在和if else打交道啊,每次花牛鼻子劲写的脚本,下次来点新需求,能重用的部分居然少到不想再重用,很绝望啊,有木有?批量运行工具还是在lhck lhcp,每次一长串命令,各种转义各种烦躁啊,有木有?转义也就罢了,还时不时被信任关系之类的bulabula,爷是root?这是啥root啊!

番二、 ansible vs puppet vs saltstack

你一定不会屈服的,实际上很多人已经揭竿而起投笔从戎写出各种IT Automation Management Tool/System(ITAMS),甚至有人还遍尝百草,把经验写成了书(佩服!),我们要搞一个进来也是大势所趋,你真的不想扩容扩到睡着了。
你也一定听过很多ITAMS,那么你看好哪一个呢?所谓萝卜青菜各有所爱,呐,我来放一下我的选择理由:
首先,没有一个工具是能满足大家所有需求的,所以开发是more or less的事了,在选择的时候,我们的标准是:
     1. 可作为批量执行工具
     2. 可支持playbook,模块化
     3. 容易上手,开发扩展容易
     4. 在权限控制方面能很好的与目前的登陆授权管理系统结合
     5. 社区活跃,有问题能查到解决办法
就playbook和模块化来说,puppet,saltstack和ansible半斤八两,就不细比了。
puppet有产品线已经在用,优点是历史悠久,比较成熟,在可远程可本地,功能强劲,不过这厮批量执行功能没得,为了批量执行个命令写个配置文件,好像有点大刀砍蚊子腿的感觉了,而且有客户端在,和授权系统结合比较麻烦。
saltstack和ansible都是python流的,而且就功能上来讲,两者也极为相似,不同之处是salt stack是有客户端的,并且execution模块还用0MQ实现了pub-sub,命令和执行结果因此可以高效并行传输,不过成也萧何败也萧何,第一个sub阶段(将querystring下发到所有机器,然后收集机器响应的阶段)太依赖与客户端返回了,如果客户端未能及时返回或未响应的话,playbook执行阶段可能会直接漏掉这部分机器而没有任何提示,这对于运维来说是不可接受的,要改造这个就得推掉saltstack的现有架构…算了吧。
与前两者比起来,ansible在特性上似乎并不抢眼,配置管理方面(playbook)绝对比不过老大哥puppet,批量执行方面也只是多线程,不像saltstack那么高大上,不过ansible搜索热度高出saltstack三倍多,显然靠的不是吹牛,至少,ansible至少不会悄悄的丢机器,这给了我们一个定心丸,而且仅依赖ssh,与登录授权管理系统天然集成,简单即有效,没有比这更美妙的事情了。
So, 让我们来尝尝Ansible吧!

Read More →

Google Hacking Ⅱ

作者: |   845 浏览  | 

如何快速进行Google Hacking审计呢?

SearchDiggity

介绍:
SearchDiggity 这款工具收集了Google-Hacking-Database的数据,当然这只是其中一部分。
SearchDiggity主要模块包括:
     Google, Bing, LinkFromDomain, CodeSearch, DLP, Flash, Malware, PortScan, SHODAN, BingBinaryMalware, NotInMyBackYard.
安装:
下载地址:   SearchDiggity_v3.1.0.msi
安装需要:     Microsoft .NET Framework v4
安装SearchDiggity 后启动的程序界面
SearchDiggity1
使用:
关于SearchDiggity详细介绍可以参考 Help – Contents, 这里就不在重复了。
注意事项:
Google 搜索每天有限制的,下面2种方法提供参考
1、购买Google API
     使用Google自定义搜索API,将有100次免费查询/天,最多是每天10,000个查询需要付费(5元购买1000次查询)。欲了解更多信息,请参阅部分API的定价。每个查询可以返回一个最多为100个结果查询。
2、使用设置大量代理
     SearchDiggity – options – proxies -add
     另外:如果google hacking关键词用好了,你是可以获取到Google API Key和 HTTP代理的 : )
SHODAN 需要购买 API Key
     去官方购买吧。
更多实例,请浏览下列的文章。
参考:
Google Hacking: The hidden face of Google
WordPress Security for Users
Search Engine Hacking – Manual and Automation
Google Hacking with GGGoogleScan
Hacking SVN, GIT, and MERCURIAL
Attacking the Phishers: An Autopsy on Compromised Phishing Websites
Google-Hacking-Database
Google Hacking Critical Infrastructure

流式日志系统启示录-Xlog-系统集成与组件选型

作者: |   5,996 浏览  | 

  • 背景

    如果你是一名SRE兄弟,收到告警短信,你是否还在疯狂的敲着ssh | grep | sed | awk 这些命令的组合排查问题呢?如果1台,2台,3台机器,ok;如果有n台机器,你会不会抓狂?

    如果你是一名DEV兄弟,开发一套高性能的分布式数据处理平台,你是不是还在考虑数据如何传输,中间件如何配置,资源如何调度的问题,Oops ,你应该将重点放在业务逻辑的开发而不是外围框架的Integration上, 考虑的问题太多了,你会不会抓狂?

很不幸,我是名SRE,我们需要使用一套日志分析工具来帮助我们快速定位问题。

Ops makes No Ops.

  • 系统设计

这是一张组件构建图

logging系统集成设计

我们设想了2条数据流处理方式:

1,实时日志分析系统(Xlog):分为5层,数据采集层,数据持久化层,数据处理层,结果数据持久化层,数据展示层。

2,tracing系统:分为5层,数据采集层,数据持久化层,数据处理层,indexing层,数据检索展示层。

本文将重点介绍下“实时日志分析系统”的构建过程和一些内部实现细节,希望对读者有些帮助。

  • 组件选型

作为一名SRE,Reuse Infrustracture的能力也是一种核心竞争力!

Xlog使用下列组件来构建分布式流式日志处理系统:

  • Fluentd–日志采集处理Agent

fluentd

http://www.fluentd.org/

  • Kafka–消息持久化队列

http://kafka.apache.org/

  • Storm–分布式HPC框架

storm

http://storm.incubator.apache.org/

  • Mongodb–结果缓存

mongodb

http://www.mongodb.org/

  • Xperf–数据展示平台 

Xlog组件选型简单说明

A. Agent选型

说到日志采集,无非三种模式

  1. 通过tail文件的方式采集滚动日志;
  2. 通过listen TCP/UDP端口进行收集;
  3. 通过request HTTP/HTTPS协议提供的URL进行采集;

说到组件选型,目前开源的收集组件

syslog/rsyslog/syslog-ng一般用于收集Linux系统日志,收集应用日志配置复杂且不利于二次开发;

scribe facebook开源的高性能日志收集组件,但是一年多无更新,bug fixing都成问题,c写的,不利于二次开发;

目前最火的三类Agent:logslash,fluentd,flume;分别用jruby,ruby,java实现,我个人觉得flume过于重了,先不考虑,logslash是     jruby实现的,二次开发不太熟悉,所以考虑fluentd

fluentd的优点:

  1. 结构化日志
  2. 支持插件的架构
  3. 消息可靠传输机制

通过使用,个人认为fluentd最方便的2点在于

 a,配置十分便捷

配置一个souce用于日志的输入

配置一个match用于日志的输出

souce/match对的组合十分灵活,可以实现多对多,1对多,多对1的日志收集模式。

b,插件式架构,支持二次开发,满足不同组件系统的集成和私有化定制

比如我们需要开发一个non-buffered的out_plugin,只需要重写下列代码的method

你只需要在

B. 持久化组件

mongodb和kafka就不多说了,mongodb在这里主要利用其“Capped”的特性来缓存storm处理完毕的消息;kafka是目前当之无愧的最高性能分布式消息队列,我们在这里用kafka主要考虑到3点:

  1. 对数据源进行topic分流,实现Category;
  2. 作为一层buffer来适配输入输出的消息速率,解除系统耦合度;
  3. 考虑后期集群数据量规模和可扩展性;

Read More →

multitail 监控多个文件或命令

作者: |   1,506 浏览  | 

之前有同事希望在终端下开多个窗口查看服务状态,后来用xterm解决。
multitail可以很好的实现该功能,示例如下:
multitail --label "baidu.com: " -l 'ping baidu.com' --label "sina.com: " -l 'ping sina.com' --label "taobao.com: " -l "ping taobao.com" --label "sohu.com: " -l "ping sohu.com" --label "syslog: " /var/log/syslog -l "vmstat 1" -sw 100,100 -sn 3,3

-sw 用来设置有多少列,每列的大小
-sn 配合-sw/-s使用,设置每列的窗口数
-C 放在multitail后面,输出颜色

选区_007
进入后,按h帮助,大写O清屏,更多功能大家自己发掘把,比如:只显示差异

安装使用yum或者apt, apt-get install multitail
更多例子:
Read More →

ceph VS glusterfs

作者: |   6,079 浏览  | 

11月初有幸去参加了在香港举行的OpenStack Summit,在体验了祖国特别行政区的繁华同时,也体验了ceph如火如荼的势头。ceph提出的统一存储(united storage:file system、block storage、object storage)开始被大家广泛认可。而glusterfs同样也是一款很出色的分布式文件系统,很多公司在生产环境中已经应用了glusterfs。

最近正在对本篇文章主要带大家简单熟悉下ceph和gluster的部署并使用fio对两款文件系统性能进行测试。

Read More →