indexing metrics: split up update vs add #304

Dieterbe · 2016-09-06T11:13:40Z

currently the metrics are a bit confusing, due to the memory index receiving continuously new "adds" that are actually updates. and ES not getting any news adds after the initial adds.

Dieterbe · 2017-01-26T11:25:04Z

There's really several problems here:

memoryIndex executes updates and adds (but calls both "adds" in metrics)
ES does not perform updates unless partition changes (created ES index does not update definitions like cassandra does #500 for that)
ES uses the bulk indexer, so adds, updates and deletes are intermingled and we can't really know how many of each went into each bulkSend (and hence also into each processEsResponse). we can't really track the properties ourselves since elastigo calls bulkSend concurrently. we could do it if we implemented our own bulksender, but that's just not something we should do now since we don't use the es index and we discourage it anyway, so we can just change the metric names to clarify they could be any operation.

* split up updates vs adds. correctly categorize them * clarify and assure that all ES/cass operation (add, update, delete) metrics also include the memory part (which was already the case for most, but not all operations. and was not documented well) * operations on ES index (add/delete/update) turn into backend operations that get mingled into larger bulk operations, clarify the ambiguity. don't pretend it was an add, make it clear we can't tell for sure what kind of operation it was. * similar for Cassandra: the backend executes inserts (on behalf of adds and updates) and deletes (on behalf of updates and deletes) Even if we tied back query results to the original command, e.g. we could increment an update success counter when an insert succeeds, if we track that insert was due to an update, the update might still not be successfull if the delete fails. So the ok/fail counters should really be for queries. * also time prune operations * specify whether durations concern one metric, or several (e.g. a pattern delete) fix #304

woodsaj · 2017-01-27T05:35:03Z

Personally i think we should just remove the ES index from the code base. There is no benefit to us keeping it around.

Dieterbe · 2017-01-27T10:18:48Z

yeah that's reasonable. I'll do that in my pr as well.

* split up updates vs adds. correctly categorize them * clarify and assure that all ES/cass operation (add, update, delete) metrics also include the memory part (which was already the case for most, but not all operations. and was not documented well) * operations on ES index (add/delete/update) turn into backend operations that get mingled into larger bulk operations, clarify the ambiguity. don't pretend it was an add, make it clear we can't tell for sure what kind of operation it was. * similar for Cassandra: the backend executes inserts (on behalf of adds and updates) and deletes (on behalf of updates and deletes) Even if we tied back query results to the original command, e.g. we could increment an update success counter when an insert succeeds, if we track that insert was due to an update, the update might still not be successfull if the delete fails. So the ok/fail counters should really be for queries. * also time prune operations * specify whether durations concern one metric, or several (e.g. a pattern delete) fix #304

Dieterbe self-assigned this Jan 25, 2017

Dieterbe closed this as completed in 6939e86 Jan 31, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

indexing metrics: split up update vs add #304

indexing metrics: split up update vs add #304

Dieterbe commented Sep 6, 2016

Dieterbe commented Jan 26, 2017 •

edited

Loading

woodsaj commented Jan 27, 2017

Dieterbe commented Jan 27, 2017

indexing metrics: split up update vs add #304

indexing metrics: split up update vs add #304

Comments

Dieterbe commented Sep 6, 2016

Dieterbe commented Jan 26, 2017 • edited Loading

woodsaj commented Jan 27, 2017

Dieterbe commented Jan 27, 2017

Dieterbe commented Jan 26, 2017 •

edited

Loading