2

I'm currently running microservices in my company. They are not api servers, just processes that communicate with each other. So the implementation to communicate with each other is RabbitMQ.

Now I'm trying to implement a health checker to know if a server has restarted or crashed. But I'm only familiar using a health check by calling a specific api in the server. But our services aren't an api server so they don't have any ports to imply. And I also don't wan't to add an api server for just to implement a health checker.

So I'm searching about any use cases about implementing health checks by sending messages (health check signals) to the health checker by a message broker such as RabbitMQ instead of using APIs.

Does anyone have some ideas?

Alex Won
  • 177
  • 2
  • 11
  • 1
    Sounds like an obvious and easy mechanism for a system like yours that already relies on message queuing. Implement any architecture you want from publishing specific messages to each service - either on a single exchange where every service (as client) looks for himself as the topic, or on an exchange-per-service - or you could simply have an exchange that's read from by the health-check service and all services emit messages periodically (dead man style) to that exchange - and that service just makes sure it hears from anyone once in awhile. Let us know what you work out! – davidbak May 03 '21 at 08:29
  • 1
    Consider also using [rabbit event exchange](https://www.rabbitmq.com/event-exchange.html) at your health-check service - so it'll be able to keep track of service connect/disconnects from the channel the service is talking to the exchange with. Channels are suppose to stay up all the time, so a disconnect indicates trouble of some kind - especially if it wasn't preceeded by a service (as client) sent message indicating a normal going-down event. – davidbak May 03 '21 at 08:34
  • Thank you. I was thinking exact the same as you. I was just wondering because it's not the normal way to implement a health checker with a message broker, so it might be a bad pattern to use. But now I suggest this way is the go to way to use. – Alex Won May 03 '21 at 08:40
  • IMO message queues are very much _underutilized_. There are many use cases they're more appropriate for than other techniques (e.g., more popular techniques like REST over HTTP). They provide distinct benefits which are built-in to the message queuing/message broker concept which you might very well otherwise need to provide for yourself for your use case (or use a "framework" which has provided it). I'd always consider the role - all the roles! - of a message broker in a system architecture and use it where it fits. – davidbak May 03 '21 at 08:43
  • (I promoted these comments to an answer.) – davidbak May 03 '21 at 08:50

1 Answers1

2

Sounds like an obvious and easy mechanism for a system like yours that already relies on message queuing. Implement any architecture you want from publishing specific messages to each service - either on a single exchange where every service (as client) looks for himself as the topic, or on an exchange-per-service - or you could simply have an exchange that's read from by the health-check service and all services emit messages periodically (dead man style) to that exchange - and that service just makes sure it hears from anyone once in awhile.

Consider also using rabbit event exchange at your health-check service - so it'll be able to keep track of service connect/disconnects from the channel the service is talking to the exchange with. Channels are suppose to stay up all the time, so a disconnect indicates trouble of some kind - especially if it wasn't preceded by a service (as client) sent message indicating a normal going-down event. In other words, as a health "protocol" - instead of getting polled by a health service, each microservice would be proactive about sending "coming up", "ready", "healthy" (periodically), and "going down" messages to the health service.

As a general comment: In my opinion message queues are very much underutilized. There are many use cases they're more appropriate for than other techniques (e.g., more popular techniques like REST over HTTP). They provide distinct benefits which are built-in to the message queuing/message broker concept which you might very well otherwise need to provide for yourself for your use case (or use a "framework" which has provided it). I'd always consider the role - all the roles! - of a message broker in a system architecture and use it where it fits.

Nimantha
  • 6,405
  • 6
  • 28
  • 69
davidbak
  • 5,775
  • 3
  • 34
  • 50