数据库服务器的监控可大致分为两类:
(1) 状态监控: 数据库服务器有没有在健康地运行?
(2) 性能监控: 健康运行的同时, 有没有性能问题? 可不可以更快些?
一. 服务器
1. 状态监控
(1) 服务器是否可访问?
(2) 数据库服务是否启用?
(3) 操作系统事件日志中的错误或告警
(4) 磁盘可用空间
2. 性能监控
(1) IO 压力
(2) 内存使用
(3) CPU 使用
(4) 网络带宽占用
这 1,2,3,4 是按照容易出现瓶颈的顺序排列的, 由于磁盘的读写速度限制, 通常 IO 是最容易出现瓶颈的地方, 我们所做的很多优化, 也都是针对 IO 的, 比如: 索引优化, 读写分离等等.
二. 数据库
1. 状态监控
(1) 数据库可否打开 (数据库状态)
(2) SQL Server/SQL Server Agent 错误日志中的错误或告警
(3) 数据库 / 文件组可用空间
(4) SQL Agent 作业运行状态
(5) 数据库备份有没有成功
(6) 数据库还原测试的结果
(7) 数据库一致性检查的结果 (DBCC CHECKDB)
以下几条状态监控, 通常需要和系统平均值 / 基线值比较才有意义, 否则没有告警的标准.
(8) 连接数, 请求数, 事务数, 线程数
(9) 数据库 / 文件 / 表的大小
(10) 表使用, 行数
2. 性能监控
(1) 有没有长时间运行的查询 (一般指没有被任何请求阻塞, 效率很差的查询)
(2) 有没有被阻塞的查询 (可能单独运行很快, 但和别的请求一起, 由于有锁等待, 耗时很长)
(3) 有没有死锁 (开发人员 / 用户口中说的 "死锁" 通常是阻塞 / 等待, 数据库死锁通常很少让用户感觉到等待, 一般是请求被中断, 因为被 kill 掉了)
(4) 有没有等待 (一般指各种资源的等待, 等待和阻塞的交集就是锁等待)
以下几条性能监控, 通常在性能优化时作为参考, 或者如: 索引碎片整理 / 统计信息更新, 直接设置为后台维护作业, 并不直接告警.
(5) 有没有缺失的 / 未被使用的 / 效率不高的索引, 以及索引碎片
(6) 有没有过期的统计信息
(7) 有没有数据库文件的争用 (比如: 日志文件, tempdb 争用)
(8) 有没有消耗 CPU 较大, IO 读写较多的查询 (通常 IO 消耗大的, 也就是内存消耗大的查询)
三. 其他
(1). 如果有部署高可用的策略, 会有镜像, 复制, 日志传送, 集群状态的监控;
(2). 某些业务数据有严格的一致性要求, 业务数据的校验, 最好也做在监控的告警里面;
(3). 对于数据库 / 实例的选项, 参数设置, 链接服务器等对象的可用性, 通常在每年 / 每季度的 health check 里检查过就可以了, 如果不放心, 当然也可以放到监控的告警中来.
四. 如何部署监控?
1. 不要选择依赖性的脚本 / 命令
以监视服务是否启动为例, 脚本如下:
(1) SQL 扩展存储过程
-- 参数 1: QueryState 检查服务状态 / Start 启动服务 / Stop 停掉服务
-- 参数 2: 服务名
- exec master.dbo.xp_servicecontrol'QueryState', 'MSSQLServer'
- exec master.dbo.xp_servicecontrol'QueryState', 'SQLServerAgent'
- exec master.dbo.xp_servicecontrol'QueryState', 'SQLBrowser'
- exec master.dbo.xp_servicecontrol'QueryState', 'NetLogon'
- EXEC xp_servicecontrolN'Stop', N'SQLServerAGENT'
- EXEC xp_servicecontrolN'Start',N'SQLServerAGENT'
(2) SQL 调用操作系统命令
- if OBJECT_ID('tempdb..#tmp_started_services') is not null
- drop table #tmp_started_services
- create table#tmp_started_services(started_servicesvarchar(255))
- insert into#tmp_started_services(started_services)
- exec master..xp_cmdshell'net start'
- select *
- from#tmp_started_services
- where LTRIM(RTRIM(started_services)) like 'SQL%'
如果 SQL Server 没启动, 这些脚本根本就跑不了, 又怎么监控呢?
也许, 又会有这么一个思路, 服务器正常时, 发出邮件通知, 如果没有收到邮件就说明服务器不正常了, 可如果有很多服务器时, 怎么知道谁没发邮件呢?
2. 部署在专门的一台 / 多台监控机上
服务器状态监控, 不管使用第三方工具, 还是使用自定义脚本, 都建议部署在专门的监控机上, 远程监视目标机器.
因为: 如果服务器 DOWN 了或者故障了, 可能本机的程序 / 脚本就无法运行了, 又怎么监控呢?
最后
基于上面的监控列表, 还需要将监测工作自动化, 并在发现问题时告警.
来源: http://www.bubuko.com/infodetail-2700330.html