# Forcing Types in Elasticsearch
**URL:** https://discuss.elastic.co/t/forcing-types-in-elasticsearch/79370
**Category:** Logstash
**Created:** [March 21, 2017, 8:59am UTC](https://discuss.elastic.co/t/forcing-types-in-elasticsearch/79370 "2017-03-21T08:59:52Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@lisadeng](https://discuss.elastic.co/u/lisadeng)
#### Post date: [March 21, 2017, 8:59am UTC](https://discuss.elastic.co/t/forcing-types-in-elasticsearch/79370/1 "2017-03-21T08:59:52Z")
I'm using the http\_poller plugin right now to monitor websites.
I noticed that when I query a website that refuses a connection, it doesn't give me a status code field in the error log.
Right now I'm trying to visualize all the downed websites by status code, so it's important that even websites that refuse connections should provide some form of a status code.
I decided that in the filter, I'd do this:
if ![http\_poller\_metadata][code] {
mutate {
add\_field =\> {"[http\_poller\_metadata][code]" =\> 500}
}
}
This seems to work well, since on Kibana, everything looks fine, (yay I got the nested fields to update nicely!), and it even shows the type as a long. The default has always been a long, and everything was working fine.
However, if I open up the JSON:
The original field:
http\_poller\_metadata.code: 200
Mine:
http\_poller\_metadata.code: "500"
This causes some indexing errors.
I was reading this article: [https://www.elastic.co/blog/little-logstash-lessons-part-using-grok-mutate-type-data](https://www.elastic.co/blog/little-logstash-lessons-part-using-grok-mutate-type-data)
But it more or less just explains the problem and now how to solve it.
Any tips? I can't figure out how to force types in Elasticsearch...
---
### Author:  [@magnusbaeck](https://discuss.elastic.co/u/magnusbaeck)
#### Post date: [March 21, 2017, 9:20am UTC](https://discuss.elastic.co/t/forcing-types-in-elasticsearch/79370/2 "2017-03-21T09:20:08Z")
Two options (not mutually exclusive):
- Use a separate mutate filter to convert `[http_poller_metadata][code]` into an integer (use the `convert` option).
- Use an Elasticsearch index template to force the field as an integer.
---
### Author:  [@lisadeng](https://discuss.elastic.co/u/lisadeng)
#### Post date: [April 3, 2017, 2:38pm UTC](https://discuss.elastic.co/t/forcing-types-in-elasticsearch/79370/3 "2017-04-03T14:38:13Z")
Hey Magnus, I tried both, and it didn't work.
By that I mean, I put an index template and specified that the status code would be of type long.
First, I also simplified the log fields in the filter{} so the index template putting would be easier for me.
I took out the http\_poller nested fields and just renamed them, so what used to be http\_poller\_metadata.code is now just status\_code.
curl -XPUT [http://localhost:9200/\_template/keepalive](http://localhost:9200/_template/keepalive) -d '
{
"template": "keepalive-\*",
"mappings":{
"website\_healthcheck": {
"properties": {
"@host": {"type":"text"},
"@timestamp": {"type":"date"},
"@version": {"type":"text"},
"http\_error":{"type":"text"},
"message":{"type":"text"},
"response\_message":{"type":"text"},
"runtime":{"type":"long"},
"status\_code":{"type":"long"},
"tags":{"type":"text"},
"times\_retried":{"type":"long"},
"url":{"type":"text"}
}
}
}
}
'
Kibana recognizes that status code is number, but the JSON STILL has quotes
around the status code,
so it's still status\_code:"500".
Currently, I'm no longer getting a 'uninvert' index error. However, over time I noticed that I get errors on 'shards failing', which I suspect has something to do with the fact that I'm running aggregations on a field that is supposedly a number, but shows up as a string in the JSON.
It's difficult to replicate this error it seems because I think it might only appear once I have many logs in an index.
---
### Author:  [@magnusbaeck](https://discuss.elastic.co/u/magnusbaeck)
#### Post date: [April 3, 2017, 2:43pm UTC](https://discuss.elastic.co/t/forcing-types-in-elasticsearch/79370/4 "2017-04-03T14:43:52Z")
> Kibana recognizes that status code is number, but the JSON STILL has quotes
> around the status code,
> so it's still status\_code:"500".
Yes, that's expected. Configuring the mapping of a field in an index template just affects how the field is mapped. The original documents are left untouched. What do your filters look like?
---
### Author:  [@lisadeng](https://discuss.elastic.co/u/lisadeng)
#### Post date: [April 4, 2017, 7:23am UTC](https://discuss.elastic.co/t/forcing-types-in-elasticsearch/79370/5 "2017-04-04T07:23:13Z")
Hey Magnus, I think I made a mistake. Perhaps I accidentally looked at an older log (my logs are coming in every 30 seconds), but using the convert option ended up working.
filter {
if [http\_poller\_metadata] or [http\_request\_failure] {
mutate {
add\_field =\> {"@host" =\> "%{http\_poller\_metadata[name]}"}
}
# Classify requests that can't connect or have an unexpected response code
if [http\_request\_failure] or [http\_poller\_metadata][code] !=200 {
mutate {
add\_tag =\> "bad\_request"
}
}
# If no existing status code, add one for classification purposes
# For example, request failures do not usually have error codes
if ![http\_poller\_metadata][code]{
mutate {
add\_field =\> {
"[http\_poller\_metadata][code]" =\> 500
}
}
mutate {
convert =\> {"[http\_poller\_metadata][code]" =\> "integer"}
}
}
}
This actually ended up working for me when I tried it again this morning.
So, it now the number shows up in the JSON without the quotes.
I guess when I did it earlier I looked at the wrong logs, or was really confused...
Thanks again for your help!
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [May 2, 2017, 7:23am UTC](https://discuss.elastic.co/t/forcing-types-in-elasticsearch/79370/6 "2017-05-02T07:23:13Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.