Monitoring 

To view or assign network settings, navigate to the following page in the CloudFS WebUI:

Configuration > Monitoring

The following table describes the monitoring settings you can configure.

Simple Network Management Protocol

Simple Network Management Protocol (SNMP) is an Internet Standard protocol that allows customers to monitor networked devices through a single tool. Devices that support SNMP include routers, modems, switches, and servers. SNMP monitors values exported by the SNMP agent and allows push notifications, which are traps in SNMP language. The two components of SNMP include SNMP agents and SNMP managers. An SNMP agent is a software on a managed device. The software allows the SNMP manager to communicate with the device using SNMP. The SNMP manager is an external software that queries, receives events, and gets responses from devices. A managed device implements an SNMP interface for node-specific information.

A Management Information Base (MIB) is a collection of information organized hierarchically. These are accessed using a protocol such as SNMP. MIBs are created by Managed Device vendors (Panzura), and they are stored on the device. MIBs must be provided to the SNMP manager so it knows how to translate the MIB values from the managed device. MIBs use a hierarchical namespace that contains object identifiers (OID). An OID identifies a variable that can be read using SNMP.

There are two transaction types: polling and traps. When polling occurs, the SNMP manager sends an SNMP request to a managed device at the default polling interval, which is 120 seconds. The managed device then responds with an SNMP response status. The second type of transaction is a trap or push notification. SNMP managers are always ready to receive a trap from a managed device. In order to receive and translate a trap from a managed device, the managed device must be configured to send traps to the manager, and the SNMP manager must be provided with a trap MIB from the managed device.

The following are the three versions of SNMP security:

• Version 1. Plain text authentication.
• Version 2. Improved authentication. Community strings are still transmitted over the wire in clear, plain text.
• Version 3. Provides the following three levels of authentication:
  o NoAuthNoPriv. Users who use this level don't have authentication or privacy when they send and receive messages.
  o AuthNoPriv. This level requires users to authenticate, but does not encrypt sent or received messages.
  o AuthPriv. This level is the most secure. Authentication is required and sent and received messages are encrypted.

You can download the MIB zip archive using the following URL: https://docs.panzura.com/PANZURA_SNMP.tgz

After downloading the MIB archive, decompress it and load files into your SNMP manager.

This download is also available by selecting Maintenance> System Operations> Download MIB.

To configure the SNMP settings on a Panzura node:

1. Log in to your Panzura node.

2. Select CONFIGURATION > Monitoring > SNMP Users > SNMP Settings.

3. In the Read Community String field, enter the community string for read-only communication between the node and SNMP manager.

   If you specify a custom community string, the public community string is disabled.

    

4. In the Recipient IP field, enter the SNMP manager IP (this is where we send traps).

5. In the Recipient Community String, enter the SNMP manager associated with community strings.

6. In the SNMP Trap Threshold Settings field, Enter the usage thresholds (percent) that will trigger SNMP trap messages.

To edit a trap:

1. Log in to your Panzura node.

2. Select CONFIGURATION > Monitoring > SNMP Users > SNMP Settings.

3. In the SNMP Trap Thresholds section, select Actions > Edit SNMP Trap.

To add an SNMP user:

1. Log in to your Panzura node.

2. Select CONFIGURATION > SNMP Users.

3. Click the ADD button.

The following table displays the SNMP traps that Panzura supports:

Syslog Message Categories

When using syslog to monitor for events needing attention, Panzura recommends monitoring for LOG_EMERG, LOG_ALERT, and LOG_CRIT.

• LOG_EMERG and LOG_ALERT messages typically represent conditions requiring immediate attention.
• LOG_CRIT events represent events that can become EMERG or ALERT if not addressed.

The following table provides a list of Syslog message categories.

Panzura MIB Objects

The Panzura node MIB provides access to the following types of system information and statistics:

• node ID, CloudFS version, and hostname

• Visibility into caching:
  • Hot, warm, and cold for automated caching
  • Hot, warm, cold for pinned files
  • Cache hits/misses for automated caching
  • Cache hits/misses for pinned
• Cloud statistics
  • Number of drive files uploaded to cloud
  • Number of drive files downloaded
  • Number of upload failures
  • Number of download failures
• SMB users
  • Total number of SMB users currently connected to the node
  • Total number of files locked by SMB users currently connected
• CloudFS local configuration
  • Mode of node: master/subordinate
  • Hostname of master node
• Local system snapshot information
  • Latest system snapshot generated reference #
  • Latest system snapshot uploaded to cloud reference #
  • Date and time when the latest master snapshot was successfully generated
• CloudFS remote configuration
  • Remote node hostnames
  • Latency from node to remote node
  • Remote node up or down
  • Down means there is no communication
• Remote snapshot information from all other nodes
  • Latest snapshot reference # synchronized from the specified remote node
  • The latest snapshot reference # uploaded by the specified remote node

MIB Download*

The following table lists the objects in the Panzura node Management Information Base (MIB).

Monitoring Recommendations for CPU Load

The amount of CPU load placed on a node is measured in terms of the number of processes that are ready to run and in the queue awaiting CPU resources. These are the recommended thresholds by model. (CPU load is measured by OID .1.3.6.1.4.1.32853.1.3.1.1.1.)

VM nodes

For nodes operating in virtualized environments, such as VMware ESXi or Amazon Web Services (AWS), first determine the number of CPU cores assigned to the node. When 4 cores are assigned, use the values given for the 28xx models.

For a larger number of cores, scale the values upward. For example, a node operating within AWS can have 8 cores.

To scale the values, first divide the number of cores by 4 to get 2. Next, multiply this by the values for the 28xx models. The CPU load recommendations become (2*320=640), (2*400=800), and (2*800=1600).