通过 Logstash 更新时,Elastic Document 的@version 不递增
Elastic Document's @version not incrementing when updating via Logstash
我想定期将问题数据从 JIRA 实例加载到我的 Elastic Stack
。我不想每次从 JIRA API 中提取数据时都创建一个新的弹性文档,而是更新现有的文档文档,这意味着每个 JIRA 问题应该只存在一个文档。更新时,我希望 @version
字段在设置 document_id
field of the elasticsearch output plugin
.
时自动递增
当前工作设置
- Elastic Stack:版本 7.4.0 运行 在 Ubuntu 上 Docker 容器
- Logstash 输入阶段:通过
http_poller input plugin
获取JIRA问题数据
- Logstash Filter阶段:使用
split filter plugin
根据需要修改JSON数据
- Logstash 输出阶段:将数据通过管道传输到 Elasticsearch 并使其在 Kibana 中可见
我挣扎的地方
数据在Elastic中正确注册并在Kibana中显示。正如预期的那样,每期有一份文件。然而,文档正在被覆盖,但 @version
保持值 1。我假设使用 action => "update"
、doc_as_upsert => true
和 document_id => "%{[@metadata][id]}"
足以让 Elasticsearch 意识到它需要递增文件的版本。
总的来说,我想知道这是否是使 JIRA 问题数据随着时间的推移可搜索的正确方法。例如,我是否可以在过去 @version
找到一张 JIRA 工单的状态?或者 @version
值只提供文档更新频率的信息,而不提供单个文档版本的值?
logstash.conf(某些数据已删除并替换为 <> 标签)
input {
http_poller {
urls => {
data => {
method => get
url => "https://<myjira>.com/jira/rest/api/2/search?<searchJQL>"
headers => {
Authorization => "Basic <censored>"
Accept => "application/json"
"Content-Type" => "application/json"
}
}
}
request_timeout => 60
schedule => { every => "10s" } # low value for debugging
codec => "json"
}
}
filter {
split {
field => "issues"
add_field => {
"key" => "%{[issues][key]}"
"Summary" => "%{[issues][fields][summary]}"
[@metadata]["id"] => "%{[issues][id]}" # unique ID of a JIRA issue, the JIRA issue key could also be used
}
remove_field => [ "startAt", "total", "maxResults", "expand", "issues"]
}
}
output {
stdout { codec => rubydebug }
elasticsearch {
index => "gsep"
user => ["<usr>"]
password => ["<pw>"]
hosts => ["elasticsearch:9200"]
action => "update"
document_id => "%{[@metadata][id]}"
doc_as_upsert => true
}
}
Kibana 文档数据的屏幕截图
我不得不审查信息,但丢失的信息应该不相关。在屏幕截图上,您可以看到相同的 _id
已正确设置,但 @version
保持为 1。在 Elasticstash/Kibana 中,仅存在相应 issue/_id 的此文档。
@version 字段来自 logstash,它只是 日志消息格式 版本的指示符。没有自增功能等
请注意,在 elasticsearch 文档中还有一个 _version 字段。
_version 是一个自动递增的值,用于 concurrency 场景中的乐观锁定。
需要说明的是,elasticsearch 无法在开箱即用的版本控制方面为您提供您所期望的。您无法访问依赖于 _version 的同一文档的不同版本。在 elasticsearch 中有一些热门的设计模式来实现这样的文档历史记录。但这是一个宽泛的问题,有很多答案,超出了这个问题的范围。
我想定期将问题数据从 JIRA 实例加载到我的 Elastic Stack
。我不想每次从 JIRA API 中提取数据时都创建一个新的弹性文档,而是更新现有的文档文档,这意味着每个 JIRA 问题应该只存在一个文档。更新时,我希望 @version
字段在设置 document_id
field of the elasticsearch output plugin
.
当前工作设置
- Elastic Stack:版本 7.4.0 运行 在 Ubuntu 上 Docker 容器
- Logstash 输入阶段:通过
http_poller input plugin
获取JIRA问题数据
- Logstash Filter阶段:使用
split filter plugin
根据需要修改JSON数据 - Logstash 输出阶段:将数据通过管道传输到 Elasticsearch 并使其在 Kibana 中可见
我挣扎的地方
数据在Elastic中正确注册并在Kibana中显示。正如预期的那样,每期有一份文件。然而,文档正在被覆盖,但 @version
保持值 1。我假设使用 action => "update"
、doc_as_upsert => true
和 document_id => "%{[@metadata][id]}"
足以让 Elasticsearch 意识到它需要递增文件的版本。
总的来说,我想知道这是否是使 JIRA 问题数据随着时间的推移可搜索的正确方法。例如,我是否可以在过去 @version
找到一张 JIRA 工单的状态?或者 @version
值只提供文档更新频率的信息,而不提供单个文档版本的值?
logstash.conf(某些数据已删除并替换为 <> 标签)
input {
http_poller {
urls => {
data => {
method => get
url => "https://<myjira>.com/jira/rest/api/2/search?<searchJQL>"
headers => {
Authorization => "Basic <censored>"
Accept => "application/json"
"Content-Type" => "application/json"
}
}
}
request_timeout => 60
schedule => { every => "10s" } # low value for debugging
codec => "json"
}
}
filter {
split {
field => "issues"
add_field => {
"key" => "%{[issues][key]}"
"Summary" => "%{[issues][fields][summary]}"
[@metadata]["id"] => "%{[issues][id]}" # unique ID of a JIRA issue, the JIRA issue key could also be used
}
remove_field => [ "startAt", "total", "maxResults", "expand", "issues"]
}
}
output {
stdout { codec => rubydebug }
elasticsearch {
index => "gsep"
user => ["<usr>"]
password => ["<pw>"]
hosts => ["elasticsearch:9200"]
action => "update"
document_id => "%{[@metadata][id]}"
doc_as_upsert => true
}
}
Kibana 文档数据的屏幕截图
我不得不审查信息,但丢失的信息应该不相关。在屏幕截图上,您可以看到相同的 _id
已正确设置,但 @version
保持为 1。在 Elasticstash/Kibana 中,仅存在相应 issue/_id 的此文档。
@version 字段来自 logstash,它只是 日志消息格式 版本的指示符。没有自增功能等
请注意,在 elasticsearch 文档中还有一个 _version 字段。 _version 是一个自动递增的值,用于 concurrency 场景中的乐观锁定。
需要说明的是,elasticsearch 无法在开箱即用的版本控制方面为您提供您所期望的。您无法访问依赖于 _version 的同一文档的不同版本。在 elasticsearch 中有一些热门的设计模式来实现这样的文档历史记录。但这是一个宽泛的问题,有很多答案,超出了这个问题的范围。