Ok, let's do it then, preferably with some --experimental flag for now.
On Wed, Oct 5, 2022 at 10:46 PM Julien Pivotto
wrote:
> Promtool check metrics is an example that also does not call an API on
> Prometheus side.
>
> I think a subcommand Promtool promql would be acceptable to me.
>
> On 05
Promtool check metrics is an example that also does not call an API on
Prometheus side.
I think a subcommand Promtool promql would be acceptable to me.
On 05 Oct 09:06, r...@chronosphere.io wrote:
> Yes I realized that to manipulate the AST (and the AST will of course
> change as new functions
I’m not sure your use cases match, but I’ve always wanted something like
prepared statements where something like a “?” operator could be an
expression placeholder, possibly even restricted to something like a label
matcher, or just a label-value, etc.
I think there might be overlap in the use
Re: drawing the line – I often feel like "specialized" tools that try to
solve all advanced use cases end up with very complex and hard to use
configuration (looking at you, relabeling). I often find it more pleasant
to express what I want to do as *code*. What would an API look like that
you or
Yes I realized that to manipulate the AST (and the AST will of course
change as new functions and features are added) much like codemirror-promql
moved into the Prometheus repository to get updates as they come to PromQL
that somewhere in the Prometheus repo itself would be a good starting
The versioning aspect is a good point, I hadn't thought of that.
If we make promtool's scope broader than what I proposed, it's IMO still a
question of where we draw the line in terms of niche specialized use cases.
The proposes features in https://github.com/prometheus/prometheus/pull/11411
are
I think the opposite - Prometheus contains PromQL, it's same codebase,
same version. It makes sense to have those tools in promtool as well, so
it is shipped to everyone, and has a known version.
On 05 Oct 11:22, Julius Volz wrote:
> I do feel that formatting entire rule files would be in scope
I do feel that formatting entire rule files would be in scope for promtool,
but more specialized formatting and manipulations of individual PromQL
queries (while cool) should likely live in a separate tool. I see the scope
of promtool to be mostly a tool to interact with both the Prometheus
Hi Rob,
I wonder if PromQL related things fit in promtool given the use for
PromQL is wider than just Prometheus. I can imagine something like a
"promqltool", which might actually be backed by the promql language
server (so people can get similar things in editors too).
However that's clearly a
9 matches
Mail list logo
