how to tune Nginx acted as reverse proxy for Kibana
缘起
老套路,公司在用 AWS 上的 Elasticsearch 服务,连带的就有一个 Kibana,按照官方的说法,Kibana 这块的密码保护,可以用 AWS 的 Cognito 服务来做,或者是用前置 Nginx 反向代理的方法来做。
但是,AWS 大中国区并没有 Cognito 服务,所以,没得选,只能采用在 Kibana 前置 Nginx 反向代理的方法来实现简单权限控制了。
过程
官方有两篇文章( https://aws.amazon.com/premiumsupport/knowledge-center/kibana-outside-vpc-nginx-elasticsearch/ 和 https://docs.aws.amazon.com/en_us/elasticsearch-service/latest/developerguide/es-kibana.html#es-kibana-proxy )涉及到了这种情况下怎么配置 Nginx,于是,我的配置文件的第一版几乎完全来自于这个配置的适当修改。
发现问题
最早发现问题是在我司办公室的网络环境下,感觉首先进入的那个页面非常慢,然后,刷新 15 分钟数据偶尔也会感觉有些慢,婶婶可忍叔叔不可忍,于是打开浏览器的各种 develop tools 来看下,发现更新数据是抓的一个 .json 的文件,有四兆多,于是考虑能否在 Nginx 端启用压缩呢?
初步解决
于是否,就在 Nginx 处打开了 gzip 压缩,当然尤其要在压缩的文件类型中指定上面发现的 .json 文件的 mime 类型:application/json。重启 Nginx,再次再刷新数据的时候,发现只传输了几百 K,速度快多了。
进一步解决
前面有提到,除了刷新数据慢,还有一个首页进入非常慢,接着就要解决这个非常慢的问题。同样用 develope tools 抓包看,发现首页进入的时候需要加载三个非常大的 .js 文件(十几兆的 vendors.bundle.dll.js 以及几兆的 commons.bundle.js 和 kibana.bundle.js),于是乎,在 Nginx 启用压缩的 mime 类型中加入 .js 文件的 mime 类型,重启 Nginx。再次刷新首页,发现秒入。又一个问题解决了。
还可以尝试
前面看到,导致慢的原因无非是几个大家伙要下载导致的,启用服务器端压缩固然能减少数据传输量来起到优化用户体验的目的,但是,如果我们启用缓存是不是更能起到优化的效果呢?要知道, .js 可很有可能是静态文件,非常适用于缓存。
但是这一步我最终没有这样去做,原因有三:
- 我并不能百分百保证这三个 .js 文件不是动态生成的(毕竟现在有很多“伪静态”的东西)
- 我并没有更多的时间
- 目前的效果已经到了可以接受的程度了
所以这一步就留到以后有时间的时候研究吧
附上 Nginx 配置
1 | server { |