On Tue, Jul 12, 2016 at 12:29:56PM +0800, Ruoshan Huang wrote: > Indeed I only care about 20 status code or so, like 400, 401, 403 (I have > been bitten many times by treating those codes as 404 :( ), and 50x also > helps a lot in our alerting system as a first method for diagnosing abnormal > things. By and large, the "big" array does waste a lot of memory (I know), > but that's the fast way I try to make a demo.
I have no problems with demos, don't worry :-) Most often a small piece of code or a patch speaks better than a long paragraph! > >> Currently I have to do the accounting on the log file. but on a high > >> load > >> machine, it cost a lot to processing the log itself. > > > > Well, on my local machine, halog takes only 0.98 second to process a 2.3 GB > > file and give me the status distribution (8.4 million lines). That's 2.4 GB > > per second or 8.6 million lines per second. This is not something I would > > consider as a high load, because if you rotate your log files past 2 GB, > > you'd eat less than 1 second of CPU for each analysis. It's probably less > > than what can be lost per hour due to cache misses when adding 4kB per > > proxy to a large config in fact :-/ > > havn't used `halog` for parsing, will try it. but I prefer collecting metrics > remotely, there are many hosts and stat sock can dump the stick table (stick > table is realy amazing, thank you for developing this!) That could possibly be ssh $host "halog -st < /var/log/haproxy.log" or anything like this. > At first I was thinking whether we could track the response status in stick > table, then it may be neat. but currently there isn't `http-response > track-sc?` directive. can it? Interesting. No it isn't, just because I think we never found a valid use case for it. It's possible that you found the first one in fact :-) > Using a dynamic ebtree will eventually recreating a tracking table or > something like the stick table, so same question here: is it possible do the > stick counter tracking in response phase, so more things can be tracked. I think it would be a nice approach, we'd be reusing existing infrastructure and possibly even take routing decisions based on certain stats (eg: # of 404 per second) suggesting routing to a cache or a backup instance. There's also something I'm not happy with regarding the stats approach, it is that it would be the first set of stats counters which are not dumped into "show stats" but would instead require their own command. And as you guessed, dumping 500 empty fields on each frontend/backend line is not something even remotely imaginable. Please take a look at how track-sc are added to http-request, look for "ACT_ACTION_TRK_SC0" in proto_http.c, you'll find your way through it, and see if you can duplicate this to the response. There should be a few tricks such as indicating that you want data present in the response instead of the request, but nothing terrible. I think you shouldn't have too many issues adding support for this. Please note however that by definition it will not count haproxy's own status codes but only the ones it is forwarding. But in general that shouldn't be an issue as when you want such details you're more interested in the status codes generated by the application than the ones generated by haproxy. Willy
