此文檔中主要是針對 configmap 對象中關于 filebeat 配置文件內容針對生產環境如何配置的說明。

1. filebeat.inputs 靜態日志收集器

在 kubernetes 環境中，有可能你需要同時收集集群中每個節點（服務器）的系統日志，比如 /var/log/ 目錄下的日志，這些日志文件級別都是靜態的，文件名稱固定的，因此這里有必要介紹手動指定的方式： filebeat.inputs
這里主要介紹的是 Filebeat 配置文件中 filebeat.inputs 的配置。

filebeat.inputs 配置項的作用就是告訴 Filebeat 程序可以從哪兒獲取需要讀取的數據。支持多種輸入模塊，比如普通文件中、redis 中、kafka 中等，路徑的配置可以使用通配符進行模糊匹配。

配置示例：

filebeat.inputs:
- type: logpaths:- /var/log/system.log- /var/log/wifi.log# 支持通配符- /log/spms-*[a-z].log
# 可以寫多個
- type: filestreampaths:- "/var/log/apache2/*"

• log log 輸入模塊適用于普通文本日志文件、syslog 格式的日志。
• filestream filestream 輸入模塊是 Filebeat 7.13.0 版本中引入的新輸入模塊，用于從文件中讀取結構化數據。filestream 輸入模塊支持讀取 JSON 格式、NDJSON 格式等結構化數據文件，它可以更高效地處理結構化數據文件，并提供更好的性能。

不同的輸入模塊支持不同的配置項，在 filestream 下可以配置如下選項(這些配置項同時支持 log 輸入模塊)。

    - type: filestream# id 是集群中的唯一標識id: sys-logspaths:# 日志收集的路徑- /var/log/*.logparsers:# 解析器- syslog: ~prospector:# 勘探者scanner:symlinks: trueprocessors:# 處理器名稱- add_host_metadata:

parsers 解析器，主要對輸入的數據進行解析，不同的數據有不同的格式，比如docker容器的日志格式一般是 json, 就需要使用 container 解析器進行解析處理。
prospector 勘探者，主要是控制 Filebeat 對日志文件進行讀取的時候如何處理，比如掃描文件的時候是否支持軟連接的文件路徑，是否對日志文件進行計算密文，以便更好的識別是否是同一個文件。

parsers 和 prospector 后面內容有詳細介紹。也可以參考官方文檔

processors 處理器，主要會把每次日志事件內容進行處理，比如添加某些字段，刪除某些字段，刪除這個事件等。處理器可以給每個 inputs 的輸入模塊配置不同的處理器，比如本示例就給 filestream 這個輸入模塊配置了
還有幾個值得注意的配置項：
harvester_buffer_size 每個采集器在獲取文件時使用的緩沖區的大小（以字節為單位）。默認值為16384。
max_bytes 單個日志消息可以具有的最大字節數。max_bytes之后的所有字節都將被丟棄而不發送。此設置對于多行日志消息特別有用，因為多行日志信息可能會變大。默認值為10MB（10485760）。
close_inactive指定在文件不再更新的情況下多久后關閉文件句柄。我們建議您將close_inactive設置為一個大于日志文件最不頻繁更新的值。例如，如果日志文件每隔幾秒鐘更新一次，則可以安全地將 close_inactive 設置為1m。如果存在更新率非常不同的日志文件，則可以使用具有不同值的多個配置。

2. filebeat.autodiscover 自動發現

當您在容器上運行應用程序時，它們會成為監控系統的移動目標。自動發現允許您跟蹤它們，并在發生更改時調整設置。

2.1. autodiscover 和 inputs

在Filebeat中，自動發現 filebeat.autodiscover和 file.inputs 存在一些區別。

1. filebeat.inputs 指定帶通配符的路徑：當你使用 filebeat.inputs 指定帶通配符的路徑時，Filebeat會根據通配符匹配的規則來收集符合條件的日志文件。這種方式適用于靜態的日志路徑，例如指定某個固定目錄下的所有日志文件。但是它并不會動態地適應新創建的容器日志。

2. filebeat.autodiscover：Filebeat 的自動發現功能允許它動態地發現和收集新創建的容器日志。當容器啟動時，Filebeat 可以檢測到新的容器日志源，并自動開始收集這些日志。這使得在容器動態創建和銷毀時，Filebeat可以及時地調整以收集新的日志。

所以，帶通配符的路徑的 filebeat.inputs 并不能收集到新創建的容器日志，這時就需要使用自動發現功能來實現動態收集新創建的容器日志。

2.2. 如何配置

您可以在filebeat.yml配置文件的 filebeat.autodiscover部分定義自動發現設置。并且必須配置一個提供者程序列表。就像下面這樣：

filebeat.autodiscover:providers:- type: kubernetes...- type: docker...

可以配置多個，就像上面的一樣。也可以配置一個就像下面的一樣：

filebeat.autodiscover:providers:- type: kubernetes...

要想啟用 provider 或者說讓他們真正有效工作起來，還需要進一步配置。

有兩種方案：

1. 給每個 provider 配置 templates ，并指定被收集日志的路徑。

    filebeat.autodiscover:- type: kubernetestemplates:- config:- type: containerpaths:- "/var/lib/docker/containers/${data.kubernetes.container.id}/*.log"

2. 給每個 provider 配置基于 hints 的自動發現，hints 是 Elasticsearch 的提示系統 。并配置一個默認配置 hints.default_config，或者使用 templates ，并指定被收集日志的路徑。hints.default_config 和 templates 可以結合起來使用，后面章節有詳細介紹。

    filebeat.autodiscover:providers:- type: kuberneteshints.enabled: truehints.default_config:type: filestreamid: kubernetes-container-logs-${data.kubernetes.pod.name}-${data.container.id}paths:- /var/lib/docker/containers/${data.kubernetes.container.id}/*.log

1.2.1. Providers 提供者

自動發現 Providers 的工作方式是監視系統上的事件，并將這些事件轉換為具有通用格式的內部自動發現事件。配置 Providers 時，您可以選擇使用自動發現事件中的字段來設置條件，當滿足條件時，會啟動特定的配置。

啟動時，Filebeat 將掃描現有容器并為它們啟動適當的配置。然后它將監視新的開始/停止事件。這樣可以確保您不必擔心狀態，而只需定義所需的配置。
此文檔主要介紹基于docker 和云原生的兩種提供者(providers) ：

• docker Docker 自動發現 provider 監視Docker容器的啟動和停止。

• kubernetes Kubernetes自動發現提供程序監視Kubernete node、pod 和 service 的啟動、更新和停止。

因為此專欄主要是云原生，所以只介紹 kubernetes 的 providers，docker 的請參考官方文檔

1.2.2. Providers kubernetes

kubernetes自動發現提供程序具有以下配置設置：
node
（可選）指定要將filebeat定位到的節點，以防無法準確檢測到，例如在主機網絡模式下運行filebeat時。就是指定一個這個 Filebeat 運行在哪個kubernetes 工作節點上，一般的設置值是一個 Pod 的環境變量 NODE_NAME，而這個變量的值是從 Pod 運行是 spec.nodeName 字段的值獲取的。

      env:- name: NODE_NAMEvalueFrom:fieldRef:fieldPath: spec.nodeName

namespace
（可選）選擇要從中收集元數據的命名空間。如果未設置，處理器將從所有命名空間收集元數據。默認情況下未設置。命名空間配置僅適用于命名空間范圍內的kubernetes資源。這個只能同時配置一個命名空間，建議使用條件判斷替代。

cleanup_timeout
當容器在一段時間內沒有產生任何活動時（即沒有日志產生或文件變化），Filebeat會停止監視該容器的配置。這可以幫助節省資源并避免不必要的日志收集。你可以根據實際需求，通過配置來調整這個時間，以滿足你對日志收集的要求。默認 60s。

kube_config
（可選）使用給定的配置文件作為Kubernetes客戶端的配置。它默認為KUBECONFIG環境變量（如果存在）。

使用此選項，有幾個條件：

• 刪除了關于 Filebeat daemonset對象使用的 rbac 相關資源對象。刪除 Filebeat 關于 daemonset 對象yaml文件中 serviceAccountName: filebeat 的配置。
• kube_config 指定的配置文件路徑是真的 Filebeat Pod 內的路徑，因此需要把配置文件映射到 Filebeat Pod 中。
  這需要再 daemonset 對象的 yaml 文件中添加如下配置：

        volumeMounts:- name: kubeconfigmountPath: /root/.kube/configreadOnly: truevolumes:- name: kubeconfighostPath:path: /root/.kube/config

此示例我使用了默認的 kubernetes admin 的認證文件，實際生產中你應該自己創建一個有合適權限的認證文件。

• 最后在 configmap 的yaml 文件中設置。

        kube_config: /root/.kube/config

resource
（可選）選擇要進行發現的資源。目前支持的Kubernetes資源有 pod、service 和node。如果未配置，則資源默認為pod。

scope
（可選）指定需要在何種級別執行自動發現。scope可以將 node 或 cluster 作為值。node 作用域允許發現指定節點(服務器)中的資源。cluster 作用域允許集群范圍內的發現。在 node 范圍內只能發現pod和節點資源。

templates

通過定義配置模板 templates，自動發現子系統可以在服務開始運行時對其進行監控。
配置模板可以包含自動發現事件中的變量。這些變量可以在 data 命名空間下訪問，例如訪問Pod IP: ${data.kubernetes.pod.ip}。

下面是配置模板中可用的字段。kubernetes.*字段將在每個發出的事件上可用：

通用字段：
host

如果 include_annotations 配置被添加到提供程序配置，那么配置中存在的注解列表將被添加到事件中。

如果 include_labels 配置被添加到提供程序配置，那么配置中存在的標簽列表將被添加到事件中。

如果將 exclude_labels 配置添加到提供程序配置中，則該配置中存在的標簽列表將從事件中排除。

如果在提供程序配置中將 labels.dot-config設置為 true，那么 Labels 中的 . 將替換為 _。默認情況下為 true。

如果在提供程序配置中將 annotations.dedot-config 設置為 true，那么 Annotations . 中將替換為_。默認情況下為 true。

事件輸出示例如下：

{"host": "172.17.0.21","port": 9090,"kubernetes": {"container": {"id": "bb3a50625c01b16a88aa224779c39262a9ad14264c3034669a50cd9a90af1527","image": "prom/prometheus","name": "prometheus"},"labels": {"project": "prometheus",...},"namespace": "default","node": {"name": "minikube"},"pod": {"name": "prometheus-2657348378-k1pnh"}},
}

Filebeat 的 templates 可以配置 input 和 module 。
示例配置：
如下配置啟動了一個用于在 kube-system Kubernetes命名空間中運行的所有pod容器的 docker 輸入模塊。

filebeat.autodiscover:providers:- type: kubernetestemplates:- condition:equals:kubernetes.namespace: kube-systemconfig:- type: containerpaths:- /var/log/containers/*-${data.kubernetes.container.id}.logexclude_lines: ["^\\s+[\\-`('.|_]"]  # drop asciiart lines

如果你希望使用 modules 來進一步處理容器中的日志，可以使用 docker 輸入模塊來替換默認的 輸入模塊。如下是配置示例：

filebeat.autodiscover:providers:- type: kubernetestemplates:- condition:equals:kubernetes.container.image: "redis"config:- module: redislog:input:type: containerpaths:- /var/log/containers/*-${data.kubernetes.container.id}.log

1.2.3. 基于提示（hints）的自動發現

Filebeat支持基于 hints 程序提示的自動發現。提示系統在Kubernetes Pod annotations或Docker labels 中查找前綴為 co.elastic.log 的提 hints。一旦容器啟動，Filebeat就會檢查它是否包含任何 hints，并啟動相應的配置。 hints會告訴Filebeat如何獲取給定容器的日志。
docker-compose 示例：

version: "3.9"
services:nginx:labels:co.elastic.logs/module: nginxco.elastic.logs/fileset.stdout: accessco.elastic.logs/fileset.stderr: errorrestart: alwaysimage: nginx:1.20.2-alpine-upstream

kubernetes 示例：

apiVersion: apps/v1
kind: <kind name>
metadata:annotations:co.elastic.logs/json.message_key: "log"co.elastic.logs/json.add_error_key: "true"

默認情況下，將使用 filestream 的 input 模塊從容器中檢索日志。您可以通過配置不同的 hints （即 annotations）來修改此行為。

支持的 hints的完整列表：

co.elastic.logs/enabled
Filebeat默認情況下從所有容器獲取日志，您可以將此提示設置為 false 以忽略容器的輸出。Filebeat不會從中讀取或發送日志。

還有如果禁用默認配置 hints.default_config.enabled: false，則可以使用此注解僅對設置為 true 的容器啟用日志檢索。如果您打算將其與Kubernetes一起使用，請記住注解值只能是字符串類型，因此您需要相應地將其明確定義為 "true" 或 "false"。

co.elastic.logs/multiline.*
多行設置。有關所有支持選項的完整列表，請參閱多行消息。
就是 Java 程序拋出異常的日志，一條日志信息別保存為連續的多行。

co.elastic.logs/json.*
JSON設置。如果是 type: filestream（默認）輸入模塊，請參閱ndjson以獲取所有支持選項的完整列表。如果是 type: container 或 type: log 輸入模塊，請參閱json以獲取所有支持選項的完整列表。

例如，以下帶有json選項的提示：

co.elastic.logs/json.message_key: "log"
co.elastic.logs/json.add_error_key: "true"

這轉化為如下 yaml 配置

• filestream

parsers:- ndjson:message_key: "log"add_error_key: "true"

• log

json.message_key: "log"
json.add_error_key: "true"

co.elastic.logs/include_lines
希望Filebeat包含的行，包含的行需要和一個正則表達式列表相匹配。

co.elastic.logs/exclude_lines
與要Filebeat排除的行匹配的正則表達式列表。

co.elastic.logs/module
指定用于解析容器中日志的 module，而不是使用原始docker inuput。
例如，處理nginx日志，有 nginx module,處理mysql日志有專門的 mysql module。
有關支持的模塊列表，請參閱模塊。

co.elastic.logs/fileset
配置模塊后，將容器日志映射到模塊處理器。您可以這樣配置哪些容器的日志使用該模塊進行智能地處理：

co.elastic.logs/fileset: access

或者在容器中為每個流配置一個文件集（stdout和stderr）：

co.elastic.logs/fileset.stdout: access
co.elastic.logs/fileset.stderr: error

co.elastic.logs/processors
定義要添加到Filebeat input/module 配置的處理器。

如果處理器配置使用列表數據結構，則必須枚舉對象字段。例如，下面的 rename 處理器配置 hints：

processors:- rename:fields:- from: "a.g"to: "e.d"fail_on_error: true

將看起來像：

co.elastic.logs/processors.rename.fields.0.from: "a.g"
co.elastic.logs/processors.rename.fields.1.to: "e.d"
co.elastic.logs/processors.rename.fail_on_error: 'true'

如果處理器配置使用映射數據結構，則不需要枚舉。例如，等效于下面的add_fields配置

processors:- add_fields:target: projectfields:name: myproject

轉換為 annotations 后：

co.elastic.logs/processors.1.add_fields.target: "project"
co.elastic.logs/processors.1.add_fields.fields.name: "myproject"

為了提供處理器定義的排序，可以提供數字。如果沒有，提示生成器將執行任意排序：

# 有的
co.elastic.logs/processors.1.dissect.tokenizer: "%{key1} %{key2}"# 沒有的
co.elastic.logs/processors.dissect.tokenizer: "%{key2} %{key1}"

在上述示例中，將首先執行標記為1的處理器定義。

kubernetes 啟用 hints

Kubernetes自動發現提供程序支持Pod注釋中的提示。要啟用它，只需設置hints.enabled：

filebeat.autodiscover:providers:- type: kuberneteshints.enabled: true

假如你的環境有點特殊，比如日志路徑是自定義的，那可以配置當看到新容器時將啟動的默認配置，如下所示：

filebeat.autodiscover:providers:- type: kuberneteshints.enabled: "true"hints.default_config:type: containerpaths:- /var/log/containers/*-${data.container.id}.log  # CRI path

也可以完全禁用默認設置，那么只會收集注解為 co.elastic.log s/enabled:true的Pods 的日志：

filebeat.autodiscover:providers:- type: kuberneteshints.enabled: "true"hints.default_config.enabled: "false"

可以用適合自己需求、有用的信息注釋Kubernetes Pods，以啟動Filebeat 輸入或 module：

annotations:co.elastic.logs/multiline.pattern: '^\['co.elastic.logs/multiline.negate: "true"co.elastic.logs/multiline.match: after

多容器Pod
當一個pod有多個容器時，除非在提示中輸入容器名稱，否則設置是共享的。例如，這些提示為pod中的所有容器配置多行設置，但為名為 sidecar 的容器設置特定的 exclude_lines hint。

annotations:co.elastic.logs/multiline.pattern: '^\['co.elastic.logs/multiline.negate: "true"co.elastic.logs/multiline.match: afterco.elastic.logs.sidecar/exclude_lines: '^DBG'

多組 hints
當容器需要在其上定義多個 input 時，可以為 annotations 集提供數字前綴。如果有沒有數字前綴的提示，那么它們會被分組到一個配置中。

annotations:co.elastic.logs/exclude_lines: '^DBG'co.elastic.logs/1.include_lines: '^DBG'co.elastic.logs/1.processors.dissect.tokenizer: "%{key2} %{key1}"

上述配置將生成兩個 input 配置。第一個 input 只處理調試日志，并將其傳遞給一個 dissect.tokenizer。第二個 input 處理除調試日志以外的所有內容。

可以在命名空間的注釋上配置 hints，當 Pod 級別的注解缺失時，可以在 Namespace 的注解上配置 hints 作為默認值。生成的提示是 Pod 注解和 Namespace 注解的組合，其中 Pod 的優先級更高。要啟用 Namespace 默認值，請按照以下方式為 Namespace 對象配置 add_resource_metadata。

filebeat.autodiscover:providers:- type: kuberneteshints.enabled: trueadd_resource_metadata:namespace:include_annotations: ["nsannotation1"]

1.2.4. Appenders

Appenders允許用戶在模板或構建器的幫助下附加已經構建的配置。可以將追加程序配置為僅在匹配所需條件時應用。所應用的配置類型特定于每個附加程序。

配置附加器可以在模板或構建器生成的配置之上應用配置。只要提供的條件匹配，就會應用配置。如果沒有提供任何條件，它總是適用的。

filebeat.autodiscover:providers:- type: kubernetestemplates:...appenders:- type: configcondition.equals:kubernetes.namespace: "prometheus"config:fields:type: monitoring

1.2.5. 處理混雜格式日志

從運行在Kubernetes上的工作負載收集日志時，這些應用程序以json格式進行日志記錄是很常見的情況。在這種情況下，可以應用特殊處理，以便正確解析這些json日志并將其解碼為字段。Bellow提供了兩種不同的方式來配置filebeat的自動發現，以便識別和解析json日志。我們將使用一個帶有兩個容器的Pod的示例，其中只有一個日志是json格式的。

示例日志：

{"type":"log","@timestamp":"2020-11-16T14:30:13+00:00","tags":["warning","plugins","licensing"],"pid":7,"message":"License information could not be obtained from Elasticsearch due to Error: No Living connections error"}

1. 將 json.* 選項與模板一起使用

filebeat.autodiscover:providers:- type: kubernetesnode: ${NODE_NAME}templates:- condition: # 條件contains: # 包含kubernetes.container.name: "no-json-logging"config:- type: containerpaths:- "/var/log/containers/*-${data.kubernetes.container.id}.log"- condition:contains:kubernetes.container.name: "json-logging"config:- type: containerpaths:- "/var/log/containers/*-${data.kubernetes.container.id}.log"json.keys_under_root: truejson.add_error_key: truejson.message_key: message

2. 使用帶有 hints 的 json.* 選項

這里的關鍵部分是正確地注釋Pod，以僅將正確容器的日志解析為json日志。在這種情況下，注釋(annotation )應該這樣構造：

co.elastic.logs.<container_name>/json.keys_under_root: "true"

Autodiscovery configuration:

filebeat.autodiscover:providers:- type: kubernetesnode: ${NODE_NAME}hints.enabled: truehints.default_config:type: containerpaths:- /var/log/containers/*${data.kubernetes.container.id}.log

然后對 Pod 進行注釋

annotations:co.elastic.logs.json-logging/json.keys_under_root: "true"co.elastic.logs.json-logging/json.add_error_key: "true"co.elastic.logs.json-logging/json.message_key: "message"

2. processors 處理器

2.1. 定義處理器

在將數據發送到配置的輸出之前，可以使用處理器對數據進行過濾和增強。要定義處理器，請指定處理器名稱、可選條件和一組參數：

processors:- <processor_name>:when:<condition><parameters>- <processor_name>:when:<condition><parameters>...

• <processor_name>指定執行某種操作的處理器，例如選擇要刪除的字段或向事件添加元數據。

• ＜condition＞指定一個可選條件。如果條件存在，則僅當條件滿足時此處理器才執行操作。如果未設置任何條件，則此處理器始終執行操作。

• ＜parameters＞是要傳遞給處理器的參數列表，比如指定要添加哪些字段，添加到哪個字段內。

處理更復雜的情況
更復雜的條件處理可以通過使用if-then-else處理器配置來完成。這允許基于單個條件執行多個處理器。

processors:- if:<condition>then: - <processor_name>:<parameters>- <processor_name>:<parameters>...else: - <processor_name>:<parameters>- <processor_name>:<parameters>...

• then
  必須包含單個處理器或一個或多個處理器的列表，以便在條件計算為true時執行。

• else
  是可選的。當條件求值為false時，它可以包含要執行的單個處理器或處理器列表。

處理器工作方式
每個處理器都接收一個事件，對該事件應用已定義的操作，然后返回該事件。如果定義處理器列表，則將按照在Filebeat配置文件中定義的順序執行它們。

處理器在哪里配置有效
在配置的頂層。處理器應用于Filebeat收集的所有數據。

filebeat.autodiscover:
...
filebeat.inputs:
...
output.elasticsearch:...
# 處理器，讓數據更豐富
processors:- add_host_metadata:when.not.contains.tags: forwarded...

在特定輸入下。處理器應用于為該輸入收集的數據。

- type: <input_type>processors:- <processor_name>:when:<condition><parameters>
...

同樣，對于Filebeat modules，您可以在模塊定義的 input 部分定義處理器。

處理器優先級 特別重要******
這里說的優先級，可以理解為那個處理器最先使用，也就是說數據先進入哪個處理器被處理，優先級主要是對配置在某個輸入模塊配置的處理器和配置在頂層的處理器來說的。

日志數據 > 輸入模塊處理器列表 > 頂層處理器列表

也就是數據是先由每個輸入模塊中的處理器列表處理后，最后再由配置在頂層(全局)的處理器列表處理。

基于上面優先級規則，再處理器中使用 when 時指定的字段就要慎重。避免使用沒有處理器添加的字段。
例如，在全局頂層處理器中可以使用 輸入模塊中處理器添加到事件的字段。而在輸入模塊中的處理器無法使用全局處理器添加的字段。

正確示例：

filebeat.inputs:
- type: filestreamid: kubernetes-container-logspaths:- /var/lib/docker/containers/*/*.logprocessors:- add_kubernetes_metadata:processors:- drop_event:when.not.regexp:kubernetes.namespace: '^spms.*'

在上面的正確示例中的全局處理器 drop_event 中使用了字段 kubernetes.namespace ，這個字段是由輸入模塊 filestream中的處理器 add_kubernetes_metadata 生成。

當然在 output.xxx 中也可以使用已經存在的資源，因為這里是最后的出口，所有處理器處理后的數據才會到這里。
例如如下示例中使用的字段 kubernetes.namespace 由處理器 add_kubernetes_metadata 添加到事件中:

output.elasticsearch:hosts: ['${ELASTICSEARCH_HOST:elastic.efk.svc}:${ELASTICSEARCH_PORT:9200}']indices:- index: "%{[kubernetes.namespace]}-%{[agent.version]}-%{+yyyy.MM.dd}"when.regexp:kubernetes.namespace: '^spms.*'

下面是我在學習中遇到的經典錯誤示例。
場景是這樣的，在 kubernetes 集群中運行了很多 Pod，但是我希望之針對某幾個名稱空間的 Pod, 使用處理器 add_kubernetes_metadata。而其他名稱空間的日志事件都刪除，不傳輸給 Elasticsearch。
錯誤配置:
configmap 的 yaml ，實驗的名稱空間是 shark-test

apiVersion: v1
kind: ConfigMap
metadata:name: filebeat-confignamespace: kube-systemlabels:k8s-app: filebeat
data:filebeat.yml: |-filebeat.inputs:- type: filestream...processors:- drop_event:when.not.regexp:kubernetes.namespace: '^shark.*'- add_kubernetes_metadata:

運行的結果是沒有任何日志事件輸出，都被刪除了。主要原因有兩個：

1. 雖然處理器被配置在頂層，但是輸入模塊中并沒有處理器 add_kubernetes_metadata, 因此全局處理器列表中的第一個處理器 drop_event 使用的字段并不存在。
2. 當使用 not 這樣的操作符的時候，條件匹配和給的的字段不存在都被視為最終條件滿足，為 true 。因此，處理器 drop_event 被執行了，所有的日志事件被刪除。

正確配置為調整全局處理器的兩個處理器的位置：

    processors:- add_kubernetes_metadata:- drop_event:when.not.regexp:kubernetes.namespace: '^shark.*'

或者把處理器 add_kubernetes_metadata 配置在輸入模塊中，處理器 drop_event 配置在全局中。

apiVersion: v1
kind: ConfigMap
metadata:name: filebeat-confignamespace: kube-systemlabels:k8s-app: filebeat
data:filebeat.yml: |-filebeat.inputs:- type: filestreamprocessors:- add_kubernetes_metadata:...processors:- drop_event:when.not.regexp:kubernetes.namespace: '^shark.*'

或者都放在輸入模塊中，但是注意順序：

    - type: filestreamprocessors:- add_kubernetes_metadata:- drop_event:when.not:or:- contains:kubernetes.namespace: 'spms-cloud'- contains:kubernetes.namespace: 'spms-standard'

上面的配置表示名稱空間不含有 spms-cloud 或者不含有 spms-standard 的事件刪除。

又或者使用正則表達式：

    - type: filestreamprocessors:- add_kubernetes_metadata:- drop_event:when.not:regexp:kubernetes.namespace: '^spms-cloud|^spms-standard'

2.2. 常用處理器

• drop_event
• drop_fields
• add_docker_metadata
• add_host_metadata
• add_kubernetes_metadata

官方完整的處理器列表:點我查看目前支持的所以處理器列表

2.2.1. 去除日志中的某些行

配置位置在 filebeat.yml 文件中。

考慮這樣的場景：
在一個服務器上，使用 docker 運行了應用的 Pod 的容器 ，也運行了 docker-compose 管理的 容器，并且 Pod 有的是應用程序（需要收集的日志），有的Pod是監控系統、日志收集系統等（不要求收集日志）。

從這么多的容器中要過濾出只要求收集的日志，就可以使用處理器 drop_event，再配合 when 條件判斷過濾。

刪除所有以 DBG: 開頭的行

processors:- drop_event:when.regexp:message: "^DBG:"

2.2.2. 向輸出的數據中添加某些自定義字段

add_fields 處理器將額外的字段添加到事件中。字段可以是標量值、數組、字典，也可以是它們的任何嵌套組合。add_fields 處理器將覆蓋目標字段（如果它已經存在）。
默認情況下，您指定的字段將分組在事件中的 fields 子字典下。要將字段分組到不同的子詞典下，請使用 target 設置。若要將字段存儲為頂級字段，請設置目 target: ''。

processors:- add_fields:target: projectfields:name: myprojectid: '574734885120952459'

• 將自定義字段添加到此目標字段內，這個字段會被自定創建。
• 將要添加的字段和值

輸出效果如下圖所示：

2.2.3. 從事件中刪除某些字段

processors:- drop_fields:when:conditionfields: ["field1", "field2", ...]ignore_missing: false

condition 是一個條件，當條件滿足時，才會刪除定義的字段。這個是可選的，不設置條件，則會都刪除。

以上配置，將刪除字段: field1 和 field2

ignore_missing 的值為 false 表示，字段名不存在則會返回錯誤。為 true 不會返回錯誤。

?? 注意： 事件中的 "@timestamp 和 type 字段是無法刪除的。

下面的配置示例是刪除頂級字段 input 和 頂級字段 ecs 中的 version 字段。

  - drop_fields:fields: ['input', "ecs.version"]

刪除之前??

{..."input": {"type": "log"},..."ecs": {"version": "1.5.0"},...
}

刪除之后??

{..."ecs": {},...
}

2.2.4. add_kubernetes_metadata 詳解

add_kubernetes_metadata 處理器根據事件源自哪個kubernetes pod，用相關元數據對每個事件添加kubernetes 集群的相關字段信息。
在啟動時，它檢測一個 in_cluster 環境并緩存與Kubernetes相關的元數據。只有在檢測到有效配置時，才會對事件添加kubernetes的字段信息。如果無法檢測到有效的Kubernetes配置，則不會使用與Kubernete相關的元數據對事件添加kubernetes字段信息。

在 Filebeat 中，add_kubernetes_metadata 處理器在啟動時會檢測是否運行在 Kubernetes 集群中，并緩存與 Kubernetes 相關的元數據。這意味著當 Filebeat 啟動時，它會嘗試自動檢測當前是否在 Kubernetes 集群內部運行，并且會獲取與該集群相關的信息，例如集群名稱、命名空間、標簽等。

這種自動檢測和緩存的行為使得 add_kubernetes_metadata 處理器能夠在啟動后快速訪問 Kubernetes 相關的元數據，而不必每次處理事件時都重新獲取這些信息。這有助于提高性能并減少對 Kubernetes API 服務器的頻繁訪問。

add_kubernetes_metadata 處理器是專門為在 Kubernetes 集群中運行的 Filebeat 實例設計的，用于從 Kubernetes API 服務器中獲取與事件相關的元數據。因此，如果 Filebeat 不在 Kubernetes 集群中運行，通常情況下是無法直接使用 add_kubernetes_metadata 處理器的。

每個事件都注釋有：

• Pod Name
• Pod UID
• Namespace
• Labels
  也就是，對 Kubernetes 的每個日志事件，處理日志數據的時候，都會在處理后的日志數據中添加上面列出的信息。

此外，節點和命名空間元數據被添加到 pod 元數據中。

add_kubernetes_metadata處理器有兩個基本構建塊：

• Indexers
• Matchers

索引器（Indexers）使用pod元數據為每個pod創建唯一的標識符。這些標識符有助于將觀察到的pod的元數據與實際事件相關聯。例如，ip_port 索引器可以獲取一個 Kubernetes pod，并根據其所有 pod_ip:container_port 的組合，為其創建標識符。

匹配器（Matchers）使用事件中的信息，來構造與索引器創建的標識符匹配的查找鍵。例如，當字段匹配器將["metricset.host"]作為查找字段時，它將使用字段 metricset_host 的值構造查找關鍵字。當這些查找鍵中的一個與其中一個標識符匹配時，事件會豐富已標識的pod的元數據。

當 add_kubernetes_medata 與 Filebeat 一起使用時，它使用容器索引器和 logs_path。因此，在 log.file.path 中路徑包含對容器ID的引用的事件會被該容器的pod的元數據豐富。

可以通過禁用配置中的默認索引器和匹配器來禁用此行為：

processors:- add_kubernetes_metadata:default_indexers.enabled: falsedefault_matchers.enabled: false

當filebeat在Kubernetes中作為pod運行時，下面的配置將啟用處理器。

processors:- add_kubernetes_metadata:#labels.dedot: true#annotations.dedot: true

add_kubernetes_metadata 處理器具有以下配置設置：
namespace
（可選）選擇要從中收集元數據的命名空間。如果未設置，處理器將從所有命名空間收集元數據。默認情況下未設置。只能指定一個名稱空間，建議在處理器中使用 when 條件處理。

kube_config
（可選）使用給定的配置文件作為Kubernetes客戶端的配置。它默認為KUBECONFIG環境變量（如果存在）。

使用此選項，有幾個條件：

• 刪除了關于 Filebeat daemonset對象使用的 rbac 相關資源對象。刪除 Filebeat 關于 daemonset 對象yaml文件中 serviceAccountName: filebeat 的配置。
• kube_config 指定的配置文件路徑是真的 Filebeat Pod 內的路徑，因此需要把配置文件映射到 Filebeat Pod 中。
  這需要再 daemonset 對象的 yaml 文件中添加如下配置：

        volumeMounts:- name: kubeconfigmountPath: /root/.kube/configreadOnly: truevolumes:- name: kubeconfighostPath:path: /root/.kube/config

此示例我使用了默認的 kubernetes admin 的認證文件，實際生產中你應該自己創建一個有合適權限的認證文件。

• 最后在 configmap 的yaml 文件中設置。

      processors:- add_kubernetes_metadata:kube_config: /root/.kube/config

add_resource_metadata
（可選）為將要添加到事件中的額外元數據，指定篩選器和配置，以便優化這些元數據，比如保留哪些，刪除哪些。
配置參數：

• node or namespace: 為來自 node 和 namespace 的額外元數據指定 labels 和 annotaions 過濾器。默認情況下，包括所有標簽，而不包括注釋。要更改默認行為，可以定義 include_labels ,exclude_labels 和 include_annotations。當存儲需要特殊處理以避免存儲輸出過載的標簽和注釋時，這些設置非常有用。注意：這些設置不支持通配符。通過設置 enabled: false，可以單獨禁用 node 或 namespace 元數據的豐富。
• deployment: 如果資源是pod，并且是從 deployment 創建的，那么默認情況下會添加 deployment 名稱，可以通過設置 deployment: false來禁用此功能。
• cronjob: 如果資源是 Pod，并且是從 cronjob 創建的，那么默認情況下會添加 cronjob 名稱，可以通過設置 cronjob: false 來禁用此功能。

示例:

      add_resource_metadata:namespace:include_labels: ["namespacelabel1"]#labels.dedot: true#annotations.dedot: truenode:include_labels: ["nodelabel2"]include_annotations: ["nodeannotation1"]#labels.dedot: true#annotations.dedot: truedeployment: falsecronjob: false

default_indexers.enabled
（可選）當您想要指定自己的pod索引器時，啟用或禁用默認pod索引器。

default_matchers.enabled
（可選）當您想要指定自己的pod匹配器時，啟用或禁用默認pod匹配器。

labels.dedot
（可選）默認為 true。如果設置為 true，那么 labels 中的 . 將替換為 _。

annotations.dedot
(可選）默認為 true。如果設置為 true，那么 annotations 中的 . 將替換為 _。

2.2.4.1. Indexers 索引器

索引器使用pod元數據為每個pod創建唯一的標識符。
可用的索引器：

• container
  使用容器的ID標識 Pod 元數據。

• ip_port
  Identifies the pod metadata using combinations of its IP and its exposed ports.
  使用 IP 和 公開的 ports 的結合標識 Pod 元數據。
  When using this indexer metadata is identified using the IP of the pods, and the combination if ip:port for each one of the ports exposed by its containers.
  使用此索引器時，元數據是使用pod的IP以及容器暴露的每個端口的組合來標識的 ip:port。

• pod_name
  Identifies the pod metadata using its namespace and its name as namespace/pod_name.
  使用它的命名空間和名稱(namespace/pod_name)標識 Pod 元數據。

• pod_uid
  Identifies the pod metadata using the UID of the pod.
  使用 Pod 的 UID 表示 Pod 元數據。

2.2.4.2. Matchers

匹配器用于構造查找鍵，這個會與索引創建的標識符進行匹配。
matcher 插件用于定義條件，以決定是否對指定的日志進行處理。

field_format
使用字符串格式創建的鍵，查找pod元數據，該字符串格式可以包括事件字段。

這個匹配器有一個選項格式來定義字符串格式。此字符串格式可以包含事件中任何字段的占位符。

例如，以下配置使用 ip_port 索引器通過 Pod IP 及其公開端口的組合來識別 Pod 元數據，并使用事件中的目標 IP 和端口作為匹配密鑰：

processors:
- add_kubernetes_metadata:...default_indexers.enabled: falsedefault_matchers.enabled: falseindexers:- ip_port:matchers:- field_format:format: '%{[destination.ip]}:%{[destination.port]}'

fields
使用某些特定字段的值作為關鍵字來查找pod元數據。定義多個字段時，將使用事件中包含的第一個字段。

此匹配器具有一個選項 lookup_fields，用于定義其值將用于查找。

例如，以下配置使用 ip_port 索引器來識別 Pod，并定義一個匹配器，該匹配器使用目標 IP 或服務器 IP 進行查找，這是它在事件中找到的第一個匹配器：

processors:
- add_kubernetes_metadata:...default_indexers.enabled: falsedefault_matchers.enabled: falseindexers:- ip_port:matchers:- fields:lookup_fields: ['destination.ip', 'server.ip']

logs_path
使用從 log.file.path 字段中存儲的日志路徑中提取的標識符查找pod元數據。

此匹配器具有以下配置設置：

• logs_path
  （可選）容器日志的基本路徑。如果未指定，則使用運行Filebeat的平臺的默認日志路徑：
  Linux：/var/lib/docker/containers/
  Windows: C:\\ProgramData\\Docker\\containers
• resource_type
  有效的資源類型：
  • pod: 以基于pod UID進行查找。當 resource_type 設置為 pod 時，還必須設置 logs_path，在這種情況下支持路徑：
    • /var/lib/kubelet/pods/ 用于讀取掛載到 pod 卷中的日志，這些日志最終位于 /var/lib/kubelet/pods/<pod UID>/volumes/<volume-name>/..下。要使用 /var/lib/kubelet/pods/ 作為log_path，必須將 /var/lib/kobelet/pods filebeat pods。
    • /var/log/pods/ 注意：當使用 resource_type: 'pod' 時，Pod 元數據將只使用Pod 元數據: pod id,namespace 填充。
  • container: 要根據容器ID進行查找，必須將 logs_path 設置為 /var/log/containers/。它默認為 container。

要能夠使用 logs_path 匹配器 filebeat，輸入路徑必須是 logs_path 配置設置中定義的目錄的子目錄。

當從默認的docker日志路徑（Linux上的 /var/lib/docker/containers/<containerID>/…）收集日志時，默認配置能夠使用容器ID查找元數據。

例如，當從 var/lib/kubelet/pods/<pod UID>/... 收集日志時，以下配置將使用pod UID

processors:
- add_kubernetes_metadata:...default_indexers.enabled: falsedefault_matchers.enabled: falseindexers:- pod_uid:matchers:- logs_path:logs_path: '/var/lib/kubelet/pods'resource_type: 'pod'

2.3. Condition 條件

每個條件都接收日志事件中的一個字段進行比較。通過在字段之間使用AND，可以在相同條件下指定多個字段（例如，field1 AND field2）。

對于每個字段，可以指定一個簡單的字段名或字段的嵌套映射，例如host.name。

不同的處理器導出不同的字段，每個處理器導出的字段可以參考官方文檔

支持的條件：

• equals
• contains
• regexp
• range
• network
• has_fields
• or
• and
• not

equals 等于
使用等于條件，可以比較字段是否具有某個值。該條件只接受一個整數或字符串值。

例如，以下條件檢查HTTP事務的響應代碼是否為200：

equals:http.response.code: 200

contains 包含
包含條件，檢查給定字段實際值的是否包含配置的值。字段可以是字符串或字符串數組。該條件只接受字符串值。

例如，以下條件檢查名稱空間中是否含有 shark-test 對應值的一部分：

contains:kubernetes.namespace: "shark-test"

regexp 正則表達式
正則表達式條件根據正則表達式檢查字段。該條件只接受字符串。

例如，以下條件檢查進程名稱是否以foo開頭：

regexp:system.process.name: "^foo.*"

has_fields

has_fields 條件檢查事件中是否存在所有給定字段。該條件接受表示字段名稱的字符串值列表。

例如，以下條件檢查事件中是否存在 http.response.code字段。

has_fields: ['http.response.code']

or
接收一個條件列表，滿足列表中任意一個條件即可。

or:- <condition1>- <condition2>- <condition3>...

配置示例：

or:- equals:http.response.code: 304- equals:http.response.code: 404

and
接收一個條件列表，必須同時滿足列表中的所有條件。

and:- <condition1>- <condition2>- <condition3>...

配置示例：

and:- equals:http.response.code: 200- equals:status: OK

or 和 and 還可以嵌套使用：

or:- <condition1>- and:- <condition2>- <condition3>

not
not運算符接收到要求反的條件。

not:<condition>

配置示例：

not:equals:status: OK

特別注意：
在使用 not 條件運算符時候，除了條達匹配視為最終條件達成，給定用于判斷的字段不存在也視為最終添加達成。

例如下面的配置效果是一樣的：

        when.not.contains:host.name: 'k8s-node1'when.not.contains:# 錯誤字段host.namespa: 'k8s-node1'

其他添加的 not 也是一樣的：

        when.not.regexp:host.name: '^k8s.*'when.not.regexp:# 錯誤字段host.namespace: '^k8s.*'

3. 配置索引生命周期管理

使用Elasticsearch中的索引生命周期管理（ILM）功能來管理您的Filebeat，它們在數據流老化時作為數據流的備份索引。Filebeat自動加載默認策略，并將其應用于Filebeat創建的任何數據流。

您可以在Kibana的索引生命周期策略UI中查看和編輯策略。有關使用UI的更多信息，請參閱索引生命周期策略。
配置示例:

setup.ilm.enabled: true

如果啟用了索引生命周期管理（這通常是默認設置），則會忽略setup.template.name 和 setup.template.pattern。

3.1. 配置選項

可以在 filebeat.yml 配置文件的 setup.ilm 部分指定以下設置：

setup.ilm.enabled
對Filebeat創建的任何新索引啟用或禁用索引生命周期管理。有效值為 true 和false。

setup.ilm.policy_name
用于生命周期策略的名稱。默認值為 filebeat。

setup.ilm.policy_file
JSON文件的路徑，該文件包含生命周期策略配置。使用此設置可以加載您自己的生命周期策略。
有關生命周期策略的更多信息，請參閱Elasticsearch參考中的設置索引生命周期管理策略。

setup.ilm.check_exists
如果設置為 false，則禁用對現有生命周期策略的檢查。默認值為 true。如果連接到安全群集的Filebeat用戶沒有 read_ilm 權限，則需要禁用此檢查。

如果將此選項設置為 false，則即使 setup.ilm.overwrite 設置為 true，也不會安裝生命周期策略。

setup.ilm.overwrite
當設置為 true 時，生命周期策略將在啟動時被覆蓋。默認值為 false。

4. 配置Elasticsearch索引模板加載

filebeat.yml 配置文件的 setup.template 部分指定用于在Elasticsearch中設置映射的索引模板。如果啟用了模板加載（默認），Filebeat會在成功連接到Elasticsearch后自動加載索引模板。

加載索引模板需要連接到Elasticsearch。如果配置的輸出不是Elasticsearch（或Elasticsearch服務），則必須手動加載模板。

您可以調整以下設置以加載自己的模板或覆蓋現有模板。

setup.template.enabled
設置為false可禁用模板加載。如果設置為 false，則必須手動加載模板。

setup.template.name
模版的名字，默認是 filebeat。 Filebeat 版本總會追加到給定的名字后，因此最終的名字是 filebeat-%{[agent.version]}。

setup.template.pattern
要應用于默認索引設置的模板模式。默認模式為 filebeat。Filebeat版本總是包含在模式中，因此最終的模式是 Filebeat-%{[agent.version]}。
示例：

setup.template.name: "filebeat"
setup.template.pattern: "filebeat"

setup.template.pattern 允許您定義一個模式，該模式將用于匹配將應用模板的索引名稱。例如，如果您將 setup.template.pattern 設置為 "myindex-*"，那么 Filebeat 將嘗試將模板應用于所有以 "myindex-" 開頭的索引。

這個選項的作用在于，它允許您根據特定的索引名稱模式來自動應用索引模板，從而確保新創建的索引能夠按照您的要求進行配置。

總而言之，setup.template.pattern 允許您定義一個模式，以便 Filebeat 可以自動將索引模板應用于匹配該模式的索引。

setup.template.overwrite
一個布爾值，用于指定是否覆蓋現有模板。默認值為 false。如果同時啟動多個Filebeat實例，請不要啟用此選項。發送過多的模板更新請求可能會使Elasticsearch過載。

setup.template.settings
通過 setup.template.settings，您可以指定要應用于索引模板的設置，例如分片和副本的數量、索引的分片設置、索引的刷新間隔等。這些設置可以確保新創建的索引與您的要求一致，并且具有適當的性能和配置。

以下是一個示例設置 setup.template.settings 的配置：

setup.template.settings:index.number_of_shards: 3index.number_of_replicas: 2

一個完整的示例

setup.template.enabled: true
setup.template.overwrite: false
setup.template.name: "spms"
setup.template.pattern: "spms*"
setup.template.settings:index.number_of_shards: 3index.number_of_replicas: 2

5. parsers 解析器

此選項需要一個日志行必須經過的解析器列表。

可以使用的解析器：

• multiline
• ndjson
• container
• syslog

multiline
控制Filebeat如何處理跨越多行的日志消息的選項。

ndjson
這些選項使Filebeat能夠解碼構造為JSON消息的日志。Filebeat逐行處理日志，因此只有當每條消息有一個JSON對象時，JSON解碼才有效。

解碼發生在行過濾之前。如果設置message_key選項，可以將JSON解碼與過濾相結合。這在應用程序日志被封裝在JSON對象中的情況下很有幫助，比如在使用Docker時。

配置示例：

- ndjson:target: ""add_error_key: truemessage_key: log

• target 新JSON對象的名稱，該對象應包含已解析的鍵值對。如果將其留空，則新 key 將進入頂級之下。
• add_error_key 如果啟用此設置，Filebeat會在json解組錯誤或配置中定義了 message_key 但無法使用時添加 "error.message" 和"error.type:json" key。
• message_key 一個可選的配置設置，用于指定要應用行篩選和多行設置的JSON鍵。如果指定了該鍵，則該鍵必須位于JSON對象的頂級，并且與該鍵關聯的值必須是字符串，否則將不會發生篩選或多行聚合。

container
使用 container 解析器從容器日志文件中提取信息。它將行解析為通用消息行，并提取時間戳。

6. 勘探者 prospector

探礦者正在運行一個文件系統觀察器，該觀察器查找路徑選項中指定的文件。目前只支持簡單的文件系統掃描。

6.1. scanner 掃描器

掃描儀監視配置的路徑。它會定期掃描文件系統，并將文件系統事件返回到“瀏覽”。

6.1.1. symlinks 軟鏈接

符號鏈接選項允許Filebeat除了獲取常規文件外，還可以獲取符號鏈接。在獲取符號鏈接時，Filebeat會打開并讀取原始文件，即使它報告了符號鏈接的路徑。

當您為獲取配置符號鏈接時，請確保排除原始路徑。如果將單個輸入配置為同時獲取符號鏈接和原始文件，Filebeat將檢測到問題并只處理它找到的第一個文件。但是，如果配置了兩個不同的輸入（一個讀取符號鏈接，另一個讀取原始路徑），則會獲取兩個路徑，導致Filebeat發送重復數據，并且輸入會覆蓋彼此的狀態。

如果指向日志文件的符號鏈接在文件名中有其他元數據，并且您希望在Logstash中處理元數據，則符號鏈接選項可能很有用。例如，Kubernetes日志文件就是這樣。

由于此選項可能會導致數據丟失，因此默認情況下會禁用此選項。
配置示例：

      prospector:scanner:symlinks: true

6.1…2. fingerprint 指紋

fingerprint 可以讓 Filebeat 根據文件的內容字節范圍來識別文件。

在比較文件時，不依賴設備ID和inode值（Filebeat默認行為），而是比較文件的給定字節范圍的哈希值。

如果由于文件系統提供的文件標識符不穩定而導致數據丟失或數據重復，請啟用此選項。

以下是可能發生這種情況的一些場景：

1. 一些文件系統（即Docker中）緩存和重用inode
   例如，如果你：
   a. Create a file (touch x)
   b. Check the file’s inode (ls -i x)
   c. Delete the file (rm x)
   d. 立即創建新文件(touch y)
   e. 檢查新文件的索引節點(ls -i y)
   對于這兩個文件，您可能會看到相同的 inode 值，盡管文件名不同。

2. 非Ext文件系統可以更改 inodes：
   Ext文件系統將索引節點號存儲在i_ino文件中，該文件位于結構索引節點內，并寫入磁盤。在這種情況下，如果文件是相同的（而不是另一個具有相同名稱的文件），則inode編號保證是相同的。
   如果文件系統不是Ext，則inode編號由文件系統驅動程序定義的inode操作生成。由于他們不知道inode是什么，所以他們必須模仿inode的所有內部字段以符合VFS，因此在重新啟動后，甚至在再次關閉和打開文件后（理論上），這個數字可能會有所不同。

3. 一些文件處理工具更改inode值。
   有時用戶會使用rsync或sed等工具無意中更改inode。

4. 某些操作系統在重新啟動后更改設備ID
   根據裝載方法的不同，設備ID（也用于比較文件）可能會在重新啟動后更改。

啟用指紋模式會延遲接收新文件，直到它們的大小至少增加到偏移量+長度字節，以便對其進行指紋打印。在此之前，這些文件將被忽略。

通常，日志行包含時間戳和其他應該能夠使用指紋模式的唯一字段，但在每個用例中，用戶都應該檢查日志，以確定 offset 和 length 參數的適當值。默認偏移量為0，默認長度為1024或1 KB。長度不能小于64。

默認 Fingerprint 方法是禁用的，如下所示。

fingerprint:enabled: falseoffset: 0length: 1024

在 docker 的 容器環境中，應該配置開啟。

      prospector:scanner:fingerprint.enabled: true

7. file_identity 文件標識

可以配置不同的 file_identity 方法，以適應收集日志消息的環境。

7.1. fingerprint

根據文件的內容字節范圍來識別文件。
低版本有可能不支持，此文檔用的是 8.14.1。

為了使用此文件標識選項，您必須在掃描儀中啟用指紋選項。

     prospector:scanner:fingerprint.enabled: true

啟用此文件標識后，更改指紋配置（offset, length 或其他設置）將導致全局重新接收與輸入的路徑配置匹配的所有文件。

file_identity.fingerprint: ~