Whether it be on the administrative side of the house or in a production environment, the digital world is not slowing down. In fact, it is increasing by the second. Data is collected from a thousand different sources and often stored in the same number of places. Automating the collection, analyzing and augmentation of this
Enterprise Alert is the central hub for managing critical alerting, notifications, and remediation needs. It is a database-driven application and most of the time, once set up and configured, it just silently does its job in the background. Where we have customers frequently adapting and maintaining notification profiles, event sources, workflows, or channels in our
Database maintenance is integral to the speed of an application. An application’s speed is driven by many factors, one of which is database performance. In an application such as Enterprise Alert that is I/O intensive, database speed is a critical factor in its performance. As such, a solid database maintenance plan is needed to ensure
Over the time Enterprise Alert generates quite some database records and log files. Some of them are very useful for reporting purposes but from some time on historic entries are not needed anymore and just consume extra space and slow down the system. It is recommended to purge historic database entries and to delete old
The estimated database growth and size for Enterprise Alert very much depends on many factors for example on how many events and alerts are handled on a daily basis as well as on the size of the events. The following example illustrates a typical customer scenario: Let’s assume an average usage of Enterprise Alert along
This article describes how to migrate Enterprise Alert to another machine with all its configurations, users and parameters. The first part describes the migration of the Enterprise Alert installation and the second part is about the related database migration. You can use both parts combined for a complete migration or separately in case you only