# Some statistics still NaN?

**URL:** <https://community.graylog.org/t/some-statistics-still-nan/5636>\
**Category:** Graylog Central (peer support)\
**Created:** [June 18, 2018, 12:14pm UTC](https://community.graylog.org/t/some-statistics-still-nan/5636 "2018-06-18T12:14:40Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![uclnj](https://avatars.discourse-cdn.com/v4/letter/u/e480ec/32.png) [@uclnj](https://community.graylog.org/u/uclnj)\
**Post date:** [June 18, 2018, 12:14pm UTC](https://community.graylog.org/t/some-statistics-still-nan/5636/1 "2018-06-18T12:14:40Z")

</div>

I have a few extractors on a feed, getting bytes sent, received and message level. All grok patterns, all number (int). The fields get added to the stream but when I view field stats, sent and received get NaN while the level (a number that doens’t change, it’s almost always 6) works just fine. I limited the query to just where the field sent\_bytes exists.

Each of the 17 results in the attachment has a value in sent and received bytes but when I create a quick values chart, it only shows 7 messages with field rcvd\_bytes.

Bug?

![19](https://us1.discourse-cdn.com/flex016/uploads/graylog/original/2X/a/a5fee87c8130e810ab8f6f7f852b9b3bf77624ab.png)

 ![30](https://us1.discourse-cdn.com/flex016/uploads/graylog/original/2X/9/95ef608a4980fa8ce328c9bfbbe7d3809cb9eee8.png) ![15](https://us1.discourse-cdn.com/flex016/uploads/graylog/original/2X/c/c38c8a55d44a60a8f978c6054200d0cb3142d3de.png)

---

<div class="post-metadata">

**Author:** ![jan](https://sea2.discourse-cdn.com/flex016/user_avatar/community.graylog.org/jan/32/11_2.png) [@jan](https://community.graylog.org/u/jan)\
**Post date:** [June 18, 2018, 1:29pm UTC](https://community.graylog.org/t/some-statistics-still-nan/5636/2 "2018-06-18T13:29:15Z")

</div>

I guess those values are not saved as number in Elasticsearch. You should add your custom template to ES that those are saved as number.

[http://docs.graylog.org/en/2.4/pages/configuration/elasticsearch.html#custom-index-mappings](http://docs.graylog.org/en/2.4/pages/configuration/elasticsearch.html#custom-index-mappings)

---

<div class="post-metadata">

**Author:** ![uclnj](https://avatars.discourse-cdn.com/v4/letter/u/e480ec/32.png) [@uclnj](https://community.graylog.org/u/uclnj)\
**Post date:** [June 18, 2018, 1:35pm UTC](https://community.graylog.org/t/some-statistics-still-nan/5636/3 "2018-06-18T13:35:08Z")

</div>

That’s a bit of a problem then no? The Grok pattern is set to numeric:int - the message fed is level=“6” bytes=“4444” - the extractor is storing the 6 as a number but the 4444 is stored as something else?

What’s the point of the grok extractor then?

---

<div class="post-metadata">

**Author:** ![jochen](https://sea2.discourse-cdn.com/flex016/user_avatar/community.graylog.org/jochen/32/8_2.png) [@jochen](https://community.graylog.org/u/jochen)\
**Post date:** [June 18, 2018, 1:36pm UTC](https://community.graylog.org/t/some-statistics-still-nan/5636/4 "2018-06-18T13:36:52Z")

</div>

> [@uclnj](#):
>
> What’s the point of the grok extractor then?

If there are other messages with the message field “rcvd\_bytes” or “sent\_bytes” with a different data type, then Elasticsearch will try to guess the data type based on the first message in the index with these fields.

As @jan already said, create a custom Elasticsearch index mapping for the fields you want to analyze.

---

<div class="post-metadata">

**Author:** ![uclnj](https://avatars.discourse-cdn.com/v4/letter/u/e480ec/32.png) [@uclnj](https://community.graylog.org/u/uclnj)\
**Post date:** [June 18, 2018, 3:47pm UTC](https://community.graylog.org/t/some-statistics-still-nan/5636/5 "2018-06-18T15:47:25Z")

</div>

The syslog feed will only ever have bytes for rcvd/sent and what the hell is the point of me telling it %{NUMBER:int} if Elasticsearch is going to guess the data type? Why not just %{Guess}. It’s pointless to include a feature where you can specify the data type if the backend is just going to guess the type to be stored based on what it sees.

Is there a way to view the schema of what elasticsearch thinks is the data type being stored?

---

<div class="post-metadata">

**Author:** ![jochen](https://sea2.discourse-cdn.com/flex016/user_avatar/community.graylog.org/jochen/32/8_2.png) [@jochen](https://community.graylog.org/u/jochen)\
**Post date:** [June 18, 2018, 3:52pm UTC](https://community.graylog.org/t/some-statistics-still-nan/5636/6 "2018-06-18T15:52:40Z")

</div>

> [@uclnj](#):
>
> The syslog feed will only ever have bytes for rcvd/sent and what the hell is the point of me telling it %{NUMBER:int}

It would indeed work, if there were only messages having that one data type for the message field in question.  
That doesn’t seem to be the case in your Elasticsearch cluster.

> [@uclnj](#):
>
> Elasticsearch is going to guess the data type?

You probably want to read about dynamic mapping:

> **[Dynamic Mapping | Elasticsearch Reference \[5.6\] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/5.6/dynamic-mapping.html)**

> [@uclnj](#):
>
> Is there a way to view the schema of what elasticsearch thinks is the data type being stored?

Yes, it’s called index mapping.

> **[Get Mapping | Elasticsearch Reference \[5.6\] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/5.6/indices-get-mapping.html)**

> **[Mapping | Elasticsearch Reference \[5.6\] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/5.6/mapping.html)**

---

<div class="post-metadata">

**Author:** ![uclnj](https://avatars.discourse-cdn.com/v4/letter/u/e480ec/32.png) [@uclnj](https://community.graylog.org/u/uclnj)\
**Post date:** [June 18, 2018, 4:09pm UTC](https://community.graylog.org/t/some-statistics-still-nan/5636/7 "2018-06-18T16:09:36Z")

</div>

Perfect, thank you all.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex016/uploads/graylog/original/3X/c/7/c7c09c6b5099570133d6502b83f50ba4430de5b6.png) [@system](https://community.graylog.org/u/system)\
**Post date:** [July 2, 2018, 4:09pm UTC](https://community.graylog.org/t/some-statistics-still-nan/5636/8 "2018-07-02T16:09:43Z")

</div>

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
