Skip to content

Commit

Permalink
RFC Observability
Browse files Browse the repository at this point in the history
  • Loading branch information
@R-Lawton
R-Lawton committed Jul 25, 2024
1 parent 1c9204a commit 34cb471
Showing 1 changed file with 37 additions and 50 deletions.
87 changes: 37 additions & 50 deletions rfcs/0000-observability-api.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -12,25 +12,25 @@ This is a proposal for a new Kuadrant observability API. Providing a way for use
# Motivation
[motivation]: #motivation

Users of Kuadrant (Platform engineers and or Site reliability engineers) will want a way to be able to opt in or opt out of different aspects of observability. Providing engineers this ability allows them to integrate Kuadrant observability pieces with their own observability stack or Openshift user workload monitoring. Resulting in a fully comprehensive observability view.
Users of Kuadrant (Platform engineers and or Site reliability engineers) will want a way to be able to opt in or opt out of different aspects of observability. Providing users this ability allows them to integrate Kuadrant observability pieces with their own observability stack or Openshift user workload monitoring. Resulting in a fully comprehensive observability view all configured in one location.

# Guide-level explanation
[guide-level-explanation]: #guide-level-explanation

The observability api, will allow a user to choose different parts of the offered Kuadrant observability. This provides more freedom to the user rather then the all or nothing current approach. with the new way the user will only have to fill in their configuration in one location rather the current many locations.
The observability api, will allow a user to choose different parts of the offered Kuadrant observability. This provides more freedom to the user rather then the all or nothing current approach for certain aspects or the manual entry in multiple locations approach. With the new way the user will only have to fill in their configuration in one location.

### Potential configurations

The different aspects a user might want to modify could be the following:

| Observability piece | Kuadrant component | Options |
|-----------------------|-----------------------------------------------------------|---------------------------------------------------------------------------------------|
| Logging | Kuadrant operator, Authorino operator, Limitador Operator | **logLevel**: (string) **logMode**: (string) |
| Tracing | Authorino operator, Limitador operator | **endpoint** (string), **tags** (map[string]string) , **insecure**(bool) ,strageyRules([]String) |
| Metrics | Kuadrant operator, Authorino, Limitador, DNS Operator | **enable** (bool), **port** (int32), **deep** (bool) |
| Alerts * | Kuadrant operator, Authorino, Limitador | **enable** bool |
| Dashboards * | Kuadrant operator, Authorino, Limitador | **enable** bool |
| Other 3rd Party * | e.g Kiali | **enable** bool |
| Observability piece | Kuadrant component | Options |
|-----------------------|-----------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------|
| Logging | Kuadrant operator, Authorino operator, Limitador Operator | **component** (string), **logLevel**: (string) **logMode**: (string) |
| Tracing | Authorino operator, Limitador operator | **component** (string), **endpoint** (string), **tags** (map[string]string) , **insecure**(bool), **strageyRules** ([]String) |
| Metrics | Kuadrant operator, Authorino, Limitador, DNS Operator | **component** (string), **enableService** (bool), **port** (int32), **deep** (bool) |
| Alerts * | Kuadrant operator, Authorino, Limitador | **namespace** (string), **component**(string), **enable** bool |
| Dashboards * | Kuadrant operator, Authorino, Limitador | **namespace** (string), **component**(string), **enable** bool |
| Other 3rd Party * | e.g Kiali | **enable** bool |

###### **Note**: Observability pieces with a * denotes these are post v1 milestone

Expand All @@ -42,14 +42,18 @@ apiVersion: kuadrant.io/v1alpha1
kind: observability
spec:
logging:
logLevel:
authorino: debug
limitador: debug
logMode:
authorino: development
limitador: development
component:
authorino:
logLevel: debug
limitador:
logMode: debug
authorino:
logMode: development
limitador:
logMode: development

tracing:
tracing:
component:
limitador:
endpoint: rpc://tempo.tempo.svc.cluster.local:4317
insecure: true
Expand All @@ -69,7 +73,8 @@ spec:
rule2:
best-rule-in-the-world-2

metrics:
metrics:
component:
authorino:
enableService: true
port: 8080
Expand Down Expand Up @@ -152,6 +157,7 @@ indirectly - Passing the information to Authorino & limitador via the Authorino
indirectly - Passing the information to Authorino & limitador in the form of there own Observability CRs
The best approach would be the indirect approach, meaning once the Observability CR is updated the information is passed to the relevant component CR. For example the tracing section in the Authorino CR spec would be updated with the required endpoints and other configuration in the Observability CR, this would then be updated in the Authorino CR.
#### Adding, modifying and deleting values or no values
If a values is being configure either being added, modified or removed all changes will have to be made in the Observability CR. If the component level operators are updated to change these values without the Observability CR being changed they will be overridden back to the source of truth the Observability CR provides.
Expand All @@ -170,50 +176,31 @@ In terms of if this piece of work would require its own observability controller
The changes will come into full affect through a phased approach due to the nature of some aspects not being available yet. The phased approach can follow the versioning syntax that k8s like v1beta1 or v1alpha1 and be portrayed in the CRD.
### Spec overview
The spec of the custom resource will have the following:
| Observability piece | Options |
|-----------------------|-------------------------------------------------------------------------------------------------------------|
| Logging | **logLevel**: (string) **logMode**: (string) |
| Tracing | **endpoint** *required* (string), **tags** *optional* (map[string]string) , **insecure** (bool) |
| Metrics | **port** (int32), **deep** (bool) |
| Healthz | **port** (int32) |
| Alerts * | **enable** (bool) |
| Dashboards * | **enable** (bool) |
| Other 3rd Party * | **enable** (bool) |
###### **Note**: Observability pieces with a * denotes these are post v1 milestone
### Default configuration
By default if no observability CR is provided the default observability landscape will look like the following:
* Logging: logLevel: **debug**, logMode: **production**
* Metrics: Port **8080**, deep: **false**
* Tracing: insecure**false**
* Console Plugin: **true**
* Alerts: **false**
* Dashboards: **false**
* Healthz: port **8081**
* Other 3rd Party: **false**
By default if no observability CR or if values are left blank the current default values will still be used the plan is to not change these and keep them as is. For new features like alerts and dashboard the default values will folllow the same style and trend as the current approach with some features being disabled by default like the tracing or have certain default value like info for logging for example.
# Rationale and alternatives
[rationale-and-alternatives]: #rationale-and-alternatives
The above approach allows for the following:
* User experience: The observability CR can be easily read to see what the current state of the observability configuration is. Also theres only one place to update rather then multiple.
* Abstraction: The [RFC 0006](https://github.com/Kuadrant/architecture/blob/main/rfcs/0006-kuadrant_sub_components_configurations.md) suggests having it in the Kuadrant CR with other non observability related variables but with new proposed ideas and aspects for observability coming down the line along with the current quite extensive options users can choose from, the Kuadrant CR will become "muddied", hard to maintain and hard to read.
* Future proof: Observability currently is Logging, metrics and tracing but down the line could include a lot more more configuration. Having it has a standalone API allows for us easily add new features.
* Single source of truth: Rather then having multiple crs to check what the current configuration is theres a single source of truth.
* Abstraction: The [RFC 0006](https://github.com/Kuadrant/architecture/blob/main/rfcs/0006-kuadrant_sub_components_configurations.md) suggests having observability in the Kuadrant CR with other non observability related variables. With new proposed ideas and aspects for observability coming down the line and the current quite extensive options users can choose from, the Kuadrant CR will become "muddied", hard to maintain and hard to read.
* Future proof: Observability currently is Logging, metrics and tracing but theres plans for more configuration. Having it has a standalone API allows for engineering to easily add new features.
* Single source of truth: Rather then having multiple crs to check what the current configuration is theres a single source of truth. Preventing users from accidentally changing values by mistake
## Other options:
An other option that has been investigated which is very similar to above, is having observability configuration as a element of the kuadrant CR spec. The majority of the work itself would be largely the same with operators having to move configuration to the Kuadrant CR and having new observability features use the kuadrant CR as the source of truth.
The reason why we should go with the above method is Abstraction. The Kuadrant CR quite quickly can get "muddied" with observability and be harder to read and maintain also losing its main purpose; being the install kick of and maintainer for the kuadrant operators.
The reason why we should go with the above method is Abstraction. The Kuadrant CR quite quickly can get "muddied" with observability and be harder to read and maintain also losing its main purpose; being the install kick of and maintainer for the kuadrant operators as well as the single source of truth aspect. From a user point of view having a users have to change configuration in 3+ separate crs in some cases is tedious and not slow.
If we don't decide to any of these options the user will have to manually in multiple places add there configuration of their desired observability stack which can result in poor user experience, mistakes being made and values not being tracked properly.
If we don't decide to any of these options the user will have to manually in multiple places add there configuration of their desired observability stack.
There was also a previous RFC [RFC 0006](https://github.com/Kuadrant/architecture/blob/main/rfcs/0006-kuadrant_sub_components_configurations.md), that suggests adding everything to the Kuadrant CR, why this RFC should replace the observability aspect are for the reasons stated above:
* Abstraction
* User experience
* Readability
* Adding to much to the Kuadrant CR
# Prior art
[prior-art]: #prior-art
Expand All @@ -223,5 +210,5 @@ Manually adding configuration to Kuadrant operator crs.
# Future possibilities
[future-possibilities]: #future-possibilities
Currently we only have configuration for Logging, Tracing, Healthz and Metrics but with the v1 milestone theres opportunity to add more pieces like the dynamic plugin. Post v1 the plan is to add alerts, dashboards and potentially other 3rd party like Kiali
Currently we only have configuration for Logging, Tracing and Metrics. Post v1 the plan is to add alerts, dashboards and potentially other 3rd party like Kiali

0 comments on commit 34cb471

Please sign in to comment.