Project: Capsule (Orchestration & Management / Scheduling & Orchestration)
File: monitoring.md

The Capsule dashboard allows you to track the health and performance of Capsule manager and tenants, with particular attention to resources saturation, server responses, and latencies. Prometheus and Grafana are requirements for monitoring Capsule. Prometheus is an open-source monitoring system and time series database; it is based on a multi-dimensional data model and uses PromQL, a powerful query language, to leverage it. Minimum version: 1.0.0 Grafana is an open-source monitoring solution that offers a flexible way to generate visuals and configure dashboards. Minimum version: 7.5.5 To fastly deploy this monitoring stack, consider installing the . The Capsule Helm allow you to automatically create Kubernetes minimum resources needed for the proper functioning of the dashboard: ServiceMonitor Role RoleBinding N.B: we assume that a ServiceAccount resource has already been created so it can easily interact with the Prometheus API. During Capsule installation, set the `serviceMonitor` fields as follow: ```yaml serviceMonitor: enabled: true [...] serviceAccount: name: <prometheus-sa> namespace: <prometheus-sa-namespace> ``` Take a look at the Helm charts file for further customization. Verify that the service monitor is working correctly through the Prometheus "targets" page : A dashboard for Grafana is provided as . Render with `kustomize` the dashboard as a ConfigMap and apply in the namespace where Grafana is installed, making sure to select the correct Prometheus datasource: ``` kubectl -n <grafana-namespace> apply -k config/grafana ``` Alternatively, manual upload the dashboard in JSON format to Grafana through Create -> Import: This section provides information about the medium time delay between manager client input, side effects, and new state determination (reconciliation). Controller name capsuleconfiguration clusterrole clusterrolebinding endpoints endpointslice secret service tenant This section provides information about webhook requests response, mainly focusing on server-side errors research. Webhook cordoning ingresses namespace-owner-reference namespaces networkpolicies persistentvolumeclaims pods services tenants This section provides information about the medium time delay between webhook trigger, side effects, and data written on etcd. Webhook cordoning ingresses namespace-owner-reference namespaces networkpolicies persistentvolumeclaims pods services tenants This section provides information about the medium time delay between all the calls done by the controller and the API server. Data display may depend on the REST client verb considered and on available REST client URLs. YMMV REST client URL REST client verb GET PUT POST PATCH DELETE This section provides information about client total rest requests response per unit time, grouped by thrown code. This section provides information about resources, giving a detailed picture of the systems state and the amount of requested work per active controller. This section provides information about "actions" in the queue, particularly: Workqueue latency: time to complete a series of actions in the queue ; Workqueue rate: number of actions per unit time ; Workqueue depth: number of pending actions waiting in the queue.