一. 服务器 1. 状态监控 (1) 服务器是否可访问？ (2) 相应的数据库服务是否启用？ (3) 操作系统事件日志中的错误或告警 (4) 磁盘可用空间 服务器状态监控，不管使用第三方工具，还是使用自定义脚本，都建议部署在专门的一台/多台监控机上，因为如果服务器DOW

一. 服务器
1. 状态监控
(1) 服务器是否可访问？
(2) 相应的数据库服务是否启用？
(3) 操作系统事件日志中的错误或告警
(4) 磁盘可用空间

服务器状态监控，不管使用第三方工具，还是使用自定义脚本，都建议部署在专门的一台/多台监控机上，因为如果服务器DOWN了或者故障了，任何本机的程序/脚本可能就无法运行了，从而也失去了监控的意义。

甚至有人想过在本机的SQL Server里写SQL语句来监视服务器状态，尽管可以实现，但是有点自相矛盾。也许，又会有这么一个思路，服务器正常时，SQL Server就发出邮件通知，如果没有收到邮件就说明服务器不正常了，可如果有很多服务器时，怎么知道谁没发邮件呢？

2. 性能监控
(1) IO压力
(2) 内存使用
(3) CPU使用
(4) 网络带宽占用

这1，服务器，2，服务器，3，4是按照容易出现瓶颈的顺序排列的，由于磁盘的读写速度，通常IO是最容易出现瓶颈的地方，我们所做的很多优化，也都是针对IO的，比如：索引优化，读写分离等等。
从DBA的角度来说，服务器的某些性能监控，如果可以的话，从数据库层来做倒也无妨。

二. 数据库
1. 状态监控
(1) 数据库可否打开 (数据库状态)
(2) 数据库备份有没有成功
(3) SQL Server/SQL Server Agent错误日志中的错误或告警
(4) SQL Agent 作业运行状态
(5) 数据库一致性检查的结果 (DBCC CHECKDB)
(6) 数据库还原测试的结果

以下几条状态监控，通常需要和系统平均值/基线值比较才有意义，否则没有告警的标准。
(7) 连接数、请求数、事务数
(8) 数据库/文件使用、大小、可用空间
(9) 表使用、行数、占用空间

2. 性能监控
(1) 有没有长时间运行的查询 (一般指没有被任何请求阻塞，效率很差的查询)
(2) 有没有被阻塞的查询 (可能单独运行很快，但和别的请求一起，由于有锁等待，耗时很长)
(3) 有没有死锁 (开发人员/用户口中说的”死锁” 通常是阻塞/等待，数据库死锁通常很少让用户感觉到等待，服务器，一般是请求被中断，因为被kill掉了)
(4) 有没有等待 (一般指各种资源的等待，等待和阻塞的交集就是锁等待)
(5) 有没有缺失的/未被使用的/效率不高的索引，以及索引碎片
(6) 有没有过期的统计信息
(7) 有没有数据库文件的争用 (比如：日志文件，tempdb争用)
(8) 有没有消耗CPU较大、IO读写较多的查询 (通常IO消耗大的，也就是内存消耗大的查询)

三. 其他
(1). 如果有部署高可用的策略，会有镜像、复制、日志传送、集群状态的监控；
(2). 某些业务数据有严格的一致性要求，业务数据的校验，最好也做在监控的告警里面；
(3). 对于数据库/实例的选项、参数设置，登录、用户、链接服务器等对象的可用性，通常在每年/每季度的health check里检查过就可以了，如果不放心，当然也可以放到监控的告警中来。