docs(scim): create documentation for SCIM monitoring

[ossdhaval]

General Guidelines

• Start by covering the general definition of the feature in a few lines and then point to the appropriate section of the SPEC. Please refrain from repeating what is there in the SPEC already.
• Try to make the content Janssen Server specific ( e.g. what are the related Janssen Server properties or feature flags, how to change relevant settings using TUI/command line (use the screenshots), recommendations around recommended values, use-cases)
• Follow the documentation contribution guidelines.
• Feel free to refer to content available in Gluu documentation (or any other IDP) if the content doesn't need to be customized for Janssen Server

Document Location

https://docs.jans.io/head/admin/scim/monitoring/

Suggested sections

Gluu documentation has SCIM related content. Search for SCIM to find relevant content for this document.

[nynymike]

I guess we need to know if the service is healthy, and in order to do that, just checking to see if the service is listening is probably not enough. A good monitoring service would excercise the database for at least a READ operation, and possible for a WRITE/DELETE operation.

Most monitoring systems can make HTTPS calls to services. But to call the SCIM endpoints, an OAuth token is needed. Perhaps we could provide a shell script that uses curl to show what is needed? And then people can figure out how to use that script or to implement something similar in their monitoring system.

[ossdhaval]

@jgomer2001 for comments.

I have seen monitoring services of two types primarily:

• Heartbeat (lightweight, can be called frequently)
• Statistics (I don't think we have this in mind for SCIM)

So, what @nynymike is proposing is somewhere in the middle. A heartbeat but which checks DB health as well.

We should keep in mind the usage pattern of a monitoring service when considering adding database interaction to it. The monitoring service may get called by a UI tool on a frequent basis. For example, to show a green-dot. Here they are expecting a heartbeat service with a quick response. Adding DB interaction may:

• Add delay to the response
• If called too frequently, may add additional overhead on the DB.

Net-net, I would suggest having two different services for each purpose.