2024-12-12T08:23:37.768Z

<Marc Singer> Hi
Did anyone ever tried to read the ceph rgw logs directly from the pool and could give me a hint how this could be accomplished?
I would like to export the logs from the pool.
Thank you

2024-12-12T08:43:45.443Z

<IcePic> Marc Singer: Sounds like something for fluentbit? Some use it to collect all kinds of output and send to where-you-want-it

2024-12-12T08:46:00.003Z

<Marc Singer> Unfortunately I need to export them from the log pool as I am looking for historical data, so fluent bit won't help me here

2024-12-12T08:47:20.314Z

<IcePic> ok

2024-12-12T09:01:17.745Z

<Marc Singer> I checked the files in the log pool with the rados command, it seems like the objects in the RGW log pool are encoded log files, part of it is readable and parts have some encoding. Could someone give me some insight how to handle these?

2024-12-12T09:54:24.152Z

<Madhu Rajanna> This is not tested, cephcsi only tests x to x+1 release only

2024-12-12T12:31:12.906Z

<Kevin Fox> ok. thanks.

2024-12-12T14:00:07.098Z

<Casey Bodley> hey @Marc Singer, i'm not sure whether you're asking about the usage log (rgw_enable_usage_log) or the ops log (rgw_ops_log_rados). for usage, the radosgw-admin commands are 'usage show', 'usage trim', 'usage clear'. for ops, the commands are 'log list', 'log show', 'log rm'. those commands should dump the entries in their decoded form

2024-12-12T15:44:00.560Z

<Yonatan Zaken> Hi Devs 🙂

A question about keyrings (and ceph.conf) that are managed by cephadm.

I have noticed that if a certain client keyring (e.g. ceph.client.admin.keyring) is set to be managed by cephadm via
`ceph orch client-keyring set`  (and also ceph.conf since --no-ceph-conf flag wasn't used)

Then, for example the ceph.conf, file might be at some point, re-generated in /tmp/cephadm-<ceph fsid>/etc/ceph
And moved (i think via the `mv` command) to /etc/ceph.

If my description above is correct, wouldn't using `mv` have the potential of changing the security context of the original file that
was created in /etc/ceph ?

Wouldn't we prefer to preserve the original security context that was applied on the original /etc/ceph ?

Thanks

2024-12-12T22:58:16.345Z

<Brent Saner> Sorry for resurrecting, but I'm still getting this on reef (`18.2.4` ).
for both the `dashboard` **AND** the `prometheus` mgr modules. i've disabled all cluster config settings for the modules but still nada.

confirmed that 18.2.4 (`e7ad5345525c7aa95470c26863873b581076945d`) has `f348840e3dc36399dabbe6cdf2d38066f254b73c` but i notice no change in behavior.

has the fix that landed **actually** fixed for anyone for either module?

2024-12-12T22:58:44.777Z

<Brent Saner> and is there a more recent bug i should be following than <https://tracker.ceph.com/issues/68802>?