Skip to main content
QUICK REVIEW

[论文解读] FaaSter Troubleshooting -- Evaluating Distributed Tracing Approaches for Serverless Applications

Maria C. Borges, Sebastian Werner|arXiv (Cornell University)|Oct 7, 2021
Software System Performance and Reliability参考文献 17被引用 11
一句话总结

本文提出了一种故障可观察性模型,并评估了两种分布式追踪方法——开发者驱动和平台支持——在无服务器应用中提升故障排查能力的效果。结果表明,两种方法均能显著降低故障模糊性,且性能开销极小,尤其是开发者驱动的追踪,其延迟可忽略不计,因此在平台追踪不可用时,推荐在生产环境中使用。

ABSTRACT

Serverless applications can be particularly difficult to troubleshoot, as these applications are often composed of various managed and partly managed services. Faults are often unpredictable and can occur at multiple points, even in simple compositions. Each additional function or service in a serverless composition introduces a new possible fault source and a new layer to obfuscate faults. Currently, serverless platforms offer only limited support for identifying runtime faults. Developers looking to observe their serverless compositions often have to rely on scattered logs and ambiguous error messages to pinpoint root causes. In this paper, we investigate the use of distributed tracing for improving the observability of faults in serverless applications. To this end, we first introduce a model for characterizing fault observability, then provide a prototypical tracing implementation - specifically, a developer-driven and a platform-supported tracing approach. We compare both approaches with our model, measure associated trade-offs (execution latency, resource utilization), and contribute new insights for troubleshooting serverless compositions.

研究动机与目标

  • 为解决无服务器应用中可观测性有限的问题,即由于托管服务的复杂分布式组合,故障难以隔离。
  • 开发一种故障可观察性模型,用于表征在无服务器函数组合中不同组件间故障的可见性。
  • 实现并评估两种追踪方法——开发者驱动和平台支持——以改善无服务器环境中的故障诊断。
  • 量化可观测性提升与性能开销(延迟、资源使用)之间的权衡,针对真实世界的无服务器工作负载。
  • 为开发者和平台提供商提供可操作的见解,以选择和部署有效的无服务器故障排查追踪解决方案。

提出的方法

  • 提出一种无服务器故障可观察性模型,根据日志和追踪中证据的一致性与模糊性对故障可见性进行分类。
  • 设计并实现一种基于 OpenWhisk 的开发者驱动追踪原型,通过自定义代码注入实现,支持在应用代码内端到端收集追踪信息。
  • 通过在 OpenWhisk 控制器和调用节点中注入追踪代码,设计一种平台支持的追踪方法,实现跨函数调用的自动追踪捕获。
  • 采用一个真实世界的电商批量导入用例,包含多个函数调用和外部服务,以在真实场景下评估两种方法。
  • 通过测量执行延迟、CPU 和内存使用率以及追踪完整性,对比性能与可观测性之间的权衡。
  • 实验中采用 100% 采样率,以评估最大可能的性能开销,模拟性能影响的最坏情况。

实验结果

研究问题

  • RQ1如何系统性地表征无服务器应用中的故障可观察性,特别是故障可见性与模糊性?
  • RQ2在无服务器平台上,实现开发者驱动与平台支持的分布式追踪在性能上存在哪些权衡?
  • RQ3分布式追踪在多大程度上减少了函数组合中日志的故障模糊性与不一致性?
  • RQ4在真实无服务器部署中,不同追踪方法对执行延迟和资源使用率有何影响?
  • RQ5在采用追踪技术进行故障排查时,对开发者和平台提供商具有哪些实际影响?

主要发现

  • 开发者驱动追踪引入的性能开销可忽略不计,平均执行时间增加为 0 秒,最大增加 3 秒,表现出极高的效率。
  • 平台支持追踪的性能成本更高,平均执行时间增加 2 秒,最大增加 82 秒,主要由于核心组件中采用 100% 采样和代码注入。
  • 平台支持方法导致可测量的资源消耗,额外占用 128 至 256 MB 内存,并可能使每个函数的可用运行时间减少 1–2 秒。
  • 尽管存在性能开销,两种方法均显著提升了故障可观察性,有效降低了跨函数边界的故障证据模糊性与不一致性。
  • 当平台追踪不可用时,推荐在生产环境中使用开发者驱动追踪,因其开销极小且可观测性优势显著。
  • 本研究证明,分布式追踪是提升无服务器应用故障诊断能力的可行且有效方案,尤其适用于复杂、多函数的组合场景。

更好的研究,从现在开始

从论文设计到论文写作,大幅缩短您的研究时间。

无需绑定信用卡

本解读由 AI 生成,并经人工编辑审核。