![](https://secure.gravatar.com/avatar/e72be9c09f357f567102abae434ef94c.jpg?s=120&d=mm&r=g)
I’m going to piggy back off the issue of the Alerts not clearing. I’m getting the same issue and I’m pretty sure its SQL config related though I don’t know much past that. For example if I add a new device, I will get alerts for ports in the Admin up / physical down as I’m checking for that with an alert checker. That’s to be expected as I haven’t had a chance to turn off alerting on interfaces I don’t care about yet. Once it polls I turn off polling/alerting on interfaces (such as access ports)
So if I go in and turn polling/alerting off on those interfaces I’d assume the alerts would clear. However the alerts persist and keep firing even if I have them turned off on those specific interfaces. I have figured out I can manually clear these alerts by restarting the mysql service.
Here is part of the poller run (not sure if you want it all)
##### Completed polling run at 2015-08-17 11:34:51 #####
o Devices Polled 1 o Poller Time 7.877 secs o Memory usage 7.25MB (peak: 7.25MB) o MySQL Usage Cell[3/0.001s] Row[8/0.002s] Rows[52/0.02s] Column[2/0.001s] Update[20/0.014s] Insert[4/0.016s] Delete[0/0s] o RRDTool Usage update[29/0.033s]
——————— Output of my.cnf —————————— I have tweaked some of these in an effort to fix past and this current issue.
[client] port = 3306 socket = /var/run/mysqld/mysqld.sock
# Here is entries for some specific programs # The following values assume you have at least 32M ram
# This was formally known as [safe_mysqld]. Both versions are currently parsed. [mysqld_safe] socket = /var/run/mysqld/mysqld.sock nice = 0
[mysqld] # # * Basic Settings # user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp lc-messages-dir = /usr/share/mysql skip-external-locking # # Instead of skip-networking the default is now to listen only on # localhost which is more compatible and is not less secure. bind-address = 127.0.0.1 # # * Fine Tuning # key_buffer = 64M #Was 16 max_allowed_packet = 64M #Was 16 thread_stack = 192K thread_cache_size = 8 # This replaces the startup script and checks MyISAM tables if needed # the first time they are touched myisam-recover = BACKUP #max_connections = 100 #table_cache = 64 #thread_concurrency = 10 # # * Query Cache Configuration # query_cache_limit = 32M #Was 1M on 7/2 Tom Changed to test query_cache_size = 32M #Was 16 8/17 # # * Logging and Replication # # Both location gets rotated by the cronjob. # Be aware that this log type is a performance killer. # As of 5.1 you can enable the log at runtime! #general_log_file = /var/log/mysql/mysql.log #general_log = 1 # # Error log - should be very few entries. # log_error = /var/log/mysql/error.log # # Here you can see queries with especially long duration #log_slow_queries = /var/log/mysql/mysql-slow.log #long_query_time = 2 #log-queries-not-using-indexes # # The following can be used as easy to replay backup logs or for replication. # note: if you are setting up a replication slave, see README.Debian about # other settings you may need to change. #server-id = 1 #log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 10 max_binlog_size = 100M #binlog_do_db = include_database_name #binlog_ignore_db = include_database_name # # * InnoDB # # InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/. # Read the manual for more InnoDB related options. There are many! # # * Security Features # # Read the manual, too, if you want chroot! # chroot = /var/lib/mysql/ # # For generating SSL certificates I recommend the OpenSSL GUI "tinyca". # # ssl-ca=/etc/mysql/cacert.pem # ssl-cert=/etc/mysql/server-cert.pem # ssl-key=/etc/mysql/server-key.pem
tmp_table_size = 2G max_heap_table_size = 2G
[mysqldump] quick quote-names max_allowed_packet = 32M
[mysql] #no-auto-rehash # faster start of mysql but no tab completition
[isamchk] key_buffer = 32M
# # * IMPORTANT: Additional settings that can override those from this file! # The files must end with '.cnf', otherwise they'll be ignored. #
Tom J
On 8/17/15, 9:11 AM, "observium on behalf of observium-request@observium.org" <observium-bounces@observium.org on behalf of observium-request@observium.org> wrote:
Re: Alerts not clearing