直到最近，我用nginx 1.4.x与zebrafishlabs / nginx-statsd作为openresty的反向代理（是的，我知道，nginx后面的nginx是愚蠢的 – 请继续阅读）与以下位置nginxconfiguration：
location /track { statsd_count "tracker.track_$scheme" 1; proxy_pass http://localhost:10081/track; proxy_set_header Host $host; } ..和以下位置openresty（当然听port 10081 TCP）configuration：
location /track { content_by_lua_file 'conf/track.lua'; }
它工作。 请注意，我有几个这样的位置 – 这很重要，你会在稍后看到。
统计信息被推送到statsd并执行脚本。
最近我决定删除前端nginx，并单独使用openresty。
现在我正在使用openresty 1.5.12.1和zebrafishlabs / nginx-statsd编译成以下（明显的）configuration：
location /track { statsd_count "tracker.track_$scheme" 1; content_by_lua_file 'conf/track.lua'; }
但是在这个变化之后有时我的统计数据不会被推送到statsd 。
显然，如果我的lua脚本使用ngx.redirect lua命令结束执行，就会发生这种情况。 。
我尝试使用此configuration作为解决方法：
location /track { statsd_count "tracker.track_$scheme" 1; proxy_pass http://127.0.0.1/track-do; } location /track-do { content_by_lua_file 'conf/track.lua'; }
…但是我得到了非常奇怪的结果：
当我以这种方式改变我的“轨道”位置时，它开始正常工作 – 所有统计信息被推送到statsd，代码被执行。
..但在同一时间我的其他位置，“静态”，没有改变停止推动任何 statsd（！）。
我认为这与nginx处理阶段有关。 zebrafishlabs / nginx-statsd确实在最后的日志阶段进行了日志logging，而content_by_lua_file在内容阶段处理，而ngx.redirect则在我的脚本使用的文档中声明：“（…）终止当前请求的处理并且永不返回”。 但proxy_pass也处于内容阶段，当我在nginx中一起使用它们时，statsd指令被运行…
你能帮我解决这个问题吗？
2.你有使用openresty的zebrafishlabs / nginx-statsd吗？ 你是怎样做的？
PS我已经想过使用lonelyplanet / openresty-statsd ，它可能是一个工作的解决方法，但我将不得不把我的脚本内我所有的statsd用法，我不想让他们干净。
更新： lonelyplanet / openresty-statsd的方式也没有工作！？
最后，我做了一个解决方法 – 开始将访问日志写入文件，通过logstash和statsd输出来分析它们。 有用。