OneAPM 在 8月 20 日推出了，数据管理平台 Cloud Insight。支持 Ubuntu、Fedora、CentOS 和 RedHat 4 种主机监控，以及数十种如 MongoDB、Nginx 等平台服务监控。

在上一次，我们针对 Cloud Insight 未来要实现的数据可视化，和多平台监控服务接入的功能，进行了介绍。那么，今天要为大家介绍 Cloud Insight 的事件流机制，以及团队成员如何基于事件流进行协作、沟通。

事件流

传统意义上，大家对于监控软件或者说数据管理软件的事件流机制，可能会理解为：就是报警功能。

当 CPU 利用率过高，或者第三方 API 的可用性达到某个触底阈值，则会触发报警条件，产生报警，并且通过邮件、短信等多种渠道，流转到具体的承责人员身上。

但是这样会不会太单调了呢？一个报警事件在人员身上一个一个地流转，有没有可能将事件流引入新浪微博或者说 Instagram 的社交机制呢？

这就是 Cloud Insight 想重新定义的事情。

Cloud Insight 引入各种服务的报警事件，如对接 OneAPM Application Insight 服务后，引入 Ai 的报警事件；Cloud Insight 也可以针对自身的主机监控和平台服务监控，管理报警事件。

除开这些，在使用 Cloud Insight 时，不同角色、不同职位监控不同的仪表盘，如：运维人员关注具体的底层指标，管理人员关注与业务高度相关的数据，如每秒产生的订单数。那么，围绕着 Cloud Insight 仪表盘中具体指标的协作、沟通和社交，也归纳在 Cloud Insight 的事件流中。

再或者，如果一个运维团队维护着 100 台主机，那么将会涉及上千张仪表盘，一个人肯定管理不过来；团队内的协作，也是 Cloud Insight 想解决和优化的问题。

协作

说一个具体的案例吧，一个关注数据库并不是本职工作的运维工程师（本职可能是管理着中间件），他可以在界面中与管理数据的运维人员进行沟通。

术业有专攻，中间件的高负载，可能由于是数据库问题所造成的，那么将问题流转给专职人员，并进行全面、顺畅的沟通，就可以促使整个公司达到更高的效率。

关联

Cloud Insight 可以接入各式各样的服务，但是针对服务的指标、仪表盘，我们为您预定义的都是相互独立的。
那么有没有可能将事件、仪表盘、指标、报警相互关联起来呢？

这也是 Cloud Insight 考虑在内的需求之一。

当您发现 mysql.innodb.writes 的数值很高时，往往可能是因为业务压力所造成的。如，推出了更换头像功能，用户在这一时刻都想上传自定义头像，会带来负载的压力。 此时 Application Insight 会抓取到慢 SQL 追踪记录，来记录代码的运行情况。

有了 Cloud Insight，在您对接 Application Insight 之后，这些记录都会是一个个事件。将事件与基础设施服务的指标，建立联系，并一起查看和分析，有助于您更快知道问题出在哪里。

事件的检索是支持全文搜索的，这样就会更方便您找到所对应的结果。

结语

Cloud Insight 通过 API 对接所有可以对接的服务，加上自身的主机和平台服务的监控，来容纳 IT 中所有的监控和管理工作；然后通过可协作、强沟通的事件流机制，来消减不同工具、不同服务间难沟通的问题。

以前，往往还要通过邮件和各种各样的团队协作工具，来进行沟通；在使用 Cloud Insight 后，通过一体化的数据管理平台，就可以在这个平台上进行沟通和协作。

Cloud Insight 就是这样一个数据管理平台，对接所有可以对接的服务，展现所有可以展现的数据；来填补部门间、人员间、技能间的沟通鸿沟。

Cloud Insight 也是一个完全由用户主导和参与的产品，我们采用小步迭代的方式，以最快速度对您在 Cloud Insight 社区中提到的意见，进行反馈和实现。

以上提到的事件流功能，预计在 2015 年年底进行沟通；有什么需求和意见，赶紧来 Cloud Insight 社区表达自己的想法吧！

还不赶紧注册个 OneAPM 账号，开始使用！使用完，别忘了来 Cloud Insight 社区，喷一嘴。