gatus icon indicating copy to clipboard operation
gatus copied to clipboard

Support service agents

Open epoberezkin opened this issue 2 years ago • 3 comments

Describe the feature request

Currently the service itself should be queried by Gatus in order to determine its response time / availability.

There are more complex services that require a standalone "agent" application to determine service availability from "business logic" point of view – e.g., it can be determined as a sequence of service requests rather than just one request, and the service "delay" is the time of transaction and not the time of one request.

The proposal is NOT to complicate the logic of Gatus to allow all possible scenarios, but rather add support for endpoint agents when:

  • the server state is displayed based on the content of the response from the agent, and not the response time.
  • the time of agent response is not taken into account, the lack of agent response is treated as "no information" (grey color) rather than as "service down"

Why do you personally want this feature to be implemented?

We are looking for an open-source solution to present the status of preset servers in https://simplex.chat apps to the end users - this can only be done via agent, as we need to test that the message is actually delivered and show e2e delivery time, rather than just that the server responds to PING or anything else.

How long have you been using this project?

evaluating

Additional information

We can sponsor this feature - not to cover all costs though, but we would sponsor say $100.

epoberezkin avatar Feb 17 '23 10:02 epoberezkin

alternatively it could be status update API I guess to achieve the same...

epoberezkin avatar Feb 17 '23 12:02 epoberezkin

Because of the fact that users could be monitoring pretty much anything, I don't think creating agents for each individual use case would be appropriate. Instead, as you've pointed out, something like #229 would make more sense, as even if we decide to create agents in the future, #229 would still likely be necessary.

TwiN avatar Feb 21 '23 00:02 TwiN

This will become possible once #724 is merged

TwiN avatar Apr 07 '24 23:04 TwiN