Pivotal Knowledge Base

Follow

How to trigger and verify Greenplum SNMP alerts

Environment

Pivotal Greenplum: 4.3.x

OS: RHEL 6.x

Purpose

Sometimes users might want to verify if Greenplum is working well with sending out SNMP trap as well as if their network monitor application could receive SNMP traps from Greenplum properly.

This article is to briefly demonstrate how to trigger and verify Greenplum SNMP alerts (traps).

Procedure

1. Read through the Enabling System Alerts and Notifications section in the Greenplum documentations

2. Install net-snmp and net-snmp-utils packages on Greenplum master host if they have not been installed

3. Configure SNMP related Greenplum GUCs as follows. Don't forget to reload configuration with gpstop -u

[gpadmin@GPDB1 ~]$ gpconfig -s gp_snmp_use_inform_or_trap
Values on all segments are consistent
GUC          : gp_snmp_use_inform_or_trap
Master  value: trap
Segment value: trap
[gpadmin@GPDB1 ~]$ gpconfig -s gp_snmp_monitor_address
Values on all segments are consistent
GUC          : gp_snmp_monitor_address
Master  value: localhost:162
Segment value:
[gpadmin@GPDB1 ~]$ gpconfig -s gp_snmp_community
Values on all segments are consistent
GUC          : gp_snmp_community
Master  value: public
Segment value: public
4. Start snmptrapd as root to listen on port 162
root@GPDB1 ~]# /usr/sbin/snmptrapd -m ALL -Lf ~/snmptrap.log &
If the following messages are shown in the file snmptrap.log then add configuration line "disableAuthorization yes" into /etc/snmp/snmptrapd.conf followed by a restart of snmptrapd
Warning: no access control information configured.
This receiver will *NOT* accept any incoming notifications.
5. Make Greenplum generate a FATAL message to trigger a SNMP trap being sent out. According to the Greenplum documentations, the following events will trigger SNMP alerts
  • All PANIC-level error conditions
  • All FATAL-level error conditions
  • ERROR-level conditions that are "internal errors" (for example, SIGSEGV errors)
  • Database system shutdown and restart
  • Segment failure and recovery
  • Standby master out-of-sync conditions
  • Master host manual shutdown or other software problem (in certain failure scenarios, Greenplum Database cannot send an alert or notification)
So you could just simply try connecting to the database with psql by specifying a non-existent user.
[gpadmin@GPDB1 ~]$ psql -U scottgai gpadmin
psql: FATAL:  no pg_hba.conf entry for host "[local]", user "scottgai", database "gpadmin", SSL off
6. Check snmptrapd logs to view the trap sent from Greenplum
[root@GPDB1 ~]# tail -f snmptrap.log
NET-SNMP version 5.5
2017-07-05 19:02:34 localhost [UDP: [127.0.0.1]:60156->[127.0.0.1]]:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (90738) 0:15:07.38 SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::enterprises.31327.5.0.1 SNMPv2-SMI::enterprises.31327.1.1 = STRING: "FATAL: no pg_hba.conf entry for host \"[local]\", user \"scottgai\", database \"gpadmin\", SSL off" SNMPv2-SMI::enterprises.31327.1.2 = INTEGER: 4 SNMPv2-SMI::enterprises.31327.1.3 = STRING: "28000" SNMPv2-SMI::enterprises.31327.1.4 = "" SNMPv2-SMI::enterprises.31327.1.5 = "" SNMPv2-SMI::enterprises.31327.1.6 = STRING: "GPDB1:4361"

Additional Information

Monitoring a Greenplum System

 

Comments

Powered by Zendesk