Discovery (port 8765) service not starting
Hi, I'm running reef, with locally-built containers based on upstream .debs. I've now enabled prometheus metrics thus: ceph mgr module enable prometheus And that seems to have worked (the active mgr is listening on port 9283); but per the docs[0] there should also be a service discovery endpoint (on port 8765) that I can point Prometheus' http_sd_config at. But there is in fact no listener on that port, nor anything obvious in logs if I failover the mgr - see a log extract here: https://phabricator.wikimedia.org/P68521 Is there something else I need to be doing to get the service discovery endpoint working? Thanks, Matthew [0] https://docs.ceph.com/en/reef/cephadm/services/monitoring/#deploying-monitor...
Without having looked too closely, do you run ceph with IPv6? There’s a tracker issue: https://tracker.ceph.com/issues/66426 It will be backported to Reef. Zitat von Matthew Vernon <mvernon@wikimedia.org>:
Hi,
I'm running reef, with locally-built containers based on upstream .debs.
I've now enabled prometheus metrics thus: ceph mgr module enable prometheus
And that seems to have worked (the active mgr is listening on port 9283); but per the docs[0] there should also be a service discovery endpoint (on port 8765) that I can point Prometheus' http_sd_config at.
But there is in fact no listener on that port, nor anything obvious in logs if I failover the mgr - see a log extract here:
https://phabricator.wikimedia.org/P68521
Is there something else I need to be doing to get the service discovery endpoint working?
Thanks,
Matthew
[0] https://docs.ceph.com/en/reef/cephadm/services/monitoring/#deploying-monitor... _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Hi, On 02/09/2024 21:24, Eugen Block wrote:
Without having looked too closely, do you run ceph with IPv6? There’s a tracker issue:
https://tracker.ceph.com/issues/66426
It will be backported to Reef.
I do run IPv6, but the problem is that nothing is listening on port 8765 at all, not that it's only doing so on v4. If I do lsof -p [pid of mgr] | grep LISTEN I just get /var/run/ceph/ceph-mgr.moss-be1001.eshmpf.asok type=STREAM (LISTEN) TCP *:9283 (LISTEN) i.e. the management socket, and the prometheus endpoint itself. AFAICT that tracker issue describes a v6-enabled deployment where it's only listening on v4. Thanks, Matthew
Do you see the port definition in the unit.meta file? jq -r '.ports' /var/lib/ceph/{FSID}/mgr.{MGR}/unit.meta [ 8443, 9283, 8765 ] Zitat von Matthew Vernon <mvernon@wikimedia.org>:
Hi,
On 02/09/2024 21:24, Eugen Block wrote:
Without having looked too closely, do you run ceph with IPv6? There’s a tracker issue:
https://tracker.ceph.com/issues/66426
It will be backported to Reef.
I do run IPv6, but the problem is that nothing is listening on port 8765 at all, not that it's only doing so on v4. If I do lsof -p [pid of mgr] | grep LISTEN I just get
/var/run/ceph/ceph-mgr.moss-be1001.eshmpf.asok type=STREAM (LISTEN) TCP *:9283 (LISTEN)
i.e. the management socket, and the prometheus endpoint itself.
AFAICT that tracker issue describes a v6-enabled deployment where it's only listening on v4.
Thanks,
Matthew _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Oh that's interesting :-D I have no explanation for that, except maybe some flaw in your custom images? Or in the service specs? Not sure, to be honest... Zitat von Matthew Vernon <mvernon@wikimedia.org>:
Hi,
On 03/09/2024 11:46, Eugen Block wrote:
Do you see the port definition in the unit.meta file?
Oddly:
"ports": [ 9283, 8765, 8765, 8765, 8765 ],
which doesn't look right...
Regards,
Mattew _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
On 03/09/2024 13:33, Eugen Block wrote:
Oh that's interesting :-D I have no explanation for that, except maybe some flaw in your custom images? Or in the service specs? Not sure, to be honest...
So obviously it _could_ be something in our images, but we're using Ceph's published .debs (18.2.2) and not doing anything clever: https://gerrit.wikimedia.org/r/plugins/gitiles/operations/docker-images/prod... I've not done anything to specifically ask for the discovery endpoint to be installed - as far as I can tell from the docs it should just get started when you enable the prometheus endpoint (which does seem to be working)... Regards, Matthew
While I generally don't recommend getting down and dirty with the containers in Ceph, if you're going to build your own, well, that's different. When I have a container and the expected port isn't listening, the first thing I do is see if it's really listening and internal-only or truly not listening. To do this, you can dial in to the container, like so (this is one of my OSD's) docker exec -it ceph-272fcd86-0831-11ee-a7df-9c5c8e84cf8f-osd-7 /bin/bash The netstat command is not available in the stock Ceph containers, but the "ss" command is, so use that to see if there is in fact a process listening on that port. If so, then your Dockerfile is probably not set to publish that port. Are you using the stock Dockerfile to build from? If not, then the process that listens apparently didn't come all the way up. Take a quick peek around the local /var/log directory just to see if there's anything logged internally (probably not). Maybe do a "dmesg" just for laughs. Since this is (so I read it), the Prometheus container, look at the /var/lib/ceph/<fsid>/prometheus.<hostname> directory, which contains the Prometheus config file (under "./etc) and see if there are irregularities there. Tim On Tue, 2024-09-03 at 13:59 +0100, Matthew Vernon wrote:
On 03/09/2024 13:33, Eugen Block wrote:
Oh that's interesting :-D I have no explanation for that, except maybe some flaw in your custom images? Or in the service specs? Not sure, to be honest...
So obviously it _could_ be something in our images, but we're using Ceph's published .debs (18.2.2) and not doing anything clever:
https://gerrit.wikimedia.org/r/plugins/gitiles/operations/docker-images/prod...
I've not done anything to specifically ask for the discovery endpoint to be installed - as far as I can tell from the docs it should just get started when you enable the prometheus endpoint (which does seem to be working)...
Regards,
Matthew _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Hi, On 03/09/2024 14:27, Tim Holloway wrote: FWIW, I'm using podman not docker.
The netstat command is not available in the stock Ceph containers, but the "ss" command is, so use that to see if there is in fact a process listening on that port.
I have done this, and there's nothing listening on port 8765 per ss -l | grep 8765
If not, then the process that listens apparently didn't come all the way up.
Take a quick peek around the local /var/log directory just to see if there's anything logged internally (probably not). Maybe do a "dmesg" just for laughs.
Nothing obvious - and logs are available outside the container as well - hence the paste earlier in this thread, https://phabricator.wikimedia.org/P68521
Since this is (so I read it), the Prometheus container, look at the /var/lib/ceph/<fsid>/prometheus.<hostname> directory, which contains the Prometheus config file (under "./etc) and see if there are irregularities there.
It's not, it's the mgr container (I've enabled the prometheus mgr module, which makes an endpoint available from whence metrics can be scraped, rather than the prometheus container which runs the service that does the scraping). Thanks, Matthew
Yeah. Although taming the Prometheus logs is on my list, I'm still fuzzy on its details. For your purposes, Docker and Podman can be considered as equivalent. I also run under Podman, incidentally. If the port isn't open inside the container, then blame Prometheus. I'd consider bumping its logging levels - the exact opposite of what I'm looking to do! Tim On Tue, 2024-09-03 at 15:34 +0100, Matthew Vernon wrote:
Hi,
On 03/09/2024 14:27, Tim Holloway wrote:
FWIW, I'm using podman not docker.
The netstat command is not available in the stock Ceph containers, but the "ss" command is, so use that to see if there is in fact a process listening on that port.
I have done this, and there's nothing listening on port 8765 per ss -l | grep 8765
If not, then the process that listens apparently didn't come all the way up.
Take a quick peek around the local /var/log directory just to see if there's anything logged internally (probably not). Maybe do a "dmesg" just for laughs.
Nothing obvious - and logs are available outside the container as well - hence the paste earlier in this thread, https://phabricator.wikimedia.org/P68521
Since this is (so I read it), the Prometheus container, look at the /var/lib/ceph/<fsid>/prometheus.<hostname> directory, which contains the Prometheus config file (under "./etc) and see if there are irregularities there.
It's not, it's the mgr container (I've enabled the prometheus mgr module, which makes an endpoint available from whence metrics can be scraped, rather than the prometheus container which runs the service that does the scraping).
Thanks,
Matthew _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
You may find this interesting. I'm running Pacific from the Red Hat repo and Prometheus was given its own discrete container image, not the generic Ceph one. Rather than build custom Prometheus, Red Hat used the Prometheus project's own containers. In fact, it has 3: one for Prometheus, one for Prometheus node-exporter and one for Prometheus alertmanager. Also Grafana is using its own image as well. Nothing on the host in question listens on Port 8765. Prometheus is listening on ports in the 9000 range. For whatever it's worth. The name of the API you're interested in, on the other hand, sounds familiar, but I'm too senile to recall from where. Tim On Tue, 2024-09-03 at 11:48 -0400, Tim Holloway wrote:
Yeah. Although taming the Prometheus logs is on my list, I'm still fuzzy on its details.
For your purposes, Docker and Podman can be considered as equivalent. I also run under Podman, incidentally.
If the port isn't open inside the container, then blame Prometheus. I'd consider bumping its logging levels - the exact opposite of what I'm looking to do!
Tim
On Tue, 2024-09-03 at 15:34 +0100, Matthew Vernon wrote:
Hi,
On 03/09/2024 14:27, Tim Holloway wrote:
FWIW, I'm using podman not docker.
The netstat command is not available in the stock Ceph containers, but the "ss" command is, so use that to see if there is in fact a process listening on that port.
I have done this, and there's nothing listening on port 8765 per ss -l | grep 8765
If not, then the process that listens apparently didn't come all the way up.
Take a quick peek around the local /var/log directory just to see if there's anything logged internally (probably not). Maybe do a "dmesg" just for laughs.
Nothing obvious - and logs are available outside the container as well - hence the paste earlier in this thread, https://phabricator.wikimedia.org/P68521
Since this is (so I read it), the Prometheus container, look at the /var/lib/ceph/<fsid>/prometheus.<hostname> directory, which contains the Prometheus config file (under "./etc) and see if there are irregularities there.
It's not, it's the mgr container (I've enabled the prometheus mgr module, which makes an endpoint available from whence metrics can be scraped, rather than the prometheus container which runs the service that does the scraping).
Thanks,
Matthew _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Hi, I tracked it down to 2 issues: * our ipv6-only deployment (a bug fixed in 18.2.4, though that has buggy .debs) * Discovery service is only run on the active mgr The latter point is surely a bug? Isn't the point of running a service discovery endpoint that one could point e.g. an external Prometheus scraper at the service discovery endpoint of any mgr and it would then tell Prometheus where to scrape metrics from (i.e. the active mgr)? Thanks, Matthew
I've been monitoring my Ceph LAN segment for the last several hours and absolutely no traffic has shown up on any server for port 8765. Furthermore I did a quick review of Prometheus itself and it's only claiming those 9000-series ports I mentioned previously. So I conclude that this isn't literally a Prometheus problem, although it could be something external that's supposed to plug in to Prometheus that isn't part of my standard Ceph setup. Since port 8765 isn't a Well-Known Port, that's about all I can say on that matter. I'd only panic if Prometheus isn't collecting something that's important to me. Tim On Wed, 2024-09-04 at 16:22 +0100, Matthew Vernon wrote:
Hi,
I tracked it down to 2 issues:
* our ipv6-only deployment (a bug fixed in 18.2.4, though that has buggy .debs)
* Discovery service is only run on the active mgr
The latter point is surely a bug? Isn't the point of running a service discovery endpoint that one could point e.g. an external Prometheus scraper at the service discovery endpoint of any mgr and it would then tell Prometheus where to scrape metrics from (i.e. the active mgr)?
Thanks,
Matthew _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Hi, regarding the scraping endpoints, I wonder if it would make sense to handle it the same way as with the dashboard redirect: ceph config get mgr mgr/dashboard/standby_behaviour redirect If you try to access the dashboard via one of the standby MGRs, you're redirected to the active one. Zitat von Matthew Vernon <mvernon@wikimedia.org>:
Hi,
I tracked it down to 2 issues:
* our ipv6-only deployment (a bug fixed in 18.2.4, though that has buggy .debs)
* Discovery service is only run on the active mgr
The latter point is surely a bug? Isn't the point of running a service discovery endpoint that one could point e.g. an external Prometheus scraper at the service discovery endpoint of any mgr and it would then tell Prometheus where to scrape metrics from (i.e. the active mgr)?
Thanks,
Matthew _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Hi, The port 8765 is the "service discovery" (an internal server that runs in the mgr... you can change the port by changing the variable service_discovery_port of cephadm). Normally it is opened in the active mgr and the service is used by prometheus (server) to get the targets by using the http service discovery feature [1]. This feature has been there for a long time now and it's the default configuration used by Ceph monitoring stack. It should start automatically without any external intervention (or manual configuration). If it's not starting it means something weird is happening, probably watching mgr logs can shed some light. For that you have to go to the host where the active mgr is running and see the logs by running: systemctl | grep mgr journalctl -u <your_mgr_service> i.e: journalctl -u ceph-9414b9ce-6b63-11ef-bd07-525400d9fd68@mgr.ceph-node-0.fiiqhv.service [1] https://prometheus.io/docs/prometheus/latest/http_sd/ On Thu, Sep 5, 2024 at 11:04 AM Eugen Block <eblock@nde.ag> wrote:
Hi,
regarding the scraping endpoints, I wonder if it would make sense to handle it the same way as with the dashboard redirect:
ceph config get mgr mgr/dashboard/standby_behaviour redirect
If you try to access the dashboard via one of the standby MGRs, you're redirected to the active one.
Zitat von Matthew Vernon <mvernon@wikimedia.org>:
Hi,
I tracked it down to 2 issues:
* our ipv6-only deployment (a bug fixed in 18.2.4, though that has buggy .debs)
* Discovery service is only run on the active mgr
The latter point is surely a bug? Isn't the point of running a service discovery endpoint that one could point e.g. an external Prometheus scraper at the service discovery endpoint of any mgr and it would then tell Prometheus where to scrape metrics from (i.e. the active mgr)?
Thanks,
Matthew _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Hi, On 05/09/2024 12:49, Redouane Kachach wrote:
The port 8765 is the "service discovery" (an internal server that runs in the mgr... you can change the port by changing the variable service_discovery_port of cephadm). Normally it is opened in the active mgr and the service is used by prometheus (server) to get the targets by using the http service discovery feature [1]. This feature has been there for a long time now and it's the default configuration used by Ceph monitoring stack. It should start automatically without any external intervention (or manual configuration).
Right; it wasn't running because I have an IPv6 deployment (that bug's fixed in 18.2.4 - https://tracker.ceph.com/issues/63448). Regards, Matthew
On 05/09/2024 15:03, Matthew Vernon wrote:
Hi,
On 05/09/2024 12:49, Redouane Kachach wrote:
The port 8765 is the "service discovery" (an internal server that runs in the mgr... you can change the port by changing the variable service_discovery_port of cephadm). Normally it is opened in the active mgr and the service is used by prometheus (server) to get the targets by using the http service discovery feature [1]. This feature has been there for a long time now and it's the default configuration used by Ceph monitoring stack. It should start automatically without any external intervention (or manual configuration).
Right; it wasn't running because I have an IPv6 deployment (that bug's fixed in 18.2.4 - https://tracker.ceph.com/issues/63448).
...though I'm not sure that having only the active mgr run this endpoint is correct, though? Isn't it more useful to be able to e.g. point my Prometheus at any of the mgrs and have service discovery work, rather than needing Prometheus to know which mgr is active to know which sd to talk to, which seems to rather defeat the point? Thanks, Matthew
Now you've got me worried. As I said, there is absolutely no traffic using port 8765 on my LAN. Am I missing a service? Since my distro is based on stock Prometheus, I'd have to assume that the port 8765 server would be part of the Ceph generic container image and isn't being switched on for some reason. Tim On Thu, 2024-09-05 at 15:05 +0100, Matthew Vernon wrote:
On 05/09/2024 15:03, Matthew Vernon wrote:
Hi,
On 05/09/2024 12:49, Redouane Kachach wrote:
The port 8765 is the "service discovery" (an internal server that runs in the mgr... you can change the port by changing the variable service_discovery_port of cephadm). Normally it is opened in the active mgr and the service is used by prometheus (server) to get the targets by using the http service discovery feature [1]. This feature has been there for a long time now and it's the default configuration used by Ceph monitoring stack. It should start automatically without any external intervention (or manual configuration).
Right; it wasn't running because I have an IPv6 deployment (that bug's fixed in 18.2.4 - https://tracker.ceph.com/issues/63448).
...though I'm not sure that having only the active mgr run this endpoint is correct, though? Isn't it more useful to be able to e.g. point my Prometheus at any of the mgrs and have service discovery work, rather than needing Prometheus to know which mgr is active to know which sd to talk to, which seems to rather defeat the point?
Thanks,
Matthew _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Hi Matthew, That makes sense. The ipv6 BUG can lead to the issue you described. In the current implementation whenever a mgr failover takes place, prometheus configuration (when using the monitoring stack deployed by Ceph) is updated automatically to point to the new active mgr. Unfortunately it's not easy to have active services running in the standby mgr. At most, we can do some redirection as we do in the dashboard. So far we haven't had the need to do that. Next releases will come with the new mgmt-gateway service introduced in [1] and [2] which will make it easy to have a single entry point to the cluster handling HA transparently in the backend. This is still WIP but you can play with it if you want using the latest code from main. Support for OIDC based on oauth2-proxy is also being introduced as part of this effort by [3]. @ Timo Holloway, as I said the support [4] for service discovery has been there for a while (I'd say 2 years aprox) unless you are using an old Ceph version (where the prometheus config was static) you should see traffic in the port 8765. [1] https://github.com/ceph/ceph/pull/57535 [2] https://github.com/ceph/ceph/pull/58402 [3] https://github.com/ceph/ceph/pull/58460 [4] https://github.com/ceph/ceph/pull/46400 On Thu, Sep 5, 2024 at 7:00 PM Tim Holloway <timh@mousetech.com> wrote:
Now you've got me worried. As I said, there is absolutely no traffic using port 8765 on my LAN.
Am I missing a service? Since my distro is based on stock Prometheus, I'd have to assume that the port 8765 server would be part of the Ceph generic container image and isn't being switched on for some reason.
Tim
On Thu, 2024-09-05 at 15:05 +0100, Matthew Vernon wrote:
On 05/09/2024 15:03, Matthew Vernon wrote:
Hi,
On 05/09/2024 12:49, Redouane Kachach wrote:
The port 8765 is the "service discovery" (an internal server that runs in the mgr... you can change the port by changing the variable service_discovery_port of cephadm). Normally it is opened in the active mgr and the service is used by prometheus (server) to get the targets by using the http service discovery feature [1]. This feature has been there for a long time now and it's the default configuration used by Ceph monitoring stack. It should start automatically without any external intervention (or manual configuration).
Right; it wasn't running because I have an IPv6 deployment (that bug's fixed in 18.2.4 - https://tracker.ceph.com/issues/63448).
...though I'm not sure that having only the active mgr run this endpoint is correct, though? Isn't it more useful to be able to e.g. point my Prometheus at any of the mgrs and have service discovery work, rather than needing Prometheus to know which mgr is active to know which sd to talk to, which seems to rather defeat the point?
Thanks,
Matthew _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Hi, On 06/09/2024 08:08, Redouane Kachach wrote:
That makes sense. The ipv6 BUG can lead to the issue you described. In the current implementation whenever a mgr failover takes place, prometheus configuration (when using the monitoring stack deployed by Ceph) is updated automatically to point to the new active mgr. Unfortunately it's not easy to have active services running in the standby mgr. At most, we can do some redirection as we do in the dashboard.
I've had a little look at the standby mode in the prometheus module; it can already figure out the active metrics URL via module.get_active_uri(), so it looks like adding an additional "redirect" standby_behaviour that emits an HTTPRedirect to the active URI wouldn't be too hard. Is that a change you'd be in principle willing to accept?
So far we haven't had the need to do that. Next releases will come with the new mgmt-gateway service introduced in [1] and [2] which will make it easy to have a single entry point to the cluster handling HA transparently in the backend.
Interesting, thanks. This would then be configured as a single endpoint (which one could presumably redeploy from time to time) that external monitoring could be pointed at? Regards, Matthew
On 06/09/2024 10:27, Matthew Vernon wrote:
On 06/09/2024 08:08, Redouane Kachach wrote:
That makes sense. The ipv6 BUG can lead to the issue you described. In the current implementation whenever a mgr failover takes place, prometheus configuration (when using the monitoring stack deployed by Ceph) is updated automatically to point to the new active mgr. Unfortunately it's not easy to have active services running in the standby mgr. At most, we can do some redirection as we do in the dashboard.
I've had a little look at the standby mode in the prometheus module; it can already figure out the active metrics URL via module.get_active_uri(), so it looks like adding an additional "redirect" standby_behaviour that emits an HTTPRedirect to the active URI wouldn't be too hard. Is that a change you'd be in principle willing to accept?
In fact, it looks like Prometheus is content with the empty responses from the standby mgrs, so this isn't necessary. Regards, Matthew
Thank you, Redouane! Some background. I migrated to Ceph amidst a Perfect Storm. The Ceph docs, as I've often complained, were/are a horrible mish-mash of deprecated instructions and more modern information. So, among other things, I ended up with a mess of resources, some legacy-based, some managed, and some OSDs that managed to get defined as both. On top of that, this was Ceph Octopus, which had the flaw that scheduled changes to the system would hang until the system was in OK status, but the way to make the system OK was to have those scheduled changes actually executed. I managed to clear that part out by migrating to Pacific. I originally settled on Octopus because I wrongly had thought that no newer release was supported standard under CentOS 7. Over time I thought I'd managed to get the system clean, via a combination of documented processes and occasional brute force, but it looks like something may not have been configured/activated, since as I said, I see no traffic targeting port 8765 not anyone listening there. So if you could guide me on fixing that, I'd be grateful. Tim On Fri, 2024-09-06 at 09:08 +0200, Redouane Kachach wrote:
Hi Matthew,
That makes sense. The ipv6 BUG can lead to the issue you described. In the current implementation whenever a mgr failover takes place, prometheus configuration (when using the monitoring stack deployed by Ceph) is updated automatically to point to the new active mgr. Unfortunately it's not easy to have active services running in the standby mgr. At most, we can do some redirection as we do in the dashboard. So far we haven't had the need to do that. Next releases will come with the new mgmt-gateway service introduced in [1] and [2] which will make it easy to have a single entry point to the cluster handling HA transparently in the backend. This is still WIP but you can play with it if you want using the latest code from main. Support for OIDC based on oauth2-proxy is also being introduced as part of this effort by [3].
@ Timo Holloway, as I said the support [4] for service discovery has been there for a while (I'd say 2 years aprox) unless you are using an old Ceph version (where the prometheus config was static) you should see traffic in the port 8765.
[1] https://github.com/ceph/ceph/pull/57535 [2] https://github.com/ceph/ceph/pull/58402 [3] https://github.com/ceph/ceph/pull/58460 [4] https://github.com/ceph/ceph/pull/46400
On Thu, Sep 5, 2024 at 7:00 PM Tim Holloway <timh@mousetech.com> wrote:
Now you've got me worried. As I said, there is absolutely no traffic using port 8765 on my LAN.
Am I missing a service? Since my distro is based on stock Prometheus, I'd have to assume that the port 8765 server would be part of the Ceph generic container image and isn't being switched on for some reason.
Tim
participants (4)
-
Eugen Block
-
Matthew Vernon
-
Redouane Kachach
-
Tim Holloway