Opentelemetry協議，是CNCF（Cloud Native Computing Foundation-雲原生計算基金會）定義的最新一代的可觀測規範（目前還在孵化中），該規範定義了可觀測性的三大支柱：metrics、trace、log（指標、鏈路、日誌）。但是如果僅僅是將這三支柱的資料收集起來，而不進行關聯，那所謂的可觀測性與傳統的監控工具（APM、日誌、zabbix等）又有何區別，難道說僅僅是一套監控工具的集合嗎？所以這裡引申出一個很重要的觀念：TAG（標籤），例如前後端打通的triceID，在某種程度上也可以看做是一個tag，將指標鏈路日誌進行初步關聯的host也可以看做是一個tag，其他的例如專案、環境、版本號等等都是一個個的tag！總之，通過TAG可以實現資料的關聯，以及更多的自定義的可觀測性玩法，就顯得尤為重要。DF目前架構中所有的可觀測項均支援tag的設定，理論上tag數量無上限。

舉例：生活中常見的現象就是找工作或者hr招聘，招聘往往會有比較具體的要求，例如xx崗位，需要具備程式設計技能、計算機常識、本科學位、n年工作經驗等等，這一個個要求就好比標籤，只有滿足標籤的人才有可能得到這個崗位，那在IT系統裡，就可以是，xx伺服器上，跑了xx應用，xx資料庫，xxnginx，環境是xx環境，負責人是xxx，當出現問題時，如果標籤足夠多，很快速的就可以知道哪臺伺服器有問題，具體影響了哪些業務，哪些應用元件，誰在負責相關的元件，這樣就可以快速找到專業對口人員進行修復及彌補，從而提升解決問題的效率。

此文將利用DF從四個示例對tag的可拓展性及可玩性進行試驗：

實驗一：給伺服器進行分組

背景：企業內部往往存在多個專案組或者事業部，不同專案組或事業部在做自己的業務開發時，往往會用專屬於自己的基礎設施，如果從基礎設施到應用都接入了DF進行可觀測性，那除了通過分工作空間之外，還有什麼方式可以進行專案資源的區分嗎？當然有，df設計之初就想到了這種情況，預設的datakit的主配置檔案中，有一個global_tag的標籤，該標籤就是從基礎設施層面進行標籤的設定，該基礎設施上的其他元件，例如應用、資料庫都會預設帶上這個標籤。

1、修改datakit-inputs，配置global_tag

$ vim /usr/local/datakit/conf.d/datakit.conf

# 在global_tags 中新增標籤，除預設的三個外，還可新增其他標籤

$ [global_tags]

$  cluster = ""

$  project = "solution"

$  site = ""

同理，可將所有相關主機的datakit都加上這個標籤。

2、DF-檢視伺服器

實驗二：修改datakit識別的hostname

背景：datakit會預設採集主機層面的hostname，然後將識別到的hostname作為全域性tag，將所有的指標、鏈路、日誌、物件等資料進行關聯，但是，在很多企業內部實際環境中，hostname是無規則的字串，沒有實際意義，而又因為hostname可能被用於連線應用或管理資料庫等其他作用，企業內部無法評估更改hostname（將hostname變更為可識別的字串）會帶來怎樣的隱患，所以不願意變更hostname，為了避免風險，datakit內建的ENV_HOSTNAME就可以應對這種情況。

此方法生效後，新的hostname所在的主機資料會重新進行上傳，原有hostname的主機資料將不再更新。

建議：如有更改hostname需要，最好在初次安裝datakit時進行修改。

1、修改datakit-inputs，配置[environments]

$ vim /usr/local/datakit/conf.d/datakit.conf

# 在[environments]中修改ENV_HOSTNAME,改成方便識別的hostname

[environments]

  ENV_HOSTNAME = "118.178.57.79"

2、DF-對比更改前後的資料

實驗三：Nginx日誌統計分服務進行資料展示

背景：企業內部的nginx，一般擔負著域名轉發或者服務轉發的作用，往往nginx所對應的域名會將前端請求轉發至後端多個不同的子域名或者多個不同埠的服務，也有可能nginx直接會承載著多個域名服務，針對這種情況，統一化的nginx監控根本無法滿足，那df是如何解決這種問題的呢？

場景：nginx對外暴露18889跟80埠，分別轉發至內網伺服器118.178.57.79的8999及18999埠。

需求：分別統計nginx18889及80兩個埠對應服務的資料，例如PV、UV、請求錯誤數量等資料。

前置條件：nginx的80及18889的訪問日誌已分別配置到不同的目錄（或者配置成不同的日誌檔名稱）

80埠日誌目錄	/var/log/nginx/80/
18889埠日誌目錄	/var/log/nginx/18999/

1、配置nginx自身指標監控

詳細配置參考[nginx可觀測性最佳實踐] https://www.yuque.com/dataflux/bp/nginx

開啟nginx.conf自身效能指標統計模組

檢視nginx的http_stub_status_module模組是否已開啟

（此示例已開啟）

在Nginx.conf中增添nginx_status的location轉發

$ cd /etc/nginx

   //nginx路徑根據實際情況而定

$ vim nginx.conf

$  server{

     listen 80;

     server_name localhost;

     //埠可自定義

      location /nginx_status {

          stub_status  on;

          allow 127.0.0.1;

          deny all;

                             }

          }

檢查該模組是否已正常開通：

linux環境：curl http://127.0.0.1/nginx_status

會出現如下資料：

如已開通，可執行 nginx -t檢視nginx狀態。

接下來執行 nginx -s reload重新載入nginx

Datakit中開啟nginx.inputs：

$ cd /usr/local/datakit/conf.d/nginx/

$ cp nginx.conf.sample nginx.conf

$ vim  nginx.conf

#修改如下內容

[[inputs.nginx]]

    url = http://localhost/nginx_status

儲存nginx.conf檔案後重啟datakit

$ service datakit restart

2、分別配置配置80及18889服務對應的日誌監控

$ cd /usr/local/datakit/conf.d/log/

$ cp logging.conf.sample nginx80.conf

$ vim nginx80.conf

## 修改log路徑為正確的應用日誌的路徑

## source 、service 、pipeline 為必填欄位，可以直接用應用名稱，用以區分不同的日誌名稱

## 新增tag dominname

## 修改如下內容：

[[inputs.logging]]

  logfiles = ["/var/log/nginx/80/access.log","/var/log/nginx/80/error.log" ]

  source = "nginx"

  service = "nginx"

  pipeline = "nginx.p"

  [inputs.logging.tags]

  domainname = "118.178.226.149:80"

$ cd /usr/local/datakit/conf.d/log/

$ cp logging.conf.sample nginx18889.conf

$ vim nginx18889.conf

## 修改log路徑為正確的應用日誌的路徑

## source 、service 、pipeline 為必填欄位，可以直接用應用名稱，用以區分不同的日誌名稱

## 新增tag dominname

## 修改如下內容：

[[inputs.logging]]

  logfiles = ["/var/log/nginx/18889/access.log","/var/log/nginx/18889/error.log" ]

  source = "nginx"

  service = "nginx"

  pipeline = "nginx.p"

  [inputs.logging.tags]

  domainname = "118.178.226.149:18889"

3、配置自定義檢視（通過tag區分域名）

建立步驟參考[建立場景及檢視] https://www.yuque.com/dataflux/bp/sample1#IVN7h

步驟：登入DF—>場景—>新建場景—>新建空白場景—>系統檢視（建立NGINX）

重點：在系統模板上修改nginx檢視相關配置

1、進入檢視編輯狀態，點選修改檢視變數，新增檢視變數

L::nginx:(distinct(`domainname`)){host='#{host}'}

註釋：繼承nginx指標中的host，在L（日誌）中查詢nginx日誌中不同的domainname

2、修改具體檢視的引數

4、df-分服務資料展示

同理：可以通過打不同的tag，用以區分不同的project、不同的負責人、不同的業務模組、不同的環境等等等等，tag具體的能力取決於你的想象空間。

實驗四：通過tag確認服務具體owner，進行告警通知

背景：企業內部隨著企業業務的發展，微服務、容器被大量使用，服務元件越來越多，相應的開發及運維人員也越來越多，每個人的分工也越來越細，當業務系統或IT系統出現故障，最佳的告警實踐就是可以直接指定相關負責人員，從而提高告警閉環的效率，這種方式常用的方式是告警只發送給相關的人員，或者是jira指派工單，那DF是怎麼操作的呢？DF中只需要在具體的可觀測inputs中新增tag（理論上支援無上限的tag數量），例如在nginx-inputs中新增自定義tag，owner = "xxx"，然後在異常檢測中將owner設定為變數，異常檢測就可以自動識別該欄位併發送至釘釘或企業微信群，效果如下：

例如在上述的nginx自定義日誌中進行新增：

乾貨！4大實驗專案，深度解析Tag在可觀測性領域的最佳實踐！

乾貨！4大實驗專案，深度解析Tag在可觀測性領域的最佳實踐！

實驗一：給伺服器進行分組

1、修改datakit-inputs，配置global_tag

2、DF-檢視伺服器

實驗二：修改datakit識別的hostname

1、修改datakit-inputs，配置[environments]

2、DF-對比更改前後的資料

實驗三：Nginx日誌統計分服務進行資料展示

1、配置nginx自身指標監控

開啟nginx.conf自身效能指標統計模組

Datakit中開啟nginx.inputs：

2、分別配置配置80及18889服務對應的日誌監控

3、配置自定義檢視（通過tag區分域名）

4、df-分服務資料展示

實驗四：通過tag確認服務具體owner，進行告警通知

1、在inputs中新增tag

2、配置異常檢測

3、觸發告警，檢視告警事件

乾貨！4大實驗專案，深度解析Tag在可觀測性領域的最佳實踐！

乾貨！4大實驗專案，深度解析Tag在可觀測性領域的最佳實踐！

實驗一：給伺服器進行分組

1、修改datakit-inputs，配置global_tag

2、DF-檢視伺服器

實驗二：修改datakit識別的hostname

1、修改datakit-inputs，配置[environments]

2、DF-對比更改前後的資料

實驗三：Nginx日誌統計分服務進行資料展示

1、配置nginx自身指標監控

開啟nginx.conf自身效能指標統計模組

Datakit中開啟nginx.inputs：

2、分別配置配置80及18889服務對應的日誌監控

3、配置自定義檢視（通過tag區分域名）

4、df-分服務資料展示

實驗四：通過tag確認服務具體owner，進行告警通知

1、在inputs中新增tag

2、配置異常檢測

3、觸發告警，檢視告警事件

最新文章