Skip to main content
Pure1 Support Portal

Messages Tab

The Messages tab displays and manages Purity alerts, audit records, and user session logs.

Figure 84. Messages Tab

Messages Tab

The alert, audit record, and user session messages that appear in the Messages tab are retrieved from a list of log entries that are stored on the FlashArray. To conserve space, Purity stores a reasonable number of log entries on the array. Older entries are deleted from the log as new entries are added. To access the complete list of messages, configure the Syslog Server feature to forward all messages to your remote server. Refer to System Tab for more information about the Syslog Server feature.

Purity assigns a unique numeric ID to each alert, audit trail, and user session event as it is created.

All messages are sorted in chronological descending order in their respective sub-views. Click any of the column headings, including the flagged and severity icon columns for alerts, to change the sort order. Click the link in any of the date/time columns to display the message details, including the message ID number.

In the navigation pane, the categories within the Alerts, Audit Trail, and User Session Logs sections allow you to filter the results that appear in the details pane. Click a category name to display only the results that belong to that category.

Alerts

Purity generates an alert when there is a change to the array or to one of the Purity hardware or software components.

The Alerts sub-view displays a list of all alerts generated by Purity.

Figure 85. Alerts Sub-View

Alerts Sub-View

In the Alerts section of the navigation pane, select Open to display open alerts, or select Flagged to display flagged alerts.

By default, Purity displays all alerts triggered within the last 24 hours. Click the Time drop-down to expand the range of time to view up to 1 years’ worth of alert messages.

The flag icon represents an alert that has been flagged by Purity or the user. Purity automatically flags all warning and critical alerts. An alert remains flagged until you have manually cleared the flag to indicate that the alert has been addressed. If there are further changes to the condition that caused the alert (for example, a temperature of a controller or shelf has changed), Purity will set the flag again.

The colored squares represent alert severity levels:

  • Green (INFO) squares represent informational messages generated due to a change in state. INFO messages can be used for reporting and analysis purposes. No action is required.

  • Yellow (WARNING) squares represent important messages warning of an impending error if action is not taken.

  • Red (CRITICAL) squares represent urgent messages that require immediate attention.

To filter alert messages by severity level, click the Severity drop-down and select the minimum severity level of the alerts you want to view. Purity displays the alerts of that severity level and higher. For example, select Warning to display alerts of Warning and Critical severities.

Alerts can be open or closed. Open alerts, which appear in bold font, are ones that need to be resolved. Once resolved, Purity unbolds the alert to close it, indicating that the alert has been addressed.

The Time column displays the date and time (UTC) of the alert.

Alert messages fall into one of three categories: array, software, or hardware. The Component column displays the array, hardware, or software component that triggered the alert. Click the Category drop-down to filter the alert messages by a specific category. Available options include Array Alerts, Hardware Alerts, Software Alerts, and All Categories (default).

The Name column displays the name of the specific array, software, or hardware component that triggered the alert.

The Event column displays the event that triggered the alert.

In addition to the Alerts sub-view, critical and warning messages are also logged and transmitted to Pure Storage Support via the phonehome facility, and sent as messages to designated email addresses. If configured, Purity can also send alert messages as SNMP traps to designated SNMP managers and as syslog messages to remote servers.

Flagging an alert message

To flag an alert message:

  1. Select Messages > Alerts.

  2. Select the check box next to the alert message you want to flag.

  3. Click the menu icon.

  4. Select Set Flag.

  5. Verify that the flag appears in the alert message.

Clearing an alert flag

To clear an alert message flag:

  1. Select Messages > Alerts.

  2. Select the check box next to the alert message you want to unflag.

  3. Click the menu icon.

  4. Select Clear Flag.

  5. Verify that the flag no longer appears in the alert message.

Audit Trail

The audit trail represents a chronological history of the Purity GUI, Purity CLI, or REST API operations that a user has performed to modify the configuration of the array. Each record within an audit trail includes the name of the Purity user who performed the operation and the Purity operation that was performed.

Purity creates audit records for operations that modify the configuration of the array (e.g., creating, modifying, deleting, or connecting volumes).

Figure 86. Audit Trail Sub-View

Audit Trail Sub-View

In the Audit Trail section of the navigation pane, select Flagged to display audit records that are flagged, or select a user name to display the audit records for the selected user.

By default, Purity displays all audit records generated within the last 24 hours. Click the Time drop-down to expand the range of time to view up to 1 years’ worth of audit records.

Purity does not flag audit records. Users can, however, manually flag audit records for internal tracking purposes. Each audit record includes the following information: the UTC time of the operation, the Purity user who performed the operation, the Purity command and subcommand that was performed, the object name against which the command was performed, and the arguments that were included in the command.

In addition to the Audit Trail sub-view, audit records are also logged and transmitted to Pure Storage Support via the phonehome facility. If configured, Purity can also send audit records as SNMP traps to designated SNMP managers and as syslog messages to remote servers.

Flagging an audit trail message

To flag an audit trail message:

  1. Select Messages > Audit Trail.

  2. Select the check box next to the audit trail message you want to flag.

  3. Click the menu icon.

  4. Select Set Flag.

  5. Verify that the flag appears in the audit trail message.

Clearing an audit trail message flag

To clear an audit trail message flag:

  1. Select Messages > Audit Trail.

  2. Select the check box next to the audit trail message you want to unflag.

  3. Click the menu icon.

  4. Select Clear Flag.

  5. Verify that the flag no longer appears in the audit trail message.

User Session Logs

The User Session Logs sub-view displays a list of user session events performed through the following Pure Storage interfaces: Purity GUI, Purity CLI, and Pure Storage REST API.

Figure 87. User Session Logs Sub-View

User Session Logs Sub-View

User session events are divided into two main categories: session login and logout actions, and session authentication actions.

Login and logout actions include:

  • Logging in to the Purity GUI or Purity CLI. This includes remote logins to the Purity CLI via SSH.

  • Logging out of the Purity GUI or Purity CLI

  • Opening a Pure Storage REST API session

  • Pure Storage REST API session timeouts

Authentication actions include:

  • Generating an API token through the REST API

  • Submitting a REST API request in a closed REST session

  • Attempting to log in to the Purity GUI or Purity CLI using an invalid password

  • Attempting to open a Pure Storage REST API session using an invalid API token

  • Attempting to obtain a REST API token using an invalid username and/or password

In the User Session Log section of the navigation pane, select a user name to display only the user session events for the selected user.

By default, Purity displays all user session events generated within the last 24 hours. Click the Time drop-down to expand the range of time to view up to 1 years’ worth of user session events.

By default, Purity displays all user session events available for all Purity interfaces. Click the User Interface drop-down to filter the display by a specific Purity interface. Available options include CLI, GUI, and REST, and All User Interfaces (default).

The Location column displays the IP address of the user client connecting to the array.

The Method column displays the authentication method by which the user attempted to log in, log out, or authenticate. Authentication methods include API token, password, and public key.

In addition to the User Session Logs sub-view, user session messages are also logged and transmitted to Pure Storage Support via the phonehome facility. If configured, Purity can also send user session messages as syslog messages to remote servers.

Login and Logout Events

When a user logs in to the Purity GUI or Purity CLI, the event appears as an 'login' event in the User Session Logs sub-view, where the Start Time represents the user login time. The End Time value appears as a dash ("-") symbol until the user logs out.

When the user logs out of the Purity interface, the same login event becomes a closed session, where the End Time represents the user logout time. The login event message ID is replaced with the logout event message ID. To conserve space, Purity stores a reasonable number of log entries. Older entries are deleted from the log as new entries are added. If the matching start time log entry is no longer stored in the log when the user logs out of the Purity interface, the Start Time value appears as a dash ("-") symbol.

Login and Logout Event Examples

The following examples represent common login and logout events:

Example 1

Figure 88. User Session Logs - Login and Logout Example

'pureuser' logs in to the Purity GUI with a valid password

User Session Logs - Login and Logout Example

Example 2

Figure 89. User Session Logs - Login and Logout Example

The 'root' user logs in to the Purity CLI with a valid public key and then logs out

User Session Logs - Login and Logout Example

Example 3

Figure 90. User Session Logs - Login and Logout Example

'pureuser' opens a REST API session with a valid API token and then the session times out.

User Session Logs - Login and Logout Example

Authentication Events

Users can log into Purity through various authentication methods, including passwords, public keys, and API tokens.

Purity creates a “failed authentication” event when a user performs any of the following actions: log in to the Purity GUI with an incorrect password, log in to the Purity CLI with an invalid password or public key, or open a REST API session with an invalid API token.

Purity creates an “API token obtained” event when a user attempts to create an API token via any of the Purity interfaces.

Purity creates a “request without session” event when a user attempts to submit a REST API request as an unauthenticated user.

In the User Session Logs sub-view, repeated failed authentication attempts are displayed in pre-configured time periods. By default, failed authentication attempts are displayed in 15-minute time periods.

The Repeat value represents the number of attempts in addition to an initial attempt that a user has performed an authentication action within the 15-minute time period.

Authentication Event Examples

The following examples represent common authentication events:

Example 1

Figure 91. User Session Logs - Authentication Example

‘pureuser’ attempts to log in to the Purity GUI once using an invalid password

User Session Logs - Authentication Example

Example 2

Figure 92. User Session Logs - Authentication Example

‘pureuser’ attempts to log in to the Purity CLI once using an invalid password

User Session Logs - Authentication Example

Example 3

Figure 93. User Session Logs - Authentication Example

An anonymous user attempts to open a REST API session three times using an invalid API token

User Session Logs - Authentication Example

Example 4

Figure 94. User Session Logs - Authentication Example

'pureuser' recreates an API token 3 times between 12:00pm and 12:15pm

User Session Logs - Authentication Example

Example 5

Figure 95. User Session Logs - Authentication Example

'pureuser' attempts to submit a REST API request 3 times in a closed REST API session between 11:45am and 12:00pm

User Session Logs - Authentication Example