GreenPlum 大数据平台--监控
数据库状态监控活动
| 活动 | 过程 | 纠正措施 |
|---|---|---|
| 列出当前状态为down的Segment。如果有任何行被返回，就会生成一个警告或者告警。
推荐频率：每5到10分钟 重要度： IMPORTANT |
在postgres数据库中运行下例查询：
SELECT * FROM gp_segment_configuration WHERE status <> 'u'; |
如果该查询返回任何行，按照这些步骤来纠正问题：
|
| 检查当前处于改变跟踪模式的Segment。如果任何行被返回，应该生成一个警告或者告警。
推荐频率：每5到10分钟 重要度： IMPORTANT |
在postgres数据库中执行下列查询：
SELECT * FROM gp_segment_configuration WHERE mode = 'c'; |
如果该查询返回任何行，按这些步骤来纠正问题：
|
| 检查当前在重新同步的Segment。如果有行被返回，应该生成一个警告或者告警。
推荐频率：每5到10分钟 重要度： IMPORTANT |
在postgres数据库中执行下列查询：
SELECT * FROM gp_segment_configuration WHERE mode = 'r'; |
当这个查询返回行时，它表示那些Segment正在被重新同步。如果状态没有从'r'变成's'，那么在受影响的Segment的主Segment和镜像Segment的pg_log文件中检查错误。 |
| 检查没有以其最优角色运转的Segment。如果找到任何Segment，该集群可能不平衡。如果任何行被返回，应该生成一个警告或者告警。
推荐频率：每5到10分钟 重要度： IMPORTANT |
在postgres数据库中执行下列查询：
SELECT * FROM gp_segment_configuration WHERE preferred_role <> role; |
当Segment没有运行在其首选角色中时，每台主机上可能不是都有均匀数据量的主Segment，这表示处理是倾斜的。等待一个可能的窗口并且重启数据库将Segment带回到它们的首选角色。 |
| 运行一个分布式查询来测试它运行在所有Segment上。对每个主Segment都应返回一行。
推荐频率：每5到10分钟 重要度： CRITICAL |
在postgres数据库中执行下列查询：
SELECT gp_segment_id, count(*)
FROM gp_dist_random('pg_class')
GROUP BY 1;
|
如果这个查询失败，就说明该集群中存在分派到某些Segment的问题。这是一种少见的事件。检查无法被分派的主机确保没有硬件或者网络问题。 |
| 在一个Greenplum数据库 4.2或者更早的集群上测试Master镜像的状态。如果值是"Not Synchronized"，则抛出一个告警或者警告。
推荐频率：每5到10分钟 重要度： IMPORTANT |
在postgres数据库中执行下列查询：
SELECT summary_state FROM gp_master_mirroring; |
在来自Master和后备Master的pg_log中检查错误。如果没有意料之外的错误并且机器是启动的，运行gpinitstandby工具将后备Master带回到线上。在GPDB 4.2及更早的版本上，这要求一次数据库重启。 |
| 在Greenplum数据库上测试Master镜像的状态。如果该值不是"STREAMING"，则抛出一个告警或者警告。
推荐频率：每5到10分钟 重要度： IMPORTANT |
运行下列psql命令：
psql dbname -c 'SELECT procpid, state FROM pg_stat_replication;' |
从来自Master和后备Master的pg_log文件中检查错误。如果没有意料之外的错误并且机器是启动的，运行gpinitstandby工具将后备Master带回到线上。 |
| 执行一次基本检查看看Master是否启动且工作。
推荐频率：每5到10分钟 重要度： CRITICAL |
在postgres数据库中运行下列查询：
SELECT count(*) FROM gp_segment_configuration; |
如果这个查询失败，则活动Master可能宕机。多尝试几次，然后手工检查活动Master。如果活动Master确实已经宕机，重新引导或者重启活动Master以确保没有进程留在活动Master上，然后触发后备Master的激活。 |
数据库告警日志监控
| 活动 | 过程 | 纠正措施 |
|---|---|---|
| 从系统中检查FATAL和ERROR日志消息。
推荐频率：每15分钟 重要度： WARNING 这项活动和接下来的一项是监控log_alert_history表中消息的两种方法。只需要设置其中一种即可。 |
在gpperfmon数据库中运行下列查询：
SELECT * FROM log_alert_history
WHERE logseverity in ('FATAL', 'ERROR')
AND logtime > (now() - interval '15 minutes');
|
向DBA发送一个告警让他（她）分析该告警。可能想要对该查询增加额外的过滤条件忽略掉兴趣度不高的特定消息。 |
| 设置服务器配置参数来发送SNMP 或者 email告警。
推荐频率：N/A。告警由系统生成。 重要度： WARNING 这项活动和上一项是监控log_alert_history表中消息的两种方法。只需要设置其中一种即可。 |
启用服务器配置参数以通过 SNMP 或者 email发送告警：
|
DBA基于告警的性质采取行动。 |
硬件和操作系统监控
| 活动 | 过程 | 纠正措施 |
|---|---|---|
| 底层平台检查需要进行的维护或者硬件问题。
推荐频率：实时（如果可能），或者每15分钟 重要度： CRITICAL |
为硬件和OS错误设置SNMP或其他系统检查。 | 如果需要，从Greenplum集群移除一台机器以解决硬件及OS问题，然后把它加回到集群中并且运行gprecoverseg。 |
| 检查卷上用于Greenplum数据库数据存储和OS的磁盘空间使用。
推荐频率：每5到30分钟 重要度： CRITICAL |
设置一个磁盘空间检查。
|
通过移除一些数据或者文件释放系统上的空间。 |
| 检查网络接口上的错误或者丢包。
推荐频率：每小时 重要度： IMPORTANT |
设置一个网络接口检查。 |
与网络和OS团队一起解决问题。 |
| 检查RAID错误或者RAID性能退化。
推荐频率：每5分钟 重要度： CRITICAL |
设置一个RAID检查。 |
|
| 运行Greenplum的gpcheck工具来测试集群的配置中编写有当前的推荐。
推荐频率：在创建集群时或者向集群中增加新机器时 重要度： IMPORTANT |
运行gpcheck。 |
与系统管理团队一起根据gpcheck工具做出的推荐更新配置。 |
| 检查足够的I/O带宽和I/O倾斜。
推荐频率：创建集群时或者怀疑有硬件问题时。 |
运行Greenplum的gpcheckperf工具。 |
如果数据传输率与下列不相似，则集群可能存在不足：
如果集群上的机器显示出一种不均匀的性能画像，与系统管理团队一起修复有错误的机器。 |
目录监控
| 活动 | 过程 | 纠正措施 |
|---|---|---|
| 运行目录一致性检查以确保集群中每台主机上的目录都是一致的并且处于好的状态。
推荐频率：每周 重要度： IMPORTANT |
在每个数据库中运行Greenplum的gpcheckcat工具：
gpcheckcat -O |
对任何检测到的问题运行修复脚本。 |
| 运行一个长期的表目录检查。
推荐频率：每月 重要度： CRITICAL |
在一次停机时间，在系统中没有用户时，在每个数据库中运行Greenplum的gpcheckcat工具：
gpcheckcat -R persistent |
对任何检测到的问题运行修复脚本。 |
| 检查没有相应pg_attribute项的pg_class项。
推荐频率：每月 重要度： IMPORTANT |
在一次停机时间，在系统中没有用户时，在每个数据库中运行Greenplum的gpcheckcat工具：
gpcheckcat -R pgclass |
对任何被发现的问题运行修复脚本。 |
| 检查泄露的临时方案和丢失的方案定义。
推荐频率：每月 重要度： IMPORTANT |
在一次停机时间，在系统中没有用户时，在每个数据库中运行Greenplum的gpcheckcat工具：
gpcheckcat -R namespace |
对任何被发现的问题运行修复脚本。 |
| 检查随机分布表上的约束。
推荐频率：每月 重要度： IMPORTANT |
在一次停机时间，在系统中没有用户时，在每个数据库中运行Greenplum的gpcheckcat工具：
gpcheckcat -R distribution_policy |
对任何被发现的问题运行修复脚本。 |
| 检查非存在对象上的依赖。
推荐频率：每月 重要度： IMPORTANT |
在一次停机时间，在系统中没有用户时，在每个数据库中运行Greenplum的gpcheckcat工具：
gpcheckcat -R dependency |
对任何被发现的问题运行修复脚本。 |
数据维护
| 活动 | 过程 | 纠正措施 |
|---|---|---|
| 检查表上缺失的统计信息。 | 在每个数据库中检查gp_stats_missing视图：
SELECT * FROM gp_toolkit.gp_stats_missing; |
在缺少统计信息的表上运行ANALYZE。 |
| 检查数据文件中出现膨胀（死亡空间）且无法用常规VACUUM命令恢复的表。
推荐频率：每周或每月 重要度： WARNING |
在每个数据库中检查gp_bloat_diag视图：
SELECT * FROM gp_toolkit.gp_bloat_diag; |
在没有用户访问该表示执行一个VACUUM FULL语句以移除膨胀并且紧凑数据。 |
数据库维护
| 活动 | 过程 | 纠正措施 |
|---|---|---|
| 在堆表中标记所占用空间可被重用的已删除行。
推荐频率：每日 重要度： CRITICAL |
清理用户表：
VACUUM <table>; |
定期清理被更新的表以防止膨胀。 |
| 更新表统计信息。
推荐频率：在装载数据后且在执行查询前 重要度： CRITICAL |
分析用户表。用户可以使用analyzedb管理工具：
analyzedb -d <database> -a |
定期分析被更新的表，这样优化器能产生有效的查询执行计划。 |
| 备份数据库数据。
推荐频率：每日，或者根据备份计划的要求 重要度： CRITICAL |
运行gpcrondump工具并行地创建Master和Segment数据库的备份。 | 最佳做法是在数据库必须被恢复时已经有一个当前的备份准备好。 |
| 清理、重新索引以及分析系统目录以维护一个高效的目录。
推荐频率：每周，或者当数据库对象被频繁创建和删除时使用更高的频率 |
|
优化器从系统表检索信息来创建查询计划。如果系统表和索引被允许随时间膨胀，系统表上的扫描会增加查询执行时间。在重新索引后运行ANALYZE很重要，因为REINDEX
会让索引上没有统计信息。
来自：https://gp-docs-cn.github.io/docs/admin_guide/monitoring/monitoring.html |
