微服务架构下，我们将服务拆分，所以用户的每一个请求不再由某个服务独立完成，而是变成了一个多种服务的组合。这样的话，一旦请求出现异常，我们就必须知道是哪个服务环节出了问题，需要对每一个服务、每一个指标进行全面的监控。1.什么是“监控系统”？在微服务架构中，监控系统按照其原理和功能大致可以分为三类（不严格分类，仅从日常使用的角度）：日志类（Log）；调用链类（Tracing）；指标。下面介绍三种常见的监控模式。1.日志日志是比较常见的。我们的框架代码、系统环境、业务逻辑一般都会产生一些日志。我们通常会记录和收集这些日志，以方便需要时查询。日志类中记录的信息一般是一些事件和一些非结构化的文本内容。日志输出和处理的方案有很多。知名的ELKStack解决方案（Elasticseach+Logstash+Kibana），如图：在每台服务器上安装Beats（可选）后，作为日志客户端收集器。然后使用Logstash进行统一的日志收集、解析、过滤等，然后将数据发送到Elasticsearch进行存储和分析，最后使用Kibana来展示数据。当然，你也可以升级解决方案：这些解决方案都比较成熟，构建起来也比较简单。除了作为监控系统，它们还可以作为日志查询系统，非常适合分析和问题调试。2.调用链类（Tracing）调用链类监控主要是指记录一次请求的全过程。一个请求从头进入，调用微服务中的不同服务节点，然后返回给客户端。在此过程中，通过调用链参数来跟踪全链接行为。这样可以很方便的知道请求哪里失败了，系统的瓶颈在哪里。这种监控一般是使用CAT工具来完成的，一般在大中型项目中都会用到，因为构建它们是有一定的成本的。后面会有单独的文章来讲解这个调用链监控系统。这也是一种简单的容错方式。意思是在服务之间调用的时候，设置一个活跃的超时时间。超过这个时间阈值后，如果“依赖服务”还没有返回数据，“调用者”就会主动放弃，避免“依赖服务”受到故障影响。3.MetricsMetrics主要使用时序数据库解决方案，是从事件发生时间和当前值的角度记录的监控信息，可以聚合起来，用来查看一些指标数据和指标趋势。所以这种监控主要不是用来查问题的，主要是看Metrics一般有5种基本度量类型：Gauges（测量）；Counters（计数器）；Histograms（直方图）；Meters（TPS计算器）；Timers（定时器）。alarming，所以现在比较流行这种方案，如果我们要搭建新的监控系统，我也推荐参考这种方案，所以本文会重点介绍时间序列的监控系统以数据库为主角来形容吧。2、“监测体系”关注的对象和指标有哪些？一般我们在做一个“监控系统”的时候，都需要进行分层监控，也就是说，我们要监控的对象是分层的，一般分为：系统层：系统层主要指的是监控在CPU、磁盘、内存、网络等服务器层面，这些一般是运维同学比较关注的对象；应用层：应用层是指从服务的角度进行监控，比如接口、框架、某个服务的健康状态等，一般是服务开发者或者框架开发者关注的对象；用户层：这一层主要是用户和业务相关的监控，属于功能层，大部分是项目经理或者产品经理会比较关注的对象。了解了监控的层次之后，我们再来看一下通用的监控指标：延迟时间：主要是指响应一个请求所消耗的延迟。例如某个接口的HTTP请求平均响应时间为100ms；请求量：指系统的容量和吞吐量，比如以每秒处理的请求数（QPS）为指标；错误率：主要用来监控错误的比例，比如一段时间内某个接口调用失败的比例作为指标。3、基于时序数据库的“监控系统”有哪些？下面介绍目前业界比较流行的几种基于时序数据库的开源监控方案。1、PrometheusPrometheus是2012年开源的监控框架，其本质是前Google员工开发的时序数据库。Promethes采用拉取方式（Pull）从应用中拉取数据，同时也支持Alert模块实现监控预警。它的性能非常强，单机可以消费上百万的时间序列。架构如下：从图片左下角可以看到，Prometheus在应用中埋点后可以拉取到PrometheusServer。如果应用不支持埋点，也可以使用exporter方式进行数据采集。从图的左上角可以看出，对于一些定时任务模块，由于是周期性运行的，所以无法拉取到数据。那么Prometheus也提供了一种推送数据的方式，但是并不是推送到PrometheusServer，而是在中间搭建了一个Pushgateway。定时任务模块将metrics信息推送到Pushgateway，然后PrometheusServer仍然使用pull方式从Pushgateway获取数据。需要拉取的数据可以在PrometheusServer中静态配置，也可以通过服务发现（即图中上中部的Servicediscovery）。PromQL：是Prometheus自带的查询语法。通过编写PromQL语句，您可以查询Prometheus中的数据。Alertmanager：数据预警模块，支持多种预警方式。WebUI：用于展示数据和图形，但一般大多与Grafana结合，使用Grafana展示。2、OpenTSDBOpenTSDB是2010年开源的分布式时序数据库，当然主要用于监控解决方案。OpenTSDB使用了HBase的分布式存储。其获取数据的方式与Prometheus不同，采用的是推送方式（Push）。在展示层，OpenTSDB自带WebUI视图，也可以和Grafana很好的结合，提供丰富的展示界面。但是OpenTSDB没有自带预警模块，需要自行开发或者结合第三方组件使用。可以通过下图了解OpenTSDB的架构：3.InfluxDBInfluxDB是2013年开源的时序数据库，这里主要用于监控系统方案。它还以推送方式（Push）收集数据。在表现层，InfluxDB也自带WebUI，也可以和Grafana集成。以上是我对微服务架构中“监控系统”的一些思考。
