集群监控和巡检

集群监控

命令功能：

查看 AntDB 集群中指定节点名字或者指定节点类型的运行状态。Monitor 命令的返回值共有两种：

running：指节点正在运行且接受新的连接；

not running：指节点不在运行；

具体功能可通过帮助命令 \h monitor 查看。

命令格式：

查看节点的运行状态

MONITOR [ ALL ] 
MONITOR GTMCOORD [ ALL ] 
MONITOR GTMCOORD { MASTER | SLAVE } [ ALL | node_name ] 
MONITOR COORDINATOR { MASTER | SLAVE } [ ALL | node_name [, ...] ] 
MONITOR DATANODE [ ALL ] 
MONITOR DATANODE { MASTER | SLAVE } [ ALL | node_name [, ...] ] 
MONITOR ZONE zonename 

查看 agent 的运行状态

MONITOR AGENT [ ALL | host_name [, ...] ] 

查看主备流复制的状态

MONITOR HA 
MONITOR HA [ ( option ) ] [ node_name [, ...] ] 
MONITOR HA ZONE zonename 

命令举例：

-- 查看当前ADB集群中所有节点的运行状态： 
MONITOR ALL; 
-- 查看当前集群中所有coordinator节点的运行状态： 
MONITOR COORDINATOR ALL; 
-- 查看当前集群中节点类型为datanode master，节点名字为db1和db2的运行状态： 
MONITOR DATANODE MASTER db1,db2; 
-- 查看集群agent状态： 
MONITOR agent ; 
-- 查看集群流复制状态： 
MONITOR ha; 

集群启动和停止

启动

命令功能：

启动指定的节点名字的集群节点，或者启动指定节点类型的所有集群节点。具体功能可通过帮助命令 \h start 查看。

命令格式：

启动集群中的节点：

START ALL 
START GTMCOORD ALL 
START GTMCOORD { MASTER | SLAVE } node_name 
START COORDINATOR [ MASTER | SLAVE ] ALL 
START COORDINATOR { MASTER | SLAVE } node_name [, ...] 
START DATANODE ALL 
START DATANODE { MASTER | SLAVE } { ALL | node_name [, ...] } 
START ZONE zonename 

启动 agent：

START AGENT { ALL | host_name [, ...] } [ PASSWORD passwd ] 

命令举例：

-- 启动集群中所有节点： 
START ALL; 
-- 启动gtmcoord master节点： 
START GTMCOORD MASTER gc; 
-- 启动当前集群中节点类型为datanode master，名字为db1和db2的节点： 
START DATANODE MASTER db1,db2; 
-- 启动集群主机上的agent： 
START AGENT all; 

停止

命令功能：

此命令与 START 命令相反，停止指定名字的节点，或者停止指定节点类型的所有集群节点。

STOP 命令如果没有指定 MODE，默认使用 smart 模式。

STOP 模式有三种：smart ，fast 和 immediate。

• Smart：拒绝新的连接，一直等老连接执行结束。
• Fast：拒绝新的连接，断开老的连接，是比较安全的停止节点的模式。
• Immediate：所有数据库连接被中断，用于紧急情况下停止节点。

具体功能可通过帮助命令 \h stop 查看。

命令格式：

STOP ALL [ stop_mode ] 
STOP AGENT { ALL | host_name [, ...] } 
STOP COORDINATOR [ MASTER | SLAVE ] ALL [ stop_mode ] 
STOP COORDINATOR { MASTER | SLAVE } { node_name [, ...] } [ stop_mode ] 
STOP DATANODE ALL [ stop_mode ] 
STOP DATANODE { MASTER | SLAVE } { ALL | node_name [, ...] } [ stop_mode ] 
STOP GTMCOORD ALL [ stop_mode ] 
STOP GTMCOORD { MASTER | SLAVE } node_name [ stop_mode ] 
STOP ZONE zonename [ stop_mode ] 
where stop_mode can be one of: 
 
    MODE SMART     | MODE S 
    MODE FAST      | MODE F 
    MODE IMMEDIATE | MODE I 

命令举例：

-- 使用fast模式停止集群中所有节点： 
STOP ALL MODE FAST; 
-- 使用immediate模式停止所有coordinator节点： 
STOP COORDINATOR ALL MODE IMMEDIATE; 
-- 使用smart模式停止当前集群中节点类型为datanode master，名字为db1和db2的节点： 
STOP DATANODE MASTER db1,db2; 或者 
STOP DATANODE MASTER db1,db2 MODE SMART;	 
-- 停止集群主机上的agent： 
STOP AGENT all; 

巡检工具

AntDB 提供巡检工具对当前数据库进行巡检。

该工具提供 Linux x86 和 Windows x86 两种环境下的二进制运行软件。

使用帮助如下：

[root@adb01 atool]# ./adb_tool_linux_x64 -h
Usage of ./adb_tool_linux_x64:
  -adblog int
        检查AntDB数据库日志中ERROR|FATAL|PANIC级别的信息并输出：0:默认不启用 1:启用
        该参数当adbtype设置为集中式版本时无效
  -adbtype int
        AntDB类型：0（默认集中式版本） 1（分布式版本）
  -command string
        节点执行OS的命令：默认ls -l
        该参数和oscmd一起使用 （default "ls -l"）
  -dbname string
        数据库名称 （default "postgres"）
  -host string
        主机IP（分布式版本连接GTMC节点） （default "10.1.194.37"）
  -oscmd int
        节点执行OS命令：0:默认不启用 1:启用
        该参数启用后其他参数均无效
  -password string
        用户密码 （default "123123"）
  -port int
        数据库端口 （default 6432）
  -querynode int
        分布式版本查询节点:0（默认CN&GTM） 1(DN) 2(ALL)
        该参数当adbtype设置为集中式版本时无效
        该参数在分布式版本生成巡检报告时无效
  -sqltext string
        执行的SQL语句，默认为空代表的是生成巡检报告
        不为空代表的是执行输入的SQL语句
  -user string
        数据库用户 （default "antdb"）

生成巡检报告使用示例如下：

./adb_tool_linux_x64 -host 10.1.194.37 -port 6432 -dbname tpcc -adbtype 1  -user antdb -password "123123" -querynode 1 > report.log 

通过查看日志，检查数据库的整体状态。

监控要点说明

节点相关

节点运行状态

监控原因： 节点状态的正常与否，是保证集群运行的关键指标，也是数据库健康状态重要指标。以下提供分布式和集中式命令行方式查看节运行点状态。

mgr 节点查看，需要关注 cn、dn、gtm 节点的运行状态，以下为不考虑高可用情况下使用 monitor all 查看各个节点情况。

CN 节点的异常，影响该 cn 上的连接；

DN 节点的异常，影响数据完整性；

GTM 节点的异常，影响数据库事务号分配正常情况。

antdb=# monitor all;
WARNING:  dn0 is datanode master, it has no synchronous node.
WARNING:  dn1 is datanode master, it has no synchronous node.
WARNING:  dn2 is datanode master, it has no synchronous node.
 nodename |      nodetype      | status | description |     host     | port | recovery |           boot time           | nodezone
----------+--------------------+--------+-------------+--------------+------+----------+-------------------------------+----------
 gc_1     | gtmcoord master    | t      | running     | 10.1.206.128 | 2239 | false    | 2023-10-25 10:45:59.360813+08 | local
 gc_2     | gtmcoord slave     | t      | running     | 10.1.206.129 | 2250 | true     | 2023-10-25 10:45:08.516375+08 | local
 cn1      | coordinator master | t      | running     | 10.1.206.128 | 2231 | false    | 2023-10-25 10:46:01.433491+08 | local
 cn2      | coordinator master | t      | running     | 10.1.206.129 | 2232 | false    | 2023-10-25 10:45:09.559234+08 | local
 dn0      | datanode master    | t      | running     | 10.1.206.128 | 2233 | false    | 2023-10-25 10:46:02.482427+08 | local
 dn1      | datanode master    | t      | running     | 10.1.206.128 | 2235 | false    | 2023-10-25 10:46:02.474643+08 | local
 dn2      | datanode master    | t      | running     | 10.1.206.128 | 2237 | false    | 2023-10-25 10:46:02.500351+08 | local
(7 rows)

主从状态、主从延迟

监控原因： 在生产环境上，为了保证数据的安全性和高可用性，对为数据库配置主、从库来保证这一点。而主库与从库之间数据通过流复制、同步 wal 日志保证数据的实时一致，复制槽状态异常，会导致 wal 日志无法及时同步到备库。因此主从状态和主从延迟的监控，是保障主库故障后，备库能够顺利切换为主库，且数据与主库一致，保证业务继续进行的关键。

主从状态：确认主、从之间复制槽存在，多个从库情况下复制槽数量正确，且状态正常。

主从延迟：主、从之间保证 0 延迟。

查看复制槽数量及状态，在对应的主节点执行：SELECT pg_wal_lsn_diff(pg_current_wal_lsn(),restart_lsn)lag,* FROM pg_replication_slots

# dn主节点执行：
antdb=# SELECT pg_wal_lsn_diff(pg_current_wal_lsn(),restart_lsn)lag,* FROM pg_replication_slots;
 lag | slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | con
firmed_flush_lsn | wal_status | safe_wal_size
-----+-----------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+----
-----------------+------------+---------------
   0 | dn0_1     |        | physical  |        |          | f         | t      |    1614742 |      |              | 0/4000060   |
                 | reserved   |
(1 row)

该 SQL 能够查看复制槽状态，wal 日志落后的大小，同步的 LSN。

• lag：表示主备延迟，等于0 或者无限接近于 0
• slot_name：表示复制槽的名称
• active：表示复制槽状态（t 为正常状态）
• restart_lsn：应该与主库此时的 lsn 保持一致

空闲事务会话数

监控原因： AntDB 数据库采用的是多进程的模型，每一个连接都对应一个后端进程，系统会为每一个后端进程分配系统资源，如内存（通过 work_mem 控制）。空闲的事务会话，一个会占用系统资源，一个会占用数据库最大连接数的空位，大量的空闲事务会话会导致系统内存无效占用，连接数被无效占用。一般产生原因是连接池配置不当导致连接在使用后没有正确释放、代码中没有正确地关闭数据库连接或者没有正确提交或回滚事务、数据库连接超时设置不合理等等。

相关查看命令:

SELECT * FROM pg_stat_activity WHERE (state = 'idle in transaction') AND xact_start is NOT NULL;

执行方式： 分布式数据库在 CN 节点和 GTM 节点执行。

等待事务会话数

监控原因： 等待事务的产生是由于需要操作的目标对象上存在有锁，与当前操作所需要获取的锁产生锁冲突、锁竞争、死锁、系统资源达到极限等等。等待事务过多，反馈到前端业务现象就是 sql 执行时间长、sql 执行失败，同样会占用内存和连接数。

相关查看命令：

SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event is NOT NULL;

执行方式： 分布式数据库在 CN 节点和 GTM 节点执行

连接数

产生原因： 初始状态下的数据连接数是设置了最大连接数，如果连接数满了，其他连接无法连接到数据库。

相关查看命令：

SELECT (SELECT setting AS "最大连接数" FROM pg_settings WHERE name='max_connections'),
(SELECT count(*)::text AS "当前连接数" FROM pg_stat_activity),
(SELECT count(*)::text AS "活跃连接数" FROM pg_stat_activity WHERE state <> 'idle'),
(SELECT (SELECT count(*)::int AS  "当前连接数" FROM pg_stat_activity)/(SELECT setting::int FROM pg_settings WHERE name='max_connections')::float8 * 100 AS "当前连接数/最大连接数(%)");

执行方式： 分布式数据库在 CN 节点和 GTM 节点执行。

进程

AntDB 是进程架构的数据库，即每个连接就是一个进程。初始状态的 AntDB，有这么些工作进程：

• /home/antdb/app/bin/postgres -D /home/antdb/master：主进程
• postgres: walsender [local] streaming 0/45927840：流复制进程
• postgres: checkpointer：做检查点的进程
• postgres: background writer：定期把共享内存中的数据刷到磁盘内的进程
• postgres: walwriter：写 WAL 日志的进程
• postgres: autovacuum launcher：自动垃圾回收的进程
• postgres: stats collector：统计信息收集进程
• postgres: logical replication launcher：逻辑复制进程

备注：所以通过 ps -ef | grep postgres 可以看 OS 层面有哪些 AntDB 的进程。

连接

在数据库内部如何查看连接状态呢？通过 pg_stat_activity 这个系统视图可以观察。可以通过这个系统视图去统计连接数，观察连接的状态，每个连接当前正在执行的 SQL 文本等等的信息。

连接包含的状态如下：

• active：后端正在执行一个查询
• idle：后端正在等待一个新的客户端命令（空闲连接）
• idle in transaction：后端在一个事务中，但是当前没有正在执行一个查询（空闲事务连接）
• idle in transaction (aborted)：这个状态与 idle in transaction 相似，不过在该事务中的一个语句导致了一个错误
• fastpath function call：后端正在执行一个 fast-path 函数
• disabled：如果在这个后端中 track_activities 被禁用，则报告这个状态

前四种比较常见，其中 idle in transaction 和 idle in transaction (aborted) 状态需要注意，前者表示事务在等待 commit/rollback，后者表示事务发生了错误，需要 rollback。如果有大量连接长时间处于这种状态，会影响数据库整体的运行状态。

Kill 数据库连接：

AntDB 提供了 2 个函数，用于 kill 连接：

• SELECT pg_cancel_backend(pid)
• SELECT pg_terminate_backend(pid)

前者只能取消正在执行的查询，后者是中断一个后端连接。函数的入参都是进程号，可以通过 pg_stat_activity 来找。

注意： AntDB 不可以在 OS 层面通过 kill -9 pid 来杀连接，这有一定的概率会导致数据库重启。

数据库对象相关

表膨胀

监控原因： 在更新数据时，是不直接删除老数据的。一个 update 操作执行后，被更改的数据的旧版本也被保留下来，直到对表做 vacuum 操作的时候，才考虑回收旧版本。做数据更新时，这些旧版本不及时回收就会造成表膨胀，比如全表的 update 操作、大量的 insert+delete 操作、长事务、未决事务、复制槽等待都会引用表膨胀。表膨胀会占用大量存储空间，并且当执行 sql，遍历数据的元组时，会耗费更多的时间，产生额外的不必要的 IO 负载。

相关查看命令：

SELECT  schemaname||'.'||relname AS table_name,
    pg_size_pretty(pg_relation_size(schemaname||'.'||relname)) AS table_size,
    n_dead_tup,
    n_live_tup,
    round(n_dead_tup * 100 / (n_live_tup + n_dead_tup),2) AS dead_tup_ratio FROM pg_stat_all_tables
    WHERE
    n_dead_tup >= 1000
    ORDER BY dead_tup_ratio DESC
    LIMIT 10;

备注：N_DEAD_TUP 越大，代表该表 update 、delete 操作较多，即表的碎片垃圾越多，表膨胀的越厉害

表倾斜

监控原因： 在分布式环境中，表倾斜则意味着数据分布不均匀，一个节点或者几个节点上存储了整张表的大部分数据，产生的后果就是压力集中到了数据倾斜的这几个节点上，前端的现象则是 sql 执行缓慢，随着数据量的增大，数据倾斜的这几个节点磁盘占用率高出其他节点。

相关查看命令：

新建两张统计表：

CREATE TABLE table_name_statistics (tablename text);
CREATE TABLE table_st(table_name text,dn1 int,dn2 int,dn3 int); 

以三个 dn 为例执行下面脚本开始统计。

使用说明：需要在脚本中修改数据库连接信息，该脚本可以获取所有表在 dn 节点上的数据分布条数，对比各个 dn 节点上的数据条数来确认是否出现严重数据倾斜。

#!/bin/bash

# PostgreSQL连接信息
DB_HOST="***"
DB_PORT="15432"
DB_NAME="***"
DB_USER="***"
DB_PASSWORD="***"

# 查询A表的记录
query="SELECT tablename FROM table_name_statistics;"
result=$(psql -h $DB_HOST -p $DB_PORT -d $DB_NAME -U $DB_USER -c "$query" -t)

# 逐行处理查询结果
while read -r table_name; do
  # 构建查询语句，查询对应表的数据行数
  count_query="SELECT COUNT(*) FROM $table_name;"
  row_count=$(psql -h $DB_HOST -p $DB_PORT -d $DB_NAME -U $DB_USER -c "execute direct on(dn1) '$count_query'" -t)
  row_count2=$(psql -h $DB_HOST -p $DB_PORT -d $DB_NAME -U $DB_USER -c "execute direct on(dn2) '$count_query'" -t)
  row_count3=$(psql -h $DB_HOST -p $DB_PORT -d $DB_NAME -U $DB_USER -c "execute direct on(dn3) '$count_query'" -t)
  # 将结果插入到B表中
  insert_query="INSERT INTO table_st (table_name,dn1,dn2,dn3) VALUES ('$table_name',$row_count,$row_count2,$row_count3);"
  psql -h $DB_HOST -p $DB_PORT -d $DB_NAME -U $DB_USER -c "$insert_query"
done <<< "$result"

索引有效性

监控原因： 如果索引所基于的表上 DML 操作频繁（在索引所在的列），那么随着时间的推移，索引的效率可能会变得越来越差，导致部分 sql 不走索引反而比走索引还快。

相关查看命令：

SELECT * FROM pg_stat_all_indexes WHERE schemaname = '***' AND relname = '***'

这个 SQL 可以查看目标表上有哪些索引，和索引的使用情况。输出结果中反馈了该表上索引名和索引扫描次数，对于没必要的索引会占用空间，建议删除，其他情况按对应 sql 结合分析。

死锁检查

监控原因： 死锁通常发生在同时进行多个事务的并发环境中。当多个事务都持有某些资源，并且都等待其他事务释放它们所需的资源时，死锁就会发生。死锁会导致以下问题：性能下降：由于事务被阻塞，其他事务可能无法及时完成，导致整个系统的性能下降。数据一致性问题：当死锁发生时，事务可能会在没有完全提交的情况下终止，导致数据一致性问题。

相关查看命令：

SELECT database,relation,sc.relname,pid,mode,granted FROM pg_locks sl LEFT JOIN pg_database sd ON sl.database=sd.oid LEFT JOIN pg_class sc ON sl.relation=sc.oid WHERE pg_backend_pid()<>sl.pid AND granted='f';

执行方式： 分布式数据库在所有 CN 节点和 GTM 主节点进行查询。

数据库年龄

监控原因： 当数据库年龄超过阈值，事务号会发生回卷，此时数据库会报错并且拒绝接受所有连接影响到所有业务的正常进行。根据现场年龄增长情况，设置告警阈值，及时处理。

相关查看命令：

SELECT datname,age(datfrozenxid) FROM pg_database;

执行方式： 分布式数据库在 CN 节点和 GTM 节点。

执行解决办法： 找到年龄最大的表依次对单表进行 vacuum freeze。

SQL 相关

长事务

监控原因：

• 锁定争用： 长事务可能会持有锁定资源，导致其他事务等待。
• 资源泄漏： 长事务可能会占用数据库资源，如内存和磁盘空间，而不释放它们。
• 难以维护： 长事务会增加数据库的复杂性，降低了维护和性能调整的可行性。

产生原因： 复杂查询和操作、事务未提交或回滚、事务内部循环、未释放的锁定、事务可能在等待锁定时保持活动状态，例如，它可能在等待其他事务释放的锁定资源上等待、长时间的数据库连接、异常处理不当、大事务的滞后提交。

相关查看命令：

SELECT pid, backend_start, xact_start, query_start, wait_event, state, backend_xid FROM pg_stat_activity WHERE backend_xid is NOT NULL AND now() - xact_start > interval '1 min';

其中：
backend_start      -- 连接创建时间
xact_start         -- 事务begin时间
query_start        -- 事务中最近的查询开始时间，一个事务内有多个查询时，只记录最近的一个
state              -- 事务状态
backend_xid        -- 当前事务的id，即xid
query	             -- 具体执行的SQL

执行方式： 分布式数据库在 CN 节点和 GTM 节点执行

长连接

监控原因： AntDB 中长连接会影响表中垃圾回收，会导致表的年龄增长无法 freeze，并且会导致表膨胀，并且会占用数据资源。

相关查看命令：

SELECT pid, backend_start, xact_start, query_start, wait_event, state, backend_xid FROM pg_stat_activity WHERE backend_xid is NOT NULL AND now() - xact_start > interval '1 min';

其中：
backend_start      -- 连接创建时间
xact_start         -- 事务begin时间
query_start        -- 事务中最近的查询开始时间，一个事务内有多个查询时，只记录最近的一个
state              -- 事务状态
backend_xid        -- 当前事务的id，即xid

慢查询

监控原因： 当 SQL 书写不规范，会导致笛卡尔积；当索引不生效，就会走全表扫描等等，遇到这种情况某些 SQL 查询就变得异常缓慢，并且耗费大量资源，需要对这些 SQL 进行改写、加索引等等优化措施。

相关查看命令：(前提创建了 pg_stat_statements 插件)

# 最耗IO SQL，单次调用最耗IO SQL TOP 5：
SELECT userid::regrole, dbid, query FROM pg_stat_statements ORDER BY (blk_read_time+blk_write_time)/calls desc limit 5;

# 总最耗IO SQL TOP 5：
SELECT userid::regrole, dbid, query FROM pg_stat_statements ORDER BY (blk_read_time+blk_write_time) desc limit 5;

# 最耗时 SQL，单次调用最耗时 SQL TOP 5：
SELECT userid::regrole, dbid, query FROM pg_stat_statements ORDER BY mean_time desc limit 5;

# 总最耗时 SQL TOP 5：
SELECT userid::regrole, dbid, query FROM pg_stat_statements ORDER BY total_time desc limit 5;

# 可以把这个条件加入到上面的查询中来查看每个sql对应的缓存命中率：
100.0 * shared_blks_hit /nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent

日志

监控原因： 数据库可能在重启、主备切换、wal 日志归档失败等等情况下会抛出 ERROR/FAILD/FATAL 信息，这些信息可能会涉及到数据的安全和数据库的稳定性，比如复制槽缺失、wal 日志归档失败等等，关注这些信息可以及时排除数据库的隐患，同时还需要关注系统的日志，如集中式中的 adbhamgr 和 adbdcs 组件的相关日志就记录在系统日志中。

相对于前面提的资源监控，日志记录的是过去的运行状态。AntDB 环境里面日志分为 2 类，一类是数据库的日志，另一类则是系统日志。

AntDB 日志

分布式数据库一般需要观察 CN 节点、GTM 主节点、DN 主节点、MGR 主节点错误日志。

日志参数：

AntDB 内控制日志输出的参数有这么几个，在部署环境的时候，我们默认会设上这些值：

logging_collector = on            #日志开关，设为 off 的话，数据库就不会产生日志文件了
log_destination = csvlog
log_directory = pg_log
log_truncate_on_rotation = on
log_rotation_age = '7d' 
log_rotation_size = '100MB' 
log_min_messages = error          #控制哪个级别的消息，会输出到日志文件
log_min_error_statement = error   #控制哪个严重级别的SQL错误，会把SQL输出到日志文件
log_duration = off
log_statement = 'ddl'             #控制哪些SQL语句会输出到日志文件

日志格式：

AntDB 的日志都在数据目录的 pg_log 内，后缀 csv 结尾的文件，可以根据文件名中的时间来选择需要的日志文件。日志格式如下：

2023-10-18 10:39:04.953 CST,,,910614,,652f4548.de516,1,,2023-10-18 10:39:04 CST,,0,LOG,00000,"ending log output to stderr",,"Future log output will go to log destination ""csvlog"".",,,,,,,"","postmaster"
2023-10-18 10:39:04.953 CST,,,910614,,652f4548.de516,2,,2023-10-18 10:39:04 CST,,0,LOG,00000,"starting PostgreSQL 13.3 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 7.3.0, 64-bit",,,,,,,,,"","postmaster"

依次分别是：
带毫秒的时间戳、 用户名、 数据库名、 进程 ID、 客户端主机:端口号、 会话 ID、 每个会话的行号、 命令标签、 会话开始时间、 虚拟事务 ID、 普通事务 ID、 错误严重性、 SQLSTATE 代码、 错误消息、 错误消息详情、 提示、 导致错误的内部查询（如果有）、 错误位置所在的字符计数、 错误上下文、 导致错误的用户查询（如果有且被log_min_error_statement启用）、 错误位置所在的字符计数、 在AntDB源代码中错误的位置（如果log_error_verbosity被设置为verbose）以及应用名

系统日志

在发生数据库发生问题的时候，除了数据库本身的日志，也需要注意下系统日志，往往有些错误消息，提示信息会出现在系统日志内。

可以查看下面三种系统日志来获取相关信息（系统日志需要 root 权限（sudo 也可以）才能读取）：

• /var/log/messages：系统日志
• /var/log/secure：用户登录，密码认证等安全相关的日志
• /var/log/cron：crontab 任务的日志

相关命令：

# 在日志目录执行：
grep -rn "ERROR" ***.CSV  、 grep -rn "FAILD" ***.CSV  、 grep -rn "FATAL" ***.CSV

操作系统

资源监控

监控原因： 例如磁盘的空间满，会导致数据库无法执行 SQL，一般都是因为数据激增或者出现笛卡尔积，内存已经放不下这部分数据，开始往磁盘上写临时文件；例如 cpu\内存\磁盘过载，会影响数据库的性能，甚至是数据库的稳定性，例如高耗 sql 一直循环重复多次调用、长连接不释放、同一时间段并发激增。

相关命令：

CPU：vmstat ，sar –u，top
磁盘IO：iostat –xd，sar –d，top
网络IO：iftop -n，ifstat，dstat –nt，sar -n DEV 2 3
磁盘容量：df –h 
内存使用：free –m，top或者使用dstat -c -d -g -m -n -p -r -s，该命令整合了vmstat，iostat和ifstat三种命令

dstat命令详解：dstat 是一款非常好用的终端工具，它能够实时监控系统各项资源使用情况，包括 CPU、内存、磁盘、网络等方面
选项：
-c: 显示cpu相关信息
-C #,#,...,total
-d: 显示disk相关信息
-D total,sda,sdb,...
-g：显示page相关统计数据
-m: 显示memory相关统计数据
-n: 显示network相关统计数据
-s: 显示swapped相关的统计数据
--top-cpu：显示最占用CPU的进程
--top-io: 显示最占用io的进程
--top-mem: 显示最占用内存的进程
--top-latency: 显示延迟最大的进程
--raw：显示裸套接字
--socket：套接字
--ipc：进程间通信信息
-p: 显示process相关统计数据
-r: 显示io请求相关的统计数据

监控指标常用系统视图

pg_replication_slots 视图提供了当前存在于数据库集簇上的所 有复制槽的列表，其中也包括复制槽的当前状态。（下表列举了一些相关列）

名称	类型	引用	描述
slot_name	name		一个唯一的、集簇范围内的复制槽标识符
plugin	name		包含这个逻辑槽正在使用的输出插件的共享对象基础名称，对于物理槽为空值。
slot_type	text		槽类型 - physical 或者 logical
datoid	oid	pg_database.oid	与这个槽相关的数据库的 OID，或者为空值。只有逻辑槽具有相关的数据库。
database	name	pg_database.datname	与这个槽相关的数据库的名称，或者为空值。只有逻辑槽具有相关的数据库。
active	bool		如果这个槽当前正在被使用则为真
active_pid	Int4		如果槽当前正在被使用，则记录使用这个槽的会话的进程 ID。如果不活动则为 NULL。
xmin	xid		这个槽要需要数据库保留的最旧事务。VACUUM 不能移除被其后续事务删除的元组。
catalog_xmin	xid		这个槽要需要数据库保留的影响系统目录的最旧事务。VACUUM 不能移除被其后续事务删除的目录元组。
restart_lsn	pg_lsn		可能仍被这个槽的消费者要求的最旧 WAL 地址（LSN），并且因此不会在检查点期间自动被移除。 如果这个槽的 LSN 从未被保留过，则为 NULL。

pg_stat_replication 记录复制的相关信息，包括复制用的用户名，复制类型，同步状态等。（下表列举了一些相关列）

列	类型	描述
pid	integer	一个 WAL 发送进程的进程 ID
usesysid	oid	登录到这个 WAL 发送进程的用户的 OID
usename	name	登录到这个 WAL 发送进程的用户的名称
application_name	text	连接到这个 WAL 发送进程的应用的名称
client_addr	inet	连接到这个 WAL 发送进程的客户端的 IP 地址。 如果这个域为空，它表示该客户端通过服务器机器上的一个 Unix 套接字连接。
client_hostname	text	连接上的客户端的主机名，由一次对 client_addr 的逆向 DNS 查找报告。 这个域将只对 IP 连接非空，并且只有在 log_hostname 被启用时非空。
client_port	integer	客户端用来与这个 WAL 发送进程通讯的 TCP 端口号，如果使用 Unix 套接字则为 -1
backend_start	timestamp with time zone	这个进程开始的时间，即客户端是何时连接到这个 WAL 发送进程的。
backend_xmin	xid	由 hot_standby_feedback 报告的这个后备机的 xmin 水平线。
state	text	当前的 WAL 发送进程状态。
sent_lsn	pg_lsn	在这个连接上发送的最后一个预写式日志的位置
write_lsn	pg_lsn	被这个后备服务器写入到磁盘的最后一个预写式日志的位置
flush_lsn	pg_lsn	被这个后备服务器刷入到磁盘的最后一个预写式日志的位置
replay_lsn	pg_lsn	被重放到这个后备服务器上的数据库中的最后一个预写式日志的位置
sync_priority	integer	在基于优先的同步复制中，这台后备服务器被选为同步后备的优先级。在基于规定数量的同步复制中，这个值没有效果。
sync_state	text	这一台后备服务器的同步状态。

pg_stat_activity 每一个服务器进程有一行， 显示与该进程的当前活动相关的信息。（下表列举了一些相关列）

列	类型	描述
datid	oid	这个后端连接到的数据库的 OID
datname	name	这个后端连接到的数据库的名称
pid	integer	这个后端的进程 ID
usesysid	oid	登录到这个后端的用户的 OID
usename	name	登录到这个后端的用户的 OID
application_name	text	连接到这个后端的应用的名称
client_addr	inet	连接到这个后端的客户端的 IP 地址。如果这个字段为空，它表示客户端通过服务器机器上的一个 Unix 套接字连接或者这是一个内部进程，如自动清理。
client_hostname	text	已连接的客户端的主机名，由 client_addr 的反向 DNS 查找报告。 这个字段将只对 IP 连接非空，并且只有 log_hostname 被启用时才会非空。
client_port	integer	客户端用于与此后端通信的 TCP 端口号，如果使用 Unix 套接字，则为 -1。如果该字段为空，它表示这是一个内部服务器进程。
backend_start	timestamp with time zone	这个进程被启动的时间。对客户端后端来说，这就是客户端连接到服务器的时间。
xact_start	timestamp with time zone	这个进程的当前事务被启动的时间，如果没有活动事务则为空。 如果当前查询是它的第一个事务，这一列等于 query_start 列。
query_start	timestamp with time zone	当前活动查询被开始的时间，如果 state 不是 active，则为上一个查询开始的时间。
state_change	timestamp with time zone	state 上一次被改变的时间
wait_event_type	text	后端等待的事件类型，如果有的话；否则 NULL。
wait_event	text	如果后端当前正在等待，则等待事件名称，否则为 NULL。
state	text	这个后端的当前总体状态。可能的值为： active：后端正在执行一个查询。 idle：后端正在等待一个新的客户端命令。 idle in transaction：后端在一个事务中，但是当前没有正在执行一个查询。 idle in transaction (aborted)：这个状态与 idle in transaction相似，除了在该事务中的一个语句导致了一个错误。 fastpath function ：后端正在执行一个 fast-path 函数。 disabled：如果在这个后端中 track_activities 被禁用，则报告这个状态。
backend_xid	xid	这个后端的顶层事务标识符，如果存在。
backend_xmin	xid	当前后端的 xmin 范围。
query	text	这个后端最近查询的文本。如果 state 为 active，这个字段显示当前正在执行的查询。 在所有其他状态下，它显示上一个被执行的查询。默认情况下，查询文本会被截断至 1024 个字节，这个值可以通过参数 track_activity_query_size 更改。
backend_type	text	当前后端的类型。可能的类型为 autovacuum launcher，autovacuum worker，logical replication launcher，logical replication worker，parallel worker，background writer，client backend，checkpointer，startup，walreceiver，walsender and walwriter。 除此以外，由扩展注册的后台 Worker 可能有额外的类型。

pg_stat_all_tables 记录了每一个表 （包括 TOAST 表）包含一行，该行显示与对该表的访问相关的统计信息。

列	类型	描述
relid	oid	表的 OID
schemaname	name	该表所在的模式的名称
relname	name	这个表的名称
seq_scan	bigint	在此表上启动的顺序扫描数
seq_tup_read	bigint	连续扫描获取的实时行数
idx_scan	bigint	对这个表发起的索引扫描数
idx_tup_fetch	bigint	索引扫描获取的实时行数
n_tup_ins	bigint	插入的行数
n_tup_upd	bigint	更新的行数（包括 HOT 更新的行）
n_tup_del	bigint	删除的行数
n_tup_hot_upd	bigint	HOT 更新的行数（即不需要单独的索引更新）
n_live_tup	bigint	活的行的估计数量
n_dead_tup	bigint	僵死行的估计数量
n_mod_since_analyze	bigint	自上次分析此表以来修改的行的估计数量
n_ins_since_vacuum	bigint	自上次清空此表以来插入的行的估计数量
last_vacuum	timestamp with time zone	最后一次手动清理这个表（不包括 VACUUM FULL）
last_autovacuum	timestamp with time zone	这个表最后一次被自动清理守护进程清理的时间
last_analyze	timestamp with time zone	上一次手动分析这个表
last_autoanalyze	timestamp with time zone	自动清理守护进程最后一次分析这个表
vacuum_count	bigint	这个表被手动清理的次数（VACUUM FULL 不计数）
autovacuum_count	bigint	这个表被 autovacuum 守护进程清理的次数
analyze_count	bigint	手动分析这个表的次数
autoanalyze_count	bigint	这个表被 autovacuum 守护进程分析的次数

pg_stat_all_indexes 记录当前数据库中所有的索引的使用情况

列	类型	描述
relid	oid	对于此索引的表的 OID
indexrelid	oid	这个索引的 OID
schemaname	name	这个索引所在的模式名称
relname	name	这个索引的表的名称
indexrelname	name	这个索引的名称
idx_scan	bigint	在这个索引上开启的索引扫描的数量
idx_tup_read	bigint	扫描此索引返回的索引项数
idx_tup_fetch	bigint	使用此索引进行简单索引扫描获取的活动表行数

pg_locks 提供了数据库服务器上活动进程中保持的锁的信息。

列	类型	描述
locktype	text	可锁对象的类型：relation，extend，frozenid，page，tuple，transactionid，virtualxid，spectoken，object，userlockor advisory。
database	oid	锁目标存在的数据库的 OID，如果目标是一个共享对象则为 0，如果目标是一个事务 ID 则为空
relation	oid	作为锁目标的关系的 OID，如果目标不是一个关系或者只是关系的一部分则此列为空
page	int4	作为锁目标的页在关系中的页号，如果目标不是一个关系页或元组则此列为空
tuple	int2	作为锁目标的元组在页中的元组号，如果目标不是一个元组则此列为空
virtualxid	text	作为锁目标的事务虚拟 ID，如果目标不是一个虚拟事务 ID 则此列为空
transactionid	xid	作为锁目标的事务 ID，如果目标不是一个事务 ID 则此列为空 ID
classid	oid	包含锁目标的系统目录的 OID，如果目标不是一个普通数据库对象则此列为空
objid	oid	锁目标在它的系统目录中的 OID，如果目标不是一个普通数据库对象则为空
objsubid	int2	锁的目标列号（classid 和 objid 指表本身），如果目标是某种其他普通数据库对象则此列为 0，如果目标不是一个普通数据库对象则此列为空
virtualtransaction	text	保持这个锁或者正在等待这个锁的事务的虚拟 ID
pid	int4	保持这个锁或者正在等待这个锁的服务器进程的 PID，如果此锁被一个预备事务所持有则此列为空
mode	text	此进程已持有或者希望持有的锁模式的名称
granted	bool	如果锁已授予则为真，如果锁被等待则为假
fastpath	bool	如果锁通过快速路径获得则为真，通过主锁表获得则为假

pg_stat_statements 服务器所执行的所有 SQL 语句的执行统计信息。

列	类型	描述
userid	oid	执行该语句的用户的 OID
dbid	oid	在其中执行该语句的数据库的 OID
queryid	queryid	内部哈希码，从语句的解析树计算得来
query	text	语句的文本形式
plans	bigint	计划语句的次数（如果启用了 pg_stat_statements.track_planning，否则为零）
total_plan_time	double precision	计划语句所花费的总时间，以毫秒为单位（如果启用了pg_stat_statements.track_planning，否则为零）
min_plan_time	double precision	计划语句所花费的最短时间，以毫秒为单位（如果启用了pg_stat_statements.track_planning，否则为零）
max_plan_time	double precision	计划语句所花费的最长时间，以毫秒为单位（如果启用了pg_stat_statements.track_planning，否则为零）
mean_plan_time	double precision	计划语句所花费的平均时间，以毫秒为单位（如果启用了pg_stat_statements.track_planning，否则为零）
stddev_plan_time	double precision	计划语句花费的时间的总体标准偏差，以毫秒为单位（如果启用了pg_stat_statements.track_planning，否则为零）
calls	bigint	语句被执行的次数
total_exec_time	double precision	执行语句所花费的总时间，以毫秒为单位
min_exec_time	double precision	执行语句所花费的最短时间，以毫秒为单位
max_exec_time	double precision	执行语句所花费的最长时间，以毫秒为单位
mean_exec_time	double precision	执行语句的平均时间，以毫秒为单位
stddev_exec_time	double precision	执行语句花费的时间的总体标准偏差，以毫秒为单位
rows	bigint	语句检索或影响的总行数
shared_blks_hit	bigint	语句的共享块缓存命中总数
shared_blks_read	bigint	语句读取的共享块总数
shared_blks_dirtied	bigint	被语句弄脏的共享块总数
shared_blks_written	bigint	语句写入的临时块总数
blk_read_time	double precision	语句读取块所花费的总时间，以毫秒为单位（如果启用了 track_io_timing，否则为零）
blk_write_time	double precision	语句写入块所花费的总时间，以毫秒为单位（如果启用了 track_io_timing，否则为零）
wal_records	bigint	语句生成的 WAL 记录总数
wal_fpi	bigint	语句生成的 WAL 整页图像总数
wal_bytes	numeric	语句生成的 WAL 字节总数