Post Install Operations

Health-Checks & Monitoring

Heimdall is divided into two components, the management server and the proxy or driver (it is the same code). This corresponds to the control plane and the data plane. The management server can go offline without impacting the proxy, although when offline, configuration changes can not be orchestrated. To monitor the accessibility of the management server, a monitoring system can use the default port of 8087 (see below in security for variations).

In order to add monitoring to the proxy nodes, say for load balancing purposes, an HTTP port can be opened up that provides the status of the system, based on the ability to completely pass a health check request through the proxy to the back-end database. The options to configure this are in the VDB documentation, under vdb properties, specifically the "healthcheck-port" and "healthcheck-interval". Once configured and the proxy restarted, a query against the url "/status" will report either "OK" with a "200 OK" status or "FAILED" with a "500 Server Error" status.

Additional monitoring can be enabled by selecting "AWS CloudWatch" when in AWS, and each proxy node will report to cloudwatch various statistics about cache hit rate, cpu load and performance. Please note, a proper IAM role is necessary for this option to be active (please see the security section for details).

Backup

In order to backup a complete configuration of Heimdall, two directories need to be archived. First, /opt/heimdall/config, which contains the json configuration files, and possibly /opt/heimdall/static/drivers, where any modified driver files are stored. If only the stock drivers are used, then this second directory does not need to be archive.

Additionally, individual VDB's can be exported via the menu icon in the upper right hand corner of the settings. This will save the vdb, data source, and rules settings that apply to the VDB. This configuration can then be imported into another instance.

Restore

To restore the configuration, install Heimdall again (if needed) and replace the content of /opt/heimdall/config with the archived versions. If the system is currently online, the new configurations can be read and activated by calling an api call to port 8087 with "/api/config/reload". This is also useful if using a configuration management system to synchronize configurations from an offline source or staging environment.

Maintenance

Heimdall is designed to operate with low maintenance. Some maintenance options that may be desired however:

  • Control how logs roll to manage disk space: Log files will roll when the log filesystem reaches 90% by default. This is configurable via the admin->properties->Reserved disk space setting OR the Max Log Age setting.
  • New version updates will be e-mailed to the configured notification contact if access to the Internet is provided. The settings can be configured to route the mail through a local mail server as desired.
  • Heimdall advertises version updates for four release trains--LTS, which is limited to major bugfixes only on the LTS train, the "release" train for normal updates and a test build. To configure which release build update notifications will be sent as, in the admin->software management tab, simply select the tracking option. Most customers should select the "release" train. The test train may be updated at times with code that a specific customer has been asked to download, and may not be as well tested as the release build, but will likely have new features as well.
  • To update to a new version of software, simply select the option in the software management tab. This will require external access to download the new build. The old build files will be saved in the /opt/heimdall directory labeled with a .old suffix in case a manual fallback is needed.