Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prometheus schematization #63878

Merged
merged 22 commits into from
Mar 9, 2023
Merged

Prometheus schematization #63878

merged 22 commits into from
Mar 9, 2023

Conversation

itsmylife
Copy link
Contributor

What is this feature?

This is an example PR to illustrate schematizing the Prometheus datasource plugin. Probably It won't be merged.
The guidance https://docs.google.com/document/d/1RRPGeD7DQ7wot0Pwnc4UZolXrZYip0ViqOozl9zbBpE/edit#

Which issue(s) does this PR fix?:

Closes #63874

Special notes for your reviewer:
This PR is an up-to-date version of this PR. I closed that one because it was behind the main and getting hard to merge it because of the conflicts.

@itsmylife itsmylife added datasource/Prometheus no-backport Skip backport of PR no-changelog Skip including change in changelog/release notes labels Feb 28, 2023
@itsmylife itsmylife added this to the 9.5.0 milestone Feb 28, 2023
@itsmylife itsmylife requested review from a team and Eve832 as code owners February 28, 2023 15:36
Comment on lines 40 to 41
interval?: string
intervalMs?: int64
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these set in the UI, or as part of the request? If we can not set them from the UI, lets keep them out of this schema.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

while i have a feeling we may find exceptions to this rule (such that we need to find a better rule), i think it's the right one at least for now

Copy link
Contributor Author

@itsmylife itsmylife Mar 8, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made the changes related to this. See: d4db739

{
common.DataQuery
expr: string
format?: string
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are the valid values? I think 'timeseries' and 'table', but would be nice to have that explicit :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree, if there's a set of acceptable values here, they should be explicitly declared.

Could make it a reference to another type, as with #QueryEditorMode, if that type needs to be used elsewhere in TS

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will check the possible values and introduce a change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See a0bd621

Copy link
Contributor

@sdboyer sdboyer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't know the specifics of the prom datasource, but overall this looks pretty close! i think i'd just simplify a bit by removing pointers and some possibly-unnecessary fields from the schema as @ryantxu noted

pkg/tsdb/prometheus/models/query.go Outdated Show resolved Hide resolved
{
common.DataQuery
expr: string
format?: string
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree, if there's a set of acceptable values here, they should be explicitly declared.

Could make it a reference to another type, as with #QueryEditorMode, if that type needs to be used elsewhere in TS

| `format` | string | No | Possible values are: `time_series`, `table`, `heatmap`. |
| `hide` | boolean | No | *(Inherited from [DataQuery](#dataquery))*<br/>true if query is disabled (ie should not be returned to the dashboard) |
| `instant` | boolean | No | |
| `key` | string | No | *(Inherited from [DataQuery](#dataquery))*<br/>Unique, guid like, string used in explore mode |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was surprised to see "key" here... but then see that is not added in this PR

#64467

{
schemas: [
{
common.DataQuery
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any effort on comments here will be HUGELY helpful. The text+values here will drive all the docs and API generation, so if we can try to explain the parameters here (and agree/confirm they are accurate!) that would be awesome.

Comment on lines 35 to 36
instant?: bool
range?: bool
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can both range and instant be true?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

they can't, and we can natively constrain them in CUE to indicate that invariant, but at the moment cuetsy evaluates the operation and converts the TS output to just false - see grafana/cuetsy#75

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it can be. In query options there is a type option field:
image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh! i totally misunderstood this on my first pass through it, then :)

Comment on lines 30 to 31
"interval": "1s",
"intervalMs": 1000,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these changes still necessary?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me check them once more. Probably we won't need them anymore. Good catch.

Co-authored-by: Ryan McKinley <ryantxu@gmail.com>
Copy link
Member

@ryantxu ryantxu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@itsmylife -- this looks like a great step forward. My only remaining comments would be to improve the comments so that a noice looking at the fields+comments could understand what they do.

But that can also evolve as we have more people look at and use this :)

Co-authored-by: Ryan McKinley <ryantxu@gmail.com>
Copy link
Contributor

@sdboyer sdboyer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed with @ryantxu, i think this is good enough to go in - and be marked as experimental. While it's absolutely true that the comments here are crucial for the as-code user use case, it takes a different mindset and knowledge base than just getting the types hooked up. It's OK to plan for a follow-up to improve them.

Thanks for all your work on this!

Copy link
Contributor

@gtk-grafana gtk-grafana left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks for all the hard work on this, I'm excited to have type synchronization across the stacks!

Copy link
Contributor

@bohandley bohandley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! The comments make sense to me as well, good work!

@itsmylife itsmylife merged commit 68b588b into main Mar 9, 2023
@itsmylife itsmylife deleted the ismail/prometheus-schematization branch March 9, 2023 10:26
eleijonmarck pushed a commit that referenced this pull request Mar 13, 2023
* Schematize prometheus

* revert changes

* close response body

* Update report.json

* Update pkg/tsdb/prometheus/models/query.go

Co-authored-by: sam boyer <sdboyer@grafana.com>

* Use without pointers

* remove unused

* Specify query format

* Rename

* Clean up schema

* Update public/app/plugins/datasource/prometheus/dataquery.cue

Co-authored-by: Ryan McKinley <ryantxu@gmail.com>

* Update pkg/tsdb/prometheus/models/query.go

Co-authored-by: Ryan McKinley <ryantxu@gmail.com>

* Clean up tests

* Update public/app/plugins/datasource/prometheus/dataquery.cue

Co-authored-by: sam boyer <sdboyer@grafana.com>

* make gen-cue

* Add comments

* Make linter happy

* Remove editormode override

* Update

---------

Co-authored-by: sam boyer <sdboyer@grafana.com>
Co-authored-by: Ryan McKinley <ryantxu@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/backend area/frontend datasource/Prometheus no-backport Skip backport of PR no-changelog Skip including change in changelog/release notes type/docs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Prometheus schematization
7 participants