在 APM 中，保证及时并准确地获取应用的信息是非常重要的，这样才能保证应用出现问题时，我们可以高效地找到并解决问题。本文以之前提交给 Node.js 的 PR 为例，介绍如何实现一个 APM watchdog 来对应用进行监控。这个 PR 的实现思想来自我们在内部实现的 APM watchdog，但是因为逻辑复杂，目前暂时还没有时间去推进。
首先来看一下如何使用，然后看看一下如何实现。
new MemoryProfileWatchdog({
// 内存阈值，达到该阈值则采集堆快照
maxRss: 1024 * 1024,
maxUsedHeapSize: 1024 * 1024,
// 轮询间隔
interval: 1000,
// 快照写到哪个文件
filename: filepath,
});可以看到，启动一个 watchdog 非常简单，我们只需要配置一些监控的阈值和轮训时间。监控的数据是基于定时轮询的，因为没有相关的订阅发布机制，当 watchdog 监控到数据达到阈值时就会采集堆快照，因为这里是一个内存 watchdog，我们也可以实现 CPU watchdog，原理是一样的。接着看看实现，首先看 JS 层的实现。
class MemoryProfileWatchdog {
#handle;
constructor(options) {
this.#handle = new profiler.MemoryProfileWatchdog({
...options,
filename,
});
this.#handle.start();
}
stop() {
if (this.#handle) {
this.#handle.stop();
this.#handle = null;
}
}
}JS 层的实现非常简单，只是对 C++ 层的简单封装，所以直接来看 C++ 层的实现，我们忽略一些细节，只关注核心逻辑。
class ProfileWatchdog : public BaseObject {
public:
enum class ProfileWatchdogState { kInitialized, kRunning, kClosing, kClosed };
ProfileWatchdog(Environment* env, v8::Local<v8::Object> object);
~ProfileWatchdog() override;
static v8::Local<v8::FunctionTemplate> GetConstructorTemplate(Environment* env);
// 启动 / 停止 watchdog
static void Start(const v8::FunctionCallbackInfo<v8::Value>& args);
static void Stop(const v8::FunctionCallbackInfo<v8::Value>& args);
void Start(Environment* env);
void Stop();
// 提交一个任务
template <typename Fn>
void AddTask(Fn&& cb, CallbackFlags::Flags flags = CallbackFlags::Flags::kRefed);
// 处理一个任务
void HandleTasks();
// 启动一个定时器
void SetTimeout();
// 定时器回调，具体的逻辑由子类实现
virtual bool TimeoutHandler() = 0;
protected:
// 轮询间隔
uint64_t interval_;
private:
static void Run(void* arg);
static void Timer(uv_timer_t* timer);
// 子线程
uv_thread_t thread_;
uv_loop_t loop_;
// 主线程和子线程的通信结构体
uv_async_t async_;
// 定时器
uv_timer_t timer_;
// 任务队列
CallbackQueue<void> tasks_;
Mutex task_mutex_;
};ProfileWatchdog 实现了 watchdog 机制，具体需要监控什么数据由子类实现，比如内存 watchdog。
class MemoryProfileWatchdog : public ProfileWatchdog {
public:
MemoryProfileWatchdog(Environment* env,
v8::Local<v8::Object> object,
v8::Local<v8::Object> options);
static void Init(Environment* env, v8::Local<v8::Object> target);
static void New(const v8::FunctionCallbackInfo<v8::Value>& args);
bool TimeoutHandler() override;
private:
// 需要监控的数据指标
size_t max_rss_ = 0;
size_t max_used_heap_size_ = 0;
std::string filename_;
};有了基本的了解后，接下来看具体实现。
void ProfileWatchdog::Start(Environment* env) {
int rc;
// 初始化一个事件循环结构体
rc = uv_loop_init(&loop_);
// 初始化线程间通信结构体
rc = uv_async_init(&loop_, &async_, [](uv_async_t* task_async) {
ProfileWatchdog* w = ContainerOf(&ProfileWatchdog::async_, task_async);
w->HandleTasks();
});
// 初始化并启动一个定时器
rc = uv_timer_init(&loop_, &timer_);
rc = uv_timer_start(&timer_, &ProfileWatchdog::Timer, interval_, 0);
// 创建 watchdog 线程
rc = uv_thread_create(&thread_, &ProfileWatchdog::Run, this);
}当启动一个 watchdog 时就会执行 Start，Start 函数中主要初始化了线程间通信的结构体，然后启动一个定时器，最后创建一个 watchdog 线程。因为 Node.js 是单线程的，为了保证 watchdog 在 JS 繁忙时仍可正常工作，我们需要借助子线程。创建子线程后，子线程就会开始执行 ProfileWatchdog::Run。
void ProfileWatchdog::Run(void* arg) {
ProfileWatchdog* wd = static_cast<ProfileWatchdog*>(arg);
uv_run(&wd->loop_, UV_RUN_DEFAULT);
CheckedUvLoopClose(&wd->loop_);
}Run 的逻辑很简单，就是启动一个事件循环，因为我们前面启动了一个定时器，所以这个事件循环里就会定时执行定时器回调 ProfileWatchdog::Timer。
void ProfileWatchdog::Timer(uv_timer_t* timer) {
ProfileWatchdog* w = ContainerOf(&ProfileWatchdog::timer_, timer);
// 往主线程插入一个任务
env->RequestInterrupt([watchdog = std::move(w)](Environment* env) {
// 执行定时器的逻辑，由具体的 watchdog 实现，返回 true 表示重启定时器，否则监控到此为止
if (watchdog->TimeoutHandler()) {
// 往子线程里插入一个任务，该任务是重启定时器
watchdog->AddTask(
[watchdog = std::move(watchdog)]() { watchdog->SetTimeout(); });
}
});
}Timer 中通过 env->RequestInterrupt 往主线程插入一个任务，因为有些代码是不能在子线程里执行的，另外 RequestInterrupt 可以保证在 JS 繁忙或阻塞在事件驱动模块时仍然可以执行我们的任务，那么这个任务具体做什么呢？看看内存 watchdog 的 TimeoutHandler 实现。
bool MemoryProfileWatchdog::TimeoutHandler() {
bool reached = false;
if (max_rss_) {
size_t rss = 0;
uv_resident_set_memory(&rss);
if (rss >= max_rss_) {
reached = true;
}
}
if (!reached && max_used_heap_size_) {
Isolate* isolate = env()->isolate();
HeapStatistics heap_statistics;
isolate->GetHeapStatistics(&heap_statistics);
if (heap_statistics.used_heap_size() >= max_used_heap_size_) {
reached = true;
}
}
// 内存达到阈值，采集快照
if (reached) {
HeapProfiler::HeapSnapshotOptions options;
options.numerics_mode = HeapProfiler::NumericsMode::kExposeNumericValues;
options.snapshot_mode = HeapProfiler::HeapSnapshotMode::kExposeInternals;
heap::WriteSnapshot(env(), filename_.c_str(), options);
// 采集完快照，停止 watchdog
return false;
}
return true;
}TimeoutHandler 就是获取主线程的内存信息，并判断是否超过了我们配置的阈值，是的话则采集堆快照并停止 watchdog，防止采集过多的重复信息，我们也可以改成隔久一点再开始重新监控，而内存如果没有超过阈值，则重启定时器，等待下一轮判断。从前面的代码可以看到，如果没有达到阈值，我们会调用 AddTask 往子线程插入一个任务。
watchdog->AddTask([watchdog = std::move(watchdog)]() {
watchdog->SetTimeout();
});看一下 AddTask 的实现。
template <typename Fn>
void ProfileWatchdog::AddTask(Fn&& cb, CallbackFlags::Flags flags) {
auto callback = tasks_.CreateCallback(std::move(cb), flags);
{
Mutex::ScopedLock lock(task_mutex_);
// 追加一个任务
tasks_.Push(std::move(callback));
}
// 通知子线程有任务处理
uv_async_send(&async_);
}
AddTask 往子线程的任务队列中插入一个任务，并通知子线程处理，接着看看子线程如何处理任务。
void ProfileWatchdog::HandleTasks() {
while (tasks_.size() > 0) {
CallbackQueue<void> queue;
{
Mutex::ScopedLock lock(task_mutex_);
queue.ConcatMove(std::move(tasks_));
}
while (auto head = queue.Shift()) head->Call();
}
}HandleTasks 会逐个任务处理，也就是执行一个个函数，我们刚才插入的函数如下。
void ProfileWatchdog::SetTimeout() {
uv_timer_start(&timer_, &ProfileWatchdog::Timer, interval_, 0);
}也就是重启定时器，这样就开始等待下次超时，直到触发了阈值。
这就是 APM watchdog 的实现原理，核心思想是利用子线程和 env->RequestInterrupt 机制，保证我们对目的线程进行相对实时的监控（取决于设置的轮询时间），并在发现问题采集相关信息来协助我们排查问题，利用这个思路，我们可以实现不同类型的 watchdog 来解决不同的问题，比如 CPU watchdog 可以在 JS 死循环时采集 CPU Profile 信息帮助我们找到有问题的代码，本文就分享到这里，最后贴上目前的实现 PR（见文章末尾）。因为涉及到多线程和 Node.js 内部的一些知识，实现起来有很多地方需要考虑的，希望后面有时间继续推进。
PR：https://github.com/nodejs/node/pull/45714
免责声明：
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的，并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据，供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
