Assuming that the monitoring host is able to make outbound connections, you can solve this by having a bastion host elsewhere which you can connect through. Obviously do make sure to clear this with your customer.
To do this, set up a server somewhere under your control. This might be a VPS with a generous traffic limit, or it might be a physical server under your control, or something else. Give it a stable DNS name, possibly on a one-per-customer basis, which maps to the IP address of the bastion host. Mind the possibility that you may need to renumber that host in the future, possibly without being able to access the monitoring host.
Now, configure the monitoring host (the one that you want to be able to ultimately connect to) to connect out to the bastion host to set up a SSH tunnel. This will probably include creating a non-privileged user account on the monitoring host to run the tunnelling SSH process, and protecting that appropriately. (Remember: this account won't be used for logging in to; it will only run a local, non-interactive SSH client process, and own the tunnel.) Also set up a non-privileged account on the bastion host, with only sufficient privileges to log in with SSH (not to a shell) and set up a SSH tunnel to the monitoring host.
With that in place, you can set up something like autossh on the monitoring host to maintain a connection to the bastion host to keep the tunnel alive. Add some decent logging on the bastion host, since on the monitoring host, the connection will almost certainly look like it originates from localhost.
When you need to connect to the monitoring host, first connect to the bastion host setting up a SSH tunnel to the bastion host's local port that forwards to the monitoring host; and then connect to the local port that maps to that tunnel. This will tunnel the SSH traffic via the bastion host, allowing your system to talk to the ultimate target host without requiring the host that is ultimately being connected to to be able to accept incoming connections.