Best way to monitor time it takes mutations to be reflected in a index

Enterprise 6.5

As in the title.

We have some queries where we request consistency from the indexes and some that not. We are growing and need to put in place metrics to help us quantify the performance story.

We’d like to implement a probe/diagnostic that would keep tabs on the time it takes for indexes to reflect data updates and measure how/if it degrades as a function of write load and index size and set up some alerts for lags above a certain threshold.

The naive approach is to have a script make data updates that we know need to be dcp’d to the indexer and then run n1ql queries hitting the target index and recording differences in time stamps between the write and the first n1ql query returning the fresh result .

Is this a viable approach?

Is there a better approach?

Please help.


You can use the “num_docs_pending” stat and “avg_drain_rate” stat for your use case. See:

“num_docs_pending” represents the number of mutations waiting to be indexed. At the start of a workload, this stat goes high and eventually comes down to “0”. “avg_drain_rate” tells you how fast indexer is flushing to storage. If avg_drain_rate is less, then more will be the time taken to catch-up mutations and vice-versa.