nginx 直接向 logstash 发送 JSON 格式日志

通过 nginx 的 log_format 指令可以很容易直接就在 nginx 这里就生成(几乎是)JSON 格式的消息发送到 logstash

log_format  logstash '{"@timestamp":"$time_iso8601",'
                     '"@version":"1",'
                     '"host":"$server_addr",'
                     '"client":"$remote_addr",'
                     '"size":$body_bytes_sent,'
                     '"domain":"$host",'
                     '"method":"$request_method",'
                     '"url":"$uri",'
                     '"status":"$status",' # status 有可能会是以0开头,比如“009”这样的状态码,因此不能以数值形式保存,需要加括号存为字符串
                     '"referer":"$http_referer",'
                     '"user_agent":"$http_user_agent",'
                     '"real_ip":"$http_x_real_ip",'
                     '"forwarded_for":"$http_x_forwarded_for",'
                     '"responsetime":$request_time,'
                     '"upstream":"$upstream_addr",'
                     '"upstream_response_time":"$upstream_response_time",'
                     '"cache_fetch":"$srcache_fetch_status",' # 统计srcahe缓存命中率
                     '"cache_store":"$srcache_store_status"}';

但是这个还是会有问题,因为中文字符编码的原因,有时候 url 或者 referer 头里面可能会出现”\x”这样的跳脱字符,导致 JSON 解析失败,这个时候需要在 logstash 的 filter 里面再加上配置

filter {
  if [type] == "nginx-access-syslog" {
    mutate {
      gsub => [
        # replace '\x' with '\\x', or json parser will fail
        "message", "\\x", "\\\\x"
      ]
    }
  }
}

把”\x”替换为”\\x”。(这个方法不通用,只对”\x”做了处理,但一般应该也只有”\x”会出现了。。。)
然后我们可以用 kibana 画图了,以上收集的参数还算比较丰富了,可以做出很不错的 dashboard 了

Android 系统更新,愿你一直这么蠢下去

最近 Android 6.0 版本发布了,而我正好有一个Nexus 7 2013,但我却还无法更新它的系统,因为 Google 的傻逼 OTA 更新方式,服务器那头拒绝给我检测到更新。

这当然不是我第一次遇到这种情况了,以前的每次系统更新也是一样,Android 升级的主动权完全不由用户掌握。

Android 系统更新本来就是个老大难的问题,但我实在想不出 Google 的人是怎么想的,就算是官方支持的设备其实也无法及时更新到最新版本的系统。

  • 如果 Google 是想采用灰度发布,那么其实根本就不应该发布。这么做只不过是先拿一部分用户直接来当小白鼠来测试你的系统而已,所有用户的设备都该被当成重要的,你应该事先完全测试好。
  • 如果 Google 是因为服务器带宽资源不足够以立即对所有用户分发,我其实不太相信这种原因。
  • 为甚么不提供方式让用户自己使用其它方式下载安装包手动更新

以上,Apple 实在做得比 Google 好得多,新版本发布后可以立即更新,无论是 OTA 还是自己本地下载更新。

为什么我讨厌引用第三方 Javascript 的网站

很多网站都喜欢在自己网站里面用到其它网站提供的第三方 javascript 库,比如 jQuery,为什么?因为有些老的教程告诉他:

  1. 第三方镜像网站做了CDN,速度访问会比较快。
  2. 用户很可能已经通过其它也是引用了那个 JS 的另外一个网站访问过它了,再次访问它的时候速度就更快了
  3. 节省自己的带宽流量
  4. 浏览器和服务端都有同一域名下的资源访问并发限制,引用其它网站的 JS 就可以规避这个问题

可我不是很认可以上的理由,因为:

  1. 你的网站的可用性打了折扣,因为使用第三方 JS库,用户需要正常访问你的网站,同时他还必须要能够访问那个第三方网站才行。而当用户只是无法访问那个第三方网站的话,你的网站是挂了(视具体功能而定),而且你几乎还无能为力(有信心那么快修改所有页面里面的引用代码吗?)。
  2. 也许用第三方静态资源会使得用户加载速度快点,但没有那么明显,并且也不是决定性因素。静态资源的加载本来就快,如果你的网站不是放在特别垃圾的线路,这并不会是什么问题。影响网站速度的还是动态内容这部分。
  3. 流量也不重要,如果你的网站本来流量就小,自己提供那些静态资源和用外部引用的区别不大;如果你的网站流量大,那是好事,意味着流量成本绝不是你该头疼的事情。
  4. 不安全,引用的外置 JS可能会被劫持,就像百度的被劫持用作攻击 Github 了一样。
  5. 隐私保护。第三方网站可以借此跟踪用户,也可以拿走本该只属于你自己的网站访问统计信息。
  6. 自己弄几个专门分发静态资源的站点同样更容易解决同源加载的问题。

貌似被 GFW 认证了

最近这段时间在自己 VPS 上面搭建的 PPTP VPN 连接每过几分钟都会中断,试验了下,发现是 1723 端口每隔一段时间都会被屏蔽。
这应该就是 GFW 在屏蔽 VPN 吧,也许我该换个 IP 地址了(我不想换做用别的类型 VPN,因为 PPTP 的客户端是最容易的,基本上任何 OS 上面都是内置支持的)。
最后我想说:真鸡巴恶心,肏你妈屄的,早点去死吧!

也谈 12306 泄密

12306 官方把这次密码泄露事件推给了第三方刷票工具,但也有安全专家把原因归结为“撞库”。
但我认为在这次事件中,12306 是负有责任的:
1、已订票单过于容易被取消。事实上就是登录进去账号之后点几下就能把订单给取消了,完全没有进行身份验证——比如短信形式的二次验证。
2、www.12306.cn 是一个反人类的网站,变相在鼓励用户使用第三方工具。我之前已经说过这个垃圾网站有多恶心。不管这次密码泄露是第三方工具还是“撞库”,这都应该给 12306 和用户敲响警钟,12306 应该认真考虑做个可用的网站出来,而用户也该意识到使用第三方工具的风险。
3、12306 没有任何措施保护已经失窃的账号。如果我没有理解错的话,12306 不是一个普通的商业网站,是依靠税收建立的,意味着其实每个公民都有“投资”,但是结果是 12306 这帮人对“投资人”都没有一丁点责任心,至少你应当可以把那些账号锁定,要求用户以其它更安全的方式验证身份后解锁。(当然我不是在说商业网站在这种情况下就应该撒手不管)。结果呢?就是有用户被他人给退票了。
总而言之,12306 就是个只会推卸责任,没有一点安全意识的人在管理。你要是以前不懂,但俗话说得好“吃一堑,长一智”,以后也该聪明点了,但是现在我看不出它有任何改进。

Fuck Google Fonts

不是因为 Google 在国内被屏蔽而导致诸多网站加载 Web Fonts 或者 JQuery 缓慢。

让自己的网站去调用第三方网站的东西,本来就是个傻逼主意。说实话吧,自己的网站上放个压缩的 JQuery 或者字体能有个多大的事?!别说用第三方的能省流量、加载速度,事实是这些都是极其小的影响。既然都喜欢让 Google 通过 js 去知道你的网站访问情况,干脆你不就把网站全交给 Google 算了!

Cloudflare universal SSL

Cloudflare 最近宣布的 universal SSL 对免费用户也开放,这真的是个不错的功能,即便很多人不相信 Cloudflare,认为这是史上最大的中间人攻击,但是既然都用了 CDN,你还能去想那么多么?我认为这个功能对于个人或其它非关键站点来说还是很实用的,个人而言,主要是看中了一点——使用 CDN 还可以隐藏自己的服务器地址,避免一些信息的泄露。

但是不得不说下,Cloudflare 那头颁发证书的速度实在是太慢了,虽然原因很明显——有很多站点要逐个颁发,但。。。还是未免也太慢了点,只能先暂停掉了。