• 网站首页
• 网站建设
• 短视频
• 网站推广
• 网站模板
• 客户案例
• 资讯动态
• 关于我们

20?如何才能实施实时手机屏幕远程监控数据传输_数据库

当前位置：网站建设 > 技术支持

只收集系统日志的话，zabbix，nagios都行，本文完结。

但是既然你提到设计了，那请继续往下看。

中小型的监控系统无非如下三样东西：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上报模式各有优劣，请自行选择方案。

版权说明：
本网站凡注明“广州京杭 原创”的皆为本站原创文章，如需转载请注明出处！
本网转载皆注明出处，遵循行业规范，如发现作品内容版权或其它问题的，请与我们联系处理！
欢迎扫描右侧微信二维码与我们联系。