发布时间：2019-11-24 分类： 电商动态
这是该系列监控报警产品的第一篇文章。涉及的主要内容是监控产品设计的一些基本知识，这是本系列文章的索引。
在过去做QQ业务运营和维护时，我每天都会使用一种平台。这是什么样的平台？它是监控和报警平台，可检查大量业务视图，检查异常，确认报警，处理报警等。对于操作和维护的学生，如果你看一下使用频率，监控和报警平台的频率要高于自动化平台。毕竟，大多数自动化平台都是由例行变更触发的，监控和报警平台是7X24小时。使用。
那时，有更多的业务和成千上万的机器以他自己的名义。当时，每天收到超过1,000个警报的记录，这是一次非常严重的事故。事实上，如果警报每天超过几十次，它基本上是无效的，也就是说，它不会被处理，也不会被处理。在业务运营和维护的作用下，我更关注从用户角度进行监控。
在去年下半年，我从业务运营和维护转变为产品经理。现在我负责腾讯智运（企业级运维管理平台）监控报警产品线的规划和登陆。对于想要转变为产品经理的商业运营和维护学生，您可以参考我。另一篇文章（从业务运营到产品经理，我是攀登产品的方式）。在产品经理的这个阶段，我更关心从构建者的角度进行监控。
用户和构建器会查看相同的内容以监视警报。最大的区别是什么？
用户是点，构建器是面，用户只关注可以自己服务的功能点，构建器尝试抽象大多数用户拥有的场景，并在抽象的基础上构建功能。努力满足大多数用户场景并解决实际问题。
“任何失败，其他链接可能都有问题，只有监控一定是个问题！”
——乔治·回黑锅
基于这两个不同的视角和实际施工中遇到的各种实际问题，我萌生了写一系列监测主题的想法，哈哈的脸色相当厚实。我曾经写过一篇文章，这次是一次挑战。我希望通过这个主题，我可以与您沟通如何规划，设计和登陆企业级监控产品。
可能是当产品经理习惯于分析用户的场景和角色时，如果将该主题的文章视为产品，那么角色和场景是什么？
在构建编织云监控和警报产品线时，您需要了解一些经验和想法
对于不熟悉本产品的新业务运营和维护学生，他们不熟悉监控报警。
我想建立一个操作和维护同学，监视警报或管理建筑同学。
正在建设监控报警平台的运维同学或产品经理。
每天使用监控报警产品的业务操作和维护同学
在这一系列文章中，我还将尝试以开放（基于群众的众筹）方式撰写。我欢迎各位朋友在评论区发布日常监控和报警产品以及特定场景的痛点。后续工作将以统一的方式评估这些反馈方案。如果是典型的普通场景或小组，但这个小场景可以代表特定类型的业务，它会采用你提供的场景，在随后的文章中会指出这是由朋友提供的。并附上我建议的场景解决方案供大家交流和讨论。
本文是本系列的第一篇文章，也是最基本的文章。老鸟可以直接散落。等待查看后续文章，本文主要包括以下主要内容：
以下三篇文章的核心内容（本系列将更长，暂定设置最后三篇文章的内容）
关于监控需要事先解释的警报的一些概念
三维监测系统的描述
因为我现在是编织云监控和报警产品线的产品经理，而这部分产品也在不断建设中。因此，主要产品规划，设计和实施的后续工作是基于织造云的载体。
预览后续系列中前三篇文章的核心内容
如何设计和实现IAAS层监控（服务器性能，网络设备，网络流量分析）？
企业级监控和报警产品需要设计哪种cmdb？ （在云时代，CMDB扮演的角色越来越核心。我之前也设计了智云的CMDB）
平台级监控产品如何更好地支持使用不同业务形式的各种组件监控？
万樟高层建筑始于
监测的定义
通过技术手段发现服务异常，并不断优化业务可用性和用户体验。这句话的关键词是找到可用性和经验的持续优化。
如何监控
活动：程序的内部点被掩埋，服务主动报告自己的操作。通常，它是转化为企业的财产或指标。该方法准确，快速，灵活，指标丰富。但是，在非标准框架中会有一些代码转换成本。
被动：无需埋葬点，检测或从外部运行服务，如ping检测，日志收集分析等。
旁路：独立于程序逻辑，监控服务质量和口碑，如舆论分析。
那么这三个类别的优点和缺点是什么？实际上，没有办法。这里的方法都适用于不同的场景。例如，可以通过外部拨号域名来实现域名监控，以实现监控目标。它也可以通过不同的拨号点进行监控。在我们的腾讯内部QQ和Qzone两个大型企业已经应用于这三种类型的监控。
监测类型
从大对象类别和层次关系的角度来看，监控一般分为五种类型：
基本监控：这里的基本监控范围主要是指IAAS层（服务器，系统，网络等）
服务器监控：一般指后台服务，如QQ后台消息服务
客户端监控：一般指应用程序，Q的客户端和微信的客户端。
WEB监控：一般指代购源码网站，例如代购源码网站域名的拨号。
用户侧监控：一般指用户舆情监控，如APP的声誉。
监控目标
一个好的监控系统应该实现以下三个目标：
完全：被监视对象的宽度，监视点的覆盖范围，例如上面提到的五种对象类型可以被覆盖
快速：监控性能，数据流处理能力
标准：智能分析和收敛，监控对象集合
监控的性质
在DevOps中，操作和维护，开发和测试的三个角色应该统一起来。为什么我们想在这里有统一的观点？也就是说，每个人都应该注意这个级别的监控点，而不是关注你，我会关注我。点。例如，所有业务监控都可以抽象出三个核心指标：请求量，成功率和时间消耗。这三个关键指标用于判断我们服务的可靠性，可靠性和可靠性，并间接反映用户对我们产品的体验。例如，如果服务的可靠性不好，那么用户的产品体验肯定不会很好。
监测目的
通过引入上述一些概念，实际上，我们已经能够推断应用监控报警的目的，即不断优化业务服务质量和建立质量体系。同样的编织云监控也是为了创建质量系统的闭环路径。
监控警报的产品属性
监控报警是基于数据的属性产品。由于它是一种数据产品，因此在设计产品时必须注意这种路径的闭环数据生成 - >数据增值–>数据消费，围绕这样的路径你可以勾勒出很多用户故事，用户故事是特定的角色，具体的活动是什么，这个活动的价值。
这是一个简单的例子来说明数据生成和数据消费。该闭环路径将在产品构造过程的详细描述中更详细地解释。
数据生成：例如，服务器报告的各种基本操作系统指标，如CPU使用率，内存使用情况等。这会产生大量要消耗的原始数据，那么我们可以对这些数据做些什么呢？
数据消耗：这些升级的原始数据可用作视图显示，例如以图形方式显示过去一小时内服务的CPU使用情况。或者，可以为原始数据设置阈值，并且当超过特定阈值时，生成警报通知。这些是最直接的消费场景。
我们是否可以扩展这些消费方案生成的报警数据的数据以供进一步消费？答案是肯定的，例如，对几个承载Cpu计算服务的服务器产生的杯子使用警报（生产）时间进行分析和分析（消费），是否有可能基本上得出服务的服务高峰期可能在那个时间范围？
我想在这里解释的是，大多数原子数据没有单一的消费或生产属性，而是取决于特定场景和数据链中的角色。
并且监控报警数据加上特定流程（ITSM）也可以驱动监控报警+大型业务逻辑交互闭环的自动化，这个场景让我先购买，下面的描述将再次提到这一部分。
监控系统
系统是指按照一定的顺序和内部关系组合的整个特定范围或同类事物。它是由不同系统组成的系统。事实上，这种描述有点抽象，让我们用大白话来应用监控系统来解释它。
对于具有一定体积的公司，需要不同的监控系统，通过系统与系统之间的内部交互形成大的整体，从而完成不同场景下的监控需求，即监控系统。使用我们的内部示例，我们在Internet上运行了10组监控系统。构建系统的关键部分还在于使用动态透视来查看这些系统生成的数据，而不是每个系统。它们都是孤立的数据岛。下图显示了编织云的整体监控系统。
在编织云监控和报警产品的构建过程中，我们整合了许多关于大规模操作和维护的监控思想和经验。
这里的监控系统与公司的规模直接相关，但一般来说，该系统中应该有三种类型的监控系统。
总结
通过上面的简要介绍，我相信每个人都会对监控报警有一个初步的宏观了解。随着后续文章的推出，您将逐步了解企业级监控产品如何从0演变为1.同时，下一篇文章将进入实际阶段。建立监控报警是一条持续而漫长的道路。它也很复杂，有许多坑，但仍然有一些基本的方法和法律可以遵循。
