# Using Elasticsearch to record network latency

**URL:** <https://discuss.elastic.co/t/using-elasticsearch-to-record-network-latency/20027>\
**Category:** Elasticsearch\
**Created:** [October 1, 2014, 2:43pm UTC](https://discuss.elastic.co/t/using-elasticsearch-to-record-network-latency/20027 "2014-10-01T14:43:31Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![jnortey](https://avatars.discourse-cdn.com/v4/letter/j/65b543/32.png) [@jnortey](https://discuss.elastic.co/u/jnortey)\
**Post date:** [October 1, 2014, 2:43pm UTC](https://discuss.elastic.co/t/using-elasticsearch-to-record-network-latency/20027/1 "2014-10-01T14:43:31Z")

</div>

We're looking to improve the way we record network latency between a server  
and a client using Elasticsearch.

We have the following mapping in elasticsearch to record this information  
(irrelevant keys have been omitted for brevity) :

_NetworkEvent.json_

{  
"properties": {  
"_startTime_": {  
"type": "long",  
"index": "not\_analyzed"  
},  
"_endTime_": {  
"type": "long",  
"index": "not\_analyzed"  
}  
}  
}

This is our strategy for recording and running queries on the network  
latency:

When the request is made from the client, we create a new NetworkEvent  
document and record the start time. We then generate a unique tracking ID  
and use that as the ID for the document:

curl -XPUT [http://localhost:9200/](http://localhost:9200/)/NetworkEvent/

When the response comes back, we get the trackingID and update the  
NetworkEvent document with the endTime. We're then able to do a script  
query with 'endTime-startTime' to display analytics about network  
transactions. This strategy was sort of roundabout but it was necessary due  
to reasons I won't go into here.

The whole trackingID as the index name and having to update the document  
was a previous requirement due to the way we were logging the data. We no  
longer have this requirement and so now we would like to have network  
requests and network responses as separate elasticsearch event types. The  
problem is that this complicates the queries since the start time and end  
times are no longer in the same document.

Any suggestions for recording this kind of data while still being able to  
query the data efficiently?

--  
You received this message because you are subscribed to the Google Groups "elasticsearch" group.  
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/37e07ff2-8f22-4d0f-aaca-7573925dc0fc%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/37e07ff2-8f22-4d0f-aaca-7573925dc0fc%40googlegroups.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<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:** [July 6, 2017, 12:58am UTC](https://discuss.elastic.co/t/using-elasticsearch-to-record-network-latency/20027/2 "2017-07-06T00:58:58Z")

</div>

Closed on July 6, 2017, 12:58am UTC