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

feat: Kyma stats receiver #45

Merged
merged 67 commits into from
Jul 4, 2024
Merged

Conversation

hisarbalik
Copy link
Contributor

@hisarbalik hisarbalik commented Jun 25, 2024

Description

Changes proposed in this pull request (what was done and why):

  • Add new OTEL metric receiver kymastatsreceiver
  • By default scrape Kyma Telemetry module status, and emit two metrics kyma.module.status.conditions and kyma.module.status.state
  • Add support for authentication methods via service account or kubeconfig

Changes refer to particular issues, PRs or documents:

Traceability

  • The PR is linked to a GitHub issue.
  • The PR has a milestone set.
  • The PR has a respective area and kind label.
  • The follow-up issues (if any) are linked in the Related Issues section.
  • If the change is user-facing, the documentation has been adjusted.
  • The feature is unit-tested.
  • The feature is e2e-tested.

@hisarbalik hisarbalik requested a review from a team as a code owner June 25, 2024 15:54
@kyma-bot kyma-bot added cla: yes Indicates the PR's author has signed the CLA. size/XL labels Jun 25, 2024
@hisarbalik hisarbalik added do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. kind/feature New feature or request area/kymastatsreceiver kyma-stats-receiver area/documentation Improvements or additions to documentation and removed size/XL labels Jun 25, 2024
@hisarbalik hisarbalik requested a review from a team as a code owner June 26, 2024 06:28
@kyma-bot kyma-bot added size/XXL and removed size/XL labels Jun 26, 2024
@hisarbalik hisarbalik requested a review from NHingerl July 4, 2024 09:49
NHingerl
NHingerl previously approved these changes Jul 4, 2024
@skhalash skhalash requested a review from NHingerl July 4, 2024 14:04
@skhalash
Copy link
Collaborator

skhalash commented Jul 4, 2024

/hold

@kyma-bot kyma-bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jul 4, 2024
@hisarbalik hisarbalik removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jul 4, 2024
return nil, &fieldNotFoundError{"state"}
}

unstructuredConds, found, err := unstructured.NestedSlice(status, "conditions")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are conditions really mandatory (included in the kyma module contract)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no kyma module contract about the status conditions

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And with that they are not mandatory

return nil, errors.New("condition is not a map")
}

condType, found, err := unstructured.NestedString(condMap, "type")
Copy link
Contributor

@k15r k15r Jul 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

all the following code is based on the expectation that the conditions implement fields similar to metav1.conditions. This is not mandatory. We should not fail if a module either does not implement conditions at all, or if those conditions do not follow the same patterns as metav1.conditions (even though it is recommended that conditions are based on metav1)

Here are all requirements that i could find: https://github.com/kyma-project/template-operator?tab=readme-ov-file#api-definition-steps

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We assume that the CR has metav1.condition implementation. When a CR has no metav1.condition implementation is not scrapeable

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so in the end, even though there is no real contract (and it would be quite simple for us to exclude the conditions for such modules) we just fail with scraping for those modules?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In case a module doe not have conditions or is not following the conventions, we should just skip that part, the same way as we skip when we cannot find a resource for a module CRD

@kyma-bot kyma-bot merged commit 4c6a0bd into kyma-project:main Jul 4, 2024
14 checks passed
@a-thaler a-thaler added this to the 1.20.0 milestone Jul 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/documentation Improvements or additions to documentation area/kymastatsreceiver kyma-stats-receiver cla: yes Indicates the PR's author has signed the CLA. kind/feature New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants