5分钟就能实现的API监控,你有什么理由不做呢?

API深度影响着你的应用

今天的数字应用世界其实是一个以API为中心的世界,我们只是没有意识到这些API的重要性。比如在电子商务交易、社交媒体等对交互高度依赖的领域,可以说API决定了应用的质量一点也不为过。

以京东为例,用户的每一次操作背后都关联着一系列API,比如购买商品时选择不同的规格、颜色等信息,这些API可能基于分布式服务位于不同地方,因此增加了更多的复杂性。也因为这些复杂的网络和应用架构,让这些API中的任何一个都可能不可用或出现某种性能问题。

(京东商城整体架构示例,图片来自互联网分享)

因此如果你想确保您的客户拥有良好的用户体验,主动监控您的API至关重要,有没有一种方式能在不影响现有用户的同时监测到哪些API存在问题呢?进而实现主动发现主动告警。没错,我们可以用模拟用户访问。

基调听云让这变成可能

既然是模拟总要有用户节点才行,基调听云经过10多年的积累和发展,目前遍布在全球各地的有30万+的模拟用户节点。这些节点通过任务下发方式主动对您的API接口做监控,无需您的开发人员做任何嵌码。只要是该API URL能在互联网上被访问,就可以通过主动监控提前发现API接口的错误或性能问题。提前发现和解决可以减少对用户的影响,帮您提升业务可用性和用户体验。

监控过程也很简单,5分钟搞定:
1、申请听云Network SaaS账号:注册|基调听云国内领先的端到端应用性能管理解决方案提供商
2、创建API接口监控任务:在任务管理界面,创建“单一文件下载”类型的任务,输入要测试的API接口URL,请求方式为get和post方式,针对post请求,可以设置post内容以及预期的内容,以便监测过程中如果返回内容和实际内容不一致时可以报错报警。

3、配置完任务,建议及时对各种指标配置告警阈值,以便及时发现问题。

是不是很简单?先别急着放松,这只是开始。我们还要分析数据,按照惯例监控从来都不是我们的目的,数据才是。

我们该关注哪些指标?

对于API监控来说,建议重点关注的指标:可用性、错误、建立连接时间、首包时间等。

登录到听云控制台以后,选择你刚刚创建好的任务,正常情况下任务创建后几分钟左右就会有采集上来的数据展示。

分三步来看:

一看趋势
通过报表功能导航栏的“趋势”功能,我们可以查看该API接口近期的性能波动情况:

以上图为例,可以看到在11月2日左右,该接口的总下载时间由原来的2秒左右下降到5秒左右,下降了一倍多,这不是个好现象。

根据经验,影响总下载时间的指标一般可能是DNS时间、建立连接时间、SSL握手时间、首包时间、内容下载时间、总下载字节数等指标。

依次查看,我们看到首包时间和总下载时间的趋势一致,基本可以判断是由于首包时间变长,导致总下载时间变长的原因。

如下:

影响首包时间的元素一般为:
1、网络原因。结合看DNS、建立连接时间、SSL等指标都比较稳定,基本排除网络原因。
2、服务器对接口的处理能力下降。有可能业务量爆发导致API接口处理的内容变多,或者服务器负载比较高等原因。

这时候就可以联系相关技术同事在服务器端进行进一步查看分析了。

二看可用性

选取可用性指标页,可以查看API接口的可用性情况。

可以看到该接口近期的可用性为99.79%,在行业参考值范围以内,同时我们也看到近期该接口出现20次错误,我们可以在“错误”模块中查看近期都出现了什么类型的错误。

示例中该接口主要出现一些502、504、408、超时等类型的错误,可以点击每一种错误类型下钻分析其错误详情。

这里散点图,描述的是每一次错误请求的分布情况,可以继续点击某个错误图示,进一步下钻分析其错误详情。

三看主机

更详细的情况,可以从主机维度分析,可以查看此类错误主要都发生在哪些主机?

技术人员拿到这些信息可以在对应的服务器上做进一步排查和关注。

总结

通过这款产品的功能让我们多了一种方式快速地对自己的API质量能进行有效监控,工具归根到底都只是辅助,重要的是有主动监控的意识加上丰富的数据分析经验,定位和解决问题才会更加的如虎添翼。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
第一部分 理论与理由 第1章 软件开发的艺术 4 1.1 理性主义,经验主义以及无绪 4 1.2 软件的演变过程 6 1.3 大型软件 8 1.4 漂亮,真理和优雅 9 1.5 更好的无绪 12 第2章 设计API的动力之源 14 2.1 分布式开发 14 2.2 模块化应用程序 16 2.3 交流互通才是一切 20 2.4 经验主义编程方式 22 2.5 开发第一个版本通常比较容易 24 第3章 评价API好坏的标准 26 3.1 方法和字段签名 26 3.2 文件及其内容 27 3.3 环境变量和命令行选项 29 3.4 文本信息也是API 30 3.5 协议 32 3.6 行为 35 3.7 国际化支持和信息国际化 35 3.8 API的广泛定义 37 3.9 如何检查API的质量 37 3.9.1 可理解性 37 3.9.2 一致性 38 3.9.3 可见性 39 3.9.4 简单的任务应该有简单的方案 40 3.9.5 保护投资 40 第4章 不断变化的目标 42 4.1 第一个版本远非完美 42 4.2 向后兼容 43 4.2.1 源代码兼容 43 4.2.2 二进制兼容 44 4.2.3 功能兼容——阿米巴变形虫效应 50 4.3 面向用例的重要性 52 4.4 API设计评审 55 4.5 一个API的生命周期 56 4.6 逐步改善 60 第二部分 设计实战 第5章 只公开你要公开的内容 67 5.1 方法优于字段 68 5.2 工厂方法优于构造函数 70 5.3 让所有内容都不可更改 71 5.4 避免滥用setter方法 72 5.5 尽可能通过友元的方式来公开功能 73 5.6 赋予对象创建者更多权利 77 5.7 避免暴露深层次继承 82 第6章 面向接口而非实现进行编程 85 6.1 移除方法或者字段 87 6.2 移除或者添加一个类或者接口 88 6.3 向现有的继承体系中添加一个接口或者类 88 6.4 添加方法或者字段 88 6.5 Java中接口和类的区别 90 6.6 弱点背后的优点 91 6.7 添加方法的另一种方案 92 6.8 抽象类有没有用呢 94 6.9 要为增加参数好准备 95 6.10 接口VS.类 97 第7章 模块化架构 98 7.1 模块化设计的类型 100 7.2 组件定位和交互 103 7.3 编写扩展点 116 7.4 循环依赖的必要性 117 7.5 满城尽是Lookup 121 7.6 Lookup的滥用 126 第8章 设计API时要区分其目标用户群 129 8.1 C和Java语言中如何定义API和SPI 129 8.2 API演进不同于SPI演进 131 8.3 java.io.Writer这个类从JDK 1.4到JDK 5的演进 131 8.4 合理分解API 143 第9章 牢记可测试性 147 9.1 API设计和测试 148 9.2 规范的光环正在褪去 151 9.3 好工具让API设计更简单 153 9.4 兼容性测试套件 155 第10章 与其他API协作 158 10.1 谨慎使用第三方API 158 10.2 只暴露抽象内容 162 10.3 强化API的一致性 164 10.4 代理和组合 168 10.5 避免API的误用 176 10.6 不要滥用JavaBeans那种监听器机制 180 第11章 API具体运行时的一些内容 184 11.1 不要冒险 186 11.2 可靠性与无绪 189 11.3 同步和死锁 191 11.3.1 描述线程模型 192 11.3.2 Java Monitors中的陷阱 193 11.3.3 触发死锁的条件 196 11.3.4 测试死锁 201 11.3.5 对条件竞争进行测试 204 11.3.6 分析随机故障 206 11.3.7 日志的高级用途 208 11.3.8 使用日志记录程序控制流程 210 11.4 循环调用的问题 215 11.5 内存管理 218 第12章 声明式编程 223 12.1 让对象不可变 225 12.2 不可变的行为 229 12.3 文档兼容性 230 第三部分 日常生活 第13章 极端的意见有害无益 236 13.1 API必须是漂亮的 237 13.2 API必须是正确的 237 13.3 API应该尽量简单 240 13.4 API必须是高性能的 242 13.5 API必须绝对兼容 242 13.6 API必须是对称的 245 第14章 

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值