这个好处是你可以端到端去看你Cassandra的情况，观察客户端到Cassandra的时延成功率是怎样的。这有利于你通过一些网络等帮助你去对问题进行一些定位。还有比如我们时延成功率，我们可以做一些动态预知的告警，我们平台有机器学习的能力，当你突然有波动的时，比如有业务版本变更或者业务突然有个浪涌上来了，这时候你就知道有异常。这种便有利于提前及时去发现问题。
我们还讲一下巡检，巡检其实跟监控有一点差异。巡检其实是提前去发现问题，不是等告警的时候才发现问题。我们针对前面讲的一些指标容量风险，包括成功率时延等等进行一些巡检，但我们会做一些图。
其实对一些没有专门运维人员的小公司，你可以用那些监控的API接口自己写一个python脚本或一个Java程序。脚本每天把数据采集出来，统计汇总后，发邮件给相关责任人看一下，这样也是蛮好的，也不需要做这么漂亮的一个图。
前面我们讲了运维面临的一些挑战和实践经验，其实我们也遇到了一些问题，想提出来和大家探讨一下。
希望改进的功能：
Repair： 因为repair还是比较消耗CPU和IO资源的，在集群数量大时，修复时间会变长，我们还要关注对业务有没有额外影响。希望后期有人能对repair的资源占用做出一定的限制，比如做一些限制配置类的东西。
数据迁移的方案： 还有就是数据迁移的方案，比如以后业务要从其它数据库或者IDC机房迁移到云上的话，Cassandra有没有一些好的迁移方案，这样开发者就不需要自己做一些开发，从而提高应用性。
数据一致性不可度量和监控：对于数据一致性不可度量，我觉得一时半会也没有什么好的解决方案，没办法很好的监控。
二级索引： 目前已经支持的两种二级索引其实都是不太推荐大家使用的。
希望支持的功能：
支持表计数统计：我们有很多开发人员带着SQL的使用思路，想查询一张表有多少条记录。其实这目前是查不出来的，我们只能通过其它手段进行一些统计。
Nodetool支持commitlog的解析和回放：目前社区还没有这个功能，如果做到的话，数据备份就可以做到按时间点恢复，也就是真正的PITR(Point-In-Time-Recovery)。
墓碑：还有就是墓碑的一些优化。
待探讨:
RocksDB（优化GC问题）：前面很多老师也提到了，RocksDB应该也是有一些规划的。目前RocksDB也比较火爆，很多大厂现在都在考虑用RocksDB做一些多模数据库。存储引擎好像都会用会考虑用Rocksdb。
3AZ部署情况下驱动优化路由算法，也就是降低跨AZ访问的时延。
未来是否会考虑分支，将存算分离、强一致性作为一个分支。我们企业云的兄弟部门在这方面做了一些尝试。
