大家好，春哥好，openrestry、nginx 有没有可以按照url统计实时流量和总流量的办法？ zhengxi...@163.com --
发件人： DeJiang Zhu发送时间： 2015-11-23 17:01收件人： openresty主题： Re: [openresty] 有没有可以按照url统计实时流量的办法？Hello，你在 access_log 里记录 body_bytes_sent，然后用脚本分析？如果你需要做请求相关的逻辑处理，也可以在 log_by_lua 里拿到 body_bytes_sent (ngx.var.body_bytes_sent)2015-11-23 13:05 GMT+08:00 zhengxi...@163.com <zhengxi...@163.com>: 大家好，春哥好，openrestry、nginx 有没有可以按照url统计实时流量和总流量的办法？ zhengxi...@163.com -- --
感谢回复：考虑过这种方式，但是这样做还是做不到实时性，log阶段是一个请求的最后阶段，比如我播放一个MP4的大文件，开始get，流量就已经在了，但是，要到播放完毕之后，才会走到Log阶段。有什么其他办法吗? zhengxi...@163.com 发件人： DeJiang Zhu发送时间： 2015-11-23 17:01收件人： openresty主题： Re: [openresty] 有没有可以按照url统计实时流量的办法？Hello，你在 access_log 里记录 body_bytes_sent，然后用脚本分析？如果你需要做请求相关的逻辑处理，也可以在 log_by_lua 里拿到 body_bytes_sent (ngx.var.body_bytes_sent)2015-11-23 13:05 GMT+08:00 zhengxi...@163.com <zhengxi...@163.com>: 大家好，春哥好，openrestry、nginx 有没有可以按照url统计实时流量和总流量的办法？ zhengxi...@163.com -- -- --
发件人： DeJiang Zhu发送时间： 2015-11-23 17:10收件人： openresty主题： Re: Re: [openresty] 有没有可以按照url统计实时流量的办法？Hello,如果实时性要求这么高的话，那么可以试试 body_filter_by_lua，这里可以拿到具体的下发内容https://github.com/openresty/lua-nginx-module/#body_filter_by_lua在 2015年11月23日 下午5:05，zhengxi...@163.com <zhengxi...@163.com>写道： 感谢回复：考虑过这种方式，但是这样做还是做不到实时性，log阶段是一个请求的最后阶段，比如我播放一个MP4的大文件，开始get，流量就已经在了，但是，要到播放完毕之后，才会走到Log阶段。有什么其他办法吗? zhengxi...@163.com 发件人： DeJiang Zhu发送时间： 2015-11-23 17:01收件人： openresty主题： Re: [openresty] 有没有可以按照url统计实时流量的办法？Hello，你在 access_log 里记录 body_bytes_sent，然后用脚本分析？如果你需要做请求相关的逻辑处理，也可以在 log_by_lua 里拿到 body_bytes_sent (ngx.var.body_bytes_sent)2015-11-23 13:05 GMT+08:00 zhengxi...@163.com <zhengxi...@163.com>: 大家好，春哥好，openrestry、nginx 有没有可以按照url统计实时流量和总流量的办法？ zhengxi...@163.com -- -- -- --
好的，回去研究下，不知道用这个统计流量，对性能损耗大不大？ zhengxi...@163.com 发件人： DeJiang Zhu发送时间： 2015-11-23 17:10收件人： openresty主题： Re: Re: [openresty] 有没有可以按照url统计实时流量的办法？Hello,如果实时性要求这么高的话，那么可以试试 body_filter_by_lua，这里可以拿到具体的下发内容https://github.com/openresty/lua-nginx-module/#body_filter_by_lua在 2015年11月23日 下午5:05，zhengxi...@163.com <zhengxi...@163.com>写道： 感谢回复：考虑过这种方式，但是这样做还是做不到实时性，log阶段是一个请求的最后阶段，比如我播放一个MP4的大文件，开始get，流量就已经在了，但是，要到播放完毕之后，才会走到Log阶段。有什么其他办法吗? zhengxi...@163.com 发件人： DeJiang Zhu发送时间： 2015-11-23 17:01收件人： openresty主题： Re: [openresty] 有没有可以按照url统计实时流量的办法？Hello，你在 access_log 里记录 body_bytes_sent，然后用脚本分析？如果你需要做请求相关的逻辑处理，也可以在 log_by_lua 里拿到 body_bytes_sent (ngx.var.body_bytes_sent)2015-11-23 13:05 GMT+08:00 zhengxi...@163.com <zhengxi...@163.com>: 大家好，春哥好，openrestry、nginx 有没有可以按照url统计实时流量和总流量的办法？ zhengxi...@163.com -- -- -- -- --
发件人： DeJiang Zhu发送时间： 2015-11-23 17:22收件人： openresty主题： Re: Re: [openresty] 有没有可以按照url统计实时流量的办法？Hello,这种方式应该不会特别小，毕竟每个输出块都得跑一遍你的统计逻辑当然，还是看你的代码逻辑，最好用火焰图工具来测量 :)2015-11-23 17:14 GMT+08:00 zhengxi...@163.com <zhengxi...@163.com>: 好的，回去研究下，不知道用这个统计流量，对性能损耗大不大？ zhengxi...@163.com 发件人： DeJiang Zhu发送时间： 2015-11-23 17:10收件人： openresty主题： Re: Re: [openresty] 有没有可以按照url统计实时流量的办法？Hello,如果实时性要求这么高的话，那么可以试试 body_filter_by_lua，这里可以拿到具体的下发内容https://github.com/openresty/lua-nginx-module/#body_filter_by_lua在 2015年11月23日 下午5:05，zhengxi...@163.com <zhengxi...@163.com>写道： 感谢回复：考虑过这种方式，但是这样做还是做不到实时性，log阶段是一个请求的最后阶段，比如我播放一个MP4的大文件，开始get，流量就已经在了，但是，要到播放完毕之后，才会走到Log阶段。有什么其他办法吗? zhengxi...@163.com 发件人： DeJiang Zhu发送时间： 2015-11-23 17:01收件人： openresty主题： Re: [openresty] 有没有可以按照url统计实时流量的办法？Hello，你在 access_log 里记录 body_bytes_sent，然后用脚本分析？如果你需要做请求相关的逻辑处理，也可以在 log_by_lua 里拿到 body_bytes_sent (ngx.var.body_bytes_sent)2015-11-23 13:05 GMT+08:00 zhengxi...@163.com <zhengxi...@163.com>: 大家好，春哥好，openrestry、nginx 有没有可以按照url统计实时流量和总流量的办法？ zhengxi...@163.com -- -- -- -- -- --
stap++吗？
这个用来自己调试还行，如果部署在线上，用来统计流量并上报，好像也不太合适。
zhengxi...@163.com 发件人： DeJiang Zhu发送时间： 2015-11-23 17:22收件人： openresty主题： Re: Re: [openresty] 有没有可以按照url统计实时流量的办法？Hello,这种方式应该不会特别小，毕竟每个输出块都得跑一遍你的统计逻辑当然，还是看你的代码逻辑，最好用火焰图工具来测量 :)2015-11-23 17:14 GMT+08:00 zhengxi...@163.com <zhengxi...@163.com>: 好的，回去研究下，不知道用这个统计流量，对性能损耗大不大？ zhengxi...@163.com 发件人： DeJiang Zhu发送时间： 2015-11-23 17:10收件人： openresty主题： Re: Re: [openresty] 有没有可以按照url统计实时流量的办法？Hello,如果实时性要求这么高的话，那么可以试试 body_filter_by_lua，这里可以拿到具体的下发内容https://github.com/openresty/lua-nginx-module/#body_filter_by_lua在 2015年11月23日 下午5:05，zhengxi...@163.com <zhengxi...@163.com>写道： 感谢回复：考虑过这种方式，但是这样做还是做不到实时性，log阶段是一个请求的最后阶段，比如我播放一个MP4的大文件，开始get，流量就已经在了，但是，要到播放完毕之后，才会走到Log阶段。有什么其他办法吗? zhengxi...@163.com 发件人： DeJiang Zhu发送时间： 2015-11-23 17:01收件人： openresty主题： Re: [openresty] 有没有可以按照url统计实时流量的办法？Hello，你在 access_log 里记录 body_bytes_sent，然后用脚本分析？如果你需要做请求相关的逻辑处理，也可以在 log_by_lua 里拿到 body_bytes_sent (ngx.var.body_bytes_sent)2015-11-23 13:05 GMT+08:00 zhengxi...@163.com <zhengxi...@163.com>: 大家好，春哥好，openrestry、nginx 有没有可以按照url统计实时流量和总流量的办法？ zhengxi...@163.com -- -- -- -- -- -- --
发件人： DeJiang Zhu发送时间： 2015-11-23 17:35收件人： openresty主题： Re: Re: [openresty] 有没有可以按照url统计实时流量的办法？Hello，2015-11-23 17:25 GMT+08:00 zhengxi...@163.com <zhengxi...@163.com>: stap++吗？火焰图的工具，在 nginx-systemtap-toolkit 和 stap++ 里都有实现，但只是这里面的部分工具https://github.com/openresty/nginx-systemtap-toolkithttps://github.com/openresty/stapxx 这个用来自己调试还行，如果部署在线上，用来统计流量并上报，好像也不太合适。我说的测量是指测量性能消耗线上跑这些工具也是挺合适的，毕竟线上才是最真实的场景（当然不是说的用来统计流量） zhengxi...@163.com 发件人： DeJiang Zhu发送时间： 2015-11-23 17:22收件人： openresty主题： Re: Re: [openresty] 有没有可以按照url统计实时流量的办法？Hello,这种方式应该不会特别小，毕竟每个输出块都得跑一遍你的统计逻辑当然，还是看你的代码逻辑，最好用火焰图工具来测量 :)2015-11-23 17:14 GMT+08:00 zhengxi...@163.com <zhengxi...@163.com>: 好的，回去研究下，不知道用这个统计流量，对性能损耗大不大？ zhengxi...@163.com 发件人： DeJiang Zhu发送时间： 2015-11-23 17:10收件人： openresty主题： Re: Re: [openresty] 有没有可以按照url统计实时流量的办法？Hello,如果实时性要求这么高的话，那么可以试试 body_filter_by_lua，这里可以拿到具体的下发内容https://github.com/openresty/lua-nginx-module/#body_filter_by_lua在 2015年11月23日 下午5:05，zhengxi...@163.com <zhengxi...@163.com>写道： 感谢回复：考虑过这种方式，但是这样做还是做不到实时性，log阶段是一个请求的最后阶段，比如我播放一个MP4的大文件，开始get，流量就已经在了，但是，要到播放完毕之后，才会走到Log阶段。有什么其他办法吗? zhengxi...@163.com 发件人： DeJiang Zhu发送时间： 2015-11-23 17:01收件人： openresty主题： Re: [openresty] 有没有可以按照url统计实时流量的办法？Hello，你在 access_log 里记录 body_bytes_sent，然后用脚本分析？如果你需要做请求相关的逻辑处理，也可以在 log_by_lua 里拿到 body_bytes_sent (ngx.var.body_bytes_sent)2015-11-23 13:05 GMT+08:00 zhengxi...@163.com <zhengxi...@163.com>: 大家好，春哥好，openrestry、nginx 有没有可以按照url统计实时流量和总流量的办法？ zhengxi...@163.com -- -- -- -- -- -- -- --
