Saptune solution_enabled follow-up/improvements

[MalloZup]

Currently the metrics we have for saptune_solution are "disappearing".

We should investigate if we can have all other solutions labels set to 0 and the active 1 , then when changes it will change also the state.

Current status:

# HELP saptune_solution_compliant show if current solution applied is compliant 1 or not 0
# TYPE saptune_solution_compliant gauge
saptune_solution_compliant{solution_name="HANA"} 1
# HELP saptune_solution_enabled show the enabled solution's name. 1 means is enabled. disabled metric is absent 
# TYPE saptune_solution_enabled gauge
saptune_solution_enabled{solution_name="HANA"} 1

[stefanotorresi]

@angelabriel can we access somehow the whole list of solutions saptune will check?

[MalloZup]

the list should be here: https://github.com/SUSE/saptune/blob/e68641cecc8dbfa32f970becace8352ac3f541a9/sap/solution/solution.go#L18 via FILE

or even via command line we could have

 saptune solution list

All solutions (* denotes enabled solution, O denotes override file exists for solution, D denotes deprecated solutions):
    BOBJ               - 941735 1771258 2578899 SAP_BOBJ
 *  HANA               - 941735 1771258 1980196 2578899 2684254 2382421 2534844
 D  MAXDB              - 941735 1771258 2578899
    NETWEAVER          - 941735 1771258 2578899
    NETWEAVER+HANA     - 941735 1771258 1980196 2578899 2684254 2382421 2534844
    S4HANA-APP+DB      - 941735 1771258 1980196 2578899 2684254 2382421 2534844
    S4HANA-APPSERVER   - 941735 1771258 2578899
    S4HANA-DBSERVER    - 941735 1771258 1980196 2578899 2684254 2382421 2534844
    SAP-ASE            - 941735 1410736 1680803 1771258 2578899

I have created this follow-up issue basically because I knew it is possible only given time constraints/task and for a first release was to much.

So yep, I think the best solution would just to shell-out things as we do with other metrics, not depending on a filepath which might change and we can do some regex for the whole mechanism to have the solutions names

[stefanotorresi]

@MalloZup have you thought about including saptune as a go library and using the API directly from the Go code, instead of invoking the CLI command? This should make things easier, at some initial cost.

[angelabriel]

saptune was not developed as a library. So it's complicated to use the GO code in this direction. Using saptune as a command gives (for some operations) a better defined CLI. And as discussed previous Sören and I working on a machine readable API, which will make it much easier to consume the saptune output in scripts (for SAP HEC or customers), exporter or other use cases.

[MalloZup]

@stefanotorresi yep is something I initially tried a poc with this and I discussed it with @angelabriel this approach, however it could have been risk to rely on some Public function which might change.

but In this particular case, maybe we could use it.

I did already a similar approach here:

https://github.com/SUSE/saptune_exporter/blob/master/meta_collector.go#L6

https://github.com/SUSE/saptune_exporter/blob/master/meta_collector.go#L39

something could be researched on complex things to avoid regex, but otherwise is better to rely on shell output as more stable. Anyways saptune provide a good parsable output for the metrics we build, not for all corner cases which we could just use some functions or regex.

[stefanotorresi]

saptune was not developed as a library. So it's complicated to use the GO code in this direction. Using saptune as a command gives (for some operations) a better defined CLI. And as discussed previous Sören and I working on a machine readable API, which will make it much easier to consume the saptune output in scripts (for SAP HEC or customers), exporter or other use cases.

I see. Well, I guess we could wait for this functionality then! Would an extra pair of hand be of any use with this regard?