一、分享背景

1、關于此次分享

(1) 關于炎凰數據

炎凰數據是一家專注于打造自主知識產權的大數據處理平臺的公司。

(2) 關于鴻鵠

鴻鵠是炎凰數據為廣大開發者（研發人員、數據分析師、數據科學家等）提供的免費社區版一站式異構數據分析平臺，包含了異構數據的采集、導入、存儲、計算分析、可視化和告警等一系列服務。平臺采用云原生架構和特有的讀時建模引擎，支持標準的SOL語言，讓用戶可以靈活地管理海量多源異構數據，快速地分析數據特征，助力用戶輕松實現數據驅動業務，誠邀大家一起參與，免費體驗，共同助力新產品的功能優化、新技術的發現探索。

(3) 分享目的

Nginx是個常用的系統，其運維管理是普遍的需求。本文從實際案例出發，介紹如何利用日志動態分析平臺（炎凰 數據的鴻鵠產品）完成Nginx運維管理的場景落地，涵蓋從數據導入、數據解析、數據建模，到數據可視化的全過程，以及告警及第三方系統集成等等。通過實際案例分享，展示一個新型的日志動態分析平臺如何通過一站式的方案解決日志運維管理中的挑戰，幫助用戶敏捷且高效地完成運維管理工作。

(4) 期望收獲

• 端到端快速高效搭建簡單Nginx運維管理的實操案例
• 使用一體化日志分析工具平臺的最佳實踐
• 手把手的異構數據解析和關聯分析的實戰經驗

2、實踐場景：Nginx運維管理

(1) 數據源

來自Nginx的access log (包含所有客戶端請求信息)，屬于日志類型數據。

• 時序文本型。
• 具備一定格式而非結構化。
• 格式非固定，具有predefined combined format，也具有各種extended format，依賴于具體配置而變化。

來自Prometheus的CPU監控數據，屬于監控類型數據。

• 時序型(按時間采樣)。
• 結構化數據 (關系型數據庫表結構，包含明確字段定義)。

來自CMDB的映射數據，屬于靜態數據。

• 非時序型
• 結構化數據 （IT資產與業務資產的關系數據，包含：FQDN，IP，Service等的相關映射關系）

(2) 場景特點

•  對log這類動態非結構化數據的解析。
•  多源異構數據的關聯分析：Nginx + Prometheus + CMDB。
•  運維管理場景下，需求靈活多變且會持續迭代。

二、實踐案例

1、場景實現準備

應用

應用是平臺提供的一種實現不同場景的方式，讓用戶將創作的儀表板、告警等資源有序地組織起來，打造完整的解決方案。

如下圖所示，利用鴻鵠平臺，創建了一個名叫“Nginx運營管理”的應用，之后所有的操作，以及所有分析資源本身都會包含在所創建的這個應用當中。

因此，實現某一通用場景的最佳實踐就是創建“應用”，進而通過打包等方式實現“共享”。

數據源

數據集是一個一組事件的集合，用來存儲事件的容器。每一個查詢，都需要描述清楚從哪個數據集開始進行查詢。導入數據的時候，都需要明確指出事件存儲在哪個數據集中。

如下圖所示，完成應用的創建后，下一步需要新建數據集。

數據源類型

數據源類型用于對具有統一類型屬性的數據進行集合處理。平臺中的數據源類型包含一系列的屬性，定義了對數據的各類解析處理規則，例如數據索引階段的抽取模式、查詢階段的抽取模式、字段分隔符等。平臺內置了多種開箱即用的數據源類型，包含ncinx accesslog，apache access log，syslog等。數據源類型對應字段_datatype，是一個字符串，用來標記事件原始數據的格式等元信息。

在實際使用的過程中，推薦用戶優先定義數據源類型，用來限定該數據的適用范圍；必要時還需自定義一些字段加工規則，用來和數據源類型進行一一對應。

2、數據處理流程

(1) 數據導入

鴻鵠系統支持各類數據源的自動化導入操作，通過數據采集器或數據連接器，將數據從不同的數據源拉取并匯總到鴻鵠系統中。同時數據的格式也是多種多樣的，包括文件類型、數據庫類型、Kafka類型等。

• 日志數據導入

注：此演示為手動導入過程，實際生產中多為自動化導入，關于自動化導入的實現，請參考使用手冊中的“數據導入”章節設定數據源類型。

完成數據上傳后，在預覽界面選擇自定義的數據源類型。利用鴻鵠系統實現對時間字段的自動化提取，并通過預覽數據的方式確認時間字段提取的正確性。

• 設定目標數據集

將數據存放在目標數據集中，如上圖所示，支持通過數據源主機來區分不同的數據來源，以達到數據源區分的目的，避免混亂。

• 數據導入驗證

• CPU監控數據
•  設定數據源類型

由于CPU數據為csv文件，因此采用內置的csv數據源類型就可以進行導入（平臺支持csv類型文件的時間字段自動識別功能）。

• 設定目標數據集

同樣地，通過數據源主機以及數據源的方式，對數據來源進行區分。

• 資產關系映射數據

資產映射數據是相對“靜態”、不帶時間屬性的數據，表達從A到B的映射關系。對于這類數據，鴻鵠系統支持用戶通過構建“查找表”來記錄這種映射關系，實現資產映射的管理。

• 構建“查找表”

上圖中，構建了fqdn、ip、service這3個查找表。新建查找表的具體界面如下圖所示。

• FQDN <-> 系統 映射表

• IP <-> 系統 映射表

• URL節點<-> Web服務模塊 映射表

(2) 數據解析

完成了數據的導入，下一步是解析數據，提取數據字段，為建模做準備。對于本例中的數據格式，由于其是非結構化數據，故采用正則表達式的方式來提取字段。在鴻鵠系統中，正則解析方式有兩種實現方式：互動劃詞，和手動編輯。

• 方式1：互動劃詞 (“數據管理” -> “字段加工” -> “新建規則應用”)
  

上圖可以看出，藍色方框內彩色部分是手動劃分的詞；完成劃詞后，會提示輸入字段名稱（右下角紅色圓圈）；確定字段名稱后，鴻鵠系統將自動生成正則并提取字段，并提供預覽界面，實現可視化互動。

• 方式2：手動編輯

如果遇到較為復雜的正則表達，樣例數據不能滿足已有的正則匹配，則可以進行一些手動的編輯。一般首先利用互動劃詞生成自動化正則表達式，然后使用手動編輯的方式進行調整。

(3) 數據建模

完成字段的解析，下一步就是對數據進行建模，根據Nginx運營管理場景的需求來實現邏輯，包括兩種方式：

• 利用視圖構建虛擬模型
  

視圖，是由SQL語句組成的查詢定義的虛擬表，是一個邏輯上抽象的虛擬表，用來存儲查詢邏輯。實際應用中，可以利用視圖進行過濾、分桶等操作。

• 利用物化視圖構建物理模型

物化視圖是一種特殊的物理表，"物化"(Materialized)了查詢的結果。和普通視圖僅保存SQL定義不同，物化視圖會存儲SQL預計算結果的數據集，適用于數據聚合加速等場景。

在實際應用中，建議通過視圖來構建物化視圖，這樣會讓概念邏輯更加清晰，具有結構化的意義，修改或者調整的成本更低。

此外，建議用戶為各資源定義合理的命名規范（如vw，mat等），以區分視圖和物化視圖。

(4) 數據可視化

完成了模型的構建，下一步即可創建圖表，以實現可視化。在鴻鵠系統中，可以通過儀表板構建多個圖表。以HTTP網絡流量統計為例，實現過程如下：

• 圖表構建

第1步：數據探索 -> 生成期望的分析結果數據。

首先基于實現的場景來進行數據探索，如上圖所示，通過SQL實現該場景下的一些計算邏輯，生成分析結果數據；進而將其添加到可視化的UI板中，生成可視化圖表。

第2步：根據分析結果數據直接創建可視化圖表，按需更改鉆取交互的配置圖表構建。

第3步：調整可視化圖表的屬性，達到預期展現效果。

完成圖表創建后，通過調整可視化的儀表板的各類屬性，即可達到用戶預期的展現效果；該模塊支持用戶自定義，以及eCharts等更高級的功能。

• 儀表板構建——Nginx運營管理

類似上述的過程，創建多個圖表，最終構建成一個儀表板。以“Nginx運營管理”這一實際使用場景為例：

其中，所有圖表均由“日期”下拉框決定時間范圍和“系統名稱”，下拉框決定觀察對象。具體圖表包括：

• HTTP網絡流量統計 (MB)
• 頁面訪問量PV
• 頁面訪問量PV vs. CPU使?率
• HTTP請求方法分布
• HTTP請求狀態碼分布 (圖表4中鉆取的時間段)
• 訪問來源分布
• 訪問來源客戶端類型分布
• Top10訪問來源模塊統計
• Top10熱門頁面訪問統計
• 頁面訪問失敗統計
• 異常操作記錄

以上這11種圖表涵蓋了大多數通用的應用場景。其中，圖表④和圖表⑤之間形成聯動。

(5) 擴展話題

完成了儀表板的構建，下面分享一些擴展話題。

• 告警開發

基于查詢字段以及建模的視圖\物化視圖，可以進行告警開發。例如前文所述，可基于儀表板中的異常操作記錄進行告警開發，以確保異常記錄的時效性。

• 創建“告警”

如上圖所示，利用自定義觸發條件設定閾值，進而形成告警記錄；再通過郵件、webhook等方式將告警結果通知給相關人員。

• “告警”執行歷史

通過告警記錄查詢，達到良好的管理目的。

• 第三方集成

前文所述，是鴻鵠自研的儀表板上完成的開發。此外，鴻鵠系統還可以集成到第三方可視化組件（例如Grafana等）中。

• 可視化部分 -> Grafana

鴻鵠系統集成Grafana，其核心思想是將復雜的計算邏輯放到鴻鵠系統來處理，將Grafana作為可視化工具來呈現結果。這里簡單分享一個在Grafana中集成鴻鵠系統的操作步驟，更詳細的操作流程可以參照相關操作文檔。

 在Grafana中添加鴻鵠插件。

配置鴻鵠鏈接信息。

構建 SQL 查詢。

生成可視化展現。

• 第三方集成（封裝數據接口）

鴻鵠系統還可以實現數據接口的封裝功能，將復雜的SQL語句封裝成查詢工具。

創建“SQL表函數”。

在鴻鵠系統中，將復雜的查詢計算邏輯“包裝”成“SQL表函數”，如上圖所示，該“SQL表函數”包括函數參數及參數類型，函數的輸入和輸出都是數據表格；用戶自定義函數邏輯將表格A轉化為表格B。

調用“SQL表函數”。

應用過程中可以直接調用包裝好的“SQL表函數”，因此對于下游用戶接口的使用非常便捷。這樣，可以將復雜邏輯甚至是Grafana不支持的邏輯，借助接口工具得以實現；詳見下圖舉例，優化前文中Grafana集成的步驟3（構建SQL查詢）：Grafana通過調用“SQL表函數”接口直接實現可視化操作，從而實現數據計算和數據可視化之間的解耦。

三、總結和回顧

1、實踐產出

通過數據導入、數據解析、數據建模和數據可視化等操作，最終實現了Nginx運維的一個完整的場景應用，實現了該場景下的數據監控和分析。這就是一個典型的實踐產出。

• 一個完整場景應用

完成Nginx運營管理場景分析和監控需求。

充分滿足場景特點：

• 實現簡單化的非結構化數據動態解析，無需編程語言開發，只需字段加工配置調整；
• 實現非結構化數據和結構化數據關聯分析，無需顯式類型轉換便可以直接快速關聯；
• 實現靈活應對多變的運維管理需求，無需端到端代碼重構，僅需數據模型迭代

可共享，易遷移。

下圖是該場景下的界面展示示例：

2、總結回顧

Nginx運營管理是個通用的、普遍的需求，不同團隊會使用不同的工具去實現這個需求。炎凰數據使用鴻鵠平臺完成了基礎版的Nginx運營管理實現，使用到了鴻鵠的諸多基本功能，包括應用、數據集、數據源類型、查找表、字段加工、視圖、物化視圖、儀表板、告警、SQL表函數等。鴻鵠系統的更多功能也等待用戶的挖掘。

此外，我們幫助大家總結了一些最佳實踐，避免大家在使用的過程中“繞彎路”。

• 創建“應用”
• 自定義“數據源類型”
• 確認時間字段的抽取正確性
• 通過“數據源主機”和“數據源”區分數據來源
• 使用“查找表”
• 有效結合“互動劃詞”與“手動編輯”
• 利用視圖：行過濾 and/or 列過濾 and/or 時間分桶
• 利用物化視圖：聚合加速
• 基于視圖構建物化視圖
• 為各資源定義合理的命名規范，如：vw，mat等
• 參考生成各圖表所需的數據樣例文檔章節，合理分配維度和度量
• 自定義圖表
• 靈活利用自定義觸發條件設定閾值
• 利用Webhook對接外部網關，例如即時通訊工具等
• 利用“SQL表函數”封裝邏輯，構建數據接口

該平臺旨在讓用戶從繁瑣的事情中解放出來，提高工作的效率。

本次分享只是開始，更多更豐富的場景等您來挖掘！

四、Q&A

Q1：數據解析規則和數據源類型是一一對應的關系嗎？

A1：在鴻鵠系統中，這樣的綁定關系并不是一對一的關系，而是多對多的關系。同一套規則可以應用于不同的數據源，實現數據間規則的共享；同樣，同一數據源也可綁定不同的規則，形成規則“pineline”。

Q2：告警配置中的限制秒是什么？

A2：限制秒是告警配置中的一個必填項。假設監控CPU使用率，當CPU使用率達到80%將會設定一級報警，而運維人員的處理則往往會需要一定的時間延遲；這樣在運維人員處理之前就會重復報警，生成冗余報警信息，甚至曹誠告警風暴；因此，通過限制秒的方式，在限制秒的時間內避免重復報警；如果時間超過了限制秒，而報警仍未得到處理，則會再次報警。

Q3：默認告警有自帶的短信等配置方式嗎？

A3：自帶方式是沒有的，一般最佳實踐是通過webhook的方式將告警信息post出去，和外部系統實現對接；如果采用短信方式，則需要進行短信網關等的設置，需要進行針對性的開發和對接，目前沒有預定義的方式。

Q4：是不是將所有來源的數據都導入到同一數據集才能實現數據關聯？

A4：本文所演示的案例中，是將3個數據源導入到同一數據集；但這樣的操作不是必須的，鴻鵠系統支持對多源異構數據進行直接關聯，并沒有數據集的限制，用戶可以根據實際的應用場景去構建數據集的分布，更好地實現數據管理的目的。

Q5：使用鴻鵠需要先掌握什么技能？上手會比較困難嗎？

A5：鴻鵠系統主要需要SQL技能，使用基本的SQL語法就可以實現基于鴻鵠系統的開發；而對于一些高階的場景，鴻鵠本身已經包裝好了部分函數（包括python函數、java函數、C++函數等）供用戶使用，大大降低了用戶的開發門檻。