多宿主网站是指托管在连接到两个或多个互联网服务提供商ISP的服务器背后的网站每个提供商都有自己的 IP 地址。DNS 会在这些 IP 之间轮询分配流量——而正是这种轮询导致了标准监控手段变得不可靠。你可以这样想你的监控工具检查“yourwebsite.com”DNS 随机挑选了一个 IP然后工具就报告了它在这条路径上发现的结果。如果你的主 ISP 速度很快且承担了 80% 的流量那么你的仪表盘就会显示健康的响应时间。然而你的备用 ISP某些特定区域的用户正在访问的那个可能正面临 780 毫秒的延迟和 12% 的丢包率而你的监控系统中却没有任何指标会发出警报。为什么基于 DNS 的监控会漏掉特定运营商的故障标准的可用性Uptime检查会对 DNS 返回的任意 IP 的性能进行平均化处理。对于单宿主Single-homed网站来说这没问题。但对于多宿主网站这会掩盖故障。某个运营商的可用性可能会降至 87%但整体报告的可用性依然维持在 99.9%。与主连接相比备用 ISP 路径可能会导致移动端用户的访问速度显著变慢。特定地区例如亚太地区/APAC的用户可能会因为当地 ISP 的问题而频繁遇到连接超时但在全球平均数据看来却一切正常。在用户开始抱怨之前这些问题根本不会暴露出来。根本问题在于DNS 监控测试的是 DNS 层而不是其背后的网络路径。强制指定 IP 地址则完全绕过了 DNS 层。这样每条路径都有了自己专属的监控器、响应时间基准和告警阈值。当某一个运营商的性能下降时你能够立即发现而不是看着它被平均数据所稀释。在 Site24x7 中设置强制 IP 监控第 1 步查找所有 IP 地址大多数多宿主网站都有 2 到 4 个 IP每个 IP 链接到不同的 ISP。在命令行运行 nslookup yourwebsite.com或使用在线 DNS 查询工具。你会得到类似以下的结果192.0.2.10主 ISP198.51.100.10备用 ISP203.0.113.10区域 ISP每一个 IP 都是一条独立的网络路径每一个都需要有自己的监控器。第 2 步为每个 IP 创建独立的监控器不要把它们合并在一个网站名称下。创建独立的监控器监控器 1192.0.2.10 — 主 ISP监控器 2198.51.100.10 — 备用 ISP监控器 3203.0.113.10 — 区域 ISP这样可以实现独立的响应时间跟踪、独立的告警阈值并让你在出问题时清晰地看到哪个运营商正在发生性能恶化。第 3 步配置 Host 请求头如果没有 Host 请求头服务器通常会拒绝直接的 IP 请求——它们需要知道流量属于哪个域名。在你的 Site24x7 监控配置中添加一个自定义的 HTTP 请求头Host: yourwebsite.com如果不加这一项你的服务器可能会返回连接错误或错误的内容导致监控结果不可靠。第 4 步选择正确的 HTTP 方法和内容检查页面加载使用 GET 方法表单和结账流程使用 POST 方法。除了 HTTP 方法之外还要配置内容检查以验证页面实际返回的内容而不仅仅是看它是否返回了 200 状态码。如果服务器返回的是缓存的错误页面、维护通知或空白主体仅检查状态码的测试依然会通过。内容验证则能抓住这些问题。在 Site24x7 监控配置的“响应验证Response Validation”部分下添加关键字检查 检查字符串Order Confirmed订单已确认对于结账流程这能确认交易已完成而不仅仅是服务器做出了响应。对于登录流程检查一个只有在认证后才会出现的字符串比如“欢迎回来”或登录后的仪表盘标题。对于商品页面检查商品名称或“加入购物车”元素。如果端点返回特定的 Content-Type请将关键字检查与响应头断言结合使用Content-Type: text/html; charsetUTF-8如果响应主体发生变化例如部署推了损坏的模板、第三方脚本加载失败、数据库查询返回空关键字检查就会失败并触发告警。而单靠状态码是无法捕获这些异常的。第 5 步选择与实际流量相匹配的监控地点从你客户实际所在的城市进行测试。对于一家服务亚太地区的电商网站来说这意味着除了你的主要区域外还要选择孟买、钦奈、班加罗尔、新加坡和德里。一个在美国东海岸表现良好的备用 ISP在亚太地区的用户端可能路由表现很差——你如果只从单一地点测试是抓不到这个问题的。Site24x7 提供了 130 多个全球节点。选择那些能反映你真实用户地理分布的节点而不是使用默认设置。输出结果对比在配置强制 IP 监控之前典型的多宿主仪表盘只显示一个数字yourwebsite.com → 99.9% 可用性。这个数字掩盖了每条路径上实际发生的事情。在配置了基于每个 IP 的监控之后IP 地址192.0.2.10主 ISP| 可用性99.98% | 响应时间25ms | 状态健康IP 地址198.51.100.10备用 ISP| 可用性87% | 响应时间780ms | 状态异常IP 地址203.0.113.10区域 ISP| 可用性99.2% | 响应时间120ms | 状态健康现在备用 ISP 87% 的可用性和 780 毫秒的响应时间变得清晰可见。如果没有这种基于 IP 的设置这些数字就会被平均到 99.9% 的总体数据中而走这条路径的客户正在经历结账超时你却对此一无所知。下一步显而易见在因为购物车被放弃而造成更多损失之前调查备用 ISP 的路由问题。这如何融入你的 DEM数字体验监控架构强制 IP 监控和数字体验监控DEM针对同一个事件回答了不同的问题。DEM 告诉你用户体验到了什么来自新加坡的购物车放弃率上升、加载时间攀升至 4.2 秒、Apdex 评分跌破阈值。亚太地区出问题了。你知道了症状但不知道原因。基于 IP 的监控则告诉你为什么。你对 198.51.100.10负责路由新加坡流量的备用 ISP的监控显示出 780 毫秒的响应时间和 12% 的丢包率。主 ISP 很健康25 毫秒。备用 ISP 出了问题。这就是原因存在于它实际发生的网络层。如果没有基于 IP 的监控你就是在调查一个没有网络层解释的 DEM 异常。而有了它你就拥有了具体的运营商、具体的 IP、具体的性能恶化时间段以及能够立即采取行动的数据。将每个 IP 监控器的响应时间告警设置为 3 秒。当备用 ISP 超过该阈值时在你的 DEM 数据积累到足够显示出趋势的会话之前你就已经知道了。强制 IP 监控并不是要取代 DEM。它是一个诊断层将“新加坡用户的体验很糟糕”转化为“你的备用 ISP 出了问题——这是证明这一点的证据数据”。开始免费试用 Site24x7并在你现有的 DEM 设置旁配置你的第一个基于 IP 的监控器。
多宿主网站是指托管在连接到两个或多个互联网服务提供商ISP的服务器背后的网站每个提供商都有自己的 IP 地址。DNS 会在这些 IP 之间轮询分配流量——而正是这种轮询导致了标准监控手段变得不可靠。你可以这样想你的监控工具检查“yourwebsite.com”DNS 随机挑选了一个 IP然后工具就报告了它在这条路径上发现的结果。如果你的主 ISP 速度很快且承担了 80% 的流量那么你的仪表盘就会显示健康的响应时间。然而你的备用 ISP某些特定区域的用户正在访问的那个可能正面临 780 毫秒的延迟和 12% 的丢包率而你的监控系统中却没有任何指标会发出警报。为什么基于 DNS 的监控会漏掉特定运营商的故障标准的可用性Uptime检查会对 DNS 返回的任意 IP 的性能进行平均化处理。对于单宿主Single-homed网站来说这没问题。但对于多宿主网站这会掩盖故障。某个运营商的可用性可能会降至 87%但整体报告的可用性依然维持在 99.9%。与主连接相比备用 ISP 路径可能会导致移动端用户的访问速度显著变慢。特定地区例如亚太地区/APAC的用户可能会因为当地 ISP 的问题而频繁遇到连接超时但在全球平均数据看来却一切正常。在用户开始抱怨之前这些问题根本不会暴露出来。根本问题在于DNS 监控测试的是 DNS 层而不是其背后的网络路径。强制指定 IP 地址则完全绕过了 DNS 层。这样每条路径都有了自己专属的监控器、响应时间基准和告警阈值。当某一个运营商的性能下降时你能够立即发现而不是看着它被平均数据所稀释。在 Site24x7 中设置强制 IP 监控第 1 步查找所有 IP 地址大多数多宿主网站都有 2 到 4 个 IP每个 IP 链接到不同的 ISP。在命令行运行 nslookup yourwebsite.com或使用在线 DNS 查询工具。你会得到类似以下的结果192.0.2.10主 ISP198.51.100.10备用 ISP203.0.113.10区域 ISP每一个 IP 都是一条独立的网络路径每一个都需要有自己的监控器。第 2 步为每个 IP 创建独立的监控器不要把它们合并在一个网站名称下。创建独立的监控器监控器 1192.0.2.10 — 主 ISP监控器 2198.51.100.10 — 备用 ISP监控器 3203.0.113.10 — 区域 ISP这样可以实现独立的响应时间跟踪、独立的告警阈值并让你在出问题时清晰地看到哪个运营商正在发生性能恶化。第 3 步配置 Host 请求头如果没有 Host 请求头服务器通常会拒绝直接的 IP 请求——它们需要知道流量属于哪个域名。在你的 Site24x7 监控配置中添加一个自定义的 HTTP 请求头Host: yourwebsite.com如果不加这一项你的服务器可能会返回连接错误或错误的内容导致监控结果不可靠。第 4 步选择正确的 HTTP 方法和内容检查页面加载使用 GET 方法表单和结账流程使用 POST 方法。除了 HTTP 方法之外还要配置内容检查以验证页面实际返回的内容而不仅仅是看它是否返回了 200 状态码。如果服务器返回的是缓存的错误页面、维护通知或空白主体仅检查状态码的测试依然会通过。内容验证则能抓住这些问题。在 Site24x7 监控配置的“响应验证Response Validation”部分下添加关键字检查 检查字符串Order Confirmed订单已确认对于结账流程这能确认交易已完成而不仅仅是服务器做出了响应。对于登录流程检查一个只有在认证后才会出现的字符串比如“欢迎回来”或登录后的仪表盘标题。对于商品页面检查商品名称或“加入购物车”元素。如果端点返回特定的 Content-Type请将关键字检查与响应头断言结合使用Content-Type: text/html; charsetUTF-8如果响应主体发生变化例如部署推了损坏的模板、第三方脚本加载失败、数据库查询返回空关键字检查就会失败并触发告警。而单靠状态码是无法捕获这些异常的。第 5 步选择与实际流量相匹配的监控地点从你客户实际所在的城市进行测试。对于一家服务亚太地区的电商网站来说这意味着除了你的主要区域外还要选择孟买、钦奈、班加罗尔、新加坡和德里。一个在美国东海岸表现良好的备用 ISP在亚太地区的用户端可能路由表现很差——你如果只从单一地点测试是抓不到这个问题的。Site24x7 提供了 130 多个全球节点。选择那些能反映你真实用户地理分布的节点而不是使用默认设置。输出结果对比在配置强制 IP 监控之前典型的多宿主仪表盘只显示一个数字yourwebsite.com → 99.9% 可用性。这个数字掩盖了每条路径上实际发生的事情。在配置了基于每个 IP 的监控之后IP 地址192.0.2.10主 ISP| 可用性99.98% | 响应时间25ms | 状态健康IP 地址198.51.100.10备用 ISP| 可用性87% | 响应时间780ms | 状态异常IP 地址203.0.113.10区域 ISP| 可用性99.2% | 响应时间120ms | 状态健康现在备用 ISP 87% 的可用性和 780 毫秒的响应时间变得清晰可见。如果没有这种基于 IP 的设置这些数字就会被平均到 99.9% 的总体数据中而走这条路径的客户正在经历结账超时你却对此一无所知。下一步显而易见在因为购物车被放弃而造成更多损失之前调查备用 ISP 的路由问题。这如何融入你的 DEM数字体验监控架构强制 IP 监控和数字体验监控DEM针对同一个事件回答了不同的问题。DEM 告诉你用户体验到了什么来自新加坡的购物车放弃率上升、加载时间攀升至 4.2 秒、Apdex 评分跌破阈值。亚太地区出问题了。你知道了症状但不知道原因。基于 IP 的监控则告诉你为什么。你对 198.51.100.10负责路由新加坡流量的备用 ISP的监控显示出 780 毫秒的响应时间和 12% 的丢包率。主 ISP 很健康25 毫秒。备用 ISP 出了问题。这就是原因存在于它实际发生的网络层。如果没有基于 IP 的监控你就是在调查一个没有网络层解释的 DEM 异常。而有了它你就拥有了具体的运营商、具体的 IP、具体的性能恶化时间段以及能够立即采取行动的数据。将每个 IP 监控器的响应时间告警设置为 3 秒。当备用 ISP 超过该阈值时在你的 DEM 数据积累到足够显示出趋势的会话之前你就已经知道了。强制 IP 监控并不是要取代 DEM。它是一个诊断层将“新加坡用户的体验很糟糕”转化为“你的备用 ISP 出了问题——这是证明这一点的证据数据”。开始免费试用 Site24x7并在你现有的 DEM 设置旁配置你的第一个基于 IP 的监控器。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
