日志，日志，日志，无论你是IT 的那个LEVEL 都知道，没有日志的系统是有硬伤，POSTGRESQL 的日志在数据库界应该属于上层的，一个错误的日志，包含的事件类型是很全面的，当然这也带出另一个问题，他不像MYSQL 那样将日志分的很细，慢查询的是慢查询，错误是错误，所以一个合适的分析的工具将变得非常重要。
通过 pgbadger 可以对postgresql 的日志进行分析，并且以网页的方式信息展示，还是先给展示一下大致的样子。
可统计的信息很多所以这个pgbadger 的功能也是很丰富的，其中有一个功能要说，他可以弥补上一期监控软件的一个缺失，就是慢查询的问题。当然问题的一个个说。
首先pgbadger 是一个通过日志来分析问题的和展示问题的软件，那我们就的把问题的关键点回归到日志，在多种数据库中，Postgresql的日志可以说是很全面的，并且都在一个日志体系里面体现，这也就为分析日志创造了方便。
那怎么让postgresql 记录更多的日志以便pgbadger 能进行更多的分析展示就是一个问题。
所以还得先说一下，日志的配置
在基于 stderr 的日志并打开了 logging_collector
然后需要对日志的记录进行微调
log_checkpoints = on
log_connections = on
log_disconnections = on
log_lock_waits = on
log_temp_files = 1
log_autovacuum_min_duration = 1
log_error_verbosity = default
Log_min_duration_statement = 1
log_line_prefix = '%t [%p]: [%l-1] user=%u,db=%d,app=%a,client=%h‘
在打开这些开关后，需要重启动数据库
然后直接执行命令生成数据
生成的过程和你的日志的大小有关，所以这里就又得说另外一件事，定期要进行日志的rotate , 保证日志不要太BIG ，导致分析的过程太慢，生成的INDEX.html 文件太大。
上面说过pgbadger 可以最大限度的弥补上一期的监控的分析的缺陷，
其中可以从中获得， 关于connections 的信息
建立连接的中的最大，最小以及平均连接的时间， 每个数据库连接以饼图的方式来进行展示，以每个用户的方式来进行连接展示。同时也可以对session进行同样的分析。这样如果是写周报，就会弥补上一期的monitor software 的一些不足。
另外对checkpoint 的监控也是通过日志中的记录来进行事后分析，其中可以对checkpoint buffers checkpoint files checkpoint warings checkpoint distance 等进行数据的分析和展示
另外对真空/分析分布:显示真空和分析随时间变化的线图，以及消耗CPU处理能力最多的表上的信息给与显示，尤其对目前的PG 来说是重要的，知道目前的vacuum 做的如何。
例如分析每张表，以及tuple 的删除以及每张表的vacuum 和超时的情况。
最后就是锁，与查询的信息了，通过锁与查询的分析，可以找到目前日志文件中这一段时间中最耗时的查询
最后TOP页，可以给出
查询时间直方图，最慢的单个查询，耗时查询:规范化查询及其总持续时间的列表，最频繁查询:一列规范化查询和执行次数，归一化最慢查询:归一化查询及其平均持续时间的列表，等信息。
events 页面也对目前的分析的LOG 本身的信息归属做了一个分析。
PGBADGER 和 上一期的 PGCULL 可能目前的一个问题就是都是英文版本，这一点可能算是一个缺点，除此以外，这两个软件一期基本上可以解决80%以上的性能和突发事件的分析问题。
PGBADGER 的安装会更方便，解压及使用，所以这也是这期根本没说怎么安装的问题。
