概述

为什么需要监控

在编写应用程序的时候，通常会记录日志以便事后分析，在很多情况下是产生了问题之后，再去查看日志，是一种事后的静态分析。在很多时候，我们可能需要了解整个系统在当前，或者某一时刻运行的情况，比如当前系统中对外提供了多少次服务，这些服务的响应时间是多少，随时间变化的情况是什么样的，系统出错的频率是多少。这些动态的准实时信息对于监控整个系统的运行健康状况来说很重要。

由于业务系统数量大，每天都会产生大量的系统日志和业务日志，单流式业务的一台服务器产生的日志达400M 想直接查看内容打开可能几分钟，而且内容之多根本无法查看，给开发和运维带来诸多不便，现业务都是分布式的，日志也是分布在每台服务器上，所以查看日志和统计更是效率低下。实时收集分布在不同节点或机器上的日志，供离线或在线查阅及分析来提升工作效率的需求异常迫切，

这些动态的准实时信息对于监控整个系统的运行健康状况来说很重要。

Profiling特别重要。如果能有一个特别强大的Profiling系统，就知道整个系统在哪个地方，哪台机器上，花了多少CPU、内存、磁盘IO或者网络带宽等资源，才能知道优化什么地方效益最大。

监控需要的信息从哪里获得？

这些信息需要数据作为基础直接获得或者计算获得，那么实时数据怎么去获取，什么标准来作为测量标准。也就是信息采集的时候，怎么去获得。如下面这些实时数据如何获得

响应时间：用户发送一个请求到用户接受服务器返回响应的这段时间就是响应时间
吞吐量：单位时间内系统处理的客户端请求数量
并发用户数量：某一个时刻同事向系统提交请求的用户数
TPS：每秒事务数
PV: 访问一个URL，产生一个PV
UV: 用户访问站点的所有页面算一个UV

整套方案需要使用到的技术

metrics: 项目代码中监控信息采集使用, 支持gc、mem 等信息收集
statsd: 使用statsd进行udp数据的传输，
telegraf: 项目外部数据收集使用telegraf
influxdb: 使用该时序数据进行数据存储
grafana: 进行数据展示

因为以前没有涉及过监控相关的技术，所以在做的时候碰到各种问题,这里记录一下这个过程踩过的坑。

当时做的时候，我的主要是想使用metrics 提供的度量作为数据采集的标准，然后将数据写入influxdb里面，然后grafana进行展现就好了，但是git上使用的这个metrics 只提供TCP 连接influxdb的方式。所以满足不了我的需要。

TCP 因为要握手所以对性能有影响，想使用UDP 作为传输方式，然后找到 statsd 是支持TCP/UDP 方式进行传输的，但是 statsd 支持支持的类型很少，并不能完全满足采集到的metrics 支持的这些度量标准。所以需要将metrics 采集以后复杂的类型转换成 statsd 基础类型进行传输。

原有系统有用telegraf 支持docker外部的信息采集，并且可以添加statsd插件，这样既可以采集到代码之外的性能指标的，也可以方便的将statsd 传输数据存入influxdb中，然后再用grafana 作为展示面板，将数据展现出来，就完成了整套方案。