简介
前几日，笔者产生了想要同时监控几个不同平台数据的念头，一般如果我们需要对某些网站平台的某些参数进行监控时，往往会选择各种各样的方法
这其实是有其原因的，首先互联网技术发展的时间已经有相当的一段时间了，何种新技术和新的架构层出不穷，但是我们与人类的交互接口却基本上没有发生根本性的转变，就是视触接口。这要就会给人一种错觉，就是得到信息是一件十分轻松的事情，但是本质而言，并不是这样的。获取信息其实是一件十分困难的事情，只是我们直接获取信息的接口比较简单，而为了把信息安全，快速的传送到使用者的面前，其实还是挺复杂的一件事情。
扯得有点远了，说回到信息监控这件事情，其实信息监控不是一项技术，而是一种行为或者是一种对于信息有特定需求而产生的监控行为。人不会无缘无故产生信息监控的行为，这里面都会有深层次的原因。因为有了和种各样的原因，数据监控才有了其本质上的意义。
既然要架构一套完整的监控系统，我们就需要从原因说起来，才更具有意义。首先是意义，我们为什么要对数据进行监控？这里其实也可以是又无穷解的一个问题，可以说是很扯淡的一个问题，我们可以换一种问法：是什么让你产生的数据监控的需求？似乎具体了一些，但是依旧不是很好回答，可以改进一点，在生产过程中的哪个阶段会让你产生数据监控的念头和欲望？经过我们几次精简和思路转换，我们终于把数据监控从一个抽象问题，变得可以具体化了一点点，虽然这只是从需求角度的一个方向，但是也往往是最好来思考使用什么架构的最好角度。
首先，我们把数据监控这件事情切割成纵向和横向，纵向值得是生产流中的各个节点的分布，横向则是在该生产流节点中数据监控的必要性。构建一套数据监控系统并不简单，我们必须时刻关注最必要的问题。我们可以通过小提琴图来表述一个生产流程中的数据监控对于问题的影响程度。
我们这里对于数据监控的决策主要使用两个参数，一个是数据监控的可行性，另一个是数据监控的必要性，并且设定了阈值，在流程中阈值达标时，才会做出类似的决策。我们看到，在示例的流程中，我们在测试反馈和改进的流程中，有充足的必要性和可行性进行数据监控，那么，我们就会在用户反馈和改进流程中构造一个监控流程，搜集信息。
有了假设中的场景，基于场景我们需要的就是分析场景中有哪些参数是最需要构建的，有哪些不需要。
参数选择
我们通过必要性和可行性的数据建模，选择了在生产流中的哪个阶段构建设置监控点，然后我们需要考虑的问题就是参数选择和参数组合问题。看下我们假定的监控的流程节点是’Feedback and Improvement’，也就是测试用户反馈搜集和产品提升阶段。首先，定义一下该生产节点所要达到的成果，测试用户反馈和产品提升的主要任务是使测试用户对于测试版产品的满意程度在可控的时间内达到合适的高度。
所以，我们又开始面临几个问题，首先是问题的量化，最直接的是对用户满意程度的计量，那么我们需要搜集的信息可能包括了几个渠道，最直接的是用户对于产品的评级，次一等的是用户对于产品的评价。这里就可以用这两个方面，作为用户满意程度的计量。那么我们按照测试用户对于产品的日平均评级、日平均评级数量、日评论正向指数、日评论反向指数、日评论数量，作为主要的用户满意度的计量参数。
然后是产品提升的计量，这里会根据产品的不同，关注的方面可能不太相同，我们这里从产品的功能模块的使用程度、整体使用时长、用户首次使用时长，作为主要的应用参数。
参数建模
看下我们在手中的参数，有关于用户的满意程度的用户日平均评级、日评级数量、日评论正向指数、日评论反向指数。也有关于产品的功能模块的使用程度、产品整体使用时长、用户首次使用时长。接下来我们就要根据我们的目标，来对于参数进行建模了。首先我们先假定所有参数都已经进行了正则化，那么我们对于用户满意度计量的参数做一个简单的加权平均数就可以了。(我们不会过多关注数学原理的东西，而把精力放在工具的搭建和方案的选择上。)
数据存储
这里其实是面对产品提升过程中的搜集到的数据，首先是对数据库的选择，由于我们的参数大部分都是非关系型数据，这里决定用一个非关系型的数据库组织我的数据。其实在面对这种和时间高度相关的数据时，通常可以使用时间序列数据库(Time Series Database 简称TSDB)。业内相关的解决方案很多，这里笔者采用的InfluxDB，易于搭建。基于Go语言编写，性能在业务开发流程中，尚可接受。
数据可视化
我们搜集完成数据之后还需要考虑数据可视化平台，一般指数监控，自己写一个BI会比较麻烦，常见的解决方案比如Grafana等，都是开箱可用，易于搭建的。
动手构建
因为时虚拟的场景，所以我们要模拟一部分数据的生成，比如这里的评级数据和评级评论信息，都需要使用程序生成和插入到数据节点中。同时我们也学要考虑迭代过程中的数据如何对于数据产生影响，以及如果显出数据的影响。怎么表征这些问题，怎么量化节点的过程
(未完待续 4月底前更新)