中小型系统必要可行的生产运维方案实践思路

为什么需要生产运维方案？

很多中小型系统在产品架构中缺少生产运维的设计，可能公司里的架构设计师认为不重要，或者开发人员不足没精力做，也可能觉得这是项目交付团队的事情，反正就是没有任何的生产运维机制，系统基本在裸奔。一旦出问题，就是看各种日志定位半天，然后写事故报告，生产运维保障方案，挨客户一通骂...，如果有这么一套系统实时监控系统各项运行指标，监控预警，做到有效预防。另外一方面，监控可以发现系统存在的潜在问题，反馈到产品侧进行改进；所以无论系统大小，都应该有一套有效的生产运维保障方案。

如果现有系统确实没有监控运维系统，那就是等到出现问题之后再排查，那如何排查呢？
参考：用“逐步排除”的方法定位Java服务线上“系统性”故障

生运运维主要内容

监控系统各项指标，根据预置规则进行告警，然后进行处理。说具体点干了两件事：
1、就是在出现的问题未酿成大的事故之前提前告警，进行自动化或者人工的干预处理；
2、即使发生了事故，比如宕机、服务雪崩等，也能记录整个过程，便于后期排查改进；

主要监控哪些内容

线上系统，可能产生的三个层面的问题需要监控记录：
（1）机器资源的层面：cpu、内存、网络、磁盘、io，出现了负载过高的问题
（2）JVM进程的层面：jvm内部各个区域的内存使用以及gc频率
（3）代码层面：代码逻辑的内部，抛异常，出现一些不希望发生的系统异常

中小型系统的可行的监控运维系统

1、监控中心

用prometheus+grafana，为什么呢？没有为什么，流行，用的人多。监控
参考：Prometheus+Grafana （史上最全）

2、日志中心

就是原来的日志文件，原来的模式就是挨个查查，如果机器多，服务多，查起来不方便，最好是把这些日志集中起来，方便查询，做成日志中心。市面上有很多，基本都是基于Elasticsearch做的。
参考：ELK日志平台（elasticsearch +logstash+kibana）原理和实操（史上最全）

3、链路跟踪

这个就是辅助定位问题的，不一定需要，如果业务量很大，日志肯定很多，想确定某个用户某次请求的完整日志，有了链路跟踪就很方便。