前言
近期，某电商网站监控系统发现异常，服务链路中总是出现相同的trace_id，以trace_id:3f2fa233444b0e8725c40277499c4be4为例子，在英、法、德等国家，同一个trace就有上万条，是监控网站出bug了？还是遭遇爬虫了？
不论何种情况，前后端开发都非常注重这个问题。
本文带你一同来看，专业的数据师是如何抽丝剥茧的。
案发现场
证据收集
巧妇难为无米之炊，问题的解决需要全面的证据，可观测性优于监控的价值就在这里体现出来了。
图其实已经很明显，即在各个国家都出现了相同的trace_id，第一反应是遭遇了爬虫，爬虫对十几个国家的网站都进行了数据的爬取，通过使用分析功能，我们发现下图内容：
爬虫的一些危害：
- 大规模的爬虫可能导致服务器资源过度消耗，对网站性能造成负面影响。
- 竞争对手也可能用爬取的数据设定更有竞争力的价格、库存等，导致不公平竞争的优势出现
- 爬虫还可能引发一系列其他问题
初步分析
item是商品的详情页，妥妥的是在爬取商品的数据了，接下来使用观测云把该trace_id作为搜索条件，对结果进行第二步分析，即针对trace_id的结果，发现数量均来自某几个ip，
使用观测云来分析browser，也发现结果相对集中，100%的chrome浏览器。
我们根据当前chrome浏览器，使用观测云来分析browser_version，发现结果相对集中，100%的120.0.6099.71的浏览器。
初步结果
来自某组ip使用chrome浏览器的user agent对十几个电商网站的商品进行数据爬取，使用ip进行查询，原来是google bot，也就是谷歌机器人，通常是谷歌用爬虫来发现内容，然后将内容编入索引，也就是常见的seo的内容。
AB test 反向验证
我们如何验证谷歌机器人呢，这里我们针对英国做了ABtest，我们通过代码识别爬虫，在不阻断爬虫爬取数据的情况下，对这部分链路，不产生trace_id，这样后端就不应该观测到浏览器侧发出的大量的相同的trace_id.
这都是猜测，实际结果如何呢？我们通过观测云的数据分析工具进行对比，发现uk的trace_id从上千个骤降为0.
这就证明原来爬虫的背后竟然是谷歌。
写在后面的话
通过监控系统发现异常情况，基本上十几分钟接解决了问题。
主要通过全面证据收集，揭示了网站可能遭遇爬虫的情况，并使用观测云数据分析工具快速洞察数据。通过数据分析与AB test反向验证，在不影响爬虫的情况下验证了猜测，最终确认了谷歌机器人的身份。
总的来说，观测云的数据分析工具加速了问题的解决，快速、准确地体现了可观测性数据的理念。
更多内容欢迎查看识别搜索引擎机器人