监控Greenplum系统

    观察Greenplum数据库系统日常的性能有助于管理员理解系统的行为、计划工作流以及故障排查问题。这一章讨论用于监控数据库性能和活动的工具。

    还有，记得回顾推荐的监控和维护任务中编写脚本监控活动来快速检测系统中问题的内容。

    上级主题：

    作为一个Greenplum数据库管理员，必须监控系统的问题时间，例如一个Segment宕机或者在一台Segment主机上磁盘空间耗尽。下面的额主题描述如何监控一个Greenplum数据库系统的健康状况以及检查一个Greenplum数据库系统的特定状态信息。

    可以配置一个Greenplum数据库系统如果发生特定的数据库事件时触发SNMP（简单网络管理协议）告警或者给系统管理员发送email通知。这些事件包括：

    • 所有的PANIC级错误情况
    • 所有的FATAL级错误情况
    • 属于“内部错误”（例如，SIGSEGV错误）的ERROR级错误情况
    • 数据库系统关闭和重启
    • Segment失效和恢复
    • 后备Master不同步情况
    • Master主机人为关闭或者其他软件问题（在特定失效场景中，Greenplum数据库无法发送告警或者通知）

    这个主题包括下列子话题：

    注意SNMP告警和email通知报告的是相同的事件信息。两种工具报告的事件信息之间没有差别。有关SNMP事件信息请见。

    将SNMP用于Greenplum数据库系统

    Greenplum数据库支持SNMP使用MIB（管理信息库）来监控一个Greenplum数据库系统的状态。MIB是描述SNMP可管理实体的对象集合，在这种情况下SNMP可管理实体就是一个Greenplum数据库系统。

    Greenplum数据库的SNMP支持允许一个网络管理系统从同一个端口（161）和IP地址获得有关硬件、操作系统和Greenplum数据库的信息。它还启用Greenplum数据库实例的自动恢复。

    先决条件

    在设置Greenplum数据库上的SNMP支持之前，确保SNMP被安装在Master主机上。如果snmpd文件在/usr/sbin目录中不存在，那么系统上没有安装SNMP。根据运行Greenplum数据库的平台，安装下面的包：

    1. 在SUSE平台上默认会安装SNMP。

    snmp.conf配置文件位于/etc/snmp/中。

    安装前任务

    在Master主机上安装了SNMP之后，以root登录，打开一个文本编辑器并且编辑path_to/snmp/snmpd.conf文件。要在Greenplum数据库中使用SNMP，对snmpd.conf文件所要求的最小配置更改是指定一个团体名称。例如：

    注意： 把public替换为用户的SNMP团体的名称。还应该配置syslocation和syscontact。按环境所需配置其他SNMP设置并且保存该文件。

    更多有关snmpd.conf文件的信息，可以输入：

    注意： 在SUSE Linux平台上，确信检查和配置snmp.conf文件中的安全性设置，这样snmpd接受来自于sub-agent的连接并且返回所有可用的对象ID（OID）。

    在完成配置snmpd.conf文件后，启动系统的snmpd守护进程：

    1. # /sbin/chkconfig snmpd on

    然后，验证系统的snmpd守护进程正在运行。输入：

    1. # snmpwalk -v 1 -c community_name localhost .1.3.6.1.2.1.1.1.0

    例如：

    1. # snmpwalk -v 1 -c public localhost .1.3.6.1.2.1.1.1.0

    如果这个命令返回”Timeout: No Response from localhost”，那么系统的snmpd守护进程没有运行。如果该守护进程正在运行，输出会类似于下面的形式：

    1. 2.6.18-92.el5 #1 SMP Tue Jun 10 18:51:06 EDT 2016 x86_64
    设置SNMP通知

    1. 要配置Greenplum数据库系统在告警发生时发送SNMP通知，在Greenplum数据库的Master主机上用gpconfig工具配置下列参数：

      • gp_snmp_community: 设置这个参数为为环境指定的团体名称。
      • gp_snmp_monitor_address: 输入网络监控器应用的hostname:port。通常，端口号是162。如果有多个监控器地址，将它们用逗号分隔。

      • gp_snmp_use_inform_or_trap: 输入trap或者inform。trap通知是从一个应用发往另一个应用的SNMP消息（例如，在Greenplum数据库和网络监控应用之间）。监控应用不答复这些消息，但是这会产生较少的网络负荷。

        inform通知和trap消息完全相同，不过应用会向生成该告警的应用发送一个确认。在这种情况下，监控应用会向Greenplum数据库发送确认消息。虽然inform消息带来了较多负荷，它们能告知Greenplum数据库监控应用已经收到了通知。

        下面的示例命令使用Greenplum数据库的gpconfig工具设置服务器配置参数：

        1. $ gpconfig -c gp_snmp_community -v public --masteronly 
        2. $ gpconfig -c gp_snmp_monitor_address -v mdw:162 --masteronly 
        3. $ gpconfig -c gp_snmp_use_inform_or_trap -v trap --masteronly

    2. 要测试SNMP通知，可以使用snmptrapd陷阱接收器。作为root输入：

      1. # /usr/sbin/snmptrapd -m ALL -Lf ~/filename.log

      -Lf表示trap被记录到一个文件中。-Le表示trap被记录到stderr。-m ALL载入所有可用的MIB（如果需要还可以指定个别的MIB）。

    启用Email通知

    完成下面的步骤可以让Greenplum数据库在特定数据库事件发生时向系统管理员发送email通知。

    1. 在文本编辑器中打开$MASTER_DATA_DIRECTORY/postgresql.conf。

    2. 在EMAIL ALERTS小节中，去除下面这些参数的注释并且输入合适的emial服务器和域的值。例如：

      1. gp_email_smtp_server='smtp.company.com:25'
      2. gp_email_smtp_userid='gpadmin@example.com'
      3. gp_email_smtp_password='mypassword'
      4. gp_email_from='Greenplum数据库<gpadmin@example.com>'
      5. gp_email_to='dba@example.com;John Smith <jsmith@example.com>'

      可以在email系统中创建专用的email账号或者组从Greenplum数据库系统发送或者接收email告警。例如：

      1. gp_email_from='GPDB Production Instance <gpdb@example.com>'
      2. gp_email_to='gpdb_dba_group@example.com'

      还可以为两个gp_email参数指定多个email地址。使用分号来分隔这些email地址。例如：

      1. gp_email_to='gpdb_dba_group@example.com;admin@example.com'

    4. 重新装载Greenplum数据库的postgresql.conf文件：

      1. $ gpstop -u

    测试Email通知

    Greenplum数据库的Master主机必须能够连接到为gp_email_smtp_server参数指定的SMTP邮件服务器。要测试连通性，使用ping命令：

    1. $ ping my_email_server

    如果Master主机能联系上SMTP服务器，登入到psql并且用下列命令测试email通知：

    1. $ psql postgres
    2. =# SELECT gp_elog('Test GPDB Email',true); gp_elog

    为gp_email_to参数指定的地址应该会收到一封主题为Test GPDB Email的电子邮件。

    还可以使用一个公共SMTP服务器（例如谷歌的Gmail SMTP服务器）和一个外部email地址测试email通知。例如：

    注意： 如果在发送和接收email通知上碰到困难，验证所在机构的email服务器和防火墙的设置。

    检查系统状态

    一个Greenplum数据库系统由横跨多台机器的多个PostgreSQL实例（Master和Segment）构成。要监控一个Greenplum数据库系统，需要了解整个系统的信息以及个体实例的状态信息。gpstate工具提供有关一个Greenplum数据库系统的状态信息。

    查看Master和Segment的状态及配置

    默认的gpstate行为是检查Segment实例并且显示可用和失效Segment的一个简短状态。例如，要快速查看Greenplum数据库系统的状态：

    1. $ gpstate

    要查看Greenplum数据库阵列配置更详细的信息，使用带有-s选项的gpstate：

    1. $ gpstate -s

    查看镜像配置和状态

    如果在使用镜像作为数据冗余，用户可能想要看看系统中的镜像Segment实例列表、它们当前的同步状态以及镜像和主Segment之间的映射。例如，要查看一个系统中的镜像Segment和它们的状态：

    1. $ gpstate -m

    要查看主Segment到镜像Segment的映射：

    1. $ gpstate -c

    要查看后备Master镜像的状态：

    1. $ gpstate -f

    检查磁盘空间使用

    一个数据库管理员最重要的监控任务是确保Master和Segment数据目录所在的文件系统不会增长到超过70%的充满程度。一个充满的数据磁盘不会导致数据损坏，但是可能会阻止正常的数据库活动继续。如果磁盘增长得太满，可能会导致数据库服务器关闭。

    可以使用gp_toolkit管理方案中的gp_disk_free外部表来检查Segment主机文件系统中的剩余空闲空间（以千字节计）。例如：

    1. =# SELECT * FROM gp_toolkit.gp_disk_free 
    2.    ORDER BY dfsegment;

    检查分布式数据库和表的尺寸

    gp_toolkit管理方案包含几个可以用来判断Greenplum数据库的分布式数据库、方案、表或索引磁盘空间使用的视图。

    用于检查数据库对象尺寸和磁盘空间的视图列表，请见Greenplum数据库参考指南。

    查看一个数据库的磁盘空间使用

    要查看一个数据库的总尺寸（以字节计），使用gp_toolkit管理方案中的gp_size_of_database视图。例如：

    1. => SELECT * FROM gp_toolkit.gp_size_of_database
    查看一个表的磁盘空间使用

    gp_toolkit管理方案汇总包含几个检查表尺寸的视图。表尺寸视图根据对象ID（而不是名称）列出表。要根据一个表的名称检查其尺寸，必须在pg_class表中查找关系名称（relname）。例如：

    1. => SELECT relname AS name, sotdsize AS size, sotdtoastsize 
    2.    AS toast, sotdadditionalsize AS other 
    3.    FROM gp_toolkit.gp_size_of_table_disk as sotd, pg_class 
    4.    WHERE sotd.sotdoid=pg_class.oid ORDER BY relname;

    可用的表尺寸视图的列表可见Greenplum数据库参考指南。

    查看索引的磁盘空间使用

    gp_toolkit管理方案包含几个用于检查索引尺寸的视图。要查看一个表上所有索引的总尺寸，使用gp_size_of_all_table_indexes视图。要查看一个特定索引的尺寸，使用gp_size_of_index视图。该索引尺寸视图根据对象ID（而不是名称）列出表和索引。要根据一个索引的名称查看其尺寸，必须在pg_class表中查找关系名称（relname）。例如：

    1. => SELECT soisize, relname as indexname
    2.    FROM pg_class, gp_toolkit.gp_size_of_index
    3.    WHERE pg_class.oid=gp_size_of_index.soioid 
    4.    AND pg_class.relkind='i';

    Greenplum数据库中所有的表都是分布式的，意味着它们的数据被均匀划分到系统中的所有Segment上。不均匀分布的数据可能会削弱查询处理性能。一个表的分布策略在表创建时被确定。有关选择表分布策略的信息，请见下列主题：

    gp_toolkit管理方案还包含一些用于检查表上数据分布倾斜的视图。有关如何检查非均匀数据分布的信息，请见Greenplum数据库参考指南。

    查看一个表的分布键

    要查看一个表中被用作数据分布键的列，可以使用psql中的\d+元命令来检查表的定义。例如：

    1. =# \d+ sales
    2.                 Table "retail.sales"
    3.  Column      |     Type     | Modifiers | Description
    4. -------------+--------------+-----------+-------------
    5.  sale_id     | integer      |           |
    6.  amt         | float        |           |
    7.  date        | date         |           |
    8. Has OIDs: no
    9. Distributed by: (sale_id)

    查看数据分布

    要查看一个表中行的数据分布（每个Segment上的行数），可以运行一个这样的查询：

    1. =# SELECT gp_segment_id, count(*)

    如果所有的Segment都有大致相同的行数，一个表就可以被认为具有平衡的分布。

    检查查询处理倾斜

    当一个查询被处理时，所有的Segment应该具有等量的负载来保证最好的性能。如果发现了一个执行不好的查询，可能需要使用EXPLAIN命令进行深入研究。有关使用EXPLAIN命令和查询画像的信息，请见查询画像。

    如果表的数据分布策略与查询谓词没有很好地匹配，查询处理负载可能会倾斜。要检查处理倾斜，可以运行一个这样的查询：

    1. =# SELECT gp_segment_id, count(*) FROM table_name
    2.    WHERE column='value' GROUP BY gp_segment_id;

    这将显示对于给定的WHERE谓词，Segment会返回的行数。

    避免极度倾斜警告

    当执行一个使用哈希连接操作的查询时，可能会收到下面的警告消息：

    Extreme skew in the innerside of Hashjoin

    当一个哈希连接操作符的输入倾斜时，就会发生这种情况。它不会阻碍查询成功完成。可以按照这些步骤来避免计划中的倾斜：

    1. 确保所有的事实表都被分析过。
    2. 验证该查询用到的任何已填充临时表都被分析过。
    3. 查看该查询的EXPLAIN ANALYZE计划，并且在其中查找以下信息：
      • 如果有带多列过滤的扫描产生超过估计的行数，则将gp_selectivity_damping_factor服务器配置参数的值翻倍并且重新测试该查询。
      • 如果在连接一个相对较小（小于5000行）的单一事实表时发生倾斜，将gp_segments_for_planner服务器配置参数设置为1并且重新测试该查询。
    4. 检查应用于该查询的过滤属性是否匹配基表的分布键。如果过滤属性和分布键相同，考虑用不同的分布键重新分布一些基表。
    5. 检查连接键的基数。如果基数较低，尝试用不同的连接列或者表上额外的过滤属性来重写该查询以降低行数。这些更改可能会改变查询的语义。

    查看数据库对象的元数据信息

    查看最后一个执行的操作

    可以使用系统视图pg_stat_operations和pg_stat_partition_operations查看在一个对象（例如一个表）上执行的动作。例如，要查看在一个表上执行的动作，比如它何时被创建以及它上一次是什么时候被清理和分析：

    1. => SELECT schemaname as schema, objname as table, 
    2.    usename as role, actionname as action, 
    3.    subtype as type, statime as time 
    4.    FROM pg_stat_operations 
    5.    WHERE objname='cust';
    6.  schema | table | role | action  | type  | time
    7. --------+-------+------+---------+-------+--------------------------
    8.   sales | cust  | main | CREATE  | TABLE | 2016-02-09 18:10:07.867977-08
    10.   sales | cust  | main | ANALYZE |       | 2016-02-25 16:07:01.157168-08
    11. (3 rows)

    查看一个对象的定义

    要查看一个对象（例如表或者视图）的定义，在psql中可以使用\d+元命令。例如，要查看一个表的定义：

    查看会话内存使用信息

    可以创建并且使用session_level_memory_consumption视图来查看正在Greenplum数据库上运行查询的会话的当前内存利用信息。该视图包含会话信息以及该会话连接到的数据库、该会话当前运行的查询和会话处理所消耗的内存等信息。

    创建session_level_memory_consumption视图

    要在Greenplum数据库中创建session_level_memory_consumption视图，为每一个数据库运行一次脚本$GPHOME/share/postgresql/contrib/gp_session_state.sql。例如，要在数据库testdb中安装该视图，可使用这个命令：

    1. $ psql -d testdb -f $GPHOME/share/postgresql/contrib/gp_session_state.sql

    session_level_memory_consumption视图

    session_level_memory_consumption视图提供有关正在运行SQL查询的会话的内存消耗以及闲置时间的信息。

    在该视图中，列is_runaway表示是否Greenplum数据库认为该会话是一个失控会话，这种判断基于该会话的查询的vmem内存消耗来做出。当查询消耗过多内存时，Greenplum数据库认为该会话处于失控状态。Greenplum数据库的服务器配置参数runaway_detector_activation_percent控制Greenplum数据库什么时候会认为一个会话是失控会话。

    有关该参数的信息请见Greenplum数据库参考指南中的“服务器配置参数”。

    Greenplum数据库管理方案gp_toolkit包含显示Greenplum数据库工作文件信息的视图。如果没有足够的内存让查询完全在内存中执行，Greenplum数据库会在磁盘上创建工作文件。这些信息可以用来排查故障和调优查询。这些视图中的信息也可以被用来为Greenplum数据库配置参数gp_workfile_limit_per_query和gp_workfile_limit_per_segment指定值。

    在方案gp_toolkit中有下面这些视图：

    • gp_workfile_entries视图为当前在Segment上创建了工作文件的每个操作符都包含一行。
    • gp_workfile_usage_per_query视图为当前在Segment上创建了工作文件的每个查询都包含一行。
    • gp_workfile_usage_per_segment视图为每个Segment都包含一行。每一行显示了当前在该Segment上用于工作文件的总磁盘空间。

    有关使用gp_toolkit的信息请见Using gp_toolkit。

    Greenplum数据库中的每一个数据库实例（Master和Segment）都运行着一个有着自己的服务器日志文件的PostgreSQL数据库服务器。日常的日志文件被创建在Master和每个Segment的数据目录中的pg_log目录下。

    日志文件格式

    服务器日志文件被写成一种逗号分隔值（CSV）格式。一些日志项并不会所有的域都有值。例如，只有与一个查询工作者进程相关的日志项才会有slice_id值。可以用查询的会话标识符（gp_session_id）和命令标识符（gp_command_count）来确定一个特定查询的相关日志项。

    下列域会被写入到日志中：

    搜索Greenplum服务器日志文件

    Greenplum数据库提供一个名为gplogfilter的工具，它可以在一个Greenplum数据库日志文件中搜索匹配指定条件的项。默认情况下，这个工具在默认日志位置搜索Greenplum数据库的Master日志。例如，要显示Master日志文件的最后三行：

    1. $ gplogfilter -n 3

    要同时搜索所有Segment的日志文件，可以通过gpssh工具来运行gplogfilter。例如，要显示每个Segment日志文件的最后三行：

    1. $ gpssh -f seg_host_file
    1. => source /usr/local/greenplum-db/greenplum_path.sh
    2. => gplogfilter -n 3 /gpdata/gp*/pg_log/gpdb*.log

    使用Greenplum数据库的管理方案gp_toolkit来查询系统目录、日志文件和操作系统环境以得到系统状态信息。gp_toolkit方案包含一些可以用SQL命令访问的视图。gp_toolkit方案对所有数据库用户都可以访问。一些对象要求超级用户权限。用与下面类似的命令把gp_toolkit方案增加到用户的方案搜索路径中：

    1. => ALTER ROLE myrole SET search_path TO myschema,gp_toolkit;

    有关可用的管理方案视图及其用法的描述，请见Greenplum数据库参考指南。

    当Greenplum数据库系统被配置为发生特定数据库事件时触发SNMP告警或者给系统管理员发送email通知，那些告警和通知会包含对象ID（OID）和SQL错误代码。

    有关让Greenplum数据库使用SNMP的信息，请见

    这是Greenplum数据库的OID层次结构：

    1. iso(1)
    2. identified-organization(3)
    3. dod(6)
    4. internet(1)
    5. private(4)
    6. enterprises(1)
    7. gpdbMIB(31327)
    8. gpdbObjects(1)
    9. gpdbAlertMsg(1)

    gpdbAlertMsg

    1. 1.3.6.1.4.1.31327.1.1: STRING: 告警消息文本

    gpdbAlertSeverity

    1. 1.3.6.1.4.1.31327.1.2: INTEGER: 严重级别

    gpdbAlertSeverity可以取下列值之一：

    1. gpdbSevUnknown(0)
    2. gpdbSevOk(1)
    3. gpdbSevWarning(2)
    4. gpdbSevError(3)
    5. gpdbSevFatal(4)
    6. gpdbSevPanic(5)
    7. gpdbSevSystemDegraded(6)
    8. gpdbSevSystemDown(7)

    gpdbAlertSqlstate

    1. 1.3.6.1.4.1.31327.1.3: STRING: SQL标准错误代码

    代码列表请见SQL标准错误代码。

    gpdbAlertDetail

    1. 1.3.6.1.4.1.31327.1.4: STRING: 详细告警消息文本

    gpdbAlertSqlStmt

    gpdbAlertSystemName

    1. 1.3.6.1.4.1.31327.1.6: STRING: 主机名

    SQL标准错误代码

    下面的表格列出了所有定义好的错误代码。有些没有被用到，但是在SQL标准中有定义。其中也显示了错误分类。对于每一种错误分类都有一个标准错误代码，它的最后三个字符为000。这种代码只用于落入该分类却没有更详细代码的错误情况。

    每种错误代码的PL/pgSQL情况名称与该表中显示的短语相同，但是把空格替换成下划线。例如，代码22012（DIVISION BY ZERO）的情况名称是DIVISION_BY_ZERO。情况名称不区分大小写。