以動態焦點過濾

動態焦點是一個強大的搜尋和過濾功能，它能夠同時在所有資料環境定義中進行搜尋。 微服務架構利用各種複雜的資料環境定義，而這些環境定義全部叢集在一個 hood 下。 動態焦點能夠對這些內容進行過濾，從而為使用者提供一種強大的對系統範圍的理解。

這種跨環境定義的方式顯示了非常強大的查詢功能，例如：

  • 過濾基礎架構
    • 針對未解決的問題
    • 針對特定技術
    • 針對特定的服務及變更事件
  • 過濾事件
    • 針對特定的服務及基礎架構組合
    • 針對特定的儲存器及技術
    • 針對特定的基礎架構

此功能充分利用我們獨特的架構和功能：

  • 動態圖形 -實體和邏輯元件的凝聚模型，包括所有歷程屬性和度量。 動態圖形還包括分散式追蹤資料和事件。 圖形中的所有節點都基於其相依關係進行連接。 Instana 中的各種視圖用於視覺化圖形的資料，而動態焦點實際上對圖形進行過濾以提供特定的子視圖及焦點。

  • 自動探索 -我們的代理程式會即時自動探索圖形中所保留的所有元件及其相依關係。 任何已儲存的過濾器將自行調整以適應系統及應用程式的現行狀況而無需任何手動變更或配置。

  • 突發事件 -我們的突發事件基於 KPI 和機器學習，並提供突發事件的相關精簡資訊。 這包括對服務、追蹤資料及實體元件的相依關係，動態焦點可以使用它們來僅對屬於特定發生事件的元件進行過濾。

聚焦於應用程式元件

以下範例可以幫助您瞭解動態焦點的概念。 我們採用分區應用程式的圖形表示法，該應用程式在兩個主機上執行，每個主機有四個儲存器。 每個儲存器中都執行一部 JVM，每個主機均執行兩個 Tomcat 和兩個 Elasticsearch 實例，它們為每個主機提供服務。 簡化版本的動態圖形模型類似如下所示：

新的過濾功能容許我們根據搜尋查詢來減少圖形中的節點。

查詢 entity.type:tomcat 將會符合圖形中的所有 Tomcat 實例。 這表示當在標準視圖中檢視基礎架構、應用程式及追蹤資料時，具有 Elasticsearch 實體及對應服務的儲存器將不再可見。

Instana 中的任何圖表、變更、問題或發生事件，將僅在縮減後圖形的環境定義中查看。

另一個範例查詢是搜尋 1.8 版的所有 JVM：entity.jvm.version:1.8.*

在此情況下，圖形類似如下所示：

這是一個強大的工具，它可以在符合特定準則的圖形內查找單一實體或實體群組，並將使用者注意力聚焦到這些實體上。

聚焦於管理屬性

Instana 還具有動態圖形之外的結構，但確實參照了它，例如，事件（如變更）、問題或發生事件。 發生事件可以包含 Instana 發現 KPI 離群值的服務，也可以包含存在諸如高 CPU 負載等問題的實體。

使用新的搜尋功能，您可以查詢並過濾諸如 event.state:open event.type:incident 等發生事件。 它會過濾目前所選取時間範圍中的所有作用中發生事件。 在此範例中，我們假定當 Elasticsearch 服務的降級導致 Tomcat 服務後續降級時，只有一個作用中的發生事件。

由於相符的發生事件將具有對這兩個服務的參照，因此查詢將僅過濾到相關實體。

反之亦然。 如果我們搜尋一項服務，則將僅顯示包含此項服務的發生事件。

語法

Instana 使用 Lucene 查詢語法，根據對映至應用程式元件的術語及布林運算子來建置複式查詢。 此外，還支援各種強大的查詢類型，例如任意文字搜尋、標籤過濾、CPU 計數查詢等等。 搜尋列透過自動強調顯示字串中有效的個別術語來幫助使用者建置查詢。 這有助於避免常見的字串語法陷阱，例如將任意文字查詢 "and" 與布林運算子 AND 混淆。

Lucene 查詢採用的形式根據實作而有所不同。 在 Instana 中，所有查詢都是從欄位到欄位修飾元再到限量元。 這兩個欄位值之間以句點區隔，而限量元則是由冒號隔開。 例如，假設一個使用者想要濾出其應用程式中的所有 Tomcat 實例。 則他們在搜尋列中的查詢內容應為：entity.type: tomcat。 這會指示 Instana 從視圖中移除所有標示為 "tomcat" 類型之實體以外的所有項目。

當然，entity.type:tomcat 只是一個查詢詞組。 不同詞組之間可以使用諸如 AND、OR 及 NOT 等布林運算子連結在一起，以建置靈活且複雜的過濾器來顯示客戶需要的確切內容。 範例：

預設運算子

AND 運算子是預設的連結運算子。 這表示如果兩個術語之間沒有布林運算子，則會使用 AND 運算子。

例如：entity.type:tomcat event.state:open 相當於 entity.type:tomcat AND event.state:open。

值得注意的是，這與 Lucene 標準不同，依預設會使用 OR。

複式子查詢

雖然 Lucene 查詢語法和動態聚焦查詢看起來是支援複雜的布林術語，但事實卻並非如此。

尤其是在動態聚焦查詢中，子查詢的取反並沒有按預期運作。

entity.kubernetes.namespace:my-namespace AND NOT (entity.kubernetes.pod.name:my-name AND event.text:"ContainersNotReady")

上述查詢將不會產生預期結果，但當以另一種方式處理時：括弧內的子查詢中的術語便不會像套用布林邏輯時那樣彼此關聯，其結果將類似於下列查詢：

entity.kubernetes.namespace:my-namespace AND NOT entity.kubernetes.pod.name:my-name AND NOT event.text:"ContainersNotReady"

自動完成

除了強調顯示 Lucene 查詢術語之外，Instana 搜尋列還能夠為未完成的可搜尋項目提供 IDE 級別的建議。 這對於 Instana 的新使用者和有經驗的使用者而言都是有很大幫助的。 那些不會使用 Lucene 語法指令的使用者可以取得自動協助，而有經驗的使用者可以更快地執行複雜的搜尋。 所有查詢提案都會出現在下拉方框中，如搜尋列所示。 如果所需的建議顯示在視圖中，則只需按一下或使用方向鍵導覽至此建議。

Instana 的搜尋功能是即時的，這表示當您輸入搜尋準則時，便會出現結果。您還能夠儲存、編輯及刪除過濾器以加快工作流程。

已知限制

語法限制

  • ! 與要取反的查詢之間不容許有空格。 請改用 !<query> 或 NOT <query> 。
  • 當多個相同的 entity.application.name、entity.service.name、entity.endpoint.name 動態焦點關鍵字組合在一起使用時，只能使用 OR 運算子將它們結合在一起。 E.g. 不支援查詢 entity.application.name:foo AND entity.application.name:bar、 entity.application.name:foo entity.application.name:bar 。 但支援查詢 entity.application.name:foo OR entity.application.name:bar。
  • 當多個不同的 entity.application.name、entity.service.name、entity.endpoint.name 動態焦點關鍵字組合在一起使用時，只能使用 AND 運算子將它們結合在一起。 E.g. 不支援查詢 entity.application.name:foo OR entity.service.name:bar ，但支援查詢 entity.application.name:foo AND entity.service.name:bar 。
  • 不支援包含應用程式、服務或端點名稱的取反查詢。 因此，NOT entity.application.name:foo、!entity.service.name:bar 及 NOT entity.endpoint.name:foobar 皆無效。 不過，仍然可以改為使用 NOT event.entity.label:foo 來過濾掉應用程式、服務或端點的事件。
  • 使用字串 contains 邏輯來評估動態焦點查詢 entity.application.name:<term>、 entity.service.name:<term> 和 entity.endpoint.name:<term> ，例如動態焦點查詢 entity.application.name:shop 也會符合 entity.application.name:shop-frontend。
  • 動態焦點查詢關鍵字 entity.application.name、entity.service.name 及 entity.endpoint.name 僅在布林查詢（請參閱上方的布林邏輯限制）、術語查詢、詞組查詢及字首查詢中受支援。

查詢限制

  • 針對 event.text 且包含連字號的動態焦點查詢可能會傳回非預期的結果。 例如: 由於 Lucene 分析器的記號化， event.text:"foo-bar-random" 也會傳回只包含 foo 或 bar 或 random 的事件。
  • 在大部分 Kubernetes 關鍵字上設定範圍時，無法選取遵循 Docker 儲存器的實體 (例如 主機 或 可用性區域)。 例如，查詢 entity.kubernetes.deployment.name:my-K8s-deployment AND entity.selfType:host 不會傳回任何主機。 相比之下，查詢 entity.kubernetes.deployment.name:my-K8s-deployment AND entity.selfType:docker 會傳回與部署相關的所有 Docker 儲存器。 不過，有幾個 kubernetes 關鍵字可用來選取主機實體，也就是 entity.kubernetes.cluster.* 和 entity.kubernetes.node.*。 例如，查詢 entity.kubernetes.cluster.label:my-K8s-cluster AND entity.selfType:host 會傳回叢集的所有相關主機。

常見問題 (FAQ)

在雙引號 ("") 內使用萬用字元 (*) 不會產生預期結果。

由於在此情況下會將 * 符號評估為字元而非萬用字元，因此不會傳回任何相符項。 根據 lucene 規格 ，不支援詞組查詢中的單一及多個字元萬用字元搜尋。 詞組查詢是一組用雙引號括住的單字，例如 event.text:"something bad happened"。

我取得的搜尋結果計數似乎不一致。

有時，結果計數讓我很困惑。 例如，在基礎架構圖內搜尋時，請記住，視圖內的搜尋可以符合比視圖內實際可見的實體更多的實體，例如在基礎架構圖中不可見的服務。

我如何知道在欄位和欄位修飾元之後要使用哪些限量元？

任何可測量的度量都可以是欄位限量元。 對於實體而言，它可以是名稱；對於事件而言，它可以是分類。 此外，Instana 的自動完成功能還有助於為查詢的每一個部分提供有效的輸入。

當我未在搜尋查詢中指定任何欄位時，會搜尋哪些欄位?

如果未在搜尋查詢中指定任何欄位，動態焦點會將現行環境定義作為目標來提供有意義的結果。 這表示它將在基礎架構圖中搜尋實體欄位，在事件視圖中搜尋事件資料，以此類推。

entity.selfType 與 entity.type 之間有何差異？

搜尋 entity.selfType 會將搜尋結果限制為搜尋到的實體，而 entity.type 將會包括搜尋到的實體的所有子項。 例如，當您搜尋 entity.selfType:host 時，基礎架構圖將僅顯示主機實體（及所有母項實體，如區域）。 但是當您搜尋 entity.type:host時，搜尋結果也會包含在主機上執行的內容，例如 Web 伺服器、資料庫等。 不過， entity.type 和 entity.selfType 會針對應用程式視景的實體類型產生相同的結果。 例如，在「事件」視圖中使用查詢 entity.type:endpoint 時，清單將僅包含已在端點實體上偵測到的事件。