20 如何才能实施实时手机屏幕远程监控数据传输但是既然你提到设计了，那请继续往下看。
中小型的监控系统无非如下三样东西：1.数据库2.展示界面3.监控agent
那么很简单了：
1.数据库
数据库用opentsdb，或者influxdb，一般选用时序数据库，按照时间戳（timestamp）对一个维度（measurement）进行监控，并且每个机器有自己的标签（tag），标签可以有多个，监控数值（value），后续可以针对维度（measurement）进行分类，针对标签(tag)进行聚合。时序数据库唯一的缺点是，只能存数值。但是监控，只需要知道数值。
2.展示界面
chronograf（不建议用，虽然偶用）grafana（都在用）
对，界面和数据库一样，同样不建议自研。
3.监控agent，嫌麻烦就用telegraf或者collectd
agent原理说起来很简单，一个死循环，X秒执行一次操作。
举系统日志监控项CPU的例子：
取出cpu当前用量（例如44%），打上维度标签（measurement=cpu），打上tag标签（hostname=a, group=aGroup, ip=10.1.1.1），打上时间戳 timestamp，记录数值（value=0.44）取前内存用量……
取磁盘用量……都取出来之后，扔进数据库。
作为用户，配置一下grafana即可
参考文章：利用Metrics+influxdb+grafana构建监控平台
使用 Grafana＋collectd＋InfluxDB 打造现代监控系统
本文结束。
关于更进一步和报警系统
如果你司只收集系统日志的话，下面的就不需要读了。
当然如果你司要收集业务监控的话，那么相信到这一步你司一定有个小小的监控系统项目了。
下面说一点偶这里曾经遇到的事情/需求。
4.实时性：如果不愿意把数据库直接暴露给agent，可以做一层proxy，由proxy进行数据验证和身份验证然后存入数据库。对，proxy这里可以做很多事情，例如cpu>80%就报警。
5.持久化说白了，存储问题。监控数据量非常大，一般三个月的数据量就很让人头大。后续要存多久的日志，怎么存，都是个问题。有时候时序数据库无法满足问题，可以考虑换成分布式存储了。是否需要缓存，最近多久的的日志放到缓存里，用什么更新策略。
6.报警虽然上面提到了，这里还是得专门拉出来。报警不一定必须要在proxy层做掉，因为处理速度可能跟不上。例如有些要求连续三分钟怎么样就持续报警。有些要求报警短信先快后慢，避免撑爆手机。
有时候你想知道某些报警是否已解除，便需要一个控制台来查询。
7.接口有些应用偶想临时不报警，有写偶想拿出监控数据进行计算，有些偶想自己传给你数据，用你的界面和数据库……
8.自定义监控说起来也不难，支持agent运行自定义脚本进行监控，支持各种传入参数监控，支持这个支持那个，总归一个自定义二字。
9.暂时想不起来了。你先搞定前三点吧。1，2有现成的，配置一下就能用，3一般自研，做起来很简单，现成的也能用，偶也给出了参考文档，代码都不用写就能跑起来。
并且，telegraf+influxdb+grafana一下午就能搞出来一套监控系统。4，5，6，7，8酌情。
10.其他可能遇到的问题
例如数据库达到上万台之后，opentsdb也撑不住，这个时候你可能需要考虑其他数据库。
恩，偶这里用kafka，也在调研scylladb。
对了，以上内容看起来很简单，做起来很难。
另：influxdata有一系列的监控解决方案，可以参考他们的架构设计。
本文完结。
prometheus最近的势头很猛，也可以关注下。
不过原理上prometheus依靠的不是agent上报，而是服务端（通过http协议）到被监控机器抓取监控信息，例如监控mysql需要一个mysqld_exporter的agent来提供导出，同样需要agent来提供http接口。这种做法和传统的agent上报模式各有优劣，请自行选择方案。
苹果6怎么关闭屏幕密码，教师如何注意网络安全问题，怎么让iframe在最上层