我是开源 SQL IDE LibreDB Studio 的维护者之一。它是 MIT 协议，在浏览器里使用，部署在数据旁边的 Docker 或 Kubernetes 上。之前在掘金介绍过这个项目，这次不讲整体功能，只想就最近加的一个功能，听听真正在做运维和后端的朋友怎么看。

起因

做微服务的团队，数据层几乎总是这一套：PostgreSQL、MongoDB、Redis、Elasticsearch，外加一个盯着所有东西的 Prometheus。出故障的时候，问题很少只跟其中一个有关：「14:10 接口延迟突然升高，是 Postgres 锁住了，还是 Redis 的 key 开始过期了？」为了回答它，一边开 Grafana，一边开数据库客户端，手动把时间抄过去，再祈祷时区没弄错。

所以我们把 Prometheus 做成了一种连接类型。像加 PostgreSQL 一样加一个连接，在同一个编辑器里写 PromQL，结果进同一个表格和图表。先说清楚：它不是 Grafana 的替代品，没有仪表盘，没有告警，也没有时间范围选择器。它的用途是在你给数据库提问的旁边，给 Prometheus 提一个一次性的问题。

做的时候定下的几件事

• 只用 instant query。 所有查询都走 /api/v1/query，范围直接写在 PromQL 里，比如 rate(prometheus_http_requests_total[5m])[1h:1m]。Grafana 的步长由时间范围和面板宽度算出来，同一条查询换个面板，数字可能就不一样；这里结果只取决于你写的文本，贴到故障群里，别人看到的是同一个数。代价是步长要自己写。
• matrix 变成宽表。 每个时间戳一行，每条 series 一列，列名是区分 series 的标签（{job="api"}）。原来给 SQL 用的图表页不改代码就能画多条折线。NaN 和 Inf 保留为字符串，因为在这张表里 null 已经表示“这个时刻没有样本”。
• 不拖慢别人的 Prometheus。 API 查询和告警规则评估共用 --query.max-concurrency（默认 20）的槽位，所以每个连接最多同时跑 4 条查询，其余排队。在 Prometheus 3.13.3 上实测：4 条重查询连续跑 60 秒，规则评估漏掉 0 次。
• 从结构上只读。 只会调用固定的 15 个读取路径，admin API、/-/reload、/-/quit、remote write 在代码里根本不存在。浏览器不直接连 Prometheus，请求从 IDE 的服务端发出；表达式放在 POST body 里，不会出现在中间代理的访问日志里。

还做不到的

• 没有指标名和标签的自动补全，只有语法高亮
• 没有时间范围选择器
• 不支持路径前缀和 SigV4，所以暂时连不上 Mimir、Grafana Cloud 托管的 Prometheus 和 Amazon Managed Service for Prometheus

想问大家

1. 如果能在 SQL 编辑器（数据库客户端）里直接查 Prometheus，你会用吗？还是 Grafana 就够了？
2. 排查故障时要临时查一下，你一般打开什么：Grafana Explore、Prometheus 自带的 UI，还是别的工具？
3. 如果下一步只先做一件事，你希望是什么：自动补全、时间范围选择器，还是别的？
4. 除了数据库，还有什么是你希望放在同一个地方一起查的？比如 Loki 或 Kafka。

想自己试试

docker network create libredb
docker run -d --name prometheus --network libredb prom/prometheus
docker run -p 3000:3000 --network libredb libredb/libredb-studio

打开 http://localhost:3000 ，用日志里打印的 admin 密码登录。新建连接选 Prometheus，主机填 prometheus，端口 9090。如果你的 Prometheus 跑在 Docker 外面，请填它的真实地址：容器里的 localhost 指的是容器自己。

仓库：https://github.com/libredb/libredb-studio

一句话的意见也很有帮助，谢谢。