# Allow for renaming of json fields in http module output

**URL:** <https://discuss.elastic.co/t/allow-for-renaming-of-json-fields-in-http-module-output/112461>\
**Category:** Beats\
**Tags:** metricbeat\
**Created:** [December 19, 2017, 3:25pm UTC](https://discuss.elastic.co/t/allow-for-renaming-of-json-fields-in-http-module-output/112461 "2017-12-19T15:25:15Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![spfeiffer](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/spfeiffer/32/25803_2.png) [@spfeiffer](https://discuss.elastic.co/u/spfeiffer)\
**Post date:** [December 19, 2017, 3:25pm UTC](https://discuss.elastic.co/t/allow-for-renaming-of-json-fields-in-http-module-output/112461/1 "2017-12-19T15:25:15Z")

</div>

I want to ingest Spring Boot Actuator metrics information (`/metrics` endpoint). The http module takes the JSON returned by my spring boot application and feeds it to ES using the elasticsearch output.

Basically, i run into this problem:

> [@V6.0.0-beta2 http module mapping trouble](https://discuss.elastic.co/t/v6-0-0-beta2-http-module-mapping-trouble/99703):
>
> I'm trying to collect metrics from Dorpwizard metrics. Those are exposed by the REST API as Json. I tryed dropwizard module for metrics but it seams not to fetch any datas. Then switched to http module for metrics but not event is indexed due to mapping error 2017-09-07T11:33:09+02:00 WARN Can not index event (status=400): {"type":"illegal\_argument\_exception","reason":"mapper [http.metrics\_http\_me.classes] of different type, current\_type [long], merged\_type [ObjectMapper]"} The index was dr…

There are JSON fields named `classes` and `classes.loaded` with an integer value. ES helpfully converts the dotted notation of `classes.loaded` to `{"classes":{"loaded":12345}}`, a nested JSON object. Unfortunately, `classes: 12345` cannot be parsed/indexed as `classes` already is an object which cannot contain a `long` primitive.

Obviously. there are three workarounds right now:

1. Feed the data to logstash and use the `de_dot` filter. This is computational intensive and needs a logstash server just for this use case. I would like to omit logstash as long as possible and go the route of ingest pipelines. Unfortunately, ingest pipelines do not offer anything resembling the `de_dot` filter.
2. Drop the fields that lead to problems, e.g. `classes` in the example given. But i have lots of those conflicting fields, and i am not fond of dropping them all. Especially as i lose the data these fields contain. Different Spring Boot services add different metrics values dynamically, calling for perpetual adaption of the list of fields to drop to get rid of the offending fields.
3. Using the community spring beat  
[GitHub - consulthys/springbeat: Simple Beat for collecting metrics from Spring Boot apps](https://github.com/consulthys/springbeat/)  
Unfortunately, there is no binary release available, and i am not really into building this stuff myself. As i am using metricbeat anyway for system metrics, i also wanted to avoid using more independent beats for the different metrics, i would prefer a module.

The jolokia module seems to suffer from the same problem:

> <https://github.com/elastic/beats/pull/5916>
>
> The include\_fields processor does not work in case the key contains a dot. See t…ests added here for this case.
> 
> There are different solutions here:
> 
> \* Modify \`GetValue\` in common.MapStr to also look for keys with dots inside instead of directly walking the tree
> \* Modifying jolokia fetcher to convert dot keys to objects
> 
> The first change would be possible with adding
> 
> \`\`\`
> \--- a/libbeat/common/mapstr.go
> +++ b/libbeat/common/mapstr.go
> @@ -296,6 +296,10 @@ func walkMap(key string, data MapStr, op mapStrOperation) (interface{}, error) {
> var err error
> keyParts := strings.Split(key, ".")
> 
> + if v, exists := data\[key\]; exists {
> + return v, nil
> + }
> +
> \`\`\`
> 
> But that does not fully solve the problem. As in the processor the following code is used, the fields which are added after filtering to the filtered fields, will have a nesting without the docs (see Put method)
> 
> \`\`\`
> for \_, field := range f.Fields {
> v, err := event.GetValue(field)
> if err == nil {
> \_, err = filtered.Put(field, v)
> }
> 
> // Ignore ErrKeyNotFound errors
> if err != nil && errors.Cause(err) != common.ErrKeyNotFound {
> errs = append(errs, err.Error())
> }
> }
> \`\`\`
> 
> This Put would also cause other issues as we see in the event below. If it's convert to an object \`classes\` and the namespaces \`classes.loaded\` would conflict because one is an object and the other one isn't. I would have expected that this already causes an issue on the Elasticsearch side before filtering.
> 
> \`\`\`
> "jolokia":{
> "metrics":{
> "Metrics":{
> "atomikos.nbTransactions":0.000000,
> "classes":18857.000000,
> "classes.loaded":19127.000000,
> "classes.unloaded":270.000000,
> "counter.servo.discoveryclient-httpclient\_createnew":13542.000000,
> "counter.servo.discoveryclient-httpclient\_delete":13534.000000,
> "uptime":406037194.000000
> },
> "java":{
> "Threading":{
> "DaemonThreadCount":37.000000,
> "ThreadCount":57.000000
> }
> }
> }
> }
> \`\`\`
> 
> An alternative solution to the above is replacing the \`.\` in the names with \`\_\` as we do for example for docker labels and other places with a similar issue. The downside of this is that filtering on fields is not straight forward as the names change between fetching from jolokia and in ES.
> 
> See https://discuss.elastic.co/t/include-fields-problem/109809

The httpbeat from which the http module in metricbeat inherited already solved that problem. It had a configurable replacement of dots in the JSON field names:

> <https://github.com/christiangalsterer/httpbeat/blob/master/config/config.go#L34>

Unfortunately, the http module has no such capability.

Given the abundance of Spring Boot applications and the need for monitoring them using actuator endpoints, i am surprised there is not so much information on how to tackle the problem efficiently. Are there plans to incorporate a `de_dot` like capability in the http module of metricbeat, like httpbeat already had it?

Thanks,  
Stefan

---

<div class="post-metadata">

**Author:** ![spfeiffer](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/spfeiffer/32/25803_2.png) [@spfeiffer](https://discuss.elastic.co/u/spfeiffer)\
**Post date:** [December 19, 2017, 3:52pm UTC](https://discuss.elastic.co/t/allow-for-renaming-of-json-fields-in-http-module-output/112461/2 "2017-12-19T15:52:18Z")

</div>

The problem also surfaced on the Spring Boot Actuator side of things:

> <https://github.com/spring-projects/spring-boot/issues/10449>

  

> <https://github.com/micrometer-metrics/micrometer/issues/154>

  
Obviously, the problem will vanish in Spring Boot 2, but i am still bound to 1.5 unfortunately ☹

---

<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:** [December 21, 2017, 4:40am UTC](https://discuss.elastic.co/t/allow-for-renaming-of-json-fields-in-http-module-output/112461/3 "2017-12-21T04:40:39Z")

</div>

@spfeiffer Thanks for bringing this up. I agree this is a problem we need to address as it affects multiple parts in Beats. Can you open a Github issue an we can discuss there on what the best place to implement is.

---

<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:** [January 18, 2018, 4:40am UTC](https://discuss.elastic.co/t/allow-for-renaming-of-json-fields-in-http-module-output/112461/4 "2018-01-18T04:40:57Z")

</div>

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