Datadog APM跟踪 - 当调用时间的一小部分是总LAMBDA时间的一小部分时如何调试？
我最近一直在努力将datadog函数级跟踪添加到AWS lambda函数（使用dd-trace库），但最终遇到了一些具有讽刺意味在性能回归中，由于性能的巨大影响，这些更改无法实际部署到生产中。
在下图中，给定的lambda的调用为120ms，但是lambda本身运行于1.34S相同颜色的紫色棒悬停在）。不过，在查看日志时，实际的lambda处理程序代码在该120ms标记上完成，并且内置的lambda日志中的结束请求才显示在<<<<<<<<<<<<代码> 1.34S 标记，在相关处理程序代码的末尾和该1.34S窗口之间绝对没有记录。
这使我感到困惑的是那个黑洞的时间（在添加任何DD-Trace代码之前，这些差距 较小，但从来没有完全不存在。有关如何调试的任何提示这些差距并最终消除它们的地方将不胜感激
。 i.sstatic.net/mygbq.png“ alt =“ datadog trace”>
I've recently been working on adding datadog function level traces to AWS lambda functions (using the dd-trace library), but ended up in a bit of an ironic situation where the instrumentation of said functions has resulted in a performance regression, that makes these changes unable to actually be deployed into production due to how drastically performance is impacted.
In the image below, the invocation for a given lambda is 120ms, and yet the lambda itself runs for 1.34s the purple bar of the same colour, right above the one being hovered over). When looking at the logs though, the actual lambda handler code is complete at that 120ms mark - and the built in lambda logs saying END REQUEST doesn't show up until the 1.34s mark, with absolutely nothing logged between the end of the relevant handler code, and that 1.34s window.
This has left me stumped on where that black hole of time is (before adding any of the dd-trace code, these gaps were much smaller, but never completely non-existent. Any tips on how to debug where those gaps from, and ultimately eliminate them, would be greatly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论