本节帮助希望使用 Dotcom-Monitor 监控工具开发应用程序的软件开发人员。

在 Dotcom-Monitor 网站界面之外,有几种方法可以查看和与监控数据进行交互,包括使用 XML 源 来消耗数据,并与 Dotcom-Monitor API 进行交互,以监控和更新已安装的监控代理。

使用 XML 源,开发人员可以订阅想要的数据,并使用自己的自定义报表以自己的格式呈现数据。 有关详细信息,请参阅 使用 XML 报告服务 (XRS) 工具

Dotcom-Monitor API 用户可以创建自己的自定义脚本或应用程序,以便与设置进行交互,并在自己的自定义环境中查看监控的数据。 我们的系统使用 REST API,通过 HTTP (S) 请求(GET、POST、PUT、删除)使用最流行的数据处理方法,实现与 Dotcom-Monitor 网站的交互。 几乎所有 Dotcom 监视器对象都可以通过 REST API 访问,并且几乎可以管理 Dotcom 监视器服务功能的几乎每个方面。 使用 API 呼叫,开发人员可以创建和删除设备和任务、推迟和启动它们、创建和管理警报组、模板、过滤器和调度器、获取设备状态信息以及许多其他选项。

一般来说,Dotcom 监视器 API 可用于以下任务:

  • 第三方集成与 Dotcom 监控解决方案。
  • 数据下载和上传。
  • 数据修改。

通过 REST API 执行的最常见操作:

  • 访问监控平台、设备、目标、调度器、位置、警报组、过滤器、警报模板的列表。
  • 访问平台、设备和目标的详细信息。
  • 编辑设备、目标、调度器、警报组和模板、过滤器。
  • 创建新的网络监视器对象(设备、目标、调度器等)。
  • 管理审计对象。

自定义收集器 API

单独的MetricsView API是一组方法,用于将任何指标从任何源上载到 Dotcom-Monitor Inc. 以进行进一步处理和分析。

Dotcom-Monitor API 分为 10 种资源类型:

  • 平台:所有监视任务都属于五个不同的平台之一。
  • 设备: 监控设备是一组有组织的监控任务,其中包含单个监控任务、一系列监控任务、包含任务的监控脚本,或包含所有三个任务的组合。
  • 任务:任务是任何单一的监控活动,例如监视目标(URL、邮件服务器、FTP 服务器等)。
  • 频率:定义执行监视会话的频率。
  • 调度器: 调度器详细说明任务何时运行或将不运行。
  • 位置:Dotcom-Monitor 全球监控网络内的监控位置。
  • 警报组: 设置组将报告和/或警报的接收者放置到组中。 组中的每个收件人都可以具有唯一的警报模板。
  • 警报模板: 模板定义警报格式。
  • 过滤器: 过滤器是一组规则,它决定如何处理和显示监控响应。
  • 审计: 提供每个帐户修改的历史信息。

在任何 API 请求之前,您都需要在 Dotcom 监视器中 进行身份验证 。 身份验证将在 60 秒不活动后过期。

下表显示了每种资源类型支持的请求类型和操作。 有关详细描述,请参阅 监控方法 部分。

资源类型 请求方法 URI 描述
平台 获取 /平台 可用平台的返回列表
装置 获取 /设备/{platform} 按平台获取设备列表。
获取 /设备/{deviceId} 获取设备信息
发布 /设备?动词_PUT 创建新设备
/设备
发布 /设备 {deviceId} //禁用警报器/ 禁用警报
发布 /设备/{deviceId} 编辑设备
发布 /设备 {deviceId} /?动词=删除 删除设备
删除 /设备/{deviceId}
任务 获取 /设备 {deviceid} //任务 在设备下获取任务列表
发布 /任务?动词=PUT 创建新任务
/任务
获取 /任务/{TaskId} 获取任务信息
发布 /任务/{TaskId} 编辑任务
发布 /任务/ {TaskId} ?动词=删除 删除任务
删除 /任务/{TaskId}
频率 获取 /频率/{platform_name} 获取可用 freq。 按平台。
调度 获取 /计划程序 获取计划程序列表
获取 /调度器/{Scheduler_ID} 获取特定的计划程序信息
发布 /计划程序?verb_PUT 创建新计划程序
计划程序
发布 /计划程序/* 调度程序 ID} 编辑计划程序
发布 /调度器 {Scheduler_Id} /?动词+删除 删除调度器
删除 /调度器/{Scheduler_Id}
位置 获取 /位置/{platform_name} 获取可用位置的列表
警报组 获取 /组 获取警报组列表
发布 /组?动词_PUT/组 创建警报组
组/组
获取 /组/{Group_ID} 获取警报组信息
发布 /组/{Group_ID} 编辑警报组
发布 /组 {Group_Id} /?动词+删除 删除组
删除 集团/{Group_Id}
警报模板 获取 /模板 获取警报模板列表
发布 /模板?动词_PUT/模板 创建新的警报模板
/模板/模板
获取 /模板/{Template_ID} 获取警报模板信息
发布 /模板/{Template_ID} 编辑警报模板
发布 /模板 {Template_Id} /?动词=删除 删除模板
删除 /模板/{Template_Id}
滤波器 获取 /过滤器 获取筛选器列表
发布 /过滤器?动词_PUT 创建新筛选器
/过滤器
获取 /过滤器/{filter_ID} 获取特定的筛选器信息
发布 /过滤器/{filter_ID} 编辑筛选器
发布 /过滤器 {filter_ID} /?动词=删除 删除筛选器
删除 /过滤器/{filter_ID}
Audit 获取 /审核/列表 获取最近 24 小时当前用户的审核对象列表。
获取 /审核/对象/[示例 ID] 获取特定 ID 的审核内容
发布 /审核/列表 获取审核对象的筛选列表。
  • Web API Monitoring: How to Start and What Approach to Use

    在开始 Web API 监控主题之前,让我们简要谈谈用于在不同类型软件之间交换数据的方法。

    很难想象一个现代公司,所有的业务流程都在一个软件产品上运行。 通常,有几个桌面和 Web 应用程序用于支持整个生命周期的业务运营。 一些开箱即用的应用程序能够与相关软件产品交互,而另一些应用程序则需要一些额外的配置或第三方服务。 例如,向软件市场引入支持软件集成的常见做法是:

    • 网络服务。
    • 通过FTP进行文件交换。
    • 非结构化 HTTP 请求。
    • 其他方法,如网络插座、专用端口等。

    虽然所有其他软件集成方法没有标准化的数据交换流程,但 Web 服务提供标准化的集成方式。 Web 服务是一种允许应用程序通过网络相互通信的技术。 简单地说,Web 服务是 Internet 上的地址,一个可以访问以获取数据或执行操作的链接。 通常,运行在 HTTP 的 Web 服务称为 Web API。 使用 HTTP 作为传输协议的优点是它使 Web 服务独立于编程语言。 在 Web 服务的情况下,向资源提出请求的客户端和提供响应的 API 服务器可以使用任何编程语言或框架。 这样,我们想要连接的应用程序是否使用相同的编程语言开发并不重要。

    Web API 通常使用以下技术实现:

    • XML-RPC(易失标记语言远程程序呼叫) – 使用 HTTP 作为传输协议的协议和 XML 编码呼叫的协议。
    • JSON-RPC (JSON 远程程序呼叫) – XML-RPC 的类似物,但消息以 JSON 格式传输除外。
    • SOAP(简单对象访问协议) – 基于 XML 使用 WSDL(Web 服务描述语言)来描述消息结构的标准化协议。
    • REST(表示状态传输) – 不是协议,而是基于 HTTP 协议方法的网络中软件交互架构。
    • 专为执行特定任务而设计的专用协议,例如用于创建 API 服务器查询并将 API 数据加载到客户端应用程序的 GraphQL。

    什么是 API 监控?

    一旦您为您的应用程序实现了 Web API 并考虑上市,您需要确保所有 API 功能都按照应用的业务逻辑工作。 此外,无论您是 API 服务的消费者还是为第三方应用程序提供服务,监控您的 Web API 性能都至关重要。 API 服务性能的任何退化都可能导致相关业务的重大损失,并影响您的用户体验。

    API 监控的主要目的是主动查找和修复 API 中的所有错误,因为它们会发生,甚至在用户注意到它们之前。

    为什么我们需要监控您的网站应用程序或网站的API? 为什么UI测试不足以确保您的Web应用程序正常工作? UI 测试确实是模拟真实用户行为的最佳方式(请参阅使用 Dotcom 监控每一步脚本工具的实时浏览器中的 Web 应用程序测试的优势)。 但是,我们倾向于通过 UI 监控的网站功能通常可以通过 API 监控测试进行检查。 例如,加载在线商店库存商品列表的 API 呼叫在背面更改,但在 UI 上保持不变,系统将无法在网站上的相应用户操作中返回列表。 在这种情况下,UI 监控将返回错误,但不会检测到错误的真正来源(它可能是连接问题、服务器过载、UI 错误、不正确的 API 呼叫等)。 另一方面,Web API 监控将显示呼叫目标 API 端点时不会返回响应。 对于其他 API 呼叫结果验证,可以使用响应内容验证。

    API 监控如何工作?

    Web API 监控侧重于资源和对这些资源的访问。 在 Web API 中,资源呈现不同类型的信息。 资源可以通过网址(统一资源定位器)访问。 当您导航到浏览器中的特定 URL 时,您连接到与该 URL 相对应的资源。 当您从此类应用程序(如邮递员或使用 CURL)向 URL 地址发送 API 请求时,也会发生同样的情况。 为了明确 Web 服务在资源上要执行什么操作,使用 HTTP 方法包括 GET(读取)、开机自检(创建)、PUT(更新)和删除(删除)。 请参阅 “REST有效负载”-如何将”网络API”推送至Web API, 了解如何使用 Dotcom 监视器来监控大量 API 的详细信息。

    每个请求之后,API 服务器都会做出响应。 响应是响应请求从 API 返回的数据。 响应可以返回不同的数据,包括 JSON 对象。

    包含请求参数并提供资源访问的资源的整个路径称为 Web API 端点。 例如,发送 API 呼叫的端点可能看起来像这样:

    http://example.com/wp-json/wp/v2/tests

    简单地说,端点是我们在执行针对我们的网站和应用程序的 Web API 监控呼叫时检查的内容。 一般来说,API 端点监控步骤包括:

    • 请求到终点。
    • API服务器的响应。
    • 响应验证和分析。

    使用网络监控器作为 API 监控工具的好处

    Dotcom-监视器是一种全面的解决方案,可用于所有类型的 Web API 监控(参见如何设置 SOAP Web 服务监控REST Web API 监控)。 除了 API 监控之外,Dotcom 监控器还为 Web 应用程序、网站、单一网页、Web 服务器和其他类型的 Web 资源提供监控工具。

    为了将监控过程带到一个新的水平,Dotcom-Monitor 允许用户在真实的浏览器窗口中测试其目标 Web 应用程序。 基于浏览器的测试可确保监控测试尽可能接近真实场景并重复真实的用户体验。 您可以在多个浏览器引擎之间进行选择,以运行您的应用程序或网站,包括桌面和移动浏览器引擎。

    详细的性能报告,包括逐元素瀑布图、屏幕截图和监控会话时录制的视频,让您充分了解 UI 场景背后的具体情况 – 这些元素会减慢您的应用速度,并导致其性能中的错误和瓶颈。

    高度定制的 Dotcom 监控器警报系统为您提供了高效的警报通知服务。 当在监控时检测到错误时,可以配置系统向专用地址发送警报通知。 请参阅我们知识库的 警报传递机制 文章中支持的警报机制。