Field type conflict


(Stecino) #1

In my filter I am converting field values for response and response_time from string to integer and float respectively.

In my mapping template I have the following snippet:

   "mappings": {
        "_default_": {
            "dynamic_templates": [
               {
                    "string": {
                        "mapping": {
                            "index": "not_analyzed",
                            "type": "number"
                        },
                        "match": "response*"
                    }
                }
            ]
        }
    }

when I get the mapping for my index I get:

curl -XGET localhost:9200/blah/_mapping?pretty
{
"blah" : {
"mappings" : {
"default" : {
"dynamic_templates" : [ {
"string" : {
"mapping" : {
"index" : "not_analyzed",
"type" : "string"
},
"match" : "cookie"
}
}, {
"string" : {
"mapping" : {
"index" : "not_analyzed",
"type" : "string"
},
"match" : "httpversion"
}
}, {
"string" : {
"mapping" : {
"index" : "not_analyzed",
"type" : "number"
},
"match" : "response*"
}
}, {
"string" : {
"mapping" : {
"index" : "not_analyzed",
"type" : "string"
},
"match" : "remote_addr"
}
} ]
},
"nginx" : {
"dynamic_templates" : [
}, {
** "string" : {**
** "mapping" : {**
** "index" : "not_analyzed",**
** "type" : "number"**
** },**
** "match" : "response*"**
** }**
** },** {
"string" : {
"mapping" : {
"index" : "not_analyzed",
"type" : "string"
},
"match" : "remote_addr"
}
} ],
"properties" : {
"@timestamp" : {
"type" : "date",
"format" : "strict_date_optional_time||epoch_millis"
},
"@version" : {
"type" : "string"
},
"agent" : {
"type" : "string"
},
"bytes" : {
"type" : "string"
},
"cookie" : {
"type" : "string"
},
"http_x_forwarded_for" : {
"type" : "string",
"index" : "not_analyzed"
},
"http_x_forwarded_for1" : {
"type" : "string"
},
"http_x_forwarded_for2" : {
"type" : "string"
},
"httpversion" : {
"type" : "string"
},
"input_type" : {
"type" : "string"
},
"kafka" : {
"properties" : {
"consumer_group" : {
"type" : "string"
},
"msg_size" : {
"type" : "long"
},
"partition" : {
"type" : "long"
},
"topic" : {
"type" : "string"
}
}
},
"nginx_host" : {
"type" : "string",
"index" : "not_analyzed"
},
"offset" : {
"type" : "long"
},
"platform" : {
"type" : "string"
},
"referrer" : {
"type" : "string"
},
"remote_addr" : {
"type" : "string",
"index" : "not_analyzed"
},
"request" : {
"type" : "string"
},
"response" : {
** "type" : "long"**
** },**
** "response_time" : {**
** "type" : "double"**
** },**
"source" : {
"type" : "string",
"index" : "not_analyzed"
},
"tags" : {
"type" : "string"
},
"timestamp" : {
"type" : "string"
},
"type" : {
"type" : "string"
},
"verb" : {
"type" : "string"
}
}
}
}
}
}

Type conflict is this: Mapping conflict! 2 fields are defined as several types
(string, integer, etc) across the indices that match this pattern. You
may still be able to use these conflict fields in parts of Kibana, but
they will be unavailable for functions that require Kibana to know their
type. Correcting this issue will require reindexing your data.

I know that it's conflicting for the older indecies that were created with a different mapping rules. What about newly created index, will it comply to this new conversion, mapping rules?


(Glen Smith) #2

Moving to Kibana


(system) #3