Introduction
elastic-apm-node 提供了非常友好的定制化支持,本篇将示范如何为 express 框架添加路由 patch,以满足信息上报的优化。
根据上一篇《Node.js APM 产品调研》的市场调研结果,笔者更青睐 Elastic APM 这个开源产品,故决定带来它的一篇专题介绍。
尽管团队已经开始试用,但踩坑时间较短,与其编写测评,不如先带大家走进这个项目,剖析个别令人感兴趣的技术点。
服务进程登场时往往“蓄势而发”,犹抱琵琶半遮面,真正的服务端口跑起来之前做了太多准备工作,然而落幕工作常被人草草了之。
如何让进程自然结束,这本是 hello world 级的基础内容,却有很多项目忽视了这一步的必要性以及重要性。
目前使用 PM2 作为进程管理的项目仍占多数,有相关意识的朋友使用 pm2 reload
让进程“平滑”重启,但这就不需要额外的代码处理了吗?
举个例子,未捕获的异常导致服务强行退出时,是不是有可能进程尚未记录异常日志、请求执行到了一半、甚至中断了更复杂的业务工作?PM2 只能截住新的请求,旧的请求是否彻底执行完毕,仍需要业务自己判断。
下面我们先抛开 PM2 ,聊聊基本的进程退出需要哪些工作。首先我们从未捕获的异常说起。
部署 RabbitMQ、MongoDB 或其他服务的单节点,有时会将 bind_ip 之类的设置写作 127.0.0.1。然而在 Debian 系统这么操作可能就给自己挖了“坑”,不管你有没有遇到过 host
相关奇怪的部署问题,来看作者的一波填坑历程吧~
在 Debian 系的 Linux 发行版中,/etc/hosts
中前两行默认配置如下,其中 myhostname
即 /etc/hostname
指定的本机名称,可通过 hostname
指令查看。
1 | 127.0.0.1 localhost |
第二行配置将本机 host 指向了 127.0.1.1
,这又能对软件的安装造成什么影响呢?请看下面的例子。
svn 给笔者的一大印象就是非常容易产生冲突,特别是项目加入新人后,由于初期没有强硬地制定规范,导致后期合并代码时灾难连天。决定在此分享这些“亡羊补牢”的规则,也算是避免 svn 产生合并冲突的一点经验。
原始需求是通过 nginx 在请求链接中增加一个固定参数 custom_param,方法很简单,在 location 中重设 $args
。
1 | # in location xxx |
顺便说一下,即使链接中没有参数也不影响一般服务端解析,符号?
会自动加上,如上例子 proxy_pass 后会路径将变成 http://remote_host/xxx?&custom_param=test。
但问题是在服务器如此配置 nginx 后,custom_param 参数并没有如约发给 remote_host……
有关被 nginx 官方自我批判的 if 语句,《If Is Evil》—— 着实应成为每位开发者初次使用 nginx if 之前必读的文章。
即使笔者一年前就开始接触使用 nginx 和 if 的组合做 url 跳转,但涉及的功能太简单,一直没能见识到它的真面目。直到近期在多个 if 内处理 proxy_pass 时,噩梦果真就降临了……希望大家仔细阅读上面的文章,引以为戒。
如果想快速知道为什么 “if is evil”,以及如何避免被坑,可以向下阅读一探究竟。