OOP refactor #4
Closed
OOP refactor #4
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- implement a OOP structure with MetricProvider objects that return prometheus Metrics from the json log result - implement an agnostic NvmeCollector that stores MetricProviders instances and delegates handling the details of Collect and Describe to them - move NvmeCollector instantiation in a convenience function in the main package
Collaborator
Author
|
@dobbi84 questa la PR |
ftalpo
force-pushed
the
ftalpo/oop_refactor
branch
from
55af85e to
9ec9ca9
Compare
dobbi84
requested changes
Jul 28, 2025
| return fmt.Errorf("NVMe cli version not supported, supported versions are: %v", _supportedVersions) | ||
| } | ||
|
|
||
| shell := utils.NewShell( |
Collaborator
There was a problem hiding this comment.
Preferirei rimanere su exec.Command ed evitare shell quando possibile
| } | ||
|
|
||
| return &pkg.NvmeCollector{ | ||
| OcpEnabled: ocpEnabled, |
Collaborator
There was a problem hiding this comment.
non dovremmo internalizzare OcpEnabled in OcpMetricProvider?
| ch <- logProvider.Desc | ||
| } | ||
|
|
||
| for _, ocpLogProvider := range c.OcpLogMetricProviders { |
Collaborator
There was a problem hiding this comment.
dovremmo eseguirlo solo se ocp flag e' settata
| // getDevices queries the devices list through the shell | ||
| // and returns an array of JSON results with the devices data. | ||
| func (c *NvmeCollector) getDevices() []gjson.Result { | ||
| shell := utils.NewShell(utils.WithValidators(gjson.Valid)) |
Collaborator
There was a problem hiding this comment.
anche qua preferirei mantenere command invece che shell
| // sendOcpSmartLogMetrics queries the shell for ocp smart-log data, | ||
| // gets the metrics from each OcpLogMetricProvider in c.OcpLogMetricProviders | ||
| // and sends them through the channel. | ||
| func (c *NvmeCollector) sendOcpSmartLogMetrics(ch chan<- prometheus.Metric, device gjson.Result) { |
Collaborator
There was a problem hiding this comment.
sembra molto codice duplicato con sendSMartLogMetrics
Collaborator
Author
|
Chiudo per duplicazione con nuovo push su ftalpo/oop_refactor nel main repo |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In questo branch ho fatto un refactor della logica, per renderla "ad oggetti" (tra molte virgolette).
Ora il codice di NvmeCollector, definito in
/pkg/collector.goè agnostico rispetto ai dettagli di tutte le metriche definite.Per ogni metrica viene istanziato un oggetto MetricProvider (
InfoMetricProvideroLogMetricProvider, definiti in/pkg/provider.go), a cui viene delegata l'estrazione del valore dai JSON e la costruzione della corrispettivaprometheus.Metric.In questo modo il collector non deve sapere nulla dei dettagli di ciascuna metrica: i metodi
CollecteDescribeora iterano sulle liste deiMetricProvider, nel caso diCollectdelegando a questi ultimi il fetching della metrica dai log JSON.L'oggetto
NvmeCollectorusato inmain.goora viene istanziato in/cmd/collector.go.Vantaggi: il codice "core" sotto
/pkgnon deve sapere nulla delle implementazioni di ogni metrica, quindi per aggiungere/rimuovere una metrica basterà editare/cmd/collector.go, senza toccare le definizioni dei metodi diNvmeCollector. Tutte le info per la definizione delle metriche sono centralizzate in/cmd/collector.go(nome, help string, JSON key)Svantaggi: il codice è meno lineare, e bisogna saltare tra 2-3 file per capire cosa succede.