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

Prometheus metrics when making API calls are inconsistent #997

Closed
macaptain opened this issue Sep 15, 2021 · 1 comment · Fixed by #1003
Closed

Prometheus metrics when making API calls are inconsistent #997

macaptain opened this issue Sep 15, 2021 · 1 comment · Fixed by #1003
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@macaptain
Copy link
Contributor

/kind bug

What steps did you take and what happened:

Prometheus metrics for OpenStack API calls are made throughout the codebase as mc.ObserveRequest(err) calls. They're inconsistent in places:

  • Sometimes we make a call without recording a metric
  • Sometimes deletion events which return 404 (not found) are recorded as errors and sometimes not
  • ReplaceAttributes call is recorded as 'trunk update', but it should probably be recorded as its own type

What did you expect to happen:
Ideally all Prometheus metric counters for OpenStack API calls are consistent.

After refactoring the networking logic into a separate client (#935), metrics recordings for networks can be tidied up from around the codebase and all put in client.go. If we apply a similar refactor to the compute package, we should be able to move all the metrics package usage into client implementation files only and see that all the metrics gathering is consistent.

Environment:

  • Cluster API Provider OpenStack version (Or git rev-parse HEAD if manually built): 754371d
  • Cluster-API version:
  • OpenStack version:
  • Minikube/KIND version:
  • Kubernetes version (use kubectl version):
  • OS (e.g. from /etc/os-release):
@k8s-ci-robot k8s-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Sep 15, 2021
@jichenjc
Copy link
Contributor

@macaptain you are right, we should move the code into one place so that we can handle all the logic well
so yes, refactor of compute node is something better to have (for ut andmetrics collection both)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants