【转自Reboot运维开发博客】写在前面 本人从事运维自动化相关工作8年。刚开始做的时候，devops这个词还没有流行起来，知道的人也很少。国内对运维的理解，就是机房，服务器，7*24小时值班，吃苦耐劳。当时甚至还流传着这样一种说法，运维达人高大威猛，可以搞定服务器。 有幸领导了两家一线互联网公司的公司级运维自动化。两家公司都有几十万台服务器和几十个IDC。很多东西都是摸索出来的。一路走来，对运维自动化也形成了一些认识。当第一家公司这么好做的时候，发现第二家公司实施的时候很多原来的认识都被打破了。但这次经历，却凝聚了一些经验。由于我的个性，我不喜欢在外面说话。偶尔实在反驳不过去，提心吊胆准备，可是找了一大堆干货还是一句话也总结不出来。***留在外面的都是寥寥数语，不成体系，更谈不上能指导多少。 终于下定决心，通过一系列的文章来写一些个人的理解。文风有限，写的不一定尽如人意。也欢迎大家加入运维开发讨论交流群交流，群号：365534424 ，废话少说，直接发帖。 炮顶杰监控（一） 我一直认为监控之于运维就像眼睛之于人一样重要。再高大上，运维工作很大一部分还是响应式的工作。来自架构调整、服务更改或来自监控。毫不夸张地说，监控是整个运维或服务生命周期中最重要的一环。事前发现、预警或故障报警，并提供监测现场供事后追溯。监控系统贯穿运维全链路。如何拥有一双好视力，今天我们就来聊一聊。 因为监控系统如此重要和用途广泛，所以行业中最成熟和众多的产品也是监控系统。商业、开源监控系统比比皆是。还有一些优秀的开源系统被广泛使用。如Zabbix、cacti、nagios、ganglia等。至于使用开源系统，还是要用户自己开发（相信看到这篇文章的人应该没有购买监控系统的打算）.当业务规模和团队不够用时，可以直接作为开源系统使用，可以解决基本问题，性价比高。如果后期业务发展良好，规模迅速扩大，复杂度迅速增加，开源系统将难以为继。具体表现在时效性、可扩展性、二次开发、支持的服务规模（或系统容量）、良好的权限控制等方面。 从以上几点来看，一个监控系统需要具备数据采集、可扩展性、告警管理、高可用性、历史数据存储与展示、权限管理等几个方面。 监控本质上就是判断被监控对象的状态。这个监控对象可以是一台服务器，也可以是一台交换机，也可以是几千台服务器组成的集群。也可以是带宽、CPU利用率，甚至可以深入到服务中去监控服务内的进程、线程、缓存利用率。 监控对象多种多样，有物理的，也有虚拟的。判断被监控对象的状态，这句话有3个要素。监控对象、状态、判断。因此，监控系统必须能够适应足够多类型的监控对象，将它们采集并转化为可测量的状态值，以支持下一步的决策动作。比如一台服务器上nginx服务的连接数。服务器上的nginx服务是被监控的对象；连接数是监控对象的指标，那么状态呢？如果超过10000我们就可以定义为异常，否则就是正常的。 从这个角度来看监控系统的核心指标。首先，可以监控的对象范围尽可能大（当然，你可以说小而精就是美。但是维护多套监控系统也是有成本的）。就是说，数据收集，收集的渠道越多，支持的方式越多，收集的指标越多越好。 可扩展性的定义 可扩展性（scalability）是对软件系统的计算和处理能力的设计指标。高可扩展性代表了一种弹性。在系统扩展和增长的过程中，软件可以保证强大的生命力，通过少量的改动甚至只是增加硬件设备，就可以实现整个系统处理能力的线性增长，高吞吐量和低延迟高可以实现性能。 可伸缩性和纯性能调优有本质区别。可扩展性是对高性能、低成本、可维护性等诸多因素的综合考虑和平衡。系统的横向扩展，通过廉价的服务器实现分布式计算；而一般的性能优化只是单机的性能指标优化。它们的共同点是根据应用系统的特点在吞吐量和延迟之间进行选择。当然，分区的横向扩展会带来CAP定理约束。 可扩展性和过度设计的矛盾 专门讨论了监控系统的可扩展性。这里我们特指在不对架构做较大改动的情况下，系统可以随着监控对象的规模进行扩展。当有1000台服务器时，这是架构。当有10,000台服务器时，这是架构。听起来不错！这是每个系统架构师的梦想。可当现实照进理想，才发现理想是残酷的。首先，对于一个设计师来说，当他在一个只有几百台服务器的公司时，很难想象他的系统有朝一日会跑上几万台服务器的规模。架构设计还有一个原则，就是尽量避免过度设计。如果一个有几百台服务器规模的公司的运维开发告诉他的老板，一个系统可以支持几万台服务器，但是要花多少时间在架构和重构上，我想老板会认为，运维开发一定是疯了。架构原则之一也是尽量避免过度工程化。 但是软件设计还是提倡好的架构，好的扩展性。否则，架构设计的价值将大打折扣，代码复用和系统实现的成本会随着规模的扩大而线性增加。通过迭代可以得到好的架构，进而指导底层系统设计。但是低阶不能预测高阶。这是建筑的好处之一。所以这里我会在后面介绍我在监控系统架构方面的一些经验和思考。 一个称职的设计者站在几百台服务器的规模上，是可以考虑到几千台服务器的情况的。但他考虑几万个单位，就有点过分了。这并不是说能支持上万台的系统架构不优秀。只是，如果他不知道，也没必要想太多。如果能提前知道，甄嬛说，那自然是极好的。 但是显然要考虑的事情会越来越多。当有几十台时，可能只需要考虑一间机房。上百台时，有2、3个机房。几千台的时候，可能还在10个IDC以内，但是几万台的时候，就很难了，可能已经超过15个IDC了。而且地域分布会更广，运营商的覆盖面、网络的复杂度、服务的复杂度都会完全不同。强行让一个运维开发完全靠想象去做是不现实的。他没有经历过这种实际的需求场景，所以没有办法去考虑这类的各种问题。所以我非常理解一些大公司对开源项目的态度。更好的可能会被改用，更进一步，可能会单独拉一个分支开始修改，更糟糕的是，修改的和主干完全不一样。其实也有自制轮子的。但有时情况就是如此。如果自己不造轮子，开源的轮子真的不好用。 监控的可扩展性 具体到监控系统，可扩展性有哪些方面？让我们从头开始。监控系统的输入是监控数据。经过一系列的处理，这些数据最终被存储起来用于事后分析和离线分析，更重要的功能是提供实时告警。我们可以把整个过程看成一个流计算过程。说到流计算，大家都会想到Storm。这是我想到的另一个想法，就是把所有的处理过程都放在strom上。balabalabala....太远了。但是仔细一看，不管是strom还是流计算平台，都是分布式的。分布式架构的一个特点是良好的可扩展性。随着服务器规模的扩大，对中间数据处理层的可扩展性要求是计算能力必须是可扩展的。简单来说就是数据量很大，可以通过增加服务器或者升级服务器来完成。 还有一些边界区域需要很好地支持可扩展性。首先是入口。或者称为数据接收端口。外部数据源源不断的进来，想要实现良好的扩展性，首先要考虑的就是接收环节。数据可以通过TCP、UDP、SNMP、HTTP等协议进入监控系统。考虑到几万台服务器的规模，这个地方很考验技术基础。使用SNMP和HTTP当然是可以的，但是这两个协议都在应用层，必然会带来额外的开销。以HTTP为例，我们使用Nginx或者Apache作为服务器，天然具有可扩展性。接收到数据后，可以将其存储在存储中（无论存储是缓存还是私有存储）。这个过程没有状态，所以它自然是可扩展的。一个Nginx实例撑不住了，另一个，另一个，十个。这解决了接口的可扩展性问题。 另一个可扩展性是存储链接。这个存储主要是监控数据的持久化存储。前面我们说过，数据接收和计算链路在某些方面可以支持扩展性。存储将不可避免地成为瓶颈。许多系统都是这种情况。前端可以通过WebServer进行扩展，但是最后大家跑到一个数据库去读写。即使脱离了读写，它仍然是一个主库。主库的压力是巨大的。 在这个地方，我推荐使用一些分布式存储来解决这个问题。但是不太推荐芒果这种比较奇葩的。因为写作能力不是很好。虽然后来有一些改进来缓解这个问题，但请注意，这只是一种缓解。 总结一下，对于可扩展性，我们的思路是：分布式，无状态。（待续）
