... | @@ -59,7 +59,7 @@ However, we should redesign the callout signature. It should be strongly typed b |
... | @@ -59,7 +59,7 @@ However, we should redesign the callout signature. It should be strongly typed b |
|
|
|
|
|
In the Kea layout, the hook is a set of callout functions. It means that we need to search each callout by name. We must share between the core and hook the type (function signature) and the identifier (function name). In Go, the hook can provide an object that will be tested for implementing expected hook interfaces. We don't need to use any identifiers.
|
|
In the Kea layout, the hook is a set of callout functions. It means that we need to search each callout by name. We must share between the core and hook the type (function signature) and the identifier (function name). In Go, the hook can provide an object that will be tested for implementing expected hook interfaces. We don't need to use any identifiers.
|
|
|
|
|
|
Opened question is how to exchange data between hooks registered on the same callout. This problem is discussed in the next section. The specific solution needs to be chosen based on the hook characteristics.
|
|
The following section discusses exchanging data between hooks registered on the same callout. The specific solution needs to be chosen based on the hook characteristics.
|
|
|
|
|
|
We probably need to implement something similar to the `LibraryManager` from Kea to manage the hooks. We also need the `HooksManager` to register and call the hook callouts.
|
|
We probably need to implement something similar to the `LibraryManager` from Kea to manage the hooks. We also need the `HooksManager` to register and call the hook callouts.
|
|
|
|
|
... | @@ -343,6 +343,24 @@ Supported operations: |
... | @@ -343,6 +343,24 @@ Supported operations: |
|
- `GET /hooks/{id}` - get the details about a specific hook, including the loading status with occurred errors
|
|
- `GET /hooks/{id}` - get the details about a specific hook, including the loading status with occurred errors
|
|
- `PUT /hooks/{id}` - edit hook, i.e., activate/deactivate hook (reload/unload), change the hook parameters
|
|
- `PUT /hooks/{id}` - edit hook, i.e., activate/deactivate hook (reload/unload), change the hook parameters
|
|
|
|
|
|
|
|
## Hook monitoring
|
|
|
|
|
|
|
|
The hook frameworks should provide a monitoring solution. The hook executor should collect diagnostics information for each hook/callout, e.g., how much time the application spends running a specific callout.
|
|
|
|
|
|
|
|
The hook REST endpoint may expose these statistics. They may be included in the data exported to the Prometheus too.
|
|
|
|
|
|
|
|
Proposed statistics:
|
|
|
|
|
|
|
|
- Total execution time of the hook callout point
|
|
|
|
- Average execution time
|
|
|
|
- Minimal execution time
|
|
|
|
- Maximal execution time
|
|
|
|
- Number of the hook callout calls
|
|
|
|
- Number of the callout calls (in some cases, the execution of the hooks may be interrupted, and a specific hook is not called; it may help diagnose problems with the hook order)
|
|
|
|
- Index of the hook in a list of hooks registered on a given callout point
|
|
|
|
|
|
|
|
There should also be statistics collected per callout to monitor performance across hooks. It may be helpful to detect callouts that are extensively used or have too many responsibilities and should be refactored for better performance.
|
|
|
|
|
|
## Steps to implement hook
|
|
## Steps to implement hook
|
|
|
|
|
|
1. Look for needed callout points in the hook module
|
|
1. Look for needed callout points in the hook module
|
... | | ... | |