监控

  • 一直以来,我们会在项目中,使用 APM 去监控应用的状况,分析性能等,这些工具很有效,而且不侵入业务,不需要埋点。

    然而,有些需求,是 APM 的监控满足不了的,比如应用业务指标

    监控模式

    目前,采集指标有两种方式,一种是『推』,另一种就是『拉』:

    推的代表有 ElasticSearch,InfluxDB,OpenTSDB 等,需要你从程序中将指标使用 TCP,UDP 等方式推送至相关监控应用,只是使用 TCP 的话,一旦监控应用挂掉或存在瓶颈,容易对应用本身产生影响,而使用 UDP 的话,虽然不用担心监控应用,但是容易丢数据。

    拉的代表,主要代表就是 Prometheus,让我们不用担心

  • 今天给大家来介绍一个报警工具,具体来说,是基于 Elasticsearch 的报警工具,假如你的日志是放在 ES 里面的,这个工具是你不错的选择。

    • 项目地址:https://github.com/Yelp/elastalert
    • 文档地址:https://elastalert.readthedocs.io/en/latest
    • 样例:https://github.com/Yelp/elastalert/tree/master/example_rules

    报警系统对于线上服务稳定性的保障作用不用多说,很多情况下,作为监控中最重要的输出环节,假如监控探测到了问题,却无法通知到我们,或者干脆通知错

  • 原文地址

    前端代码异常监控实战

    前言

    之前在对公司的前端代码脚本错误进行排查,试图降低 JS Error 的错误量,结合自己之前的经验对这方面内容进行了实践并总结,下面就此谈谈我对前端代码异常监控的一些见解。

    本文大致围绕下面几点展开讨论:

    1. JS 处理异常的方式
    2. 上报方式
    3. 异常监控上报常见问题

    JS 异常处理

    对于 Javascript 而言,我们面对的仅仅只是异常,异常的出现不会直接导致 JS 引擎崩溃,最多只会使当前执行的任务终止。

    1. 当前代码块将作为一个任务压入任务队列中,JS 线程会不断地从任务队列中提取任务执行。
    2. 当任务执行过程中出现异常,且异常没有捕获处理,则会一直沿着调用栈一
  • 其实今天的文章算是 APM 以及 Node.js 探针原理 的续篇,在去年介绍了一些原理之后,其实还有很多地方没有说清楚。

    不过,开头还是先介绍下分布式追踪。

    简单介绍

    分布式追踪在微服务领域非常重要,因为服务一旦多了,就涉及到性能瓶颈分析与线上问题排查、服务之间的关系梳理等等,这在单体应用的时候,非常简单,你甚至在本地就能解决,但是在一个比较大的公司内部,就需要团队与团队,部门与部门之间的合作才能解决,于是用传统这种的方案就很难解决了,在几十上百服务中一个个排查试试可真得累死人,而且找到问题的概率很低。

    那么,它跟我们说的 APM 有什么关系呢?APM 的作用是监控应用性能,但是当一个应用

  • 话说,在很久以前的程序界,是没有内存垃圾回收这种说法的,大家习惯于被 C 以及 C++ 的内存问题各种花式吊打。

    直到有一天,John McCarthy 大神 1959 年在 LISP 中实现了内存垃圾回收,大家才惊奇的地发现:『居然还有这种操作?』。
    正如 iPhone 出来之后重新定义了手机,内存垃圾回收的出现无异于重新定义了高级语言。

    好,接下来开始聊聊 Node.js 里面的 GC。

    Nodejs GC

    网上各种文章都会告诉你 Node.js 中类似于下面的这种内存垃圾回收原理[1][3]:

    在 Node 中,内存是 v8 负责管理的,而在程序的 heap 空间中,主要分为 New