Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kyma module health as metric input #1389

Open
4 tasks
a-thaler opened this issue Aug 26, 2024 · 0 comments
Open
4 tasks

Kyma module health as metric input #1389

a-thaler opened this issue Aug 26, 2024 · 0 comments
Labels
area/metrics MetricPipeline kind/feature Categorizes issue or PR as related to a new feature. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.

Comments

@a-thaler
Copy link
Collaborator

Description
A Kyma module by design has an operational health. Also the entities managed by the module are having a health usually. When users want to get an overview of it from a monitoring perspective, they could start collecting the mtrics of a module to gather insights. However, often the metrics are providing insides about the operational health and not so much about the business health. The fact that a ServiceBinding of the BTP Operator is in a bad state will not be reflected. So a user would need to set up kube-state-metrics or alike and start collecting the status of all the involved resources, push them to a backend and start creating dashboards.

Instead Kyma should provide out-of-the-box monitoring capabilities for the modules so that users easily can figure out if some resource is in an unhealthy state. That should be possible in a similar way as it was realized for the telemetry module in #728, so having an API to enable metric collection for any Kyma module.

If enabled, the telemetry module could discover all modules via the moduleTemplates, determine the moduleCR status and all module subresource statuses. In Cloud Logging prepared Dashboards will show the module health.

apiVersion: telemetry.kyma-project.io/v1alpha1
kind: MetricPipeline
metadata:
  name: icke
spec:
  input:
    kyma:
      enabled: true

Tasks

  • Preparation
    • Enforce a well-defined contract about the module status to rely on
    • Assure that subresources are listed in the moduleTemplates for all modules
  • Implementation

Reasons

Attachments

Release Notes


@a-thaler a-thaler added kind/feature Categorizes issue or PR as related to a new feature. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. area/metrics MetricPipeline labels Aug 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/metrics MetricPipeline kind/feature Categorizes issue or PR as related to a new feature. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.
Projects
None yet
Development

No branches or pull requests

1 participant