The Syncplicity Storage Connector generates several different events and metrics related to the performance and overall health of the Storage Connector. With the v.188.8.131.52 release these events and metrics are available for consumption by 3rd party monitoring tools.
The following glossary includes a list of every metric and its definition, grouped by category, which can be helpful in building desired graphs, thresholds and alerts for system health and/or performance monitoring. Storage Connector metrics are provided in JMX format. For all time-based metrics the unit of measure is msec (unless stated otherwise).
This class of metrics are primarily used to monitor performance, capacity utilization and operational health of the Storage Connector.
The number of concurrent requests that can be processed by the Storage Connector node. Each Storage Connector throttles the total number of upload and download requests. The throttling limit is set using the configuration value syncplicity.request.limit in the configuration file.
This counter represents the minimum of the remaining capacity of the Storage Connector to process concurrent requests against the throttling limit. It is calculated based on the highest sum of concurrent upload and download requests during the last sampling period.
This counter represents the maximum of the remaining capacity of the Storage Connector to process concurrent requests against the throttling limit. It is calculated based on the lowest sum of concurrent upload and download requests during the last sampling period.
The current number of download requests at the end of sampling interval.
The current number of upload requests at the end of a sampling interval.
The total number of download requests that were processed during the last sampling interval.
The total number of upload requests that were processed during the last sampling interval.
The number of files that were successfully processed for clean up during the last sampling interval. The Storage Connector periodically cleans up partial files, which are typically due to incomplete file uploads, from storage.
The number of bytes transferred from clients to storage during last sampling interval.
The amount of time Storage Connector spent transferring bytes from clients to storage over the last sampling interval.
The number of bytes transferred from storage to clients during last sampling interval.
The amount of time Storage Connector spent transferring bytes from storage to clients over the last sampling interval.
The number of DELETE requests made by the Storage Connector to storage.
The sum of response time of DELETE requests to storage that occurred during the last sampling interval.
The number of GET requests made by the Storage Connector to storage.
The sum of response time of GET requests made by the Storage Connector to storage that occurred during the last sampling interval.
The number of PUT requests made by the Storage Connector to storage.
The sum of response time of PUT requests made by the Storage Connector to storage that occurred during last sampling interval.
Storage Services Metrics
This class of metrics are useful in monitoring the health of the Storage Connector and the communication with client endpoints and storage services such as rights management APIs.
The following metrics are used to monitor actual file download health. This are one of the most important metrics for the storage administrator to have. They are most useful to look at when there’s a need to access Storage Connector file download performance or to investigate file download overall health. The most common errors are fileDownload.error.404, which indicates that a file is not present in storage, and fileDownload.error.500, which means the file couldn’t be downloaded from storage typically caused by the unavailability of the storage layer or Syncplicity Orchestration. All counters in this section show number of events that occurred during the last sampling interval.
The number of full file download requests completed.
The number of completed download requests for a range of the file as specified by the request header.
The number of failed file download requests due to Bad Request errors. The most common causes for this error include missing headers or arguments which are required, use of an invalid offset, or the file is not present in storage.
The number of failed file download requests related to rights management protection. The possible causes include a misconfigured rights management server, the file being requested for download is unable to be encrypted, or there are network issues communicating with the rights management server.
The number of failed file download requests due to Not Found errors. This indicates that the file requested for download does not exist in storage.
The number of failed file download requests typically due to the unavailability of the storage layer or Syncplicity Orchestration. Other potential causes for this error include the file was marked as corrupt (no longer present in storage), the access key was invalid or there were unexpected internal errors.
The number of full file download requests that completed successfully.
The following metrics are used to monitor actual file upload health. This are one of the most important metrics for the storage administrator to have. They are most useful to look at when there’s a need to access Storage Connector file upload performance or to investigate file upload overall health. The most common error is fileUpload.error.500 which is an indicator of a loss of connectivity or availability to the storage layer or Syncplicity Orchestration. All counters in this section show number of events that occurred during the last sampling interval.
The number of failed file upload requests due to Bad Request errors. The most common causes for this error are a missing directory ID or pathname, invalid form data, missing headers or arguments which are required, or the use of an invalid upload offset.
The number of failed file upload requests due to exceeding quota limits. An out of quota error occurs when the user does not have enough space to upload the file requested.
The number of failed file upload requests typically due to the unavailability of the storage layer or Syncplicity Orchestration. Other potential causes for this error include the access key was invalid or there were unexpected internal errors.
The number of initiated file upload requests. For files that are larger than 5MB, this counter is incremented only for the first chunk.
For files larger than 5MB, the # of chunks uploaded for a file after the first chunk (which is counted by fileUpload.initiated).
The number of full file upload requests that completed successfully. For example, when a client initiates an upload of a 15MB file, it will upload in 3 5MB chunks (default chunk size). Once all chunks are uploaded this counter is incremented by 1.
The number of chunk file upload requests that completed successfully. For example, when a client initiates an upload of an 18MB file, it will upload in 4 5MB chunks (default chunk size). The value of this counter would increment +1 for each chunk that is successfully uploaded. This counter applies to Syncplicity desktop and mobile clients and does not apply to the web online file browser.
These metrics are deprecated.
The deviceToken metrics are useful in monitoring the token authorization service health. Each client must authenticate itself to Syncplicity before it can access files in storage. The primary method of authentication is with a short-lived security token, which is commonly performed when the client begins an upload or download request. Upon receiving this request, the Storage Connector responds with a security token that the client must include in all subsequent requests it makes.
When deviceToken.error.40x or deviceToken.error.500 counts are present with frequency or high volume this is indicative of an issue with one or more client endpoints. The most common cause is that Syncplicity Orchestration cannot generate a device token due to missing required headers, parameters or access denied.
deviceToken.error.403 - Deprecated
deviceToken.error.404 - Deprecated
deviceToken.error.500 - Deprecated
Syncplicity is integrated with the EMC IRM plugin to provide protection to secured content, enabling organizations to maintain control of information rights beyond the firewall (more Information about EMC IRM).
When irm.error.403 or irm.error.500 counts are present with frequency or high volume this is indicative of an issue with the IRM RMS server that typically indicates that IRM is misconfigured, the file can’t be protected, or the RMS server is unavailable.
The following metrics are used to measure the health of shared links. The Shared Link API provides a method to authenticate user-initiated file shares issued by Syncplicity.
When link.error.40x or link.error.500 counts are present with frequency or high volume this is indicative of issues with shared link generation. Typical causes include the unavailability of Syncplicity Orchestration, missing required headers or parameters, or unauthorized access.
Syncplicity Web Preview is only available in the Syncplicity public cloud. The following metrics are not used for on-premise Storage Connector deployments.
These metrics are used to monitor storage authorization health. The Storage Authorization API validates the authenticity of a Storage Connector instance.
When storageAuthorization.error.40x or storageAuthorization.error.500 counts are present with frequency or high volume this is indicative of an issue with missing headers or parameters that are required, an invalid storage token, invalid or restricted email, or Syncplicity Orchestration is unavailable.
These metrics are useful to monitor storage password health. The Storage Password Service is used for client authentication when second layer authentication or SSO authentication is enabled.
When storagePassword.error.40x or storagePassword.error.500 counts are present with frequency or high volume this is indicative of an issue at the second layer authentication or SSO level. For example, this could indicate there are missing headers or parameters that are required, an invalid or missing storage password, or Syncplicity Orchestration is unavailable.
The following metrics are used to monitor thumbnail health. The thumbnail API is called when a Syncplicity client issues a request to retrieve an image thumbnail or generate a thumbnail.
When thumbnail.error.40x or thumbnail.error.500 counts are present with frequency or high volume this is indicative of an error during thumbnail generation, the thumbnail requested does not exist, or either storage or Syncplicity Orchestration was unavailable to service the request.
Syncplicity Services Metrics
The following metrics may appear in your data stream but should be ignored at this time as they are for future integrations. They measure performance of Storage Connector calls to other Syncplicity web services.
JVM total heap used
The total number of active threads in the JVM
The current CPU load
The lapsed CPU time since the last screen update, expressed as a percentage of total CPU time.
The JVM share of the elapsed CPU time
The total free physical memory available
The system load average for the last minute multiplied by 100
The total physical memory
The number of loaded classes
The number of of unloaded classes
The total initial memory
The total memory used
The maximum available jvm memory
The total memory committed
The initial heap memory
Total heap memory used
The maximum available heap memory
The total heap memory committed
The initial non-heap memory
The total non-heap memory used
The maximum available non-heap memory
The total non-heap memory committed
The total number of open OS file descriptors
The maximum available system open OS file descriptors
The number of threads in a specific state
The number of invocations of a garbage collector
The total time spent in a garbage collector