It should not be best effort. As written, exactly
rgw_usage_log_flush_threshold outstanding log entries will be
buffered. The default value for this parameter is 1024, which is
probably not high for a sustained workload, but you could experiment
with reducing it.
Matt
On Fri, Apr 12, 2019 at
Ok thanks. Is the expectation that events will be available on that socket as
soon as the occur or is it more of a best effort situation? I'm just trying to
nail down which side of the socket might be lagging. It's pretty difficult to
recreate this as I have to hit the cluster very hard to get
Hi Aaron,
I don't think that exists currently.
Matt
On Fri, Apr 12, 2019 at 11:12 AM Aaron Bassett
wrote:
>
> I have an radogw log centralizer that we use to for an audit trail for data
> access in our ceph clusters. We've enabled the ops log socket and added
> logging of the
I have an radogw log centralizer that we use to for an audit trail for data
access in our ceph clusters. We've enabled the ops log socket and added logging
of the http_authorization header to it:
rgw log http headers = "http_authorization"
rgw ops log socket path = /var/run/ceph/rgw-ops.sock