Feat: record query metrics

[hopeyen]

Track query volume and performance like the original indexer service.
Some metrics from the original are registered but not used so they are not included here

Part of #4

For later: Add cost model metrics once there is cost server

[coveralls]

Pull Request Test Coverage Report for Build 5967540548

• 0 of 32 (0.0%) changed or added relevant lines in 1 file are covered.
• 3 unchanged lines in 2 files lost coverage.
• Overall coverage increased (+1.0%) to 38.906%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
service/src/server/routes/subgraphs.rs	0	32	0.0%

Files with Coverage Reduction	New Missed Lines	%
service/src/metrics/mod.rs	1	0.0%
service/src/server/routes/subgraphs.rs	2	0.0%

Totals
Change from base Build 5967527200:	1.0%
Covered Lines:	761
Relevant Lines:	1956

---

💛 - Coveralls

[aasseman]

🤔 shouldn't the query duration be discarded if there's an error? I don't know what the choice was in the original indexer-service though.

[aasseman]

And I also have similar question about FAILED_QUERIES. Shouldn't it be incremented at all the points where the functions returns with an error?

[hopeyen]

🤔 shouldn't the query duration be discarded if there's an error? I don't know what the choice was in the original indexer-service though.

The typescript version uses the syntax try { start_timer and stuff } catch { error_handle } finally { stop_timer } in which finally should happen regardless of try result, so it does record errored out queries.
Does it make more sense to just discard? maybe I add another label with an Enum on the results🤔?

And I also have similar question about FAILED_QUERIES. Shouldn't it be incremented at all the points where the functions returns with an error?

FAILED_QUERIES seems to be recorded for when query_processor fails to execute a paid query (ts version)

[aasseman]

Yup I see, thanks for the pointers, yours indeed behaves like the original. IMO the original is wrong though 😬 .
Should we just go ahead with this, and perhaps track a potential rework of the query processing monitoring logic in the issues?

[hopeyen]

I agree with you 😂 We can change it up later, will add a note to the metrics tracking issue #4