Grafana 是一款強大的可視化工具，不止是用于 Prometheus 做數(shù)據(jù)源，還可以集成數(shù)據(jù)庫、日志等作為數(shù)據(jù)源整體使用。

最近我在配置一個監(jiān)控面板，其中的數(shù)據(jù)由 Prometheus 和 MySQL 組成；簡單來說就是一個指標的查詢條件是從數(shù)據(jù)庫中來的。

pulsar_subscription_back_log_no_delayed{topic=~"$topic",subscription=~"$subscription"}

其中的 topic 數(shù)據(jù)是從  MySQL 中來的，其實就是在 Grafana 聲明一個變量，從數(shù)據(jù)庫返回了一個列表。

因為我們的查詢條件是 topic=~"$topic"是正則匹配，所以理論上應(yīng)該把所有的 topic 關(guān)聯(lián)的數(shù)據(jù)都查詢出來。

但實際情況是任何數(shù)據(jù)都查不到。

查看發(fā)出去的原始請求后才發(fā)現(xiàn)問題出在哪里：

原來是選擇所有 topic 后 grafana 會~~~~自動對參數(shù)轉(zhuǎn)義，這個我查了好多資料包括咨詢 ChatGPT 都沒有得到解決。

經(jīng)過多次測試，發(fā)現(xiàn)只要開啟多選 grafana 就會自動轉(zhuǎn)義。

最后我只能想到一個不需要生成多行記錄的辦法：將所有數(shù)據(jù)合并成一條記錄。

這樣的話就只會生成一條數(shù)據(jù)，其中包含了所有的 topic，也就避免了被轉(zhuǎn)義。

SQL 中的 CONCAT 函數(shù)其實我也不知道怎么使用，還是 ChatGPT 告訴我的。

最后便能完美的查詢出數(shù)據(jù)了。

有碰到類似問題的朋友可以嘗試這個方法，我估計用到這個場景的并不多，不然 ChatGPT 也不會不知道。