Support custom attributes in Request Response Record stored in ElasticSearch

[sv2]

Pick additional data from both request and response, add it to Request Response Record and store in ElasticSearch. Allow application to add custom attributes to Request Response Record. This is to enable reporting in ElasticSearch / Kibana based on custom application-specific attributes.

Define flexible custom attributes in the schema by using dynamic mapping:

{
   "attributes": {
       "path_match": "attributes.*",
           "mapping": {
              "type": "keyword"
             }
         }
}

This should allow app to add anything under rrr.attributes and ES would index it correctly as long as values casted to strings.

Additional discussion are in #4, #27

[ridakk]

it might not be a good thing to cast everything to string. for ex: i am adding an object as below to rrr.

rrr.attrs.rid = {
  root: '1234',
  local: '1111',
  remote: '4321'
}

once this is stringified, it will be hard to read and guess it will be impossible to search through kibana from multiple entries with root part only

[sv2]

Right ... the challenge is that once "rid" is added dynamically as an object to ElasticSearch index mapping, it will have to be always an object in all subsequent indexed documents. That is, if app by some reason adds attr.rid = "abc" in the next request, Elasticsearch will reject this. This opens up possibility to lose information about request / response if application uses custom attributes with the same name but different types. I am trying to find a way to avoid such loss of information - ensure that information is always written to Elasticsearch, even if application adds custom attribute with the same name but with different type of values in different requests. Perhaps to store such object we can simply declare that a placeholder "attrsobj" should be used to add objects, and enforce object type for everything application places under it.

[ridakk]

To me, it is quite fair just to document this as a limitation. otherwise, it will be quite hard to cover every different use case. and having different holders for objects, string, integers sound not ok to me just from perpective of application as i really hate to write if cases :)