Monitoring

Most events are generated by and reported through the System Management application.

Events specific to HCP for cloud scale are reported with the IDs 6006 (informational), 6007 (warning), and 6008 (severe). These events are:

Alert messages notify you of situations that need your attention. Alerts can have a severity of Info, Warning, Severe, or Critical. You can view system alerts through the Admin App, CLI, or REST API, and storage component alerts through the Object Storage Management app.

Each alert corresponds to a system event.

For the system to send email notifications, you need to create a rule that specifies who to email, what email server to use, what events to send emails about, and what information to include in email messages.

• Enable: Turns on email notifications.
• Host: The hostname or IP address of the email server.
• Port: The port on which the email server listens for email messages.
• Security: The security protocol used by the email server (SSL or STARTTLS) or None if the email server doesn’t use a security protocol.
• Authenticated: Enable this if the email server needs authentication, then specify:
  • In the Username field, the username for an email account that’s authorized to establish the connection between the system and the email server.
  • In the Password field, the password for the email account.

You use the email notification message settings to configure a template for formatting all email notifications sent by the system.

• From: The email address from which you want email notifications to be sent.
• Subject: The email subject.
• Body: The email message body.

This table lists the variables you can use to make the email notification template. When the system sends an email notification, it replaces the variables in the notification with event-specific information.

• Email addresses: A comma-separated list of email addresses to send notification emails to.
• Severity Filter: The event severities about which to send email notifications. Can be one or more of these: INFO, WARNING, SEVERITY.

When you create a syslog notification rule, the system sends log messages to your syslog server for each applicable system event.

• Enable: Turns on syslog notifications
• Host: The hostname or IP address of the syslog server
• Port: The port on which the syslog server listens for log messages
• Facility: Category for the messages sent by this notification rule

You use the syslog notification message settings to configure a template for formatting all syslog notifications sent by this notification rule.

• Message: The message to send. You can use these variables as part of the message:

  Variable	Description
  $severity	Event severity: INFO, WARNING, or SEVERITY
  $subject	A short description of the event
  $message	Event message text
  $time	Time at which the event occurred
  $userName	Name of the user responsible for the event
  $subsystem	Category for the component affected by the event
  $objectId	Unique identifier for component affected by the event
  $objectType	The type of the component affected by the event.
  $objectSourceId	Unique identifier of the internal system component or process that was the source of the event. Value is [unknown] for most events.
  $objectSourceType	Type of the internal system component or process that was the source of the event. Value is [unknown] for most events.

• Sender Identity: Identity of the sender for the event. Sent with every syslog message.

The event severities about which to send email notifications. Can be one or more of these: INFO, WARNING, or SEVERITY.

Each service maintains its own set of logs. By default, log files are maintained in the folder install_path/log on each instance in the system. During installation, you can configure each service to store its log files in a different, non-default location.

This table lists the available log levels.

You can manage any of the log files yourself. That is, you can delete or archive them as necessary.

System logs are managed automatically in one or more of these ways:

• All log files are periodically added to a compressed file and moved to install_path/retired/. This occurs at least one time per day, but can also occur at other times. For example:
  • Whenever you run the log_download script.
  • Hourly, if the system instance's disk space is more than 60% full.
  • At the optimum time for a specific service.
• When a log file grows larger than an optimum size, the system stops writing to that file, renames it, and begins writing to a new file. For example, if the file exampleService.log.0 grows to 10MB, it is renamed to exampleService.log.1 and the system creates a new file named exampleService.log.0 to write to.
• When an optimum number of log files for a specific service is reached, the system can overwrite the oldest file. For example, if a service is limited to 20 log files, when the file exampleService.log.19 is filled, the system overwrites the file named exampleService.log.0.

The tool log_download lets you easily retrieve logs and diagnostic information from all instances in the system. This tool is located at this path on each instance:

install_path/bin/log_download

For information about running the tool, use this command:

install_path/bin/log_download -h

By default, each service stores its logs in its own folder at this path:

install_path/log

This table shows the default log folder names for each service. Depending on how your system was configured when first deployed, your system's logs might not be stored in these directories.