Health Endpoint Design Document #2503
Conversation
sezal98
requested review from
Aniruddh25,
aaronburtle,
abhishekkumams,
RubenCerna2079,
ravishetye,
rohkhann,
neeraj-sharma2592 and
sourabh1007
as code owners
|
How would the health endpoint will function with hot reload? In case of bad config it might use last good known config which might give wrong status. Would be good to add limitations. |
I dont see an issue in this, If DAB Engine is working then health point should be consistent with that. If DAB engine is using the last known config, then health endpoint would also show the health of the last known config. Another important point to note is.. Health is independent of Validity of config. Health endpoint is only shown when the config is valid (no errors) and DAB engine is running. So the case of bad config would not occur. @JerryNixon , Any thoughts on this? |
Thanks for clarifying. can you add the same to your documentation as well. |
|
How will we be checking if an endpoint is healthy or not? Are we gonna make a db call internally? Or hit the endpoint itself to check the status? Or something else? |
Yes, as mentioned in the document, we would be making the call internally and hitting the specified query. If this query is sucessfull and within the threshold specified, the entity would be considered healthy. Else, we would say, its unhealthy with the exception message |
| | `enabled` | Boolean | No | `true` | Enables or disables health checks at the runtime level. | | ||
| | `cache-ttl` | Integer | No | `5` | Time-to-live (in seconds) for caching health check results. | | ||
| | `max-dop` | Integer | No | `1` | Maximum Degree of Parallelism for running health checks. | | ||
| | `roles` | Array | No | `*` | Roles allowed to access the health endpoint (e.g., `anonymous`, `authenticated`). | |
There was a problem hiding this comment.
What does the * mean?
|
|
||
| #### `data-source.health` Configuration | ||
|
|
||
| The data source config parameters specify the query that we should run on the data source and the threshold of ms if should come under to qualify as a healthy data source for DAB. |
There was a problem hiding this comment.
Change if to it
| The data source config parameters specify the query that we should run on the data source and the threshold of ms if should come under to qualify as a healthy data source for DAB. | |
| The data source config parameters specify the query that we should run on the data source and the threshold of ms it should come under to qualify as a healthy data source for DAB. |
|
|
||
| #### `<entity-name>.health` Configuration | ||
|
|
||
| The Entity config parameters contain information about the GET filter or query which needs to be carried out on the data source entiy and under what threshold should the response be received for it to qualify as a healthy entity. |
There was a problem hiding this comment.
Should be entity
| The Entity config parameters contain information about the GET filter or query which needs to be carried out on the data source entiy and under what threshold should the response be received for it to qualify as a healthy entity. | |
| The Entity config parameters contain information about the GET filter or query which needs to be carried out on the data source entity and under what threshold should the response be received for it to qualify as a healthy entity. |
| The objective of this task is to enhance the "Health Endpoint" for DAB. Currently we only show whether the DAB Engine is healthy or not and which version of DAB is running. However, the objective under this task item is to enhance this to support delatiled description of each supported (enabled) endpoint with all different kinds of parameters that would be defined below. | ||
|
|
There was a problem hiding this comment.
Should be detailed instead of delatiled
| The objective of this task is to enhance the "Health Endpoint" for DAB. Currently we only show whether the DAB Engine is healthy or not and which version of DAB is running. However, the objective under this task item is to enhance this to support delatiled description of each supported (enabled) endpoint with all different kinds of parameters that would be defined below. | |
| The objective of this task is to enhance the "Health Endpoint" for DAB. Currently we only show whether the DAB Engine is healthy or not and which version of DAB is running. However, the objective under this task item is to enhance this to support detailed description of each supported (enabled) endpoint with all different kinds of parameters that would be defined below. | |
| | **Property** | **Data Type** | **Required** | **Default** | **Description** | | ||
| |------------------|---------------|--------------|-------------|------------------------------------------------------------------------------------------------------| | ||
| | `enabled` | Boolean | No | `true` | Enables or disables health checks for the specific entity. | | ||
| | `filter` | String | No | `null` | Filter condition applied to the health check query (e.g., `"Id eq 1"`). | |
There was a problem hiding this comment.
Why would we need a filter for the health check?
| "health" : { | ||
| "moniker": "sqlserver", (optional default: NULL) // not required, on purpose, most have just one | ||
| "enabled": true, (default: true) | ||
| "query": "SELECT TOP 1 1", (option) | ||
| "threshold-ms": 100 (optional default: 10000) |
There was a problem hiding this comment.
I think it might be good to show how it would look like when there are multiple data-source
| "status": "Unhealthy", | ||
| "status": "Healthy", |
There was a problem hiding this comment.
Why are there 2 status?
Why make this change?
Design DOcument for Health Endpoint
Resolves: 2504
What is this change?
How was this tested?
Sample Request(s)