fix: Optimize export metric behavior

[Taylor-lagrange]

I hereby agree to the terms of the GreptimeDB CLA

What's changed and what's your intention?

Optimize export metric behavior in pr #2928

Please explain IN DETAIL what the changes are in this PR and why they are needed:

• Avoid network when standalone and frontend are feeding themselves by ExportMetricHandler
• Default export metric schema be set to information_schema after solve Duplicate information_schema #2976

About discuss on #2972

Because GreptimeDBTelemetryTask in metasrv is a bit complicate, so we’ll discuss it later

Checklist

• I have written the necessary rustdoc comments.
• I have added the necessary unit tests and integration tests.
• This PR does not require documentation updates.

Refer to a related PR or issue link (optional)

Closes #2975

[codecov]

Codecov Report

Attention: 130 lines in your changes are missing coverage. Please review.

Comparison is base (1d80a0f) 85.76% compared to head (6f811c5) 85.18%.
Report is 31 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3047      +/-   ##
==========================================
- Coverage   85.76%   85.18%   -0.58%     
==========================================
  Files         791      805      +14     
  Lines      127985   131093    +3108     
==========================================
+ Hits       109760   111674    +1914     
- Misses      18225    19419    +1194     

[killme2008]

Almostly LGTM

[killme2008]

@v0y4g3r @fengjiachun PTAL

[zhongzc]

I wholeheartedly agree with the configuration mentioned by @killme2008. Frankly speaking, it would be hard for me to hit the Approve button if we didn't follow through with this approach. 🥲

Here are my opinions:
#2928 (comment)
#2928 (comment)

[Taylor-lagrange]

In my original idea, I did retain the design of using the entire url as a parameter, for greater compatibility. In the subsequent review, the parameters are split to endpoint and db according to the advice. So we can reach an agreement to merge endpoint and db into one parameter (e.g. http://127.0.0.1/v1/prometheus/write?db=information_schema), which will have wider compatibility?

But as for distinguishing the two import methods (i.e. remote_write for url and self_import for internal), I personally think it may increase users' understanding. Because only frontend and standalone can use self_import in certain case, others have to rely on url, because there is no good way to know the frontend address in the cluster.

How about yours opinion? @killme2008 @zhongzc

[killme2008]

In my original idea, I did retain the design of using the entire url as a parameter, for greater compatibility. In the subsequent review, the parameters are split to endpoint and db according to the advice. So we can reach an agreement to merge endpoint and db into one parameter (e.g. http://127.0.0.1/v1/prometheus/write?db=information_schema), which will have wider compatibility?

But as for distinguishing the two import methods (i.e. remote_write for url and self_import for internal), I personally think it may increase users' understanding. Because only frontend and standalone can use self_import in certain case, others have to rely on url, because there is no good way to know the frontend address in the cluster.

How about yours opinion? @killme2008 @zhongzc

Yes, totally agree with the URL as configured parameter instead of endpoint and db.

Considering that standalone would be the most installed version, i think it's valuable for user to useself_import, and we can make it default for standalone.

[zhongzc]

LGTM