开发者学堂课程【PostgreSQL 快速入门：22 PostgreSQL 监控3PostgreSQL 性能快照和图形化分析工具 pg_stats_info 的使用】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/16/detail/81
22 PostgreSQL 监控3PostgreSQL 性能快照和图形化分析工具 pg_stats_info 的使用
内容介绍
一、简介
二、pg_stats_info 安装
一、简介
本课程讲述 Post 监控第三方插件，也是 pg_stats_info 插件，该插件已经更新到2.5版本，对其进行演示。
网站如下：
http://pgstatsinfo.projects.pgfoundry.org/
在该网站当中的项目称为 pg_stats_info。该项目包括三个部分，首先是 pg_stats_info，用于收集数据库的状态信息，存放到 Databa 当中，该数据库可以用来存放各个 instance 的快照。pg stats reporter，是一个图形化的产生报告的工具。相当于使用 pg_stats_info 产生了报告，存储在数据库当中。
通过 pg stats reporter 生成指定时间段的报告，Reporter 是可以用于生成图形画或文本报告的工具，当前使用较少，该部分用于生成静态页面或文本文件，该文本文件也可以使用 pg_stats_info 提供的命令完成，所以使用较少。
当前使用的较多的是 pg_stats_info 和 pg stats reporter。pg_stats_info 结构如下：
pg_stats_info 作为被监控数据库的worker进程跟随数据库一起启动， 被监控数据库的状态信息定时自动或手动的上传到 repo 数据库. repo 数据库可用和被监控机放一起, 也可以独立使用。对于数据库比较多的环境,建议使用独立的repo 数据库。
下面的三台，是被监控的主机，被监控的主机需要安装 pg_stats_info 插件，该插件会跟随数据库一起启动，启动之后需要进行配置，配置完成之后再启动就会定期或手工抓取被监控的数据数十亿的当前的统计信息以及内存当中的统计信息，及操作系统层面的状态信息，抓取完成之后将其传输至 repository Server 上。可以与该数据库放在一起，也可以单独放在一个数据库当中。该架构图当中 repository database 是单独的服务器。
Pg stats reporter 服务可以将其与 repository database 放在一起，也可以放在另一台服务器上。
当中可以配置连接的 repository database。该架构图当中有三个被监控的数据库实例，数据库实例的镜像都是通过网络传输到集中的一台 repository database 上，用户在该网络上可以连接到 repository database 当中查看报告或者连接到 HTML 的页面查看报告。
Pg_stats_info 的运行机制：
该插件被安装在被监控的数据库主机上，配置完成数据库配置文件之后，要跟随数据库一起启动，存在 Pg_stats_info 进程，该进程类似于 postgre otogeconda launcher 进程，也是 launcher 的进程。
要监控时，就会 fork 给 pg status info d的一个 demo 进程，需要指定参数。参数是已经启动的数据库的主进程的进程号，会自动采集数据库当前的统计信息以及当前的活动，相当于代理。采样之后将其存储到 repository database 当中。
同时还可以 csv log，从 postgre 产生的 csv 日志当中抽取进行解析，解析出性能的报告，例如 Track Point 报告、auto analyze 等性能报告。
转换之后将其存储到 repository database 当中。此处涉及到时间问题，因为 pg_stats_info 在 repository database当中，其中的表都带有时区，在查看报告时，也需要根据时间进行比对，由此涉及到问题：在数据库当中存储的时间以及日志时间，可能会不一致。
例如 csv log，postgre 存在 log time zone 配置，timezone 配置。在 pg_stats_info 当中需要配置正确，否则报告会出问题或无法产生报告。也就是数据可以正常上传到 repository database 当中，但是生成报告时会发现有问题，原因就是时间没有配置正确。服务器时间是亚洲上海时区，timezone 默认配置为 prc，也就是中国时区。
但是 Pg_stats_info 对于 log timezone 只支持 utc，格林威治时间，是0时区。例如中国时区是+8，如果使用 utc，就显示为00，没有间偏移量。以上是需要注意的一点，配置时时间需要配成与主机一样，也就是 timezone 必须和主机相同，例如主机十区是上海，那么就配置为 prc。
Log time zone 一定要配置为 Utc，不能配置为 Prc，以上二者必须配置正确，否则会出现问题。上传到 repository 之后，Pg stats reporter 插件用于从 repository Database 当中生成 HTML 报告，或是生成 text 报告。最下方是监控终端，可以连接到 web 页面，查看生成的报告。
还存在一个 pg_stats_info，可以将原来数据库写在 CSV log 当中的的告警数据，写到另外一个 text 文件或系统的syslog 当中。输入如下代码：
Cd pg_log
11 -pt
数据库产生的 csv 文件位于以下位置：
Postgresql-2014-03-08_000000.csv
Pg_stats_info 也会产生过滤文件，会将其放入其中。该文件可以用第三方监控的中间件，进行监控该文件，该文件有信息时，插件就会进行报告。一个启动了 Pg_stats_info 插件的数据库进程列表举例：
pg93
17471
1 0 07:34 pts/1
00:00:05 /home/pg93/pcsq19. 3. 3/bin/postgres
pε93
17472 17471 0 07:34 pts/1
00:00:00 postgres: pa statsinfo launcher pr ocess
pgg93
17473 17471 0 07:34 ?
00:00:00 postgres: loger process
pg93
17475 17471 0 07:34 ?
00:00:25 postgres: checkpointer process
pg93
17476 17471
0 07:34 ?
00:00:24 postgres: writer process
pg93
17477 17471 3 07:34 ?
00:03:16 postgres: wal writer process
pg93
17478 17471 0 07:34 ?
00:00:04 postgres: autovacuwn launcher pr ocess
pg93
17479 17471 0 07:34 ?
00:00:03 postgres: archiver pr ocess
last was 0000001000001 000000076
pc93
17480 17471 0 07:34 ?
00:00:16 postgres: stats collector process
pε93
17482 17472 0 07:34 pts/1
00:00:08 /home/pg93/pgsq19. 3. 3/bin/pg statsinfod 17471
当中存在两个进程，分别是 Launcher 进程，类似于 auto vacuum launcher。例如此时存在一个表，垃圾数据的预值达到了，需要进行 Vacuum 或 analyze，该进程会创造一个 Autobackend 的 walker 进程，同样 Pg_stats_infor Launcher 进程也类似。
例如用户告知需要启动 pg_stats_info 的自动 agent，就会创造一个进程：Pg_stats_infod 17471，17471是数据库的主进程的 pid，Pid 相同。Pg states Info，负责从数据库获取快照，写入 database，同时过滤 CSV log 当中的信息到另一个文件或 csvlog。csvlog 在 message 文件当中，许多监控插件都可以监控该文件。同时 pg states 进程还可以接收或启动或关闭 agent 信号。
例如：
Pg_stats_info –Start
连接信息是指连接数据库的信息，此时就可以进行连接，从而关闭该进程。
例如关闭 agent 操作：
--stop -h 127.0.0.1 -p 1921 -U postgres
此时会打印信息：
Pg_stats_info Stoppgd
表示该进程关闭。在进行查看时，该进程就不存在。启动操作类似。Pg_stats_info 只要配置完成，之后就可以通过该命令进行启动或关闭 Agent，维护较为方便。
二、Pg_stats_info 安装
环境如下：
被监控数据库版本: PostgreSQL 9.3
repo 数据库版本: PostgreSQL 9.3，位于另一台服务器中。
被监控数据库服务器操作系统:CentOS6.4x64，另外一台是5.6。相当于有两个被监控环境，一个用于存放 repository Database。
被监控服务器和 REPO 服务器时区：+8，三台服务器时区相同。
被监控数据库时区参数: timezone='PRC', log_ timezone='UTC'
Timezone 必须和服务器的时间相同，log_ timezone 必须配置为 utc。
REPO 数据库时区参数: timezone='PRC'，如果 repository Database 也需要被监控，那么时区也需要配置为 utc。
在被监控服务器 REPO服务器的环境中。 保持操作系统的时区，数据库的 timezone 一致。否则可能导致各统计表的采集时间不一致的问题。
首先需要使用以下命令将其下载并安装：
wget http://pgfoundry.org/frs/ download. php/3540/ps statsin£o-2.5.0. tar. gz
3.150是被监控服务器，3.39是存放 repository Database 服务器，3.33是被监控的服务器。
Pg_stats_info 需要在两台服务器当中进行下载，下载完成之后进行解压，解压进目录，接下来执行如下命令：
Export PATH=/home/pg93/pgsql/bin:$PATH
将数据库放在指定目录当中。例如此处使用 pg 93启动数据库，放在 home 当中，需要将home/pg93/pgsql/bin:$PATH 放入路径当中。
因为 pg_stats_info 需要读 Pg Config 的输出。需要得知 Include 文件的位置。执行以上命令就能够输出想要的信息，例如 include 文件位置，lib 库的位置。以上是 pg states info 需要的配置。
接下来执行如下代码：
make USE_ PGXS=1
make USE_ PGXS=1 install
执行完毕即可。配置完成之后，可以在数据库的 pgsql 当中查看动态链接库文件已经生成。同时在 bin 当中生成了三个命令：
root 341269 Mar 4 12:21 Pg_ stats infod
root 982 Mar 4 12 :21 arc hive_ pglog.sh
root 234710 Mar 17 :21 pg_ stats info
安装完成之后，配置 postgre config，需要配置以下内容：
shared_ preload_ libraries = ' pg_stat_ statements.pg
statsinfo'
# (change requires restart)
timezone = ' PRC'
log_ timezone = 'UTC'
log_destination = ' csvlog’
# Valid values are combinations of
logging collector = on
# Enable capturing of stderr and csvlog
Log_checkpoints = on
Log_connections = on
log_disconnections = on
log_error. verbosity = verbose
# terse, default, or verbose messages
Log_statement = ' ddl'
# none, dd1, mod, all
track_ activities = on
track_ counts = on
track_functions = all
# none, pl，all
log _min_messages = log
# values in order of decreasing detail: .
Log_truncate_ on_ rotation = on
#If on, an existing log file with the
首先是 shared_ preload_ libraries，需要统计 SQL 语句的执行统计信息。该插件也需要安装，使用以下命令安装：
create extension
如果没有编译，可以进入 postgre 源代码的目录的 contribute 当中，寻找插件。
此处需要两个链接库：
pg_stat_ statements
pg statsinfo
时区需要配置为 prc，与主机相同，logtimezone 是 UTC，destination 必须是 csv log，如果不是 csv log，需要解析csv log，所以格式必须固定，也就是 postgre 输出的是 csvlog。logging collector 必须打开。
Log_checkpoints 也需要打开。如果不打开就不能够收集 checkpoint 信息。track_activities 和 track_ counts 也必须打开。如果不打开，当前执行的 SQL 语句就无法打印。
Check account 如果不打开，统计信息的计数器就不会打开，就无法统计信息。Check function 如果需要统计函数的统计信息，就要将其打开，否则 pg_stats_info 也无法收集该部分信息。log _min_messages 改为 log，Log_truncate_ on_ rotation 指 csv log 到达一定大小，会自动生成新的日志文件。
以下是 pg states 的配置项：
Pg_ stat_ statements. max = 1000
表示最多配置当前1000条的不同的 SQL 记录。
Pg_stat_statements. track = all
表示统计所有SQL语句。
以下语句与 pg stats for 相关:
pg statsinfo. snapshot_ interval = 10min
表示十分钟抓取一次快照, 传到 repoditory Database 当中。
# set snapshot interval
PG statsinfo. enable_ maintenance =' on'
表示是否允许自动维护。由于快照一直在生成，如果不维护，reposiroru Database 当中将会有许多快照，例如每个快照有100M，所有快照就会有100G。数据会越来越庞大。打开自动维护，每次收集完快照就会自动将以前的快照删除。
# enable maintenance mode(' on’or ' off' )
pg_ statsinfo. maintenance_ tine = '00:02:00
表示在凌晨两点进行快照维护。
# Delete old snapshots every day in this time.
PC_ statsinfo. repository_ keepday = 7
表示快照保留时间是七天，七天以前的快照会在每天凌晨2点进行删除。
# keep old snopshots in this pgriod in maintenance.
pg_ statsinfo. syslog min nessages = ' disable'
由于可以将csvlog解析，输出存储到syslog当中，该配置表示不输出。
PG statsinfo. text1og line_ prefix = '%t %p %c-%I %x %q
(%u，%d， %r，%a)’
# This format is samne as syslog' s format.
表示输出格式，格式可以参看配置文件:
例如%t 表示时间戳，%p 表示进程 ID 。
pg. _statsinfo. syslog line. prefix =
'%t %p %c-%l %x %q(%u, %d, $r，%a)’
# This format is same as syslog s format.
PG statsinfo.1ong 1ock_ threashold = 30
# threethold parmeter for getting LCK information
如果锁的时间超过30秒，就将其记录下来。将该锁示为较为长时间的长锁，会将其记录到快照当中。
pg statsinfo. repository server=' host=172.16.3. 39
port=5432 user=statsrepo dbname=statsrepo'
指 repository Database 所在位置。例如此处被监控的是3.150和3.33，3. 39表示端口，如果不配置密码，此处必须使用 host。如果将密码写入，就可以写为 Hostaddr，Hostaddr 指 IP 地址，Host 可以是 IP 地址，也可以是主机名。由于将会使用到密码文件，所以此处配置为 host。
用户是 statsrepo。配置完成之后，配置密码文件。例如3.35被监控机，输入如下代码：
vi.pgpass
配置完成之后，权限更改为400。
配置完成以上内容。之后，被监控机还存在其他配置项。与 pg_stats_info 插件无关。
接下来配置启动数据库的 os 用户环境变量，确保默认可以直接使用超级用户连接，无需密码。环境变量包含如下：
export PGPORT=1921
export PGDATA=/ssd2/pc93/pa root
export LATG=en_US. utf8
export PGHOME=/home/pg93/pgsql
export LD_ LIBRARY_ _PATH=
$PGHOME/1ib:/lib64:/usr/1ib64:/usr/1oca1/1ib64:/lib:/usr/lib:/usr/1oca1/lib: $ID_LIBRARY_ _PATH
export DATE=' date +"XYXmXd8H3xM*’
export PATH=$ORACLE_ )HOME/bin: $PGHOME/bin:$PATH:
export MANIPATH=$PGHOME/ shar e/ man: $MANPATH
export PGUSER=posteres
export PGHOST=$PGDATA
export PGDATABASE=digoal
注意，必须配置超级用户。因为在启动数据库时，会在 postgre 数据库当中新建 schema，schema 之下还存在一些函数或视图，调用的是如下文件:
Pg_stats_info.sql
该文件就是用于进行连接创建 schema, 聚合的函数或视图。相当于是创建在本地的事务。所以必须使用超级用户，否则启动数据库时，如果是普通用户就会报错：
Pg_stats_info 插件启动有问题。
export PGUSER=posteres 是至关重要的。启动时就不会存在问题。接下来是配置 repository 数据库，如果数据库是独立的，那么新建库和用户即可，也就是3.39，当中要创建一个角色，创建数据库色，需要有登录权限，需要设置密码，可以不是超级用户，但必须要给予权限，同时需要允许其他主机使用该用户连接该数据库。否则如果不能连接，那么快照也无法传送。pg hba 也要打开，时区配置完成，时间与服务器保持一致。
以下文件必须配置正确：
/etc/sysconfig/clock.
例如此时是 assured，是亚洲时间，那么也需要配置为 prc。
在启动安装了 pg_ statsinfo 插件的被监控库时， statsinfo 进程会自动执行 pg_statsrepo_ partition sq| 和 pg_ _statsrepo_ alert.sql。在启动3.150时，将连接配置完成，repository 的连接也配好，还会执行两个文件。那么他其实还会执行两个，除了这个文件之外，他还会执行两个文件：
pg_statsrepo_ partition sq|
pg_statsrepo_ alert.sql
以上两个文件的作用是连接到3.39执行，创建了告警表，如果需要告警，就会需要用到以上两个文件。创建快照的静态表会，包括 instance 表，database 表，表空间统计信息，schema 统计信息，表的统计信息，会自动连接3.39，自动创建表和函数。所以此处只需要普通用户，启动时使用超级用户。接下来可以启动3.150，启动之后会自动执行以下三个脚本：
Pg_states_info.sql
pg_statsrepo_ partition sq|
pg_ statsrepo_ alert.sql
例如需要手动创建快照, 首先连接到 postgre，当中存在 Snap shot 函数执行该函数就会自动创建快照，该快照就会传到3.39当中。如果不手动创建，就会默认按照之前的配置十分钟自动产生一个快照。
使用如下语句查看快照：
Select * from snapshot；
由于配置了3.150和3.33两个实例，分别一分钟传递一个快照。
Snap ID 表示快照 ID，instID 表示实例 ID，通过查询 instance 表就可以查看到有两个实例：
name 是数据库的唯 ID，hostname 是主机名，port 是端口号。Version 是版本， xlog File 的大小。
接下来是配置被监控机的 pg pass。启动 post 数据库的操作系统用户的 home 目录下，也就是连接到 stats repository 当中，如果之前修改了 log time zone，假设之前的 log time zone 是 Prc，现在改为了 UTC，最好进入到目录当中，将 CSVLOG 清除再重新启动。
因为修改了 log time zone，日志文件名会变化，如果不清除，会出现问题，所以最好将其清除之后重启。启动之后就可以手动创建快照。
例如此时创建快照到被监控机：
Select Stats info.snapshot(abc.hello);
此时可以将其进行查询:
Select * from snapshot where Comment=’ abc.hello’;
此时结果中会显示创建时间，创建快照的名字和快照的大小也会将其打印出来。如果快照当中包含了 checkpoint 的信息，可以使用如下语句：
Select * from checkpoint Where instid=1 and start >=’2014-03-08 12:49:53.424401.08’;
由于此次快照当中没有收集到信息，输入如下代码:
Select from checkpoint where inst -t id Order by start desc
limit 1;
结果如下：
时间是47分，收到的日志来自于 CSVlog。查看 CSVlog，结果如下：
相当于不存在。由于日志是 utc 时间，存储带时区，所以需要+8，所以时间刚好是最后收到的一条。例如此时收到的是0.001s，信息从以下内容当中解析：
从 CSVlog 当中解析，存储到 Checkpoint 当中。包括 auto vacuum 以及其他收集的信息都存在当中。以上就是 pg stats 的安装。
如果需要产生报告，可以使用插件 pg Statsinfo 命令行产生 text 的报告。
例如库中，已经产生许多报告，需要生成text报告。当中会提到报告的 ID，例如需要产生包含所有信息的报告，就选择 all，选择之后就会产生所有统计信息。执行如下命令，并且指定开始时间和结束时间：
/home/pg93/pgsql/bin/pg statsinfo -l -h 172 16.3.39 一P
5432 -U statsrepo -d statsrepo |less
-l表示列出有哪些报告，连接之后，需要生成哪个时间段当中的报告，就指定该时间段。
例如指定 snapshot ID，Begin ID 以及结束 ID ，生成报告如下：
去了 Summary 当中包含数据库的状态信息，包括版本、端口，数据库当前大小总共提交次数，总共回滚次数。接下来是每个数据库的统计信息。
例如 postgre 是22M，block read 当中 disk 的百分比和单纯的disk百分比。
接下来是 disk 和 read 的总共秒数，数据库的大小的增量是193，也就是从166个块增长到170个块，总共增长了193M，提交效率是每秒三万多次提交，Catch 的命中率是97%，io的速率，每秒读出的行数。
以上内容都是对于单个库的统计信息显示。接下来是事务的统计信息，
如图所示：
首先数据库的提交是每秒三万多次，其他几乎为零。通过以上数据能够得出哪些库较为繁忙。以下是数据库的大小：
列出了第166个快照和第170个快照的大小，能够看出只有第一个库有增长。以下是 recovery conflict 统计信息：
都为0。
Wl 的统计信息：
WAL Write Total
449.626 MiB
WAL Write Speed
494 MiB/s
统计信息包括每秒写入个数，每秒大概写七兆统计日志。从166~170快照，总共写了四百多兆日志。Instance progress 统计信息如下：
比如idls状态的百分比，Running 状态的百分比。以上也是两个快照之间的对比。
操作系统层面的资源使用情况：
例如 CPU 的使用以及负载，有三个负载，平均负载是0.2。io关联到表空间，例如 SDE1设备，对应到两个表空间，分别是 pg global，pg default， total write 有1G多，total write time 也有统计。可以看出较为繁忙的设备，此处只有一个设备输出，因为与数据库相关的只有一个快设备。以下是内存统计：
空闲内存数量，buffer 数量，交换分区的使用以及脏页面等使用情况。
磁盘情况如下：
设备是 md 表述。内容包括表空间的使用情况，目录使用情况，可用空间，剩余空间，此处剩余90%，分区的大小450g，使用了27g，剩余百分之九十四，test 表磁盘的分布如下：
包括表的大小是12g， total read，索引。
事务：
例如 autocacuum 事务，执行了1s多，发生在9:00。
需要注意的表：
较繁忙，按照排名进行排序。例如 test 表，insert 插入了2032159次，也就是从166到第170个快照，insert 了203万多行，后面是其他的信息。
碎片：
也就是哪些表存在顺态，例如第一张表的顺序是0.122。意义不大，假设需要通过索引扫描大量数据，索引状态不好，如果没有进行排序，扫描时就会进行离散扫描数据快，会带来 io 负载。读取时就能够多读一些，对业务做匹配。
观察以上表格需要结合业务逻辑和执行计划。
Checkpoint activity：
指的是两个快照之间总共产生了多少次 checkpoint，包括写 buffer 总共是多少，总共消耗的时间是多少。
SQL 级别：首先查看函数：
包括调用函数总次数，调用两百多万次。排名最前，如果嵌套其他函数，self time 将会排除其他函数的调用时间，也就是该函数实际执行时间，每一次调用所花费的时间。
Statements:
统计来自于 pg stats statement 插件，插件会记录语句。总共调用的次数，总共花费的时间，每次调用的秒数。如果函数当中写其他 SQL 语句，那么也会被记录下来。SQL 语句并不是直接执行，而是在函数当中直接调用，也会将其记录下来。例如 insert 语句和 update 和 Select。
接下来是所冲突和 replication 信息，最后是 set 信息，配置文件也会将其收集下来，查看当前配置是否发生变更。最后是索引和表的统计信息：
其中包含的内容有表的宽度，列数，大小，两个快照之间的增量，索引扫描次数，索引的统计信息包括索引的大小，索引的增量以及索引被扫描的次数。例如没有用到的索引，扫描次数就是零，有调用次数表示两个快照之间使用到了该索引。以上就是产生的文本报告。如果需要产生图形化报告，可以使用 pg Stats reporter 插件。插件需要依赖一些事物，例如依赖阿帕奇 server，还依赖一些库，这些库已经打包在pg stats源代码当中。例如：
jQuery : 2.0.1
jQuery UI : 1.10.2
jquery-ui-timepicker-addon : 1.3
dygraphs JavaScript Visualization Library : b839102723 (commit ID)
jqPlot : 1.0.8 r1250
tablesorter : 2.0.3
Superfish : 1.7.2
Smarty : 3.1.13
但是都已经打包好，就不需要另外去安装，也不需要另外下载。
PG stats Reporter 安装，该插件无论安装在何处都行。只要能够连到 reppsitory 数据库即可。连接数据库读取当中的函数，利用函数产生报告。图形化报表的工具需要安装如下内容：
http php psql
因为其依赖于以上内容，使用install安装。安装好之后，将其源码包下载。源码包的目录结构当中包括 bin、HTML、pgstats、JavaScript 等样式、依赖的 lib 库，将以上内容放入到 library 库中。安装步骤如下：
tar xvfz PE stats_ reporter' -2.0.0. tar. gz .
cd PE. _stats_ reporter
cd -r html/ps stats_ reporter /var/www/html
cd -r PE _stats_ reporter._1ib /var/www
cd bin/pe stats_ reporter /usr/1ocal/bin
cd /var/www/pe_ stats_ reporter. lib
chown -R apache: apache cache compiled
解压之后将依赖的事务拷贝到其中。由于之前依赖的阿帕奇内容已经安装好，所以可以直接进行拷贝。之后再将lib目录拷贝，接下来将可执行文件拷贝，最后将lib目录权限改为启动 httpd 的目录。
配置pg stats reporter：
cd /var/www/p6 stats_ reporter_ 1ib
cp pg_ stats_ reporter. ini. sample /etc/pa stats_ reporter. ini
cd /etc
vi Pg_stats_ reporter. ini
改完之后生成配置文件。配置文件可以从 library 目录当中的样本文件将样本文件拷贝进行修改。包含以下内容:
首先是 Install directory，库的 section 可以随便写，假设有多个，可以写多个连接。以下是报告内容：
对于数据库连接的事务、密码等。
接下来是 web 页面的语言：
是否统计 summary：
是否统计数据库统计信息，如果均为 true，就表示全部都要统计。如果是 false，就表示不生成该系列报告。
配置完成之后，就可以启动 HTTPd 服务：
Service HTTPd restart.
启动之后就可以进行 web 连接：
连接完成，如图所示：
以上是已经配置完成的状态。
当中需要生成的报告，除了按钮之外，还可以使用直接在 HTTP 当中写参数的方式。
例如，Begin，end，instance 的值。假设需要在 sample 下生成30150报告：
如图所示：
对于信息分块，说明如下：
1.创建新的报告
2. repo 数据库按钮，如果在/etc/pg_ _stats_ _reporter ini 中配置了多个 repo 的话,这里将显示多个。
例如配置了 repository，名称为 smaple：
如果有多个 repository，就会有更多下拉框。白色部分是该 repository 收集的信息。
3.该 repo 数据库中存储的 instance 信息例如一-个 repo 中可以存储多个实例的 snapshot 信息
4.重载/etc/pg_ _stats_ reporter.ini 配置文件，假设修改配置文件，可以点击进行重载。
5. SNAPSHOT 的分类，对于收集信息，需要产生的报告类型。例如3月6日~3月7日，报告如下：
分析事物的统计信息如下：
也就是文本当中输出的信息制作为图形化界面。
例如 CPU 使用：
之前所查看的都是文本信息。
6.隐藏左边栏按钮
7.帮助信息按钮
8.9. 输入需要生产报告的时间段
10.生成报告
以上内容均可在命令行当中输入。
首先查看 repository 大小，目前是2G，因为配置了自动维护。假设存在两个被监控的实例，自动维护二者均保留七天。假设一个自动保留为七天，另一个为五天，结果只会保留五天。因为通过函数做维护，并不是指删除实例的数据，是将整个 Snap shot 删除。无论存放多少实例，一个实例只保留五天，另一个保留的时间比五天多，完成自动维护之后，只剩下五天的快照信息，不会保留七天，因为是统一的。其实质也是通过调用函数，完成目的操作。例如手工执行函数，执行 miantemance，在3月5日9点之前的快照全部删除，只保留3月5日之后的快照。假设更改为19点，维护执行之后就会进行删除。再次进行查看：
Select * from Snapshot order By“time”limit 10；
执行代码之后不会立马完成，因为delete需要时间，动作较慢。稍等片刻就会查看到快照被删除：
最后时间是指定的时间点，在实例一执行，实例二当中也被删除。所以一个配置五天，另一个配置七天，最终也只会剩下五天。
以上是手动配置维护快照的结果，也存在手动创建快照.
以上是 pg_stats 插件的使用，可以自行参考报告进行搭建。
