WebSocket
WebSocket监控
升级握手完成，套接字片刻后仍保持打开，并接收到第一条消息。
立即尝试
一次检查，从一个地点立即进行，不保存任何数据。监控会从我们运行的每个地点检查，并在两个其他大陆确认故障后才通知任何人，而单次检查无法显示这些信息。
它的用途
您的聊天、实时仪表板、价格推送、协作编辑器、游戏大厅：这些都是WebSocket，它是产品中可能失败的部分，而底层的每一层都显示正常。页面加载、API响应、证书有效、端口开放，但套接字从未打开。
或者套接字打开后在200毫秒内又关闭，从用户角度看就是屏幕静默停止更新，没有人会报告宕机。他们刷新页面，工作一会儿后放弃。因此这项监控不会止步于握手：它会在握手后继续监控套接字，就像TCP检查可以坚持要求问候而不是满足于端口开放。
这是人们实际会损失金钱的情况：连接的推送停止发布。提供一条要发送的消息和回复必须匹配的模式，或者仅提供模式，静默的推送是故障而不是看似正常的绿色行。
和这里的每个检查一样，它从Amsterdam, New York, Sydney and Singapore运行，并且故障会在其他两个大陆确认后才会通知任何人。如何运作。
你可以设置什么
以下内容在你添加时的表单中，每个套餐都包含。
- 地址
- 一个ws://或wss://地址，带路径。主机和端口是TCP检查，这是另一个问题。
- 首先发送此内容
- 一个文本帧，在套接字打开时立即发送，适用于响应而非发布的端点。
- 预期消息
- 一个帧必须匹配的正则表达式。填写它是使帧成为必需的原因。
- 等待时间
- 秒数。与连接超时分开，因为每30秒发布一次的推送是健康的，但会超出握手形状的截止时间。
- 超时
- 握手本身可能需要的时间。
- 确认
- 需要多少其他地区的确认才能触发警报。
问题
为什么我不能直接用HTTPS监控它？
因为健康的响应会被记录为故障。WebSocket以携带Upgrade: websocket和Sec-WebSocket-Key的HTTP GET开始，服务器对普通GET返回400或426是完全正常的。HTTPS监控会看到这个状态码并报告你宕机，而实际上你运行正常。
检查实际做了什么？
它完成升级握手，即返回101状态码并包含从发送的密钥派生的Sec-WebSocket-Accept，然后短暂保持socket以检查是否保持打开状态。之后断开连接。它不会在检查之间保持连接，因此对你的服务器来说完全不像一个客户端。
我的推送大部分时间都很安静，这会失败吗？
不会。一个打开但没有发送任何消息的socket是健康的，除非你填写了预期消息，因为没有内容发布的feed并不是坏掉的feed。填写预期消息后规则会有意改变：在你设置的等待时间内需要收到一个帧，这样可以捕捉到连接但已停止的feed。
1000是正常关闭，1011是服务器遇到无法恢复的条件，两者都会表现为连接关闭。关闭代码和原因包含在失败信息中，而不是简单地归为断开连接，因为它们指向不同的修复方向。
1000是正常关闭，1011是服务器遇到无法恢复的条件，两者都会表现为连接关闭。关闭代码和原因包含在失败信息中，而不是简单地归为断开连接，因为它们指向不同的修复方向。
支持Socket.IO、SignalR、STOMP或MQTT吗？
不会，我们明确说明这一点而不是暗示支持。这些是基于WebSocket之上的框架，每个都有自己的握手和命名空间概念，半支持它们的检查比完全不支持更糟。原始检查仍然可以告诉你底层传输是否正常。
会检查wss://地址的证书吗？
会。wss://连接会像其他连接一样通过公共信任库验证，因此过期证书、自签名证书或主机名不匹配都会导致检查失败。剩余天数是证书监控的问题，值得与此检查一起运行。
可以检查我自己网络上的socket吗？
不会，这是我们最不遗憾的拒绝。连接到内部地址的WebSocket是由我们的基础设施按计划打开的长期双向隧道，比一次性抓取更像服务器端请求伪造。地址会在连接前立即解析，私有地址会被拒绝。
我的客户端会自动重连，为什么还需要监控socket？
应该监控，没有重试逻辑的客户端是更大的问题，因此这项工作并不浪费。这确实意味着你的客户端隐藏了真正值得关注的问题。一个接受连接、保持30秒后断开的socket会让重连的客户端看起来几乎一直连接，但间隙中发送的所有消息都丢失了。此检查会连接、完成握手并保持socket，因此以这种方式失败的服务器会被检查发现，而不是被另一端的重试逻辑掩盖。