Feature plans

[yeya24]

Now this linter can work, but it is not good. It only has some very basic features.

What it cannot support:

1. Metrics opt field is from some identifiers like var, const, or from other packages.
2. Functions. Like we can use when creating new xxxOpts, but we cannot do it in this tool since that function can only be executed at runtime.

Help: fmt.Sprintf("%s", aaa)

3. Getting metrics information from prometheus.Desc, it is doable, but we need to parse ch <- prometheus.MustNewConstMetric as well, otherwise we cannot get the correct metric type.

4. Support outputting the position (filename, column and row) of the bad metric

[yeya24]

But this tool can already be used in linting metrics names. For example, I did a test for Cortex.

promlinter .

cortex_cache_fetched_keys: counter metrics should have "_total" suffix
cortex_cache_hits: counter metrics should have "_total" suffix
cortex_purger_pending_delete_requests_count: non-histogram and non-summary metrics should not have "_count" suffix
cortex_ingester_received_chunks: counter metrics should have "_total" suffix
cortex_ingester_received_files: counter metrics should have "_total" suffix
cortex_ingester_sent_chunks: counter metrics should have "_total" suffix
cortex_ingester_sent_files: counter metrics should have "_total" suffix
memberlist_client_watch_prefix_dropped_notifications: counter metrics should have "_total" suffix
cortex_ruler_managers_total: non-counter metrics should not have "_total" suffix

[yeya24]

Step 3 and 4 is done.

[roidelapluie]

Is checking that metrics are actually registered supported?

[yeya24]

Is checking that metrics are actually registered supported?

Hello, it is not supported and I haven't think of it. It would be complicated because there are a lot of patterns to register metrics. It would be great if you could share some ideas!

[roidelapluie]

Is checking that metrics are actually registered supported?

Hello, it is not supported and I haven't think of it. It would be complicated because there are a lot of patterns to register metrics. It would be great if you could share some ideas!

That's also why it is sometimes forgotten :)

[sayboras]

Just quickly try this, I would like to highlight some issues i have right now, keen to hear your thought.

parsing Namespace with type *ast.SelectorExpr is not supported
parsing desc of type *ast.SelectorExpr is not supported

[yeya24]

Just quickly try this, I would like to highlight some issues i have right now, keen to hear your thought.

parsing Namespace with type *ast.SelectorExpr is not supported
parsing desc of type *ast.SelectorExpr is not supported

@sayboras Hey, thanks for the feedback. That's a problem for me as well. It is common to use const values from other packages like conf.Namespace when defining metrics.

TBH, I am quite new to golang static linting and I don't know how to get the const or var values from other packages. It would be good if you could help or give some ideas. Thanks!

[yeya24]

But this linter should work well in most cases when defining metrics using string literals. Like the metrics in the testcase https://github.com/yeya24/promlinter/blob/master/testdata/testdata.go