This document describes the metrics collected within the Nasuni Orchestration Center (NOC).
We classify the information stored or created on an appliance into two categories:
Data: Data consists of the contents of a file. Data is never sent to the Nasuni NOC. Data exists only on your appliance and in the object store of your cloud provider.
Metadata: Metadata is any information about the file or the filesystem.
About data
Data is never sent to the Nasuni NOC. Data exists only on your appliance and in the object store of your cloud provider.
About metadata
Metadata, however, can exist in five places within the Nasuni system:
#1: Within the contents of the file.
This type of metadata is similar to data, in that they only exist on your appliances and in the object store of your cloud provider. They are never sent to Nasuni's NOC.
Examples:
Path name of the file.
Usernames that have accessed the file.
Size of the file.
Groups that have permissions on the file, such as access control lists (ACLs).
#2: As independent metadata files within UniFS (Nasuni’s global file system).
This type of metadata is also similar to data, in that they only exist on your appliances and in the object store of your cloud provider. They are never sent to Nasuni's NOC.
Examples:
Path name of the file.
Usernames that have accessed the file.
Size of the file.
Groups that have permissions on the file, such as access control lists (ACLs).
#3: As non-identifiable information in our NOC.
This metadata includes one-way salted hashes of usernames and path names, and GUIDs representing the volume names and appliance names.
This metadata is used to process the transactions in the system, such as global file locks and appliances’ snapshots.
This metadata exists temporarily in databases stored in the Nasuni NOC.
This metadata can also exist in the file names of log files generated by those services. An example of one of those log file names is:
Push lock for volume 81b02f16-d6e3-4b38-8d81-b7e16004abc1_0 rejected for filer f1406bdd-d4b2-4972-a6d5-0fe07b40deb7 due to fairness algorithm
Notice that the name of the volume and the name of the appliance (sometimes called a “filer”) are not identified. In addition, there is nothing in these logs that can tie these GUIDs back to the volume name, appliance name, or customer name. These logs generally rotate every six months.
#4: As information presented through the Nasuni dashboard at account.nasuni.com.
This metadata includes names of volumes and appliances. This metadata is stored in our NOC dashboard so that customers can have a view into the aggregate performance of their system. This information is stored in our analytics database, which is intentionally kept separate from the transactional data in #3 above.
Here is an example of an image created from this metadata. This example shows quota usage for a collection of appliances. As you can see, this is aggregate information and does not refer back to the specific transactions referenced in #3 above.
#5: As information inside alert bundles.
This metadata can include path names of files and names of volumes that are occasionally stored in log files on the appliance. Those log files can be periodically sent back to Nasuni as part of an alert bundle.
Similar to #3, the alert bundles are named using non-identifiable GUIDs and are stored in an AWS S3 bucket in the Nasuni NOC.
An example of a log line in a log file is this:
2020-04-04 18:26:50.086 cacheman 30044:push.334 (INFO): Directory /now/coldcashpulltest/readdirenabled push finished, [err: no error], [total entries: 0] latency [total:143, db:1, fs:0, xml:0, network:0], pushed 0 new chunks, 1 dirty shards
You can see that the path /now/coldcashpulltest/readdirenabled is referenced in the logline. However, there is no information about the user who accessed the file or directory, or any information about the contents of the file. That information is never available to the logging services on the appliance.