You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe
The goal of kobs is it to simplify the operation of services on Kubernetes by providing the concept of applications. This way all the important information for a service like metrics, logs, traces and alerts can be find in one place. It would be nice when these information can also be connected via integrations.
An integration should allow users to connect all information of a service on a plugin level, for example:
When a log line in the klogs plugin contains a field named traceID, it should be possible to open the corresponding trace in the Jaeger plugin.
When a span from Istio in the Jaeger plugin contains a tag guid:x-request-id=628d57f7-1978-99f1-aace it should be possible to open the corresponding access logs in the klogs plugin (content.request_id='628d57f7-1978-99f1-aace').
When we collect the "default" Kubernetes metrics like resource usage of a Pod / Container or the usage of a PVC, it should be possible to add these information to the corresponding pods, without that a user has to add the dashboard annotation to each Pod. This can also be done for the status metrics of a Deployment, StatefulSet, DaemonSet, etc.
Describe the solution you'd like
These integration should be configured in the kobs configuration file in the section of each plugin, which means that we can add a new integrations field to the configuration of each plugin, which should support this feature.
To have not that much breaking changes in the plugin configurations in the future, we should have a "scaleable" solution for this feature in place. Currently my preferred way of implementing this, is to add a type field for each integration, where we can then use the type name as another key to define the options for the integration. We are already using this schema in various places, e.g. the provider configuration of clusters:
Add a new integrations feature for kobs. In this first iteration we
implemented the suggested integrations feature from #255 for Kubernetes
Resources.
This integration allows an administrator of kobs to add a set of default
dashboards to Kubernetes Resources. This way we can add for example a
resource usage dashboard to all Pods, without that each Pod must have
the "kobs.io/dashboards" annotation.
The configured dashboards in the integrations and the dashboards from
the "kobs.io/dashboards" annotation are always merged and not
overwritte.
Add a new integrations feature for kobs. In this first iteration we
implemented the suggested integrations feature from #255 for Kubernetes
Resources.
This integration allows an administrator of kobs to add a set of default
dashboards to Kubernetes Resources. This way we can add for example a
resource usage dashboard to all Pods, without that each Pod must have
the "kobs.io/dashboards" annotation.
The configured dashboards in the integrations and the dashboards from
the "kobs.io/dashboards" annotation are always merged and not
overwritte.
Is your feature request related to a problem? Please describe
The goal of kobs is it to simplify the operation of services on Kubernetes by providing the concept of applications. This way all the important information for a service like metrics, logs, traces and alerts can be find in one place. It would be nice when these information can also be connected via integrations.
An integration should allow users to connect all information of a service on a plugin level, for example:
traceID
, it should be possible to open the corresponding trace in the Jaeger plugin.guid:x-request-id=628d57f7-1978-99f1-aace
it should be possible to open the corresponding access logs in the klogs plugin (content.request_id='628d57f7-1978-99f1-aace'
).Describe the solution you'd like
These integration should be configured in the kobs configuration file in the section of each plugin, which means that we can add a new
integrations
field to the configuration of each plugin, which should support this feature.To have not that much breaking changes in the plugin configurations in the future, we should have a "scaleable" solution for this feature in place. Currently my preferred way of implementing this, is to add a
type
field for each integration, where we can then use the type name as another key to define the options for the integration. We are already using this schema in various places, e.g. the provider configuration of clusters:kobs/pkg/api/clusters/provider/provider.go
Line 27 in e81cb3c
The text was updated successfully, but these errors were encountered: