Selfhosted

40006 readers

614 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.

Resources:

selfh.st Newsletter and index of selfhosted software and apps
awesome-selfhosted software
awesome-sysadmin resources
Self-Hosted Podcast from Jupiter Broadcasting

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago

MODERATORS

[email protected]

Uptime-kuma & Docker: Timeouts when monitoring services on same host (lemmy.world)

submitted 1 year ago by [email protected] to c/[email protected]

9 comments fedilink hide all child comments

Hello.

Pretty sure I'm doing something stupid, but I can't find it.

I have Caddy and Uptime-kuma installed as Docker containers. They are on the same Docker bridge network. Both work fine (with the below exception).

I'm trying to monitor Caddy virtual hosts from Uptime-kuma and getting a timeout.

If I exec into the Uptime-kuma container, I can ping the host name I want to monitor (and the DNS is resolving correctly to the Docker hosts external IP).

But I can't reach port 80/443 using telnet or openssl.

Any suggestions for what I might be doing wrong?

Thanks!

top 8 comments

sorted by: hot top controversial new old

[–] [email protected] 2 points 1 year ago* (last edited 1 year ago) (1 children)

The way I have my monitoring set up is to poll the containers from behind the proxy layer. Ex. if I'm trying to poll Portainer for example:

***
services:
    portainer:
    ...

with the service name portainer

from uptime-kuma within the same docker network it would look like this:

Can confirm this is working correctly to monitor that the service is reachable. This doesn't however ensure that you can reach it from your computer, because that depends on if your reverse proxy is configured correctly and isn't down, but that's what I wanted in my case.

Edit: If you're wanting to poll the http endpoint you would add it before like http://whatever_service:whatever_port

[–] [email protected] 2 points 1 year ago (1 children)

Thanks. In this case I'm trying to monitor Caddy itself (sites that are just html files that it hosts rather than redirect to other containers). I could point the monitor at caddy:443 but then I'd need to find someway to specify the HOST: for the virtualhosting to work?

[–] [email protected] 2 points 1 year ago (1 children)

Oh I see, I definitely misunderstood what you were asking. How is your caddy server set up? Is it serving one site per subdomain (site.your.domain) or is it one site per path (your.domain/site/)? I am running traefik so I probably won't be able to help with specifics, but it's worth a shot.

[–] [email protected] 2 points 1 year ago

Caddy is server subdomains and standalone domains, doesn't seem to make a difference which is which .. neither work. For the moment I'm monitoring them from another server but that's annoying ... which I could figure out what I'm doing wrong!

[–] [email protected] 1 points 1 year ago (1 children)

Are you hosting behind NAT / at home? If so, you may need to enable NAT reflection on your router.

[–] [email protected] 1 points 1 year ago (1 children)

I am behind cgnat but why would that matter for trying to reach a service on the same box?

[–] [email protected] 2 points 1 year ago (1 children)

It matters only if "the docker hosts external IP" your dns resolves is a public IP. In that case packets travel to the router which needs to map/send them back to the docker hosts LAN IP (NAT-Reflection). With cgnat this would need to be enabled on the carrier side, where you set up the port forwarding. If that's not possible, split-DNS may be an alternative.

If "the docker hosts external IP" is actually your docker hosts LAN IP, all of that is irrelevant. Split-DNS would accomplish that.

[–] [email protected] 1 points 1 year ago

Sorry I'm being stupid. I'm on CGNAT at home but this is actually on a VPS.

load more comments