Note: organize articles from Tencent cloud senior front-end engineer Chen Jiaxing in Hello Serverless speech on Sharon Station in Shenzhen, lectures on the theme " NodeJS Runtime Monitoring", interested readers may be concerned about the public number, reply back " Serverless Shenzhen" to receive a lecturer speech PDF .
According to statistics, SCF of users, nodejs and Python users are up to, and I believe all of you should have a lot that NodeJS developers, we have had practice or are interested in surveillance, then it should be able to have their own harvest, and if you are not Node developers, it does not matter, many of the principles are the same, I hope you look at this from a different perspective topic, should be able to crash more spark. I share the theme of node JS runtime monitoring, I am here to spend a little time to say a few words why do monitoring.
The role of monitoring
I believe all of you are developers have considerable experience in the development, and we need daily monitoring? Definitely need! However, the actual monitor can do anything, there may be some students actually not too clear concept.
In fact, the role of monitoring is very simple, only two, the first is to identify problems, monitor data and charts linked with the general, when data and charts to show the same characteristics are not usual, we'll be able to know, could where the problem is.
And the other role is to solve the problem, in general, different issues will show different data characteristics, for example, memory was rising to the pinnacle of style to the cliff suddenly down, obviously a memory leak to the last memory consumption do the last service automatic restart feature, different feature data, it can be based on experience or reasoning, to find cause of the problem, and then verify and solve problems.
Why do we need to monitor simple finish it in terms of the share of the focus, the Node Runtiem level monitoring.
Let's take a look at conventional monitoring, regular monitoring to what it can be.
CPU usage - CPU usage percentage of
Memory Usage
The package and the package volume card traffic - Internet is basically all applications will communicate with the network
The runtime level of monitoring to be able to monitor what is it, the CPU usage time, including system and user time, the Node within the program memory usage, total memory consumption inside the package program, the actual memory usage
, Amount of free memory, and so on. Here there is a Event Loop Lag , behind me and then say something in detail.
The contrast is obvious, routine monitoring is an overview of the gross amount, and Runtime next level of monitoring is more detailed data, including the use of internal details of various aspects of the above, and more detailed data, developers will undoubtedly mean the easier to find and solve problems.
Writer Lu Xun once said, Talk IS Cheap, at The Show Me code . Here take a look at API , for the CPU , there are two API can obtain the relevant information, on the one hand cpuUsage , on the other hand is cpus .
Obviously all CPU information, why would it, in fact, to understand what's inside in two different libraries below you will find quite justified, the latter os library below, given the fact that the system CPU information, the former on process library, using the current process CPU information. So, from the runtime level monitoring point of view, which in fact is not rumtime level of concern, we need to focus on the former, the former returns similar {user: 24929: 65655, system } structure.
For memory, here also there are two API can obtain memory-related information, first memoryUsage interface, you can get to.
rss : the Node course of total memory footprint
heapTotal : total heap memory usage (has applied for down)
heapUsed：实际堆内存使用量
external：扩展等外部程序的内存占用量
而getHeapStatistics获取到的信息跟memoryUsage是有重合的，这里就不详细介绍了，就说两个点，一个是getHeapStatistics能获取到最大可用堆内存，这是memoryUsage没有返回的，至于node可用的最大内存，比较久之前的版本会有即使调整—max-old-space-size也只能到1.7G（64bit）的内存，目前使用的node的版本也都去掉了这个限制。
另一个是，在node10的getHeapStatistics 返回的数据多了两个值。number_of_native_contexts native_context 的值是当前活动的顶层上下文的数量。 随着时间的推移，此数字的增加表示内存泄漏。number_of_detached_contexts detached_context 的值是已分离但尚未回收垃圾的上下文数。 该数字不为零表示潜在的内存泄漏。
关于Event loop lag，Event loop lag直译就是事件循环延迟，我觉得可能叫异步调用延迟会比较合适。
这里我先放一张阮一峰老师用过的@busyrich的一张图，这张图说的是NodeJS的事件循环是怎样运作的，众所周知，NodeJS是单线程的，异步任务的调度在nodeJS的环境下是由LibUV库运作的，我也不再这里长篇大论地解释Event loop了，如果对此还不太清楚的同学可以到阮一峰老师的博客学习一下。这里只说一下这个延时到底是怎么来的，简单点来说，我们设定一个异步任务，在同步队列执行完之后就是马上执行，但是如果同步队列一直被阻塞的话，就是出现异步任务延时执行的现象，这种现象在一些CPU密集型的服务中会比较常见，如果你的服务的异步任务执行延时忽然不正常了，很可能就在某个地方出现了类似死循环的问题，同步任务把队列占满了，当然，死循环往往也会伴随内存泄露出现。
Event loop lag没有API能直接获取，不过测量起来也非常简单，这里放上简单的原理代码。直接利用setTimeout的实际执行时间和设定时间直接的差值，这份代码是我随手撸的用以说明原理的demo，实际使用上还要稍作加工，npm也有库能直接使用，也写得非常简单实用。
监控性能消耗
Runtime级别监控对比外部监控还有一个不一样，就是需要介入到Runtime中，不难想象，做数据的收集肯定是会对性能有一些影响的，可能我们就会担心会不会大幅影响性能呢，为此我特意在云函数上做了一些测试。
在耗时上，在一个比较简单的服务上，添加监控后发现，耗时的确是高了蛮多，但随着测试样本增大，平均耗时有一直下降的趋势，说明添加监控初始化时可能会消耗大概几十ms左右的时间，后面其实每次增加的耗时也就不到1毫秒。
在内存消耗上这种趋势会更加明显一些，需要一点点内存来缓存数据，次数一多起来，差别基本就趋于0了，所以综上所述，rumtime里面添加监控的性能消耗其实都是非常小的。
Runtime Profile
很多时候，监控数据更多用于发现问题，有些更复杂的问题，还得需要更详细的信息，这里就涉及到做Runtime的profile了。
从现实的场景出发，我们往往就像这个狼叔一样，后面的服务器都炸了，可是我们还是一脸懵逼的状态，我们往往发现问题是源于接口调用成功率降低，或者调用时间不正常地变长了，那出现这些问题的原因其实可能有很多，有可能是出现了逻辑死循环，有可能是内存泄漏，频繁触发GC，node的GC其实是非常消耗系统资源的，甚至GC也解决不了问题，导致内存耗尽，需要重启服务，那么出现这些问题的时候除了监控数据，还有什么东西能帮助我排查到底是哪里的问题呢？
这里就需要profile出场了，我会主要介绍两种profile，一个是heap dump，也就是内存快照，另外就是CPU profile。
估计很多开发者都会接触过heap dump，一般遇到疑似内存泄漏问题，第一反应就是打快照，这里就是快照导入到chrome devtool后的效果。
V8-profiler(v8-profiler-node8)
Heapdump
这两个包都可以做内存的heapdump，原理都是一样的，具体用法大家可以到对应的包下面看看用法。
得出的包导入到chrome后可以查看里面的内容了，主要有这几种模式：
Summary
Comparison
Containment
Statistics
summary就是一个总览，可以看到不同constructor创建的对象占用内存的细节。
Comparison 是调试时候最常用的一栏，用于对比不同时间点的快照之间的异同，一般来说，在问题发生前，和问题发生后进行快照，然后对比两者之间新增了哪些内容，就比较容易找出问题的原因。
Containment 视图允许您探索堆内容。此视图提供了一种更好的对象结构视图，有助于分析全局命名空间 (window) 中引用的对象以找出是什么让它们始终如影随形。使用此视图可以分析闭包以及在较低级别深入了解您的对象。
Statistics 就是以饼图的形式给出不同内容的占比。
CPU profile可以通过查看不同函数的运行占用CPU时间，看出什么地方占用了大量CPU时间，这就就是看cpu profile的入口，在调试工具窗口的右上角更多栏打开，more tools，javascript profile栏下，嗯，没错，我之前也在吐槽，为啥这个玩意要藏这么深，其实是有原因的，chrome的devtool也是不断在进化，而这个js profile的功能其实已经很大程度上整合到了performance tab之下了，performance tab下面的除了jsprofile外，还会dom渲染，图片加载等页面性能的细节，可惜这些特性对node也是没用的，所以我们目前还是在用的原来的这个工具
同样，通过V8-profiler可以获取CPU profile。
同样有几个视图：
Tree 则是通过调用树的顺序，列出不同函数的消耗时间。
这个就是charts视图下的时序火焰图，能更好地以时间为轴看到整个代码执行的过程。
Chart 通过时序火焰图的形式展示不同函数的时间占用。
能更好地以时间为轴看到整个代码执行的过程。
通过flamegraph 这个npm包也能根据CPU profile生成火焰图的SVG进而进行查看，通过火焰图，能非常直观地看出，到底是哪个进程消耗了大量的时间。
值得留意的是，这个火焰图跟前面说的charts视图下的时序火焰图是不一样的，这个火焰图会根据相同的函数进行归类，能比较直观的看出其中耗时最长的步骤
说了这么多，跟severless有啥关系呢，这些东西如何在SCF上实现呢？
云函数下的NodeJS Runtime监控
serverless的程序也需要做监控嘛，原理上面都讲了，收集的数据放到DB，profile放到cos，然后慢慢分析就好啦。
SCF一键开启吼不吼啊，在SCF上，性能分析都能自动化，惊不惊喜，意不意外，目前SCF上一键开启分析功能已经在开发中，具体会做些什么呢？
Serverless 虽然是不用关心服务器等基础设施，但是程序的性能还是要关注的，毕竟128m比256m便宜，更快的处理 & 响应速度也非常重要。
其次在云函数上，每次调用的确是相互独立的，可是容器和实例都是必须复用的，关于冷启动和热启动的话题也总是云函数的热门话题，如果函数频繁遇到冷启动，除了调度问题外，也有可能是代码本身的问题，比如函数调用多次后出现内存泄漏导致out of memory，也就是内存耗尽了，自然会触发重启，出现冷启动。
所以，根据云函数的特性，我们对收集的信息也会进行定制化，首先收集快照的时机会在函数执前跟执行后，这样就能很直观地看到函数执行过程中内存的变化，而cpu profile则会全过程收集，详细记录函数执行的全过程。
另外，我们还会输出函数调用过程中的GC log，以便进行进一步的收集。
总而言之，无论常规监控还是runtime级别的监控，都是帮助我们更好地把握程序的健康状况，对我们日常开发运维都非常重要。同时，经过测试，即使性能消耗比较高的runtime级别监控，其实其性能消耗也在控制范围以内，在不添加太多工作量的前提下，我们都应该尽量全方位地监控我们的程序。
另一方面，如何在发现除了问题的时候更好地解决问题，做Profile是最高效的方法。
The cloud function, or Severless , are doing their best to service for all developers, lowering the threshold of access and analysis to provide the most convenient monitoring and profile service.
Recommended activities
As an important enterprise database infrastructure, grasp the lifeblood of business. With the rise of cloud technology, a new era of database services has come from the "cloud database +" to "cloud + database." August 17, Tencent cloud ingenuity to bring a variety of new, redefined cloud database service. Tencent cloud scene more invited experts to discuss how to integrate cloud and the ability to make a database of AI become more "intelligent", "stable", "reliable", "security" and "cheap" Talk about the future of database usage scenarios, come click here to read the original reservation live it ~
