Feature: Filtering Rule for HTTP requests payload (like on emails)

[Tobias Nordahl Kristensen]

Hi,

I'd like to see it possible to filter the HTTP request for a specific value, as it's currently possible with emails.

I've not spotted this in the current solution.

I'm using a solution where I can create a webhook, but not control other than "on job run". So I'd like to use healthcheck to filter the content, on basis of the payload (like if it contains "success" or similar).

I would be great to see a JSON parsed, however, using plain-text should possibly also work :)

Thank you for making this. I actually enjoy how simple it is it work with.

Example data

Here's one Request Body for the application I'm trying to Filter (JSON formatted for easier reading).

The first one are the "job done" post, where I'd like to look to match the params.vms.id and result.

Solution one would be to look after VM_ID_I_NEED_TO_MATCH_GOES_HERE in the text, and "result":true in the text, too (so more than one check), or have the JSON parsed, and define the result nested_key, including a mandatory information to be part of the payload, before healthchecks will acknowledge the requests as related to the current check.

Example for "Job Done", I need to acknowledge as a success

Requirements:

• VM_ID_I_NEED_TO_MATCH_GOES_HERE needs to be part of the payload
• Result should be true

For both requirements, it should be possible to just cheat the payload as a string, without having to use a JSON parser or similar. But two different requirements need to be allowed as a user-input (or a regex sting, maybe?... I mean.. Keep is simpel stupid, if that's the easiest thing to do).

{
   "callId":"CALL_ID_GOES_HERE",
   "method":"backupNg.runJob",
   "params":{
      "id":"SECRET_ID_GOES_HERE",
      "schedule":"SCHEDULER_ID_GOES_HERE",
      "settings":{
         "SETTINGS_ID_GOES_HERE":{
            "snapshotRetention":5
         }
      },
      "vms":{
         "id":"VM_ID_I_NEED_TO_MATCH_GOES_HERE"
      }
   },
   "timestamp":1709391402615,
   "userId":"USER_ID_GOES_HERE",
   "userName":"admin",
   "result":true,
   "duration":15735,
   "type":"post"
}

Here's another example. Note the difference in the vms "array", which looks a bit odd, but, that's how it's reported.
Therefore, the plain-text validator are OK with me, I guess.

Again, more real-world like data. I've just replaced letters and stuff like that.

{
   "callId":"222h2akasaa",
   "method":"backupNg.runJob",
   "params":{
      "id":"fccd0fbb-5ba8-47fd-9e44-401a1f10c474",
      "schedule":"2a029a93-0f6d-4a10-891f-0a891041eeec",
      "settings":{
         "6d564d15-3d24-40e4-aa81-5c7df522def9":{
            "exportRetention":1
         }
      },
      "vms":{
         "id":{
            "__or":[
               "bcdff841-c452-4eee-af61-5b8fddc3318b",
               "083ac012-06ea-44f8-96e4-93b4731328e4",
               "2c1ed51f-67bc-4306-b8f6-c080ee9221d9",
               "8577151d-c758-49ce-a177-ad29d3e5fec2",
               "f3c60996-418a-41f3-a246-aad3731e5c84",
               "25d04cd3-292e-430d-85db-c67f1ecc45b0"
            ]
         }
      }
   },
   "timestamp":1709396008102,
   "userId":"9a9758c5-233d-4a69-84e6-7b62ba522895",
   "userName":"admin",
   "result":true,
   "duration":4645273,
   "type":"post"
}

Another example

Here's another example, which I'd need to maybe acknowledge,or maybe ignore, on basis of the "result" value, and the
params.id value (a22aa300-2310-11dd-a222-2201aa1101b1) value.

{
   "callId":"CALL_ID_GOES_HERE",
   "userId":"USER_ID_GOES_HERE",
   "userName":"admin",
   "userIp":"::USER_IP_GOES_HERE",
   "method":"backupNg.runJob",
   "params":{
      "id":"ID_GOES_HERE",
      "schedule":"SCHDEULE_ID_GOES_HERE"
   },
   "timestamp":1709391402650,
   "duration":15776,
   "result":true,
   "type":"post"
}

With more "real world" data:

{
   "callId":"1ab2abcdaa2a",
   "userId":"USER_ID_GOES_HERE",
   "userName":"admin",
   "userIp":"::REMOVED",
   "method":"backupNg.runJob",
   "params":{
      "id":"a22aa300-2310-11dd-a222-2201aa1101b1",
      "schedule":"a3cfd101-faaa-12c2-bbd1-12b22c22eaa1"
   },
   "timestamp":1709396008114,
   "duration":4645290,
   "result":true,
   "type":"post"
}

[Pēteris Caune]

Hello @exetico, thanks for the suggestion and for the examples.

Are you working with Xen Orchestra? Looking at its docs, there appears to be an email alerts functionality: https://xen-orchestra.com/docs/advanced.html#alerts Perhaps you can use that, and the existing email keyword filtering functionality?

Doing complex evaluation of JSON messages (e.g., if field x is "foo" and field y is "bar") is out of scope for this project.

Interestingly, somebody semi-recently suggested Healthchecks could run client-supplied WASM code to process incoming requests. I think this would be a perfect use case for something like that, but I currently have no near-term plans to add that. Perhaps sometime in the future, if running client's WASM becomes industry standard, and expected "table-stakes" feature, and is easy to implement.

You could look into using AWS Lambda or Cloudflare Workers or a similar FaaS: XO would send the webhook to your function. The function would parse the JSON, check the fields for correct values, and then call Healthchecks' success or failure URL.