Move MQE codes to independent Maven module inoap-server.

[wankai123]

Since we plan to use MQE in other places(such as Alarm), I moved the relevant codes to the independent Maven module， to make it easier to depend on.

[sonatype-lift]

Sonatype Lift is retiring

Sonatype Lift will be retiring on Sep 12, 2023, with its analysis stopping on Aug 12, 2023. We understand that this news may come as a disappointment, and Sonatype is committed to helping you transition off it seamlessly. If you’d like to retain your data, please export your issues from the web console.
We are extremely grateful and thank you for your support over the years.

📖 Read about the impacts and timeline

[kezhenxu94]

Since we plan to use MQE in other places(such as Alarm), I moved the relevant codes to server-core， to make it easier to depend on.

Can you elaborate (because I have no more context, only the PR description):

• How/Why we would use MQE in alarm?
• Did you try anything else that is "not easier" to depend on?
• Why can't we make the MQE parser a dedicated module?

Asking because it sounds nonsense to move everything into the core module just to make it "easier" to depends on, although the current modularization is a mess, I hope not to make it worse

[wu-sheng]

We are making the new alerting core. Totally changed.
We would do static configurations, instead, we would apply MQE(using metrics with windows as datasources, like a memory table) to query the metrics and compare with the threshold.
Typically, like this, exp=count(service_sla < 95) > 3 duration=10m, meaning 3 mins in the past 10 mins, the success rate is less than 95.
Also, the composite rules could be covered as well.

[wu-sheng]

About depending on, we need an abstract data source concept(query or alerting core's memory windows) for feeding MQE.

We had a discussion about whether we need a maven module, but it seems either is fine. But an OAP-level module seems unnecessary. The MQE engine implementations, for now, can't extend w/o code changes

[wu-sheng]

@kezhenxu94 From my reading/understanding, this is the extension point.
MQE on Query API implementation would pick query DAOs to access data from the database.
Alerting kernel will provide another implementation on this, to read data from time window based metric data.

[kezhenxu94]

I still don't see why MQE-related codes should go into the core module, from the point of MQE, you might say "hey we have 10000 other modules that depends on MQE and we need to reuse it", that is a perfect reason why MQE MUST NOT be in the query plugin, but it's not a reason why it should go into the core module. To me it's not only about extension/reuse codes, it's also about organizing code, code structure, readability for new contributors, and sample for future contributors, for example, how do you persuade a contributor not to put random codes into the core module if they said "I do this by referring to the existing codes, and MQE did this".

One more thing, adding more codes into the core module does not only increase the granularity of the core module, but also introduces some transitive dependencies that can not be easily removed if anyone doesn't use the MQE query, and adds extra workload if anyone want to customize/extend the MQE features (e.g. add operators), they have to override the entire core module.

[wu-sheng]

As I replied, I would have no interest to argue it should be in a maven module or not. I just said it should not be an OAP module, that's all. Because it doesn't take a responsibility of an independent feature.

You don't need to convince me. You asked for a context, so, I provided.

You and @wankai123 could choose your preference. I am fine for both ways.

[wu-sheng]

If you want to separate codes, create a maven module, called mqe-lib for code reusing.

[wankai123]

OK, I'll put them in a new maven module.

[wankai123]

How about creating a new module in server-library and moving MQE into it? @kezhenxu94

[kezhenxu94]

How about creating a new module in server-library and moving MQE into it? @kezhenxu94

Sounds perfect to me