# Monitoring Amazon File Cache
<a name="monitoring_overview"></a>

You can use the following automated monitoring tools to watch Amazon File Cache and report when something is wrong:
+ **Monitoring using Amazon CloudWatch** – CloudWatch collects and processes raw data from Amazon File Cache into readable, near real-time metrics. You can create a CloudWatch alarm that sends an Amazon SNS message when the alarm changes state.
+ **Log monitoring using AWS CloudTrail** – You can share log files between accounts, monitor CloudTrail log files in real time by sending them to CloudWatch Logs, write log processing applications in Java, and validate that your log files have not changed after delivery by CloudTrail.

**Topics**
+ [Monitoring with CloudWatch](monitoring-cloudwatch.md)
+ [Logging Amazon File Cache API calls with CloudTrail](logging-using-cloudtrail.md)

# Monitoring with CloudWatch
<a name="monitoring-cloudwatch"></a>

You can monitor caches using Amazon CloudWatch, which collects and processes raw data from Amazon File Cache into readable, near real-time metrics. These statistics are retained for a period of 15 months so that you can access historical information and gain a better perspective on how your web application or service is performing. By default, Amazon File Cache metric data is automatically sent to CloudWatch at 1-minute periods. For more information about CloudWatch, see [What Is Amazon CloudWatch?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) in the *Amazon CloudWatch User Guide*.

CloudWatch metrics are reported as raw *Bytes*. Bytes are not rounded to either a decimal or binary multiple of the unit.

CloudWatch metrics for an Amazon File Cache resource are organized into three categories:
+ [Front-end I/O metrics](frontend-io-metrics.md)
+ [Backend I/O metrics](backend-io-metrics.md)
+ [Cache utilization metrics](utilization-metrics.md)

All CloudWatch metrics for Amazon File Cache are published to the `AWS/FSx` namespace in CloudWatch. For each metric, Amazon File Cache emits a data point per disk per minute. To view aggregate cache details, you can use the `Sum` statistic. Note that the file servers behind your caches are spread across multiple disks.

# Front-end I/O metrics
<a name="frontend-io-metrics"></a>

The following metrics report cache-level information on system read and write operations. All these metrics take one dimension (`FileCacheId`) and are published into the `AWS/FSx` namespace in CloudWatch.


| Metric | Description | 
| --- | --- | 
| DataReadBytes |  The number of bytes for cache read operations. The `Sum` statistic is the total number of bytes associated with read operations during the period. The `Minimum` statistic is the minimum number of bytes associated with read operations on a single disk. The `Maximum` statistic is the maximum number of bytes associated with read operations on the disk. The `Average` statistic is the average number of bytes associated with read operations per disk. The `SampleCount` statistic is the number of disks. To calculate the average throughput (bytes per second) for a period, divide the `Sum` statistic by the number of seconds in the period. Units: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fsx/latest/FileCacheGuide/frontend-io-metrics.html) Valid statistics: `Sum`, `Minimum`, `Maximum`, `Average`, `SampleCount`.  | 
| DataWriteBytes |  The number of bytes for cache write operations. The `Sum` statistic is the total number of bytes associated with write operations. The `Minimum` statistic is the minimum number of bytes associated with write operations on a single disk. The `Maximum` statistic is the maximum number of bytes associated with write operations on the disk. The `Average` statistic is the average number of bytes associated with write operations per disk. The `SampleCount` statistic is the number of disks. To calculate the average throughput (bytes per second) for a period, divide the `Sum` statistic by the number of seconds in the period. Units: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fsx/latest/FileCacheGuide/frontend-io-metrics.html) Valid statistics: `Sum`, `Minimum`, `Maximum`, `Average`, `SampleCount`.  | 
| DataReadOperations |  The number of read operations. The `Sum` statistic is the total number of read operations. The `Minimum` statistic is the minimum number of read operations on a single disk. The `Maximum` statistic is the maximum number of read operations on the disk. The `Average` statistic is the average number of read operations per disk. The `SampleCount` statistic is the number of disks. To calculate the average number of read operations (operations per second) for a period, divide the `Sum` statistic by the number of seconds in the period. Units: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fsx/latest/FileCacheGuide/frontend-io-metrics.html) Valid statistics: `Sum`, `Minimum`, `Maximum`, `Average`, `SampleCount`.  | 
| DataWriteOperations |  The number of write operations. The `Sum` statistic is the total number of write operations. The `Minimum` statistic is the minimum number of write operations on a single disk. The `Maximum` statistic is the maximum number write operations on the disk. The `Average` statistic is the average number of write operations per disk. The `SampleCount` statistic is the number of disks. To calculate the average number of write operations (operations per second) for a period, divide the `Sum` statistic by the number of seconds in the period. Units: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fsx/latest/FileCacheGuide/frontend-io-metrics.html) Valid statistics: `Sum`, `Minimum`, `Maximum`, `Average`, `SampleCount`.  | 
| MetadataOperations |  The number of metadata operations. The `Sum` statistic is the count of metadata operations. The `Minimum` statistic is the minimum number of metadata operations per disk. The `Maximum` statistic is the maximum number of metadata operations per disk. The `Average` statistic is the average number of metadata operations per disk. The `SampleCount` statistic is the number of disks. To calculate the average number of metadata operations (operations per second) for a period, divide the `Sum` statistic by the number of seconds in the period. Units: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fsx/latest/FileCacheGuide/frontend-io-metrics.html) Valid statistics: `Sum`, `Minimum`, `Maximum`, `Average`, `SampleCount`.  | 

# Backend I/O metrics
<a name="backend-io-metrics"></a>

The following metrics report information on read and write operations between the cache and its linked data repository. The metric takes one dimension (`FileCacheId`) and is published into the `AWS/FSx` namespace in CloudWatch.


| Metric | Description | 
| --- | --- | 
| `RepositoryReadSuccess` | The rates of files being read into the cache from its linked data repository. | 
| `RepositoryReadFailure` | The rate of files failing to be read into the cache from its linked data repositories. If you observe a high rate of read failures, check if any data repository association (DRA) is unreachable or misconfigured, and if the link between your VPC and an on-premises data store is saturated. If the link is not saturated, you can create a larger cache.  | 
| `RepositoryWriteSuccess` | The rate of files being written from the cache to its linked data repositories. | 
| `RepositoryMetadataReadSuccess` | Understand the rate at which the workload is triggering the loading of file and directory metadata into the cache. | 
| `RepositoryMetadataReadFail` | The rate of file and directory metadata failing to be read into the cache from its linked data repositories. If you have high metadata read failures, check the connectivity to the linked data repository and share the workload.  | 
| `RepositoryMetadataReadNotFound` | The rate at which cache is looking up the data repository for paths that don't exist. | 
| `RepositoryOperationsInProgress` | The number of read and write operations (including metadata operations) on data repositories that are in progress. | 

# Cache utilization metrics
<a name="utilization-metrics"></a>

The following metrics report cache-level storage information. These metrics take one dimension (`FileCacheId`) and are published into the `AWS/FSx` namespace in CloudWatch.


| Metric | Description | 
| --- | --- | 
| `FreeDataStorageCapacity` |  The amount of available data storage capacity. The `Sum` statistic is the total number of bytes available in the cache The `Minimum` statistic is the total number bytes available in the fullest disk. The `Maximum` statistic is the total number of bytes available in the disk with the most remaining available storage. The `Average` statistic is the average number of bytes available per disk. The `SampleCount` statistic is the number of disks. Units: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fsx/latest/FileCacheGuide/utilization-metrics.html) Valid statistics: `Sum`, `Minimum`, `Maximum`, `Average`, `SampleCount`.  | 
| `FreeMetadataStorageCapacity` | The amount of available metadata storage capacity. The `Sum` statistic is the total number of bytes of metadata storage available in the cache. The `Minimum` statistic is the total number of bytes available in the fullest metadata target (MDT) disk. The `Maximum` statistic is the total number of bytes available in the MDT disk with the most remaining storage. The `Average` statistic is the average number of bytes available per MDT disk. The `SampleCount` statistic is the number of MDT disks. Units: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fsx/latest/FileCacheGuide/utilization-metrics.html) Valid statistics: `Sum`, `Minimum`, `Maximum`, `Average`, `SampleCount`.  | 

# How to use Amazon File Cache metrics
<a name="how_to_use_metrics"></a>

The metrics reported by Amazon File Cache provide information that you can analyze in different ways. The following list shows some common uses for the metrics. These are suggestions to get you started, not a comprehensive list.


| How Do I Determine... | Relevant Metrics | 
| --- | --- | 
| My cache's throughput? | SUM(DataReadBytes \$1 DataWriteBytes)/Period (in seconds)  | 
| My cache's IOPS? | Total IOPS = SUM(DataReadOperations \$1 DataWriteOperations \$1 MetadataOperations)/Period (in seconds) | 

# Accessing CloudWatch metrics
<a name="accessingmetrics"></a>

You can see Amazon File Cache metrics for Amazon CloudWatch Logs in many ways. You can view them through the CloudWatch console, or you can access them using the CloudWatch CLI or the CloudWatch API. The following procedures show you how to access the metrics using these various tools.

**To view metrics using the CloudWatch console**

1. Open the [CloudWatch console](https://console.aws.amazon.com/cloudwatch).

1. In the navigation pane, choose **Metrics**. 

1. Select the **FSx** namespace.

1. (Optional) To view a metric, type its name in the search field.

1. (Optional) To filter by dimension, select **FileCacheId**.

**To access metrics from the AWS CLI**
+ Use the [https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html) command with the `--namespace "AWS/FSx"` namespace. For more information, see the [AWS CLI Command Reference](https://docs.aws.amazon.com/cli/latest/reference/).

**To access metrics from the CloudWatch API**
+ Call `[GetMetricStatistics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)`. For more information, see [Amazon CloudWatch API Reference](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/). 

# Creating CloudWatch alarms to monitor Amazon File Cache
<a name="creating_alarms"></a>

You can create an Amazon CloudWatch Logs alarm that sends an Amazon SNS message when the alarm's state changes. An alarm watches a single metric over a time period that you specify, and performs one or more actions based on the value of the metric relative to a given threshold over a number of time periods. The action is a notification sent to an Amazon SNS topic or Auto Scaling policy.

Alarms invoke actions for sustained state changes only. CloudWatch alarms don't invoke actions because they are in a particular state; the state must have changed and been maintained for a specified number of periods.

The following procedures outline how to create alarms for an Amazon File Cache resource.

**To set alarms using the CloudWatch console**

1. Sign in to the AWS Management Console and open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).

1. Choose **Create Alarm**. Doing this launches the Create Alarm Wizard.

1. Choose **FSx Metrics** and scroll through the Amazon File Cache metrics to locate the metric that you want to place an alarm on. To display only the Amazon File Cache metrics in this dialog box, search the cache ID of your cache. Choose the metric to create an alarm on, and choose **Next**.

1. In the **Conditions** section, choose the conditions that you want for the alarm, then choose **Next**.
**Note**  
Metrics may not be published during system maintenance. To prevent unnecessary and misleading alarm condition changes and to configure your alarms so that they are resilient to missing data points, see [ Configuring how CloudWatch alarms treat missing data](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data) in the *Amazon CloudWatch User Guide*.

1. If you want CloudWatch to send you an email when the alarm state is reached, for **Whenever this alarm**, choose **State is ALARM**. For **Send notification to**, choose an existing SNS topic. If you choose **Create topic**, you can set the name and email addresses for a new email subscription list. This list is saved and appears in this box for future alarms.
**Note**  
If you use **Create topic** to create a new Amazon SNS topic, verify the email addresses before sending them notifications. Emails are only sent when the alarm enters an alarm state. If this alarm state change happens before the email addresses are verified, they don't receive a notification.

1. Preview the alarm you're about to create in the **Alarm Preview** area. If it appears as expected, choose **Create Alarm**. 

**To set an alarm using the AWS CLI**
+ Call `[put-metric-alarm](https://docs.aws.amazon.com/cli/latest/reference/put-metric-alarm.html)`. For more information, see *[AWS CLI Command Reference](https://docs.aws.amazon.com/cli/latest/reference/)*.

**To set an alarm using the CloudWatch API**
+ Call `[PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html)`. For more information, see *[Amazon CloudWatch API Reference](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/)*. 

# Logging Amazon File Cache API calls with CloudTrail
<a name="logging-using-cloudtrail"></a>

Amazon File Cache is integrated with AWS CloudTrail, a service that provides a record of actions taken by a user, role, or an AWS service in Amazon File Cache. CloudTrail captures all API calls for Amazon File Cache as events. Captured calls include calls from the Amazon File Cache console and from code calls to Amazon File Cache API operations.

If you create a trail, you can enable continuous delivery of CloudTrail events to an Amazon S3 bucket, including events for Amazon File Cache. If you don't configure a trail, you can still view the most recent events in the CloudTrail console in **Event history**. Using the information collected by CloudTrail, you can determine the request that was made to Amazon File Cache. You can also determine the IP address from which the request was made, who made the request, when it was made, and additional details. 

To learn more about CloudTrail, see the [AWS CloudTrail User Guide](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).

## Amazon File Cache information in CloudTrail
<a name="service-name-info-in-cloudtrail"></a>

CloudTrail is enabled on your AWS account when you create the account. When API activity occurs in Amazon File Cache, that activity is recorded in a CloudTrail event along with other AWS service events in **Event history**. You can view, search, and download recent events in your AWS account. For more information, see [Viewing Events with CloudTrail Event History](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html). 

For an ongoing record of events in your AWS account, including events for Amazon File Cache, create a trail. A trail enables CloudTrail to deliver log files to an Amazon S3 bucket. By default, when you create a trail in the console, the trail applies to all AWS Regions. The trail logs events from all AWS Regions in the AWS partition and delivers the log files to the Amazon S3 bucket that you specify. Additionally, you can configure other AWS services to further analyze and act upon the event data collected in CloudTrail logs. For more information, see the following topics in the *AWS CloudTrail User Guide:* 
+ [Overview for Creating a Trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail Supported Services and Integrations](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [Configuring Amazon SNS Notifications for CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html)
+ [Receiving CloudTrail Log Files from Multiple Regions](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) and [Receiving CloudTrail Log Files from Multiple Accounts](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)

All Amazon File Cache [API calls](https://docs.aws.amazon.com/fsx/latest/APIReference/Welcome.html) are logged by CloudTrail. For example, calls to the `CreateFileCache` and `TagResource` operations generate entries in the CloudTrail log files.

Every event or log entry contains information about who generated the request. The identity information helps to determine the following: 
+ Whether the request was made with root or AWS Identity and Access Management (IAM) user credentials.
+ Whether the request was made with temporary security credentials for a role or federated user.
+ Whether the request was made by another AWS service.

For more information, see the [CloudTrail userIdentity Element](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html) in the *AWS CloudTrail User Guide.*

## Understanding Amazon File Cache log file entries
<a name="understanding-service-name-entries"></a>

A *trail* is a configuration that enables delivery of events as log files to an Amazon S3 bucket that you specify. CloudTrail log files contain one or more log entries. An *event* represents a single request from any source and includes information about the requested action, the date and time of the action, request parameters, and so on. CloudTrail log files aren't an ordered stack trace of the public API calls, so they don't appear in any specific order.