Clark! thanks for joining this bug - I'm still not 100% clear on that - you may need to educate me or perhaps other would have a stronger baseline knowledge here. The only log format I'm aware of from apache is request/response logging [1]
Our storage server logs are based on something like that [2], e.g.
... we have extra fields - so if you have specific "preexisting tools to parse and point out interesting things" ideally we could add something specific we could test against?
The proxy request log lines are different [3], e.g.
There's some historic reasons for that format, and AFAIK most deployments both need and depend on that format - it's the only one I ever want or need for access logs in production - we even have special documented facilities to make it easy to segregate access logs [4] - but like on my *development* machine like I just log *both* formats
... so there's no reason we wouldn't go ahead and configure Swift on devstack to log the requests in just the format you want wherever you need it to log! But I'd be happy to prioritize here if the default documented access request/response log format in the proxy is suitable for you.
But it's not clear to me how either of these formats is relevant for like the *interesting* messages?
e.g.
Aug 30 17:30:59 hummingbird swift: ERROR with Account server 10.0.0.1:1001/sdb re: Trying to PUT /a/: #012Traceback (most recent call last):#012 File "/vagrant/swift/swift/proxy/controllers/base.py", line 1532, in _make_request#012 headers=headers, query_string=query)#012 File "/vagrant/swift/test/unit/__init__.py", line 1022, in connect#012 raise HTTPException()#012HTTPException (txn: tx16901d6ed06b4696914e7-0057c5c2d1)
e.g.
Aug 30 17:30:18 hummingbird swift: Quarantined object /tmp/tmpjU1T8M/tmp_test_object_auditor/node/sda/objects/0/a43/615cd4810e0d969889af154f7b02ba43/1472578218.87833.data: metadata content-length 10 does not match actual object size 0
^ do you have any requirements, thoughts or opinions on the "format" of unstructured messages that *aren't* request/response logging?
Clark! thanks for joining this bug - I'm still not 100% clear on that - you may need to educate me or perhaps other would have a stronger baseline knowledge here. The only log format I'm aware of from apache is request/response logging [1]
Our storage server logs are based on something like that [2], e.g.
Jul 11 17:31:15 saio object-6030: 127.0.0.1 - - [11/Jul/ 2016:17: 31:15 +0000] "PUT /sdb3/994/ AUTH_test/ 4-7545540342374 804127/ 6d3d68f655563fe d" 201 - "PUT http:// localhost: 8080/v1/ AUTH_test/ 4-7545540342374 804127/ 6d3d68f655563fe d" "tx13648ea2c493 4c5680256- 005783d7e3" "proxy-server 27428" 0.2930 "-" 27954 0
... we have extra fields - so if you have specific "preexisting tools to parse and point out interesting things" ideally we could add something specific we could test against?
The proxy request log lines are different [3], e.g.
Jul 11 17:31:15 saio proxy-server: 127.0.0.1 127.0.0.1 11/Jul/ 2016/17/ 31/15 PUT /v1/AUTH_ test/4- 754554034237480 4127/6d3d68f655 563fed HTTP/1.0 201 - Hummingbird% 20Client AUTH_tk1e0e05eb9... 131072 - - tx13648ea2c4934 c5680256- 005783d7e3 - 0.8403 - - 1468258275. 055514097 1468258275. 895791054 0
There's some historic reasons for that format, and AFAIK most deployments both need and depend on that format - it's the only one I ever want or need for access logs in production - we even have special documented facilities to make it easy to segregate access logs [4] - but like on my *development* machine like I just log *both* formats
Jul 11 17:31:15 saio proxy-server: STDERR: 127.0.0.1 - - [11/Jul/2016 17:31:15] "PUT /v1/AUTH_ test/4- 754554034237480 4127/6d3d68f655 563fed HTTP/1.1" 201 254 0.855121 (txn: tx13648ea2c4934 c5680256- 005783d7e3)
... so there's no reason we wouldn't go ahead and configure Swift on devstack to log the requests in just the format you want wherever you need it to log! But I'd be happy to prioritize here if the default documented access request/response log format in the proxy is suitable for you.
But it's not clear to me how either of these formats is relevant for like the *interesting* messages?
e.g.
Aug 30 17:30:59 hummingbird swift: ERROR with Account server 10.0.0.1:1001/sdb re: Trying to PUT /a/: #012Traceback (most recent call last):#012 File "/vagrant/ swift/swift/ proxy/controlle rs/base. py", line 1532, in _make_request#012 headers=headers, query_string= query)# 012 File "/vagrant/ swift/test/ unit/__ init__. py", line 1022, in connect#012 raise HTTPException( )#012HTTPExcept ion (txn: tx16901d6ed06b4 696914e7- 0057c5c2d1)
e.g.
Aug 30 17:30:18 hummingbird swift: Quarantined object /tmp/tmpjU1T8M/ tmp_test_ object_ auditor/ node/sda/ objects/ 0/a43/615cd4810 e0d969889af154f 7b02ba43/ 1472578218. 87833.data: metadata content-length 10 does not match actual object size 0
^ do you have any requirements, thoughts or opinions on the "format" of unstructured messages that *aren't* request/response logging?
Cheers,
-Clay
1. https:/ /en.wikipedia. org/wiki/ Common_ Log_Format docs.openstack. org/developer/ swift/logs. html#storage- node-logs docs.openstack. org/developer/ swift/logs. html#proxy- logs /github. com/openstack/ swift/blob/ ac81ccd948de222 98f2ebd8493695b 793454cd54/ etc/proxy- server. conf-sample# L593
2. http://
3. http://
4. https:/