postgresql 监控你说了不算，谁说了算 ? (6 监控中需要考虑的问题)

数据库监控,其实是一个收集指标,分析指标,最终得出系统当前状态数据的结果.同时对于关键指标正常的情况和非正常的情况,进行分析最终得出阈值,在触发阈值后开始进行报警. 另外监控还有两个用途:一是用于历史数据分析和展示，帮助我们确定系统的中长期趋势，从而帮助我们计划升级;二是在出现问题时立即采取行动.

一般一个系统监控需要监控的点:

CPU Usage
Network Usage
Disk Space / Disk Utilization
RAM Usage
Disk IOPS
Swap space usage
Network Errors

当然这里并不是一个DB 需要的完整的监控,仅仅是基于数据库系统中的LINUX系统的资源监控.

这里相关的监控就不在展开了. 对于POSTGRESQL 的基本监控有以下几个点

Buffer cache performance (cache hits vs disk reads)
Number of commits
Number of connections
Number of sessions
Checkpoints and bgwriter statistics
Vacuums
Locks
Replication

获得这些信息,有两种途径,

1 通过日志来进行分析

2 通过查询数据库来进行相关的数据获取

关于监控的两种方式,是需要区别的对待的, 我们可以通过以下的两种情况来对采用何种监控

着重于历史性的分析和优化方面的信息, 比较适合使用POSTGRESQL 的日志系统,由于POSTGRESQL 的日志比较完整,所以比较适合进行这方面的数据提取和验证.

另一种则是定时的对数据库中的信息进行收集,这样的数据提取的方式,主要是一方面对短时间的信息趋势进行跟踪,另一方面对触发阈值的指标进行报警.

所以两种监控对应, 目的是不同,操作方式是不同的,数据分析的方式不同,应用的场景也是不同的.

这里我们从PostgreSQL Statistics Collector 来开始PG的monitor 之旅, 类似很多其他的数据库,例如有些数据库有information_schema, perforamnce_schema, sys库, 或者 DMV 动态的监控视图,等等, PG 也有丰富的动态信息收集系统来进行数据库信息的收集工作.

这里也分两种, 一种为系统正在操作的信息, 另一种是从数据库系统开机后系统的累加信息.

Dynamic statistics views

pg_stat_activity、pg_stat_replication、pg_stat_wal_receiver或逻辑状态pg_stat_subscription、pg_stat_ssl和真空状态pg_stat_progress_vacuum的信息。

Collected statistics views

提供有关的INDEX ,序列, wal archive ,表,库,以及后端进程运行的一些信息.

下面我们就可以通过一个事例来看看获得PG当前数据库连接数的几种方式有什么不同.

ps -ef |grep postgres |wc -l

通过上面的命令可以获得访问机器的与POSTGRESQL有用的sessions ,部分监控session就是这样做的, 但实际上这样的监控有一个问题,就是答非所问.