NoSQL · Data models beyond tables
What should you monitor in a NoSQL deployment?
Short answer
Monitor latency percentiles, error rates, throughput, saturation, replication lag, disk and compaction health, cache hit rates and throttling. Alert on user-visible symptoms, not only raw resource metrics.
The useful starting framework is latency, traffic, errors and saturation, plus database-specific signals. Averages hide tail latency, so track p50, p95 and p99. A query that is fast on average can still be unacceptable for a meaningful fraction of users.
Signals worth having
- Read and write latency by operation, including p99
- Error and timeout rate, split by client and server causes
- Throughput, plus throttled or rejected requests
- Replication lag and failover events
- Disk usage, IOPS and compaction backlog
- Cache hit rate and eviction rate
mongodb_ss_opcounters{type="query"}
redis_evicted_keys_total
cassandra_table_live_disk_space_used
cassandra_table_pending_compactions
dynamodb_throttled_requests_sum
aws_dynamodb_consumed_read_capacity_unitsMetrics show that something is wrong; logs and traces show where. Correlate a slow request with the specific query, partition and downstream call. Include the database operation in traces so a slow span is attributable rather than a generic client timeout.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1Why are p99 metrics more useful than averages?
- 2Which database-specific metric would you alert on first?
- 3How do traces complement metrics and logs?
- 4What does replication lag tell you about user impact?
Say it in the interview
I monitor latency percentiles, errors, throughput and saturation first, then add database-specific signals such as replication lag, disk usage, compaction backlog and cache eviction. Averages hide tail latency, so p99 matters for user experience. When an alert fires, logs and traces let me attribute the slow request to a query or partition. I alert on user-visible symptoms and keep resource alerts as early warning rather than the main pager signal.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live NoSQL mock interview and get scored feedback on depth, clarity and confidence.