Solace health checks

Options
Anton
Anton Member Posts: 25
edited May 2022 in General Discussions #1

Hi,

I'm currently implementing health checks endpoints for my Asp.Net Core services. Most of them are connected to Solace, so I'd like to have one of the health checks to check if service can be connected to VPN. What would be the best/"cheap" way of doing this? Creating Solace Session each time and trying to connect? My main concern is that this healthcheck will be called quite often, so not sure if opening and closing new session every 30 secs is a good idea.

Tagged:

Answers

  • TomF
    TomF Member, Employee Posts: 406 Solace Employee
    Options

    Hi @anton, there is a health check service on the broker. This was designed for load balancers. Will that help?

  • Anton
    Anton Member Posts: 25
    Options

    Hi @TomF . Thanks, but this is to check if broker is alive. What I want to check is if my service can actually connect to Broken successfully. Most of my services have dependencies on Sql Server and Solace, so idea is to have 2 health check for readiness probe that will check if connections can be successfully established to Sql Server and Solace.

  • TomF
    TomF Member, Employee Posts: 406 Solace Employee
    Options

    Ah, so the check is not that the broker is alive, but that the application can connect.

    Have you thought about leaving the connection up all the time? That's the ultimate connection probe :-) If the number of services is small compared to the broker connection tier (say 20 services on a 100 tier broker or 200 services on a 1k broker), it will be simpler more robust, and easier to manage.

  • Anton
    Anton Member Posts: 25
    Options

    @TomF do you mean opening it once in a health check and keeping it open? That could be an option. Btw, how bad or heavy for Broker if I open and close connection like every 30 secs?

  • TomF
    TomF Member, Employee Posts: 406 Solace Employee
    Options

    @Anton, what I really meant was open your connection to the broker to check that the connection can be made.

    _Keep the connection_. If there are any connection problems, the API will tell you! This gives you an easy way to track the connection health, because the APIs do most of that work for you.

    When you need to start consuming or publishing, _use the same connection_.

    Openning a connection is quite resource intensive, especially if it's an encrypted connection, but unless you are opening and closing over a hundred connection a second it's unlikely to cause a problem. Personally, I would be more worried about the complexity of the code I'm using and how robust it is. Using a single connection, you'll get advance notification of a connection problem as soon as it happens, rather than waiting for the 30 second health check, and what's more, there's very little code needed because most of it is already implemented in the API.

  • Tamimi
    Tamimi Member, Administrator, Employee Posts: 491 admin
    Options

    To add to Tom's point, depending on the API you are using you can configure callbacks on your session/messaging service incase any interruption happens. So for example, if you are using the PubSub+ Python API you simple register the service interruption listener to your messaging service and that is your health check for "the application can connect"


  • Anton
    Anton Member Posts: 25
    Options

    Thanks for you answers. I'll probably start with opening and closing new session as this seems to be the easiest one. It also aligns with how healthcheck are implemented for sql server, kafka, etc.