根据数据库的重要性，如何对存储IO响应时间进行告警监控，具体告警阈值如何合理配置？

3个实践思路，供参考
1、响应时间是敏感的指标，如果单纯依据响应时间是否超出阈值就产生告警则可能导致毛刺场景下频繁的告警困扰运维，所以首先建议类似响应时间的告警要有样本点的概念，其次要判断响应时间类的指标是持续在恶化还是偶然升高，显然持续恶化的场景是应该更加关注的场景
2、可以通过同比、环比的思路，比对相同时间在周期内的响应时间表现，以此来判断是否属于异常
3、应该提供一定的异常置信区间，关注特别异常的点

存储的IO响应时间个人认为分为以下几种，
卷的响应时间
案例如下：
 Volume: 监控提醒值 监控告警值 持续时间
Read Response times  15ms-20ms >20ms 30min
Write Response times   15ms-20ms >20ms 30min
磁盘响应时间
案例如下：
Disk : 监控提醒值 监控告警值 持续时间
Back-end Read Response times  50ms-100ms >100ms 30min
Back-end Write Response times  30ms-50ms >50ms 30min
Read Response Time 30ms-50ms >50ms 30min
Write Response Time  20ms-30ms >30ms 30min

控制节点响应时间
案例如下：
 Node: 监控提醒值 监控告警值 持续时间
Read Response Time  15ms-20ms >20ms 30min
Write Response Time 15ms-20ms >20ms 30min
System CPU Utilization  50% 70% 30min
Node Utilization Percentage  50% 70% 30min
Write Cache Delay Percentage  0-1 >1 30min

具体可以根据业务重要性进行优化。

告警监控重点考虑2个内容：数值、持续性。
首选，要有基线。基线的建立依赖于历史数据和对应用的理解。
其次，要有业务目标，业务目标到IT目标的映射，决定了IT目标的底线是什么。
最后，要有结合自身特点的实践。

比如，
我们通常会建议客户记录历史的峰值，如果高于历史峰值，我们先警告；如果高于历史峰值30%，系统做通知告警；如果再高，可能就要提前引入故障预警流程了。
持续性问题，偶然超出历史峰值，要记录，不影响应用的，可以事后分析。持续超出历史峰值，比如持续了5分钟，要告警，要重点监控，要立刻分析原因。