Postgresql日志收集

PG安装完成后默认不会记录日志,必须修改对应的(${PGDATA}/postgresql.conf)配置才可以,这里只介绍常用的日志配置。

1.logging_collector = on/off  ----  是否将日志重定向至文件中,默认是off(该配置修改后,需要重启DB服务)

DB安装完成,启动的服务进程如下

[[email protected] ~]# ps -elf | grep postgres
0 S postgres  2385     1  0  80   0 - 66829 poll_s 12:41 ?        00:00:00 /opt/pg9.6/bin/postgres -D /mnt/pgdata
1 S postgres  2387  2385  0  80   0 - 66829 ep_pol 12:41 ?        00:00:00 postgres: checkpointer process
1 S postgres  2388  2385  0  80   0 - 66829 ep_pol 12:41 ?        00:00:00 postgres: writer process
1 S postgres  2389  2385  0  80   0 - 66870 ep_pol 12:41 ?        00:00:00 postgres: wal writer process
1 S postgres  2390  2385  0  80   0 - 66952 ep_pol 12:41 ?        00:00:00 postgres: autovacuum launcher process
1 S postgres  2391  2385  0  80   0 - 29643 ep_pol 12:41 ?        00:00:00 postgres: stats collector process

将此配置修改为on,并重启DB服务,DB启动过程中会提示将日志重定向${PGDATA}/pg_log中。

[[email protected] ~]# su -l postgres -c ‘/opt/pg9.6/bin/pg_ctl -D /mnt/pgdata start‘
server starting
LOG:  redirecting log output to logging collector process
HINT:  Future log output will appear in directory "pg_log".

此时在运行的进程如下,与之前相比,多了一个logger进程。

[[email protected] ~]# ps -elf | grep postgres
0 S postgres  2448     1  0  80   0 - 66830 poll_s 12:50 ?        00:00:00 /opt/pg9.6/bin/postgres -D /mnt/pgdata
1 S postgres  2449  2448  0  80   0 - 29645 ep_pol 12:50 ?        00:00:00 postgres: logger process
1 S postgres  2451  2448  0  80   0 - 66830 ep_pol 12:50 ?        00:00:00 postgres: checkpointer process
1 S postgres  2452  2448  0  80   0 - 66830 ep_pol 12:50 ?        00:00:00 postgres: writer process
1 S postgres  2453  2448  0  80   0 - 66871 ep_pol 12:50 ?        00:00:00 postgres: wal writer process
1 S postgres  2454  2448  0  80   0 - 66953 ep_pol 12:50 ?        00:00:00 postgres: autovacuum launcher process
1 S postgres  2455  2448  0  80   0 - 29644 ep_pol 12:50 ?        00:00:00 postgres: stats collector process   

以下配置修改不需要重启服务,只需重载配置

[[email protected] ~]# su -l postgres -c ‘/opt/pg9.6/bin/pg_ctl -D /mnt/pgdata reload‘

2.log_directory = ‘pg_log‘ ---- 日志文件目录,默认是${PGDATA}的相对路径,即${PGDATA}/pg_log,也可以改为绝对路径

默认为${PGDATA}/pg_log,即集群目录下,但是日志文件可能会非常多,建议将日志重定向到其他目录或分区。

将此配置修改为/var/log/pg_log下,必须先创建此目录,并修改权限,如

[[email protected] ~]# mkdir -p /var/log/pg_log
[[email protected] ~]# chown postgres:postgres /var/log/pg_log/
[[email protected] ~]# chmod 700 /var/log/pg_log/

重启DB服务后,日志将重定向至/var/log/pg_log下

[[email protected] ~]# su -l postgres -c ‘/opt/pg9.6/bin/pg_ctl -D /mnt/pgdata start‘
server starting
LOG:  redirecting log output to logging collector process
HINT:  Future log output will appear in directory "/var/log/pg_log".

[[email protected] ~]# ls /var/log/pg_log/
postgresql-2016-06-18_130611.log

3.log_filename = ‘postgresql-%Y-%m-%d_%H%M%S.log‘ ---- 日志文件命名形式,使用默认即可

4. log_rotation_age = 1d ----  单个日志文件的生存期,默认1天,在日志文件大小没有达到log_rotation_size时,一天只生成一个日志文件

5. log_rotation_size = 10MB  ---- 单个日志文件的大小,如果时间没有超过log_rotation_age,一个日志文件最大只能到10M,否则将新生成一个日志文件。

6.log_truncate_on_rotation = off ---- 当日志文件已存在时,该配置如果为off,新生成的日志将在文件尾部追加,如果为on,则会覆盖原来的日志。

7.log_lock_waits = off ---- 控制当一个会话等待时间超过deadlock_timeout而被锁时是否产生一个日志信息。在判断一个锁等待是否会影响性能时是有用的,缺省是off。

8.log_statement = ‘none‘ # none, ddl, mod, all ---- 控制记录哪些SQL语句。none不记录,ddl记录所有数据定义命令,比如CREATE,ALTER,和DROP 语句。mod记录所有ddl语句,加上数据修改语句INSERT,UPDATE等,all记录所有执行的语句,将此配置设置为all可跟踪整个数据库执行的SQL语句。

9.log_duration = off ---- 记录每条SQL语句执行完成消耗的时间,将此配置设置为on,用于统计哪些SQL语句耗时较长。

10.log_min_duration_statement = -1 # -1 is disabled, 0 logs all statements and their durations, > 0 logs only statements running at least this number of milliseconds

-1表示不可用,0将记录所有SQL语句和它们的耗时,>0只记录那些耗时超过(或等于)这个值(ms)的SQL语句。个人更喜欢使用该配置来跟踪那些耗时较长,可能存在性能问题的SQL语句。虽然使用log_statement和log_duration也能够统计SQL语句及耗时,但是SQL语句和耗时统计结果可能相差很多行,或在不同的文件中,但是log_min_duration_statement会将SQL语句和耗时在同一行记录,更方便阅读。

11.log_connections = off ----是否记录连接日志

12.log_disconnections = off ---- 是否记录连接断开日志

13.log_line_prefix = ‘%m %p %u %d %r ‘ ---- 日志输出格式(%m,%p实际意义配置文件中有解释),可根据自己需要设置(能够记录时间,用户名称,数据库名称,客户端IP和端口,方便定位问题)

14.log_timezone = ‘Asia/Shanghai‘ ---- 日志时区,最好和服务器设置同一个时区,方便问题定位

服务器时区设置

[[email protected] ~]# cp -rf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime 
时间: 06-16

Postgresql日志收集的相关文章

Postgresql 日志收集

PG安装完成后默认不会记录日志,必须修改对应的(${PGDATA}/postgresql.conf)配置才可以,这里只介绍常用的日志配置. 1.logging_collector = on/off ---- 是否将日志重定向至文件中,默认是off(该配置修改后,需要重启DB服务) ps -ef | grep postgres postgres 26167 1 1 09:55 ? 00:00:00 /usr/lib/postgresql/9.5/bin/postgres -D /var/lib/p

一共81个,开源大数据处理工具汇总(下),包括日志收集系统/集群管理/RPC等

作者:大数据女神-诺蓝(微信公号:dashujunvshen).本文是36大数据专稿,转载必须标明来源36大数据. 接上一部分:一共81个,开源大数据处理工具汇总(上),第二部分主要收集整理的内容主要有日志收集系统.消息系统.分布式服务.集群管理.RPC.基础设施.搜索引擎.Iaas和监控管理等大数据开源工具. 日志收集系统 一.Facebook Scribe 贡献者:Facebook 简介:Scribe是Facebook开源的日志收集系统,在Facebook内部已经得到大量的应用.它能够从各种

CentOS6.8下使用rsyslog+ldap部署日志服务器来实现日志收集

在我们的运维工作中,常常会对系统上的日志进行收集,手动管理少量的几台服务器的日志收集没有太大难度,但是企业当中批量的管理成千上万台服务器的时候,这时候想一台台的收集日志未免太浪费时间了,这时候我们需要一个批量管理日志的系统来解决这一难题,今天我给大家带来的使用 1.syslog介绍 日志服务在Centos5上位syslog,随着系统版本的升级之后,日志服务改为rsyslog,rsyslog是syslog的升级版,提供了许多高级的特性.syslog由klogd和syslogd组成,klogd记录的

[转载] 一共81个,开源大数据处理工具汇总(下),包括日志收集系统/集群管理/RPC等

原文: http://www.36dsj.com/archives/25042 接上一部分:一共81个,开源大数据处理工具汇总(上),第二部分主要收集整理的内容主要有日志收集系统.消息系统.分布式服务.集群管理.RPC.基础设施.搜索引擎.Iaas和监控管理等大数据开源工具. 日志收集系统 一.Facebook Scribe 贡献者:Facebook 简介:Scribe是Facebook开源的日志收集系统,在Facebook内部已经得到大量的应用.它能够从各种日志源上收集日志,存储到一个中央存储

PostgreSQL 日志配置

在刚安装完的 PostgreSQL 中,通常只需要像下面这样配置日志,并保持其他默认值,就基本可以满足用户大多数需求: # 启动日志收集, 这是一个后台进程,抓取发送到stderr的日志消息,并会将他们重定向到日志文件. logging_collector = on # 日志输出路径,可以是自定义绝对路径或相对于数据目录 PGDATA 的相对路径log_directory = 'log' # 文件名,可以带上格式字符串log_filename = 'postgresql-%a.log' # 当生

日志收集系统 ELK

查看日志一直都是一个很困扰的问题,登录到服务器上查看几百兆的txt文件,从中找到某个问题可能会留下的日志记录......   尤其是现在,在集群式部署的服务器原来越多的时候,找到一个异常记录几乎要翻遍每一台服务器,想想就崩溃了!这个时候就特别希望能有一个集中查看日志的方案来拯救我. 曾经找到一个名为log4Grid的项目,试用了一下.日志数据都保存到mssql数据库中,通过一个web项目来查询显示日志记录.只是实现了基本的日志数据收集和显示,项目没有持续更新,使用起来也不够稳定.不是一个成熟的日

打造高效的运维日志收集与分析平台

0x01 背景      面对与日俱增的日志信息,最传统的日志收集方式已难以满足运维人员的基本需求.So,我们何不利用如今丰富的开源工具来打造一款高效实用的运维日志收集分析平台呢.以下就我们目前尝试在做的运维日志平台进行简要介绍,希望能与各位交流心得经验. 0x02 平台架构     我们并没有采用ELK的架构进行日志收集,而是采用了多款日志收集工具结合的方式,即EKF(K/Z), elasticsearch + kafka-zookeeper + Flume + kibana/zabbix.

用fabric部署维护kle日志收集系统

最近搞了一个logstash kafka elasticsearch kibana 整合部署的日志收集系统.部署参考lagstash + elasticsearch + kibana 3 + kafka 日志管理系统部署 02 上线过程中有一些环节,觉得还是值的大家注意的比如: 1,应用运维和研发人员要讨论一下日志格式的定义, 2,在logstash取日志和消费端logstash消费日志麻.过滤日志的时候怎么要高效,避免服务本身告成系统压力过大,如果每天要处理过亿日志量,性能不注意,哈哈,可以使

Tomcat容器日志收集方案fluentd+elasticsearch+kilbana

在上一遍博文中我们介绍了Nginx容器访问日志收集的方案,我们使用EFK的架构来完成对容器日志内应用日志的收集,如果不知道什么是EFK架构,那么请访问以下链接获取相关的帮助 Nginx容器日志收集方案fluentd+elasticsearch+kilbana 如果你已经认真阅读了上面的链接,并撑握了其用法,那么再来看本博文(针对于初学者),下面假设我们已经搭建好了上一讲所需要的基础环境,我们接下来就直接开始步入正题. 在步入正题之前我们首先需要确认我们需要完成的目标与效果,同样我们在启动Tomc