在当前微服务架构流行情况下，对于初创企业，可能就几个技术（2-20个不等），但是却要开发十多个应用，要维护几十台云机器，甚至可能是混合云的模式。由于业务变化迅速，应用需要采用敏捷开发，针对这十来个应用怎么快速高效无误的部署，出现系统异常能快速给出报警信息，快速定位问题并修复bug后重新部署上线，并且是在不影响线上服务的基础上，这对技术团队提出很高的要求。传统的开发模式和流程里面，这些工作需要开发人员和运维人员一起配合协作才能完成。但是实际上的效果不少特别好，因为开发人员对操作系统优化，监控报警并不熟悉，而运维人员不懂业务逻辑，不懂具体应用开发。所以针对这样的情况，今年devOPS的概念和具体的实践不断被提出来。
行业内各巨头（比如BAT）的自动化运维架构都各种功能各种酷炫，功能复杂，但是开发工作难度和强度也非常大，需要消耗大量的人力和财力。那么小团队就没有实现自己的devOPS了吗？
答案当然是可以实现的。
笔者在一家小团队，有10几个开发人员，管理这几十台服务器和几十个应用，在初期代码的管理、应用的构建、部署发布、监控等都只能都人肉实现，需要不断的到处救火，消耗了大量的开发人员的精力。好在有opensource，我们借助开源的力量慢慢形成了自己的一套devOPS体系，总体效果还不错。
本文就是总结笔者在这方面一些经验和实践，希望对读者有帮助。
对于监控和告警，现在市面上监控系统很多：Zabbix、Open-Falcon、Prometheus，最终选择了Prometheus，因为Prometheus生态强大，功能强大。
Prometheus简介
Prometheus是一套开源的系统监控报警框架。它启发于Google的borgmon监控系统，由工作在SoundCloud的google前员工在年创建，作为社区开源项目进行开发，并于年正式发布。年，Prometheus正式加入CloudNativeComputingFoundation，成为受欢迎度仅次于Kubernetes的项目。
作为新一代的监控框架，Prometheus具有以下特点：
强大的多维度数据模型：
插件多，想要监控什么，基本都会有现成的插件。
易于管理：Prometheusserver是一个单独的二进制文件，可直接在本地工作，不依赖于分布式存储。
高效：平均每个采样点仅占3.5bytes，且一个Prometheusserver可以处理数百万的metrics。
使用pull模式采集时间序列数据，这样不仅有利于本机测试而且可以避免有问题的服务器推送坏的metrics。
可以采用pushgateway的方式把时间序列数据推送至Prometheusserver端。
可以通过服务发现或者静态配置去获取监控的targets。
有多种可视化图形界面。
易于伸缩。
需要指出的是，由于数据采集可能会有丢失，所以Prometheus不适用对采集数据要%准确的情形。但如果用于记录时间序列数据，Prometheus具有很大的查询优势，此外，Prometheus适用于微服务的体系架构。
Prometheus技术架构图.png
Prometheus基本原理
Prometheus的基本原理是通过HTTP协议周期性抓取被监控组件的状态，任意组件只要提供对应的HTTP接口就可以接入监控。不需要任何SDK或者其他的集成过程。这样做非常适合做虚拟化环境监控系统，比如VM、Docker、Kubernetes等。输出被监控组件信息的HTTP接口被叫做exporter。目前互联网公司常用的组件大部分都有exporter可以直接使用，比如Varnish、Haproxy、Nginx、MySQL、Linux系统信息(包括磁盘、内存、CPU、网络等等)。
用Ansible来Prometheus安装
Ansible是一个自动配置管理工具，本文先不介绍了，以后有空再来做下介绍，ansible也是小团队搭建devOPS的利器。使用Ansible作为部署工具的一个好处是太多现成的role了，安装Prometheus时，笔者使用的是现成的：
prometheus-ansble（github.