Rust Tokio - 监控停滞的任务答案

【问题标题】：Rust Tokio - monitoring stalled tasksRust Tokio - 监控停滞的任务
【发布时间】：2021-01-13 06:42:52
【问题描述】：

我正在 prod 中运行一个 rust Tokio 应用程序。在上一个版本中我有一个错误，一些请求导致我的代码进入无限循环。

发生的情况是当进入无限循环的任务卡住时，所有其他任务继续正常工作并处理请求，直到停顿任务的数量高到足以导致我的程序无响应。

我的问题是我们的监控系统花了很多时间来识别出问题。例如：响应 kubernetes 健康检查的任务运行良好，但我无法确定我的系统中的任务已停止。

所以我的问题是在这种情况下我是否有办法识别和提醒？

例如：如果我能找到定义任务超时的方法，并且如果它在 X 秒/毫秒后没有返回到调度程序 - 此任务将标记为停止，这对我来说将是一个很好的解决方案。

【问题讨论】：

标签： rust monitoring rust-tokio

【解决方案1】：

在这里使用tracing 可能是一个选项：在issue 2655 之后，每个tokio 任务都应该有一个跨度。除了tracing-futures，这意味着您应该在每次进入或暂停任务（see this example）时获得一个跟踪事件，通过添加相关数据（例如任务ID/请求ID/...）然后您应该能够提供将此信息传递给分析工具以了解：

任务被阻止（被恢复然后再也没有挂起）
如果您添加自己的跨度，则“用户空间”跨度从未退出/关闭，这可能意味着它卡在非阻塞循环中（这也是一个问题，尽管不太严重）

我认为这就是它的范围：正如issue 2510 所指出的，tokio 尚未使用它生成的跟踪信息，因此没有提供“内置”自省工具。

【讨论】：

感谢您的回答-这听起来很酷，但是如果我理解正确-此解决方案需要监视由跟踪创建的日志文件，并且需要记录任务处理/暂停的所有事件.或者我可以在我的应用程序中创建一个任务来处理这些事件而不是使用日志吗？
tracing 实际上是一个 instrumentation 系统，尽管它有简单的方法将其用作日志系统（如果只是为了便于迁移），您应该能够构建您的拥有自己的订阅者来处理您希望的这些事件。看看tracing_subscriber 和 OpenTelemetry 或 Gelf 订阅者，tracing-gelf 看起来特别相关，因为它通过将 gelf Logger 生成到单独的任务中来工作。