# Metricbeat logs contain errors about nonexistent Redis properties

**URL:** <https://discuss.elastic.co/t/metricbeat-logs-contain-errors-about-nonexistent-redis-properties/56923>\
**Category:** Beats\
**Created:** [August 1, 2016, 7:09pm UTC](https://discuss.elastic.co/t/metricbeat-logs-contain-errors-about-nonexistent-redis-properties/56923 "2016-08-01T19:09:31Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![ladenedge](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ladenedge/32/11145_2.png) [@ladenedge](https://discuss.elastic.co/u/ladenedge)\
**Post date:** [August 1, 2016, 7:09pm UTC](https://discuss.elastic.co/t/metricbeat-logs-contain-errors-about-nonexistent-redis-properties/56923/1 "2016-08-01T19:09:31Z")

</div>

Metricbeat-5.0.0-alpha4  
Redis v3.0.501 (Windows)

My log contains the following errors, repeated on every period:

```
2016-08-01T14:56:42-04:00 ERR Key does not exist in in data: gcc_version
2016-08-01T14:56:42-04:00 ERR Key does not exist in in data: config_file

```

These correspond to expected Redis INFO properties, but those particular properties do not exist in my (Windows) version of Redis. Metricbeat ends up sending this to its output:

```
"config_file": "",
"gcc_version": "",

```

I might suggest dropping the Redis module's "Key does not exist" log message to a WARN or INFO.

---

<div class="post-metadata">

**Author:** ![ruflin](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ruflin/32/3116_2.png) [@ruflin](https://discuss.elastic.co/u/ruflin)\
**Post date:** [August 2, 2016, 8:46am UTC](https://discuss.elastic.co/t/metricbeat-logs-contain-errors-about-nonexistent-redis-properties/56923/2 "2016-08-02T08:46:17Z")

</div>

We already changed the behaviour here for the next version of metricbeat (5.0.0-alpha5). Non existing values will not be sent anymore: [https://github.com/elastic/beats/pull/2034](https://github.com/elastic/beats/pull/2034) On the non optional fields, an error will be logged. As these fields do not exist under Windows, it would probably make sense to make them optional. Why does `config_file` not exist?

---

<div class="post-metadata">

**Author:** ![ladenedge](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ladenedge/32/11145_2.png) [@ladenedge](https://discuss.elastic.co/u/ladenedge)\
**Post date:** [August 2, 2016, 3:29pm UTC](https://discuss.elastic.co/t/metricbeat-logs-contain-errors-about-nonexistent-redis-properties/56923/3 "2016-08-02T15:29:21Z")

</div>

A just question. When I run INFO manually on the same machine, I _do_ see a `config_file` option.

Here is the [DBG output from metricbeat](http://pastebin.ca/3671834) and the [INFO output from redis-cli](http://pastebin.ca/3671831) in case you want to compare.

The change you describe sounds good, though I wonder why any fields would need to be non-optional for just this reason. In any case, thank you for the response -- I'll look forward to future versions!

---

<div class="post-metadata">

**Author:** ![ruflin](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ruflin/32/3116_2.png) [@ruflin](https://discuss.elastic.co/u/ruflin)\
**Post date:** [August 3, 2016, 10:48am UTC](https://discuss.elastic.co/t/metricbeat-logs-contain-errors-about-nonexistent-redis-properties/56923/4 "2016-08-03T10:48:37Z")

</div>

I'm quite surprised that it shows up when you run it manually but not when run from metricbeat. I assume it is the same redis-server instance?

About the optional params: Missing values in a request can mean something is wrong. That is why we log an error if values are missing.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [August 22, 2016, 7:10pm UTC](https://discuss.elastic.co/t/metricbeat-logs-contain-errors-about-nonexistent-redis-properties/56923/5 "2016-08-22T19:10:09Z")

</div>

This topic was automatically closed after 21 days. New replies are no longer allowed.