The code is pretty imperative at this stage. Since we are, for every iteration (whether that be in the display loop or when the program is scraped by prometheus) we are consuming all of the data produced by the eBPF programs in the sub-routines (memleak, cudatrace) and updating local state.
For maintainability and extensibility, perhaps it would make sense to model this as a visitor pattern, where visiting a node (in this case a sub-routine) equated to consuming events produced by the kernel, and updating local state.
Defining a Visitor trait and having a separate loop for consuming data (independent of the display and Prometheus export loops) may be a good design decision.
The code is pretty imperative at this stage. Since we are, for every iteration (whether that be in the display loop or when the program is scraped by prometheus) we are consuming all of the data produced by the eBPF programs in the sub-routines (memleak, cudatrace) and updating local state.
For maintainability and extensibility, perhaps it would make sense to model this as a visitor pattern, where visiting a node (in this case a sub-routine) equated to consuming events produced by the kernel, and updating local state.
Defining a
Visitortrait and having a separate loop for consuming data (independent of the display and Prometheus export loops) may be a good design decision.