如何用 OTel Collector 的 transform 與 filter 處理器在導出前規范化并過濾日志【免費下載鏈接】netdataThe fastest path to AI-powered full stack observability, even for lean teams.項目地址: https://gitcode.com/GitHub_Trending/ne/netdata當多個 receiver 采集到的日志在發送到 Netdata 之前需要統一做同樣的事——把 JSON 日志體展開成屬性、把應用自有的level字段提升為 severity、補上缺失的 service 標識再丟掉健康檢查之類的噪聲記錄——OTel Collector 的transform和filter處理器就是干這個的。本文適用于已經跑通 Ingest OpenTelemetry Metrics and Logs 中前置步驟的環境本機有一個帶 OpenTelemetry 插件的 Netdata AgentCollector 與 Agent 同主機通過127.0.0.1:4317的 OTLP/gRPC 端點通信。文檔示例均使用 OpenTelemetry Collector Contrib0.157.0驗證。前提先確認采集鏈路已通在寫處理器之前先保證最小鏈路能工作。要點來自 Ingest OpenTelemetry Metrics and LogsNetdata Agent 必須帶 OpenTelemetry 插件。Linux 原生 DEB/RPM 包作為netdata的依賴安裝靜態構建默認捆綁32 位 ARMv6 除外所有 Docker 鏡像都包含Linux 源碼構建需要--enable-plugin-otel。插件在 Windows 和 FreeBSD 上不可用。導出端只能用otlp_grpcexporter 加端口4317。Netdata 不接受otlp_httpexporter 或 OTLP/HTTP 端口4318如果localhost解析到 IPv6請寫127.0.0.1。同主機回環連接可以用下面這個禁用 TLS 的 exporter跨主機時要改用 TLS詳見 Securing the OTLP Endpointexporters: otlp_grpc/netdata: endpoint: 127.0.0.1:4317 tls: insecure: true驗證otel-logs視圖需要 Netdata Cloud 賬號并登錄該視圖是有訪問門檻的。何時用 transform而不是 receiver 自帶的解析器如果某類格式只在某一個文件源出現優先用 receiver 內置的解析能力。file_logreceiver 的operators可以直接加json_parser在采集時就把時間戳和 severity 提升為 OpenTelemetry 日志記錄字段receivers: file_log/my_application: include: [/var/log/myapp/*.json] start_at: end operators: - type: json_parser timestamp: parse_from: attributes.time layout: %Y-%m-%dT%H:%M:%S.%LZ severity: parse_from: attributes.leveltransform處理器適合跨多個 receiver 復用、或需要在采集之后統一改寫的場景filter處理器則專門用來丟棄記錄。下面的所有配置均假定你在一條共享的 logs 管道上做這種統一處理。用 transform 解析 JSON 日志體當日志的 body 是一段 JSON 字符串時用ParseJSON解析并把鍵合并進日志屬性processors: transform/parse_json: error_mode: ignore log_statements: - merge_maps(log.attributes, ParseJSON(log.body), insert) where IsString(log.body)對于形如{level:error,msg:connection refused,duration_ms:312}的 body處理器會添加level、msg、duration_ms三個屬性同時保留原始 body。insert策略在已存在同名屬性時保留原值error_mode: ignore讓非法 JSON 的記錄繼續走管道Collector 只記錄轉換錯誤。where IsString(log.body)保證只對字符串 body 執行。注意ParseJSON要求 body 是 JSON 字符串遇到非字符串或非法 JSON 會返回錯誤。用 transform 規范化 severity 與資源標識解析出level之后把它提升為 severity text并在缺失時補上 Netdata Logs tab 用來識別流的 resource 標識processors: transform/normalize_logs: error_mode: ignore log_statements: - set(log.severity_text, log.attributes[level]) where log.attributes[level] ! nil - set(resource.attributes[service.name], my-application) where resource.attributes[service.name] nil - set(resource.attributes[service.namespace], production) where resource.attributes[service.namespace] nil第一條語句只把源值原樣保存為文本它不會推斷出 OpenTelemetry 的 severity number。如果下游條件或儀表盤依賴數值 severity需要按來源的級別顯式映射不要假設所有應用使用同一套標尺。靜態的service.name/service.namespace只在管道只服務一個已知服務時合適共享管道應從可信的 receiver 元數據派生標識或保留應用已有的 OpenTelemetry resource 屬性。用 filter 丟棄噪聲記錄注意transform里給屬性賦值不會丟棄記錄丟記錄必須用filter處理器的log_conditions——任意一條條件命中該記錄即被丟棄條件之間是 OR 關系processors: filter/drop_noise: error_mode: ignore log_conditions: - IsMatch(log.body, (?i)health.?check)filter 的位置很關鍵放在 Netdata exporter 之前也放在任何不應統計被丟棄記錄的 connector 之前。filter 會永久丟棄匹配的遙測數據文檔建議從窄條件開始、先觀察代表性輸入、在非關鍵管道上測試再部署。組裝一條完整的文件到 Netdata 管道把上面的組件拼起來tail 一份 JSON 行日志解析 body缺失時補 service 標識丟棄健康檢查再把剩余日志發到本機 Netdata Agentreceivers: file_log/my_application: include: [/var/log/myapp/*.json] start_at: end processors: transform/prepare_logs: error_mode: ignore log_statements: - merge_maps(log.attributes, ParseJSON(log.body), insert) where IsString(log.body) - set(log.severity_text, log.attributes[level]) where log.attributes[level] ! nil - set(resource.attributes[service.name], my-application) where resource.attributes[service.name] nil filter/drop_health_checks: error_mode: ignore log_conditions: - IsMatch(log.body, (?i)health.?check) exporters: otlp_grpc/netdata: endpoint: 127.0.0.1:4317 tls: insecure: true service: pipelines: logs: receivers: [file_log/my_application] processors: [transform/prepare_logs, filter/drop_health_checks] exporters: [otlp_grpc/netdata]處理器順序是這條管道能不能生效的核心遵循文檔給出的 OTTL 操作規則用信號專屬路徑寫語句和條件如log.body、log.attributes、resource.attributes。where讓單條語句有條件地執行filter 條件不同任一命中即丟棄。先解析、再讀取解析出的屬性先規范化、再按規范化后的值過濾過濾放在不應收到被丟棄記錄的 connector 和 exporter 之前。error_mode: ignore會記錄求值錯誤并繼續處理只有當你寧可丟棄受影響的載荷也不轉發未轉換數據時才用propagate。OTTL 語法和處理器配置隨版本演進以你所部署的確切 Collector 版本的上游文檔為準。生產環境的文件采集還應加上持久化 offsetfile_storage擴展 receiver 的storage選項做法見 Collect Logs with OpenTelemetry Collector 的 Application log files 一節不帶 storage 時 offset 只存在內存里重啟行為取決于start_at。驗證結果保存配置后按你的安裝方式啟動或重載 Collector。在 Netdata 打開該節點的Logstab選擇otel-logs數據源再用Services選擇器選中你配置的服務。Netdata 里存儲的服務字段就是resource.attributes.service.name所以第 4 節 transform 中補的service.name直接決定這里能選中什么。如果 Collector 報告導出成功但記錄缺失檢查記錄的時間戳Netdata 只接受過去 24 小時內、未來 10 分鐘內的記錄被拒的記錄通過 OTLPpartial_success上報。排查與邊界文檔給出的對照項如下出現對應現象時按此判斷Collector 拒絕配置用你確切在用的 Collector 版本核對組件標識符和 OTTL 路徑。transform和filter是 Contrib 組件Core 發行版里不一定有。解析出的屬性沒有出現用臨時的 debug exporter 檢查 incoming body 的類型和值。ParseJSON要求 JSON 字符串非法 JSON 會返回錯誤在error_mode: ignore下記錄會繼續走管道。severity 過濾表現異常先確認來源到底設置了severity_number、只有severity_text、還是自定義屬性。文本到數值的映射需要按來源單獨寫規則。太多記錄消失了移除或收窄 filter 條件同時觀察代表性記錄。log_conditions內的條件按 OR 組合。Netdata 收到了日志但 service 選擇器是空的在導出前設置resource.attributes.service.name然后在otel-logs數據源里核對它。最后一條容易踩的邊界transform 和 filter 只待在一條信號管道內它們不會把日志變成指標。如果你要從匹配的日志記錄派生指標例如 warning/error 計數需要 connector 橋接 logs 和 metrics 管道Netdata 維護的配方在 Create metrics from OpenTelemetry logs。【免費下載鏈接】netdataThe fastest path to AI-powered full stack observability, even for lean teams.項目地址: https://gitcode.com/GitHub_Trending/ne/netdata創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 如何用 OTel Collector 的 transform 與 filter 處理器在導出前規范化并過濾日志？
如何用 OTel Collector 的 transform 與 filter 處理器在導出前規范化并過濾日志【免費下載鏈接】netdataThe fastest path to AI-powered full stack observability, even for lean teams.項目地址: https://gitcode.com/GitHub_Trending/ne/netdata當多個 receiver 采集到的日志在發送到 Netdata 之前需要統一做同樣的事——把 JSON 日志體展開成屬性、把應用自有的level字段提升為 severity、補上缺失的 service 標識再丟掉健康檢查之類的噪聲記錄——OTel Collector 的transform和filter處理器就是干這個的。本文適用于已經跑通 Ingest OpenTelemetry Metrics and Logs 中前置步驟的環境本機有一個帶 OpenTelemetry 插件的 Netdata AgentCollector 與 Agent 同主機通過127.0.0.1:4317的 OTLP/gRPC 端點通信。文檔示例均使用 OpenTelemetry Collector Contrib0.157.0驗證。前提先確認采集鏈路已通在寫處理器之前先保證最小鏈路能工作。要點來自 Ingest OpenTelemetry Metrics and LogsNetdata Agent 必須帶 OpenTelemetry 插件。Linux 原生 DEB/RPM 包作為netdata的依賴安裝靜態構建默認捆綁32 位 ARMv6 除外所有 Docker 鏡像都包含Linux 源碼構建需要--enable-plugin-otel。插件在 Windows 和 FreeBSD 上不可用。導出端只能用otlp_grpcexporter 加端口4317。Netdata 不接受otlp_httpexporter 或 OTLP/HTTP 端口4318如果localhost解析到 IPv6請寫127.0.0.1。同主機回環連接可以用下面這個禁用 TLS 的 exporter跨主機時要改用 TLS詳見 Securing the OTLP Endpointexporters: otlp_grpc/netdata: endpoint: 127.0.0.1:4317 tls: insecure: true驗證otel-logs視圖需要 Netdata Cloud 賬號并登錄該視圖是有訪問門檻的。何時用 transform而不是 receiver 自帶的解析器如果某類格式只在某一個文件源出現優先用 receiver 內置的解析能力。file_logreceiver 的operators可以直接加json_parser在采集時就把時間戳和 severity 提升為 OpenTelemetry 日志記錄字段receivers: file_log/my_application: include: [/var/log/myapp/*.json] start_at: end operators: - type: json_parser timestamp: parse_from: attributes.time layout: %Y-%m-%dT%H:%M:%S.%LZ severity: parse_from: attributes.leveltransform處理器適合跨多個 receiver 復用、或需要在采集之后統一改寫的場景filter處理器則專門用來丟棄記錄。下面的所有配置均假定你在一條共享的 logs 管道上做這種統一處理。用 transform 解析 JSON 日志體當日志的 body 是一段 JSON 字符串時用ParseJSON解析并把鍵合并進日志屬性processors: transform/parse_json: error_mode: ignore log_statements: - merge_maps(log.attributes, ParseJSON(log.body), insert) where IsString(log.body)對于形如{level:error,msg:connection refused,duration_ms:312}的 body處理器會添加level、msg、duration_ms三個屬性同時保留原始 body。insert策略在已存在同名屬性時保留原值error_mode: ignore讓非法 JSON 的記錄繼續走管道Collector 只記錄轉換錯誤。where IsString(log.body)保證只對字符串 body 執行。注意ParseJSON要求 body 是 JSON 字符串遇到非字符串或非法 JSON 會返回錯誤。用 transform 規范化 severity 與資源標識解析出level之后把它提升為 severity text并在缺失時補上 Netdata Logs tab 用來識別流的 resource 標識processors: transform/normalize_logs: error_mode: ignore log_statements: - set(log.severity_text, log.attributes[level]) where log.attributes[level] ! nil - set(resource.attributes[service.name], my-application) where resource.attributes[service.name] nil - set(resource.attributes[service.namespace], production) where resource.attributes[service.namespace] nil第一條語句只把源值原樣保存為文本它不會推斷出 OpenTelemetry 的 severity number。如果下游條件或儀表盤依賴數值 severity需要按來源的級別顯式映射不要假設所有應用使用同一套標尺。靜態的service.name/service.namespace只在管道只服務一個已知服務時合適共享管道應從可信的 receiver 元數據派生標識或保留應用已有的 OpenTelemetry resource 屬性。用 filter 丟棄噪聲記錄注意transform里給屬性賦值不會丟棄記錄丟記錄必須用filter處理器的log_conditions——任意一條條件命中該記錄即被丟棄條件之間是 OR 關系processors: filter/drop_noise: error_mode: ignore log_conditions: - IsMatch(log.body, (?i)health.?check)filter 的位置很關鍵放在 Netdata exporter 之前也放在任何不應統計被丟棄記錄的 connector 之前。filter 會永久丟棄匹配的遙測數據文檔建議從窄條件開始、先觀察代表性輸入、在非關鍵管道上測試再部署。組裝一條完整的文件到 Netdata 管道把上面的組件拼起來tail 一份 JSON 行日志解析 body缺失時補 service 標識丟棄健康檢查再把剩余日志發到本機 Netdata Agentreceivers: file_log/my_application: include: [/var/log/myapp/*.json] start_at: end processors: transform/prepare_logs: error_mode: ignore log_statements: - merge_maps(log.attributes, ParseJSON(log.body), insert) where IsString(log.body) - set(log.severity_text, log.attributes[level]) where log.attributes[level] ! nil - set(resource.attributes[service.name], my-application) where resource.attributes[service.name] nil filter/drop_health_checks: error_mode: ignore log_conditions: - IsMatch(log.body, (?i)health.?check) exporters: otlp_grpc/netdata: endpoint: 127.0.0.1:4317 tls: insecure: true service: pipelines: logs: receivers: [file_log/my_application] processors: [transform/prepare_logs, filter/drop_health_checks] exporters: [otlp_grpc/netdata]處理器順序是這條管道能不能生效的核心遵循文檔給出的 OTTL 操作規則用信號專屬路徑寫語句和條件如log.body、log.attributes、resource.attributes。where讓單條語句有條件地執行filter 條件不同任一命中即丟棄。先解析、再讀取解析出的屬性先規范化、再按規范化后的值過濾過濾放在不應收到被丟棄記錄的 connector 和 exporter 之前。error_mode: ignore會記錄求值錯誤并繼續處理只有當你寧可丟棄受影響的載荷也不轉發未轉換數據時才用propagate。OTTL 語法和處理器配置隨版本演進以你所部署的確切 Collector 版本的上游文檔為準。生產環境的文件采集還應加上持久化 offsetfile_storage擴展 receiver 的storage選項做法見 Collect Logs with OpenTelemetry Collector 的 Application log files 一節不帶 storage 時 offset 只存在內存里重啟行為取決于start_at。驗證結果保存配置后按你的安裝方式啟動或重載 Collector。在 Netdata 打開該節點的Logstab選擇otel-logs數據源再用Services選擇器選中你配置的服務。Netdata 里存儲的服務字段就是resource.attributes.service.name所以第 4 節 transform 中補的service.name直接決定這里能選中什么。如果 Collector 報告導出成功但記錄缺失檢查記錄的時間戳Netdata 只接受過去 24 小時內、未來 10 分鐘內的記錄被拒的記錄通過 OTLPpartial_success上報。排查與邊界文檔給出的對照項如下出現對應現象時按此判斷Collector 拒絕配置用你確切在用的 Collector 版本核對組件標識符和 OTTL 路徑。transform和filter是 Contrib 組件Core 發行版里不一定有。解析出的屬性沒有出現用臨時的 debug exporter 檢查 incoming body 的類型和值。ParseJSON要求 JSON 字符串非法 JSON 會返回錯誤在error_mode: ignore下記錄會繼續走管道。severity 過濾表現異常先確認來源到底設置了severity_number、只有severity_text、還是自定義屬性。文本到數值的映射需要按來源單獨寫規則。太多記錄消失了移除或收窄 filter 條件同時觀察代表性記錄。log_conditions內的條件按 OR 組合。Netdata 收到了日志但 service 選擇器是空的在導出前設置resource.attributes.service.name然后在otel-logs數據源里核對它。最后一條容易踩的邊界transform 和 filter 只待在一條信號管道內它們不會把日志變成指標。如果你要從匹配的日志記錄派生指標例如 warning/error 計數需要 connector 橋接 logs 和 metrics 管道Netdata 維護的配方在 Create metrics from OpenTelemetry logs。【免費下載鏈接】netdataThe fastest path to AI-powered full stack observability, even for lean teams.項目地址: https://gitcode.com/GitHub_Trending/ne/netdata創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考