DEV Community: Subramanya L

I Got Tired of Writing the Same PromQL Queries, So I Built PromDex

Subramanya L — Mon, 27 Jul 2026 07:43:07 +0000

Every Spring Boot service already exposes a goldmine of metrics through Actuator and Micrometer.
The problem isn't collecting metrics. The problem is turning those metrics into something useful.
Every new service usually means repeating the same workflow:

Writing the same sum(rate(...)) PromQL queries again
Looking up whether a metric is a counter, gauge, histogram, or summary
Creating Grafana dashboards panel by panel
Copying dashboards between projects and tweaking them for the latest service None of this is particularly difficult. It's just repetitive. And repetitive work is exactly the kind of work that gets postponed — or copied incorrectly. So I built PromDex. ## What is PromDex? PromDex is a drop-in Spring Boot starter that automatically exposes REST endpoints for:
Building PromQL queries
Discovering Prometheus metrics
Generating Grafana dashboards Add the dependency, start your Spring Boot application, and the /promql/* endpoints are available immediately — no @Configuration, no manual bean wiring. ## What does it do?
Build PromQL queries from structured requests
Discover metrics directly from /actuator/prometheus
Detect counters, gauges, histograms, and summaries automatically
Generate Grafana import-ready dashboards
Support JVM, HTTP, Kafka, Database, Cache, Kubernetes, and custom application metrics ## Zero-configuration demo With nothing more than the dependency added, this endpoint:

curl http://localhost:8080/appmetrics > dashboard.json

returns a complete Grafana dashboard JSON. Import it into Grafana and you get panels for JVM, HTTP, pod status, and discovered application metrics immediately — no dashboard building required.

How PromDex works

PromDex combines two sources of metrics:

Static catalog — common metrics Spring Boot and Micrometer already expose (JVM memory, CPU usage, HTTP request metrics, pod metrics), each with correct PromQL already prepared.
Runtime discovery — PromDex scrapes your application's own /actuator/prometheus endpoint and reads the Prometheus # TYPE declarations to determine whether each metric is a counter, gauge, histogram, or summary, then generates sensible default PromQL for each: | Metric type | Generated query | |---|---| | Counter | sum(rate(metric[5m])) | | Gauge | metric | | Histogram | histogram_quantile(0.9, sum(rate(metric_bucket[5m])) by (le)) | | Summary | sum(rate(metric_sum[5m])) / sum(rate(metric_count[5m])) | ## Installation

<dependency>
    <groupId>io.github.subramanya-dev</groupId>
    <artifactId>promdex</artifactId>
    <version>1.0.0</version>
</dependency>

That's it. No configuration classes, no extra beans — just add the dependency and start your application.
Make sure Prometheus Actuator is exposed if you want live discovery:

management:
  endpoints:
    web:
      exposure:
        include: prometheus

Build PromQL automatically

Instead of manually writing queries like:

sum(rate(http_requests_total{job="api", status="5.."}[5m])) by (status)

send a request to /promql/build:

curl -X POST http://localhost:8080/promql/build \
  -H "Content-Type: application/json" \
  -d '{
    "metricName": "http_requests_total",
    "metricType": "COUNTER",
    "function": "rate",
    "range": "5m",
    "labels": { "job": "api", "status": "5.." },
    "aggregation": "sum",
    "groupByLabel": "status"
  }'

PromDex returns:

{
  "query": "sum(rate(http_requests_total{job=\"api\", status=\"5..\"}[5m])) by (status)",
  "description": "Query built for metric 'http_requests_total' using rate",
  "valid": true,
  "warning": null
}

No string concatenation, no manual PromQL building.

Discover metrics automatically

Want to know which metrics your application exposes?

curl http://localhost:8080/promql/discovered

PromDex scrapes the metrics endpoint and returns every discovered metric with its type, description, suggested PromQL, and unit — including custom application metrics you've registered yourself.

Automatic method metrics

PromDex can instrument Spring beans with a single annotation:

@Service
class PaymentService {
    @MethodMetrics("payment_charge")
    public Receipt charge(Charge request) {
        return gateway.charge(request);
    }
}

This automatically publishes invocation count, execution time, and exception metrics — tagged by method and outcome, and immediately discoverable and dashboard-ready.

Note: an exception that's caught and fully handled inside the method won't cross the AOP boundary automatically — record it explicitly with methodMetricsRecorder.recordHandledException(...) if you need it captured.

Production notes

PromDex generates PromQL heuristically. It's designed to remove repetitive work — not replace engineering judgement.
Before using generated dashboards or alerts in production:

Review the generated queries against real Prometheus data

Keep metric labels bounded — don't derive names or labels from request IDs, user IDs, order IDs, or raw error messages. That's a fast path to Prometheus cardinality explosions ## Project links

GitHub: github.com/subramanya-dev/promdex

Maven Central coordinates:

<dependency>
    <groupId>io.github.subramanya-dev</groupId>
    <artifactId>promdex</artifactId>
    <version>1.0.0</version>
</dependency>

What's next?

PromDex is still in its early days, and there are plenty of ideas for future improvements. If you're building Spring Boot applications with Prometheus and Grafana, I'd love for you to give it a try.
Feedback, issues, feature requests, and pull requests are all welcome. If PromDex saves you from writing even one more sum(rate(...)) query by hand, it's already done its job.

Stop Validating AI Agents Only at the Start: Introducing Mid-Chain Governance

Subramanya L — Sun, 26 Jul 2026 17:15:52 +0000

Modern AI agents rarely complete a task in a single model invocation. Instead, they execute multi-step workflows:

Retrieve documents
Call APIs
Query databases
Generate intermediate plans
Invoke external tools
Produce a final response

Most AI safety mechanisms, however, only validate the initial prompt or final output.

This leaves an important gap.

The Hidden Risk in Multi-Step AI Workflows

Imagine an AI assistant receives a perfectly safe request:

"Generate a quarterly sales report."

The initial prompt is harmless, so it passes validation.

The agent then:

Searches internal documentation.
Retrieves customer data.
Generates SQL queries.
Calls external services.
Produces the report.

What if, during step 3, the generated SQL unexpectedly references sensitive tables in its output? Or what if an intermediate reasoning step produces text describing a policy-violating action?

Neither issue would be detected if validation only occurs at the beginning — the output of a mid-workflow step is exactly what an entry-only check can never see.

The danger isn't always in the user's prompt — it can emerge in what the agent produces along the way.

Why Entry-Point Guardrails Aren't Enough

Today's guardrails typically focus on:

Prompt filtering
Content moderation
Final response validation

These are valuable, but they assume the workflow remains safe after the initial check.

In reality, AI agents continuously generate new text and outputs at each step. Each of those outputs can contain fresh risks — sensitive data surfacing in a query, an unsafe instruction appearing in an intermediate plan, policy-violating content in a drafted response — before the final answer is ever assembled.

These risks don't necessarily exist in the original prompt. They emerge in what gets produced while the agent is working.

A Different Approach: Mid-Chain Governance

Mid-Chain Governance re-checks a step's output text at intervals during execution, rather than relying solely on entry-point validation.

To be precise about what this means: it doesn't intercept or block an action before it happens (a tool call, a database query, an API request) — it checks the text a step produces before that text is passed along to the next step or delivered to the user. That's a meaningful distinction. If step 3 generates SQL referencing a sensitive table, this checks the generated SQL text, catching it before it's used downstream — not by intercepting the database connection itself.

Instead of checking every single step — which adds latency — it supports checking at intervals, always guaranteeing the response actually delivered to the user gets checked, regardless of which step produced it.

This balances safety coverage with performance.

Governance is applied to the outputs that matter most, not to every intermediate token.

Why Selective Re-Verification?

Checking every single step's output is safer but costs latency. Checking only at entry is fast but blind to anything produced afterward. Selective re-verification — checking at intervals plus always before delivery — is a middle ground: in an accompanying simulation, it recovered most of the catch-rate benefit of checking-every-step at roughly half the latency cost. (That's a simulation result, not a production measurement — more on that below.)

Potential Use Cases

This kind of mid-chain output checking could be relevant to:

Enterprise AI assistants
Customer support agents
Autonomous software engineering agents
Multi-agent orchestration platforms

Any system where an agent produces meaningful output at multiple steps — not just a single final response — is a candidate. That said, this is a young, small project (see below), not something with production track record in these domains yet.

An Open-Source Experiment — and What It Actually Is

To explore this idea, I built midchain-governance, a small open-source library implementing selective output re-verification for multi-step AI pipelines.

Worth being direct about scope: re-checking constraints across multi-step AI processes isn't a new idea — it's an active area, with published work on compliance gating and on constraint drift across agent delegation (linked in the repo's docs/CITATIONS.md). This project doesn't claim to invent that concept. What it is: a specific, tested implementation — the interval logic, the guarantee that the delivered output is always checked regardless of chain length, and a simulation exploring the catch-rate/latency tradeoff, with the code and tests to back it up. It's also brand new, with no production track record yet — the simulation numbers are honestly documented as simulation, not a forecast.

The goal isn't to replace existing guardrails, but to complement them with a specific, narrow mechanism: checking outputs as they move through a chain, not just at the door.

If you're building AI agents or agentic workflows, I'd love your feedback, ideas, and contributions.

GitHub Repository: https://github.com/subramanya-dev/midchain-governance

Final Thoughts

As AI systems become increasingly autonomous, the security model needs to evolve beyond "validate once and trust forever."

Safety checks shouldn't stop after the first prompt. Checking what an agent actually produces as it works — not just what the user asked for, and not just the final answer — is one piece of that.

What are your thoughts? Are intermediate output checks something you've encountered in your own AI applications? I'd love to hear your perspective in the comments.