专家坐堂：网站运维技术与实践（获奖名单已公布-2014-5-28）

持续更新

回复 40# 小飞侠xl
logstash 还在测试，自己也不是很懂。

nagios主动检测的报警平率看需求吧，一般3-5分钟吧。

nagios可以设置成只会在监控项目状态改变的时候触发报警事件。（具体看你怎么设置）
比如在报警触发的时候发一封邮件，监控项恢复正常后再发一封邮件。


   

小飞侠xl

了解了，多谢回复 41# 持续更新


   

zhangxuan3210

1.运维工作中肯定少不了监控。那么在选择和部署监控系统时，你是更注重报警和趋势规划还是报表和数据可视化呢？
这两者是日常运维工作上的不同事情:
报警主要关注服务当前状态，保证服务能高可用运行，实时性较高，报警本身不难，难在报警后需要知道怎么处理，这个需要在部署监控系统时更有效和方便的进行监控，帮助运维人员感知问题和解决问题。
报表和数据可视化主要关注服务间的关联和发展趋势，实时性不高，可离线计算，能帮助leader或工程师预测未来的服务趋势，以便进行扩容或架构升级，同时也帮助工程师挖掘相关服务上的关联性和数据价值，为服务进行创新。
据个人理解，在选择和部署监控系统时，主要是关注报警和解决报警，报表和数据可视化可通过离线计算平台等实现。

2.日志处理是网站运维最重要的工作之一。你偏向自己写脚本处理还是利用现成的框架？
基本使用现成框架，如storm,elasticsearch等，一般现成框架比较通用，使用成本低，且经过证明是可行性高(不然别人也不会用)，可用性高，可形成一个平台型产品，自己写脚本处理不够通用，性能较低，且可用性低，如有问题，可能经常需要重构等，运维成本高。如果有些特殊需求可优先升级框架来满足需求，如实在不行可通过脚本处理，但尽量和框架结合。

3.欢迎大家就网站运维技术各方面问题向 饶琛琳 ID:chenryn 提问。
在运维中常常遇到如下问题，还请chenryn 进行解答:
1.机器自动化管理方面:如服务扩容时，往往多个运维工程师运维同一批机器，如何知道该服务部署到哪些机器，机器故障时，如何自动恢复，提高机器利用率。
2.网站安全方面:如何有效的保护自己运维网站的安全，不受外界恶意攻击，或者受到攻击后的迅速处理。
3.网站可用性方面:在面对系统服务复杂时，当系统出现异常时，如何做到服务自动降级，保证网站服务的高可用性。

4.说说读完试读章节后您的感想。
看完试读章节，感觉还是收益匪浅，之前搞过logstash，主要是异常日志收集展示(logstash->redis->logstash->elasticsearch->kibana),但对日志平台认识比较局限，读后学到其他很多开阔的思路，呵呵。
看完本书目录，对其中的产品访问监测，日志分析与报警，弹性控制和部署章节很期待，希望能学到一下好的运维思想和方法，很期待本书。

uxyzp

现成的框架？

这个有人介绍下吗……

yunas

支持好书，支持好话题，点赞。


1.运维工作中肯定少不了监控。那么在选择和部署监控系统时，你是更注重报警和趋势规划还是报表和数据可视化呢？
关于监控方面。更注重即时报警和趋势比较图。这两种比较结合起来比较容易、快速、精准定位问题。
监控软件以cacti+nagois为主，以及zabbix做辅助。其他的例如Smokeping功能还是在ping的监控上，也是它设计的初衷吧。
Zenoss优点是集网络与系统管理软件；Ganglia优点是集群监视项目，体现的是集群节点的监控状态。
上面这些软件的共同特点都是“开源”。只是各应用的监控环境，场景不同，各适用不同场景。都是为了“监控而生”哈哈。
Cacti+Nagios结合使用，是目前的主流。相互结合，互换补充，目前是个非常不错的部署方案。
Cacti的界面非常漂亮。Cacti其实是一套php程序，它运用snmpget采集数据，使用rrdtool绘图，无需明白rrdtool的参数能轻易的绘出漂亮的图形。
Nagios是一款用于系统和网络监控的应用程序并遵循GPL协定。它可以在你设定的条件下对主机和服务进行监控，在状态变差和变好的时候给出告警信息。
Cacti走势图的绘制是它的优点，又是它主要强大功能。Nagios是对服务进行监控和报警，这个是它的优势和功能特点。两者结合是强强组合。
丰富的第三方插件都是两者最大的优点，nagios调用飞信接口估计是最多人用的。因为他免费，又及时。Nagios结合PnP应用更加方便。

cacti在监控方面有良好的绘图，cacti在流量和图型塑造上要强于nagios，但是在故障分析上有些略逊，而且报警机制也有待完善，这时nagios就派上用场了。
nagios ：适合监视大量服务器上面的大批服务是否正常, 重点并不在图形化的监控, 其集成的很多功能例如报警,都是 cacti没有或者很弱的。但在绘图以及图型塑造方面精细度比cacti要弱。

因此在网站的监控方面，即时报警和趋势比较图很重要。也是排查问题的重要方法和云雾监控技巧。

2.日志处理是网站运维最重要的工作之一。你偏向自己写脚本处理还是利用现成的框架？

日志处理的处理方法目前都是使用shell脚本，根据实际的需求写shell脚本完成批量操作。
同时网站运维最重要的工作也是重要的方法是自己写脚本处理。
如果是现成的分析工具，通常都是辅助工具。
利用现成的框架，这种框架目前互联网上很少，大多数都是开源软件，然后这些软件通常难以通用。因为实际使用中，日志格式都是自定义的，然后开源分析软件并不统一。
这就产生复用率的问题。因此开源的软件、利用现成的框架复用性比较差。

网站运维中，分析网站状况非常重要的方法其中就是：分析日志
关于Linux平台下的运维人员，还是推荐Shell加Perl的组合，毕竟那么多年过来了。这个组合一直在为各大网站的工程师们稳定的工作着。另外，Python也是一个非常值得推荐利器。这种语言具有非常简捷而清晰的语法特点，适合完成各种高层任务，几乎可以在所有的操作系统中运行。目前，基于这种语言的相关技术正在飞速的发展，用户数量急剧扩大，相关的资源非常多。
说以，网站运往必须都是需要使用shell脚本，根据实际的需求写shell脚本完成批量操作。

3.欢迎大家就网站运维技术各方面问题向 饶琛琳 ID:chenryn 提问。
无。

4.说说读完试读章节后您的感想。
看了目录和试读章节，网站访问监测、日志分析与报警、部署方案部分不错。运维思想和运维方法，是一本很好的参考书。
现在运维方面的书籍越来越多，内容丰富很多了。值得读者好好学习运维中的实践解决方法。很多参考资料和工具软件、开源软件、解决案例是运维最实用的。很多解决方案，技术难点进行分析和解说。
软件的安装是最基础的，这方面的书籍目前很多，对初学者比较有参考用。安装中常见的问题、常遇到的问题，或者解决方法，是运维工作中最常遇到，也是比较实用的。
这是属于运维的基础，扎实的韵味基础非常重要。

expert1

回复 30# reyleon


    都是搬砖民工级别，此外游戏比网站有钱一些，互联网行业就游戏利润率最高了。

chenryn

回复 36# 持续更新


    只要没影响到业务，为什么要限定呢。

    这个事情就好像cgroup的设计，当资源本来就富余的时候，设定的限制其实是不起作用的，只有当别人也要资源的时候，才会调控cgroup内资源。

    如果不方便用cgroup的，那让一个核出来用taskset也行。不过你能说说具体场景么？nagios监控脚本都是短时间运行，为什么会占用cpu和mem到你不可接受的地步。

chenryn

回复 40# 小飞侠xl


    报警频率是多级的啊，每次之间间隔慢慢拉长。然后如果是发短信，在短信猫的数据库前面我们还做了归并抑制。

    logstash我常用的就是input/file input/stdin input/redis filter/grok filter/date filter/mutate filter/date filter/ruby filter/metrics output/email output/ealsticsearch_http output/stdout output/redis

chenryn

回复 43# zhangxuan3210


1.机器自动化管理方面:如服务扩容时，往往多个运维工程师运维同一批机器，如何知道该服务部署到哪些机器，机器故障时，如何自动恢复，提高机器利用率。

不知道服务到哪些服务器上这个是不可接受的啊，扩容一定是应该有完整方案的。从技术上说，像puppet这类部署系统，后端肯定是要有cmdb关联的，虽然关联方式可能是通过cmdb导出生成pp文本，可能是通过enc直接读取，但是fqdn和classes的对应关系肯定是要是唯一且清晰的。运维可以不清楚服务在哪些机器了，但是他知道只要上某个系统他就一定可以获取到跟别人一样的这个信息，这就行。
自动恢复方面，我觉得比较好做的还是服务进程方面的故障。如果是主机故障，又没有虚拟化的自动迁移，那么恢复时间很多时候就只能很漫长的等待硬件检测、进机房更换等等，这些就不可控了。这个时间只能是说有个内部tracker系统，发邮件通知的方式跟踪流程，别下线维修就彻底忘了这事儿了。

2.网站安全方面:如何有效的保护自己运维网站的安全，不受外界恶意攻击，或者受到攻击后的迅速处理。

之前说过我在这方面不是很有经验，我看隔壁安全团队的情况，功夫在戏外吧。

3.网站可用性方面:在面对系统服务复杂时，当系统出现异常时，如何做到服务自动降级，保证网站服务的高可用性。

我理解中服务降级更多的是业务开发问题而不是运维问题。目前来想运维领域可能比较接近的就是如何防止集群的雪崩效应吧？这个在一致性哈希基础上做一些折中(不清楚现在tengine里一致性哈希的实现是怎么样的，我司的版本就有这方面的取舍)，或者配合实时分析(或者提前能知道做活动的提前准备)，给高流量的请求转移到单独的集群上。

小飞侠xl

报警频率多级的设置一般的监控都没有吧？回复 48# chenryn