Project

General

Profile

Actions

action #68758

open

[functional][qe-core] create grafana instance for mean cycle and lead times

Added by jorauch over 3 years ago. Updated almost 2 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
Target version:
Start date:
2020-07-08
Due date:
% Done:

0%

Estimated time:

Description

For the metrics project we want to collect mean and cycle times in the qa team.
We can reuse the python scripts from QSFU and use its output for grafana


Related issues 1 (0 open1 closed)

Related to openQA Infrastructure - action #68785: [monitoring] Setup of QA generic monitoring instanceResolvedokurz2020-07-09

Actions
Actions #1

Updated by szarate over 3 years ago

I think we already have a running grafana instance that can be used for the time being (tools team instance), I'll ping okurz to get details on how to access it

Actions #2

Updated by okurz over 3 years ago

yes, we have an instance https://stats.openqa-monitor.qa.suse.de/ running on the VM "openqa-monitor" on qamaster. The accounts on the grafana server are manually maintained. You are welcome to try to login. Then I should be able to add a role to your account(s). Otherwise maybe I need to add the account(s) first. Correction: accounts are managed using LDAP but were missing from salt, fixed with https://gitlab.suse.de/openqa/salt-states-openqa/-/merge_requests/336 Anyone with a SUSE LDAP entry can login. After login I can add corresponding roles to your account(s). Grafana dashboards can be created in the webUI. To properly manage them after initial experimentation we should provision the dashboards same as we do for openQA. For this you can export the dashboards to JSON over the webUI and save them in gitlab.suse.de/openqa/salt-states-openqa/tree/master/openqa/monitoring/grafana and mention new files in https://gitlab.suse.de/openqa/salt-states-openqa/-/blob/master/openqa/monitoring/grafana.sls#L5

As these metrics are not directly related to openQA though I think another instance might be more suited. I might be able to setup something and will inform you in this case.

Actions #3

Updated by okurz over 3 years ago

There is a test instance of grafana available now on http://1c036.qa.suse.de:3000/ . Use the username "admin" and password "susetesting" to create your own users and then feel free to play around and do whatever you want and can with grafan. The data is not-persistent and no guarantees on uptime given :)

EDIT: Btw, there also exists https://grafana.com/signup/cloud/select-org so you can just create grafana instances yourself for trying out as you want to query data from a public issue tracker or github for testing.

Actions #4

Updated by jorauch over 3 years ago

  • Status changed from Workable to In Progress

Thank you very much for providing these infos and the instance

Actions #5

Updated by jorauch over 3 years ago

I cannot connect to the instance via SSH ssh jrauch@1c036.qa.suse.de -p 3000 after I created that user
However all the tutorials tell me to use the grafana-cli to install the JSON plugin
Am I overlooking something or is this supposed to work differently?

Actions #6

Updated by okurz over 3 years ago

Normally servers listen on one port with only one service :) port 3000 is http, not ssh. You can login over the webui and install plugins there, that should suffice.

Actions #7

Updated by jorauch over 3 years ago

I can find neither under data sources nor under plugins a JSON plugin (only on the grafana hompeage where it suggests the CLI) that's why I tried it via SSH

Actions #8

Updated by szarate over 3 years ago

I've set up a grafana instance for testing at http://10.162.168.44:3000, using admin/susetesting as credentials

Actions #9

Updated by jorauch over 3 years ago

  • Related to action #68785: [monitoring] Setup of QA generic monitoring instance added
Actions #10

Updated by okurz over 3 years ago

if you want to setup a grafana instance locally real quick something like this should suffice: podman run --rm -it -p 3000:3000 -v my_grafana_dir:/var/lib/grafana grafana/grafana . this will export your folder my_grafana_dir into the container so that you can also experiment freely with plugins, etc. . We can also install plugins on our production instance but we should test it first before you add it to salt like in https://gitlab.suse.de/openqa/salt-states-openqa/-/blob/master/openqa/monitoring/grafana.sls#L92

Actions #11

Updated by okurz over 3 years ago

btw, what are the plans with the still existing but still shutdown VM qsfu.qa.suse.de?

Actions #12

Updated by jorauch over 3 years ago

  • Due date deleted (2020-07-22)

I have nothing to do with this instance, we would need to ask mgriessmeier or nsinger about this
I will try to set up the influxdb without a container to avoid unnecessary complexity until we go into production

Actions #15

Updated by jorauch over 3 years ago

Doings: Run it on the productive instance and group by project

Actions #16

Updated by jorauch over 3 years ago

  • Status changed from In Progress to Feedback

Created a cronjob on openqa-monitor.qa.suse.de running under my user in my home
Now waiting for feedback from ralf and need to put it into salt

Actions #17

Updated by tjyrinki_suse over 3 years ago

  • Subject changed from [functional][u] create grafana instance for mean cycle and lead times to [qe-core][functional] create grafana instance for mean cycle and lead times
Actions #18

Updated by tjyrinki_suse about 3 years ago

  • Project changed from 46 to 205
  • Subject changed from [qe-core][functional] create grafana instance for mean cycle and lead times to [performance][functional] create grafana instance for mean cycle and lead times

Adjusting to the new squad structure, correct if wrong.

Actions #19

Updated by zyuhu about 3 years ago

tjyrinki_suse wrote:

Adjusting to the new squad structure, correct if wrong.

Hello, QE-performance squad is responsible for SLES performance and sap hana performance testing.
For this issue, could anyone help me to understand the background. If not SLES or sap hana performance related, then it should be moved to proper squad.

Actions #20

Updated by jorauch about 3 years ago

Hello,

this does not belong to QA Performance as this was an own side project (QA metrics) last year.
From my point of view we can even close it, as the work described is done.
If you need to know more about the metrics project you can ask Santi or Ralf

Actions #21

Updated by szarate about 3 years ago

  • Project changed from 205 to QA
  • Subject changed from [performance][functional] create grafana instance for mean cycle and lead times to [functional] create grafana instance for mean cycle and lead times

The word performance should have never been in the title :)

Actions #22

Updated by okurz almost 3 years ago

  • Subject changed from [functional] create grafana instance for mean cycle and lead times to [functional][qe-core] create grafana instance for mean cycle and lead times
  • Assignee changed from jorauch to tjyrinki_suse

@tjyrinki_suse I think the latest change was overlooked. At the time jorauch worked for "functional", nowadays "qe-core". So to me the question would be: Does the approach still work for QE-Core?

What I see missing from my point of view:

  • Putting configuration into salt
  • Fixing the queries to update the data as there is currently no data received
  • Adjust the queries to query team specific data, not based on progress projects
Actions #23

Updated by okurz almost 3 years ago

  • Target version set to QE-Core: Ready
Actions #24

Updated by tjyrinki_suse over 2 years ago

  • Assignee changed from tjyrinki_suse to szarate

If this hasn't been replaced by some other plan, the https://github.com/DrMullings/Scripts-Snippets-Stuff/blob/master/Kanban/TimesToGrafana.py sounds fine even if queried need to be fixed.

Actions #25

Updated by tjyrinki_suse almost 2 years ago

  • Target version deleted (QE-Core: Ready)

Putting back to product backlog.

Actions #26

Updated by okurz almost 2 years ago

  • Target version set to future
Actions

Also available in: Atom PDF