昨天我們講解了index的一些module,讓大家對index有多幾層的認識,並且大概知道如何去調整index的一些設定,像是sorting、或是reindex等等。今天我們要來講解一個有趣的東西-Ingest,大家還記得在前幾天的時候,我們有介紹過node角色,其中一個節點角色的名稱就是Ingest。
而負責Ingest節點,當初我們有提到它的功用是Run Pipeline,而究竟什麼是PipeLine,到底要怎麼使用?
Ingest Pipeline其實就是當你在加入documents時,他所經歷的一套流程,而document經過這一連串處理後,最後就會被加入你的index中。
我們一樣來看一下官網原文介紹:
**Use an ingest node to pre-process documents before the actual document indexing happens. The ingest node intercepts bulk and index requests, it applies transformations, and it then passes the documents back to the index or bulk APIs.
All nodes enable ingest by default, so any node can handle ingest tasks. You can also create dedicated ingest nodes.
這邊前面就是在講述我們上面的描述,適用於bulk(批次上傳)以及一般的indexing documents動作;另外它有提到的是,一般你的ELK上的node,預設都能夠扮演ingest這個角色,也就是當今天上傳我們指定要執行某個pipeline,基本上每個node都能夠協助這些tasks
接著我們來實際上去設計看看pipeline,它會在document被index前先執行,因此我們作一些小測試。
PUT _ingest/pipeline/my_pipeline_id
{
"description" : "describe pipeline",
"processors" : [
{
"set" : {
"field": "foo",
"value": "new"
}
}
]
}
首先我們加入一個my_pipeline_id,它的processors就是定義它的流程,我們加入設定一個field foo,值為new,因此其實可以想像,以後每一個document run過這pipeline,都會被設定一個foo的值- new
PUT demo-index/_doc/my-id?pipeline=my_pipeline_id
{
"foo": "bar"
}
接著我們在demo-index中放入一個documment foo:bar
然後後面記得指定pipeline是剛剛設定的my_pipeline_id
{
"_index": "demo-index",
"_type": "_doc",
"_id": "my-id",
"_score": 1.0,
"_source": {
"foo": "new",
"description": "describe pipeline",
"processors": [
{
"set": {
"field": "foo",
"value": "new"
}
}
]
}
}
可以看到回傳的foo值是new,可以看到在pipeline過程中,把foo的值設定成new,另外他也會給予這個pipeline的processors明細,因此你可以知道這過程中他被動過什麼手腳。
關於具體上set的設定方式,也可以參考 Pipeline SET
大家可以看到,你在設定processors執行動作時,可以給予條件限制,例如drop的條件,或是set的條件,如此一來可以有更多的彈性
PUT _ingest/pipeline/drop_guests_network
{
"processors": [
{
"drop": {
"if": "ctx.network_name == 'Guest'"
}
}
]
}