翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AWS Transfer Family サーバーの Amazon CloudWatch ログ記録
Amazon CloudWatch は、 AWS リソースを包括的に可視化する強力なモニタリングおよびオブザーバビリティサービスです AWS Transfer Family。
+ リアルタイムモニタリング: CloudWatch は Transfer Family のリソースとアプリケーションをリアルタイムでモニタリングするため、パフォーマンスを追跡および分析できます。
+ メトリクスの収集: CloudWatch は、リソースとアプリケーションのさまざまなメトリクスを収集して追跡します。これは、測定して分析に使用できる変数です。
+ CloudWatch ホームページ: CloudWatch ホームページには、Transfer Family やその他の AWS サービスに関するメトリクスが自動的に表示され、モニタリングデータを一元的に表示できます。
+ カスタムダッシュボード: CloudWatch でカスタムダッシュボードを作成して、カスタムアプリケーションとモニタリングするリソースに固有のメトリクスを表示できます。
+ アラームと通知: CloudWatch では、メトリクスをモニタリングし、特定のしきい値を超えたときに通知または自動アクションをトリガーするアラームを作成できます。これは、Transfer Family サーバーのファイル転送アクティビティをモニタリングし、それに応じてリソースをスケーリングする場合に便利です。
+ コストの最適化: CloudWatch によって収集されたデータを使用して、使用率の低いリソースを特定し、インスタンスの停止や削除などのアクションを実行してコストを最適化できます。
全体として、CloudWatch の包括的なモニタリング機能は、Transfer Family インフラストラクチャとその上で実行されているアプリケーションを管理および最適化するための貴重なツールです。
Transfer Family ウェブアプリケーションの CloudWatch ログ記録の詳細については、「」を参照してください[Transfer Family ウェブアプリケーションの CloudTrail ログ記録](webapp-cloudtrail.md)。
## Transfer Family の CloudWatch ログ記録のタイプ
Transfer Family には、CloudWatch にイベントを記録する 2 つの方法があります。
+ JSON 構造化ログ記録
+ ログ記録ロールによるログ記録
Transfer Family サーバーでは、必要なログ記録メカニズムを選択できます。コネクタとワークフローでは、ログ記録ロールのみがサポートされています。
**JSON 構造化ログ記録**
サーバーイベントのログ記録には、JSON 構造化ログ記録を使用することをお勧めします。これにより、CloudWatch ログクエリを有効にする、より包括的なログ記録形式が提供されます。このタイプのログ記録では、サーバーを作成する (またはサーバーのログ記録設定を編集する) ユーザーの IAM ポリシーに、次のアクセス許可が含まれている必要があります。
+ `logs:CreateLogDelivery`
+ `logs:DeleteLogDelivery`
+ `logs:DescribeLogGroups`
+ `logs:DescribeResourcePolicies`
+ `logs:GetLogDelivery`
+ `logs:ListLogDeliveries`
+ `logs:PutResourcePolicy`
+ `logs:UpdateLogDelivery`
以下は、ポリシーの例です。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"logs:CreateLogDelivery",
"logs:GetLogDelivery",
"logs:UpdateLogDelivery",
"logs:DeleteLogDelivery",
"logs:ListLogDeliveries",
"logs:PutResourcePolicy",
"logs:DescribeResourcePolicies",
"logs:DescribeLogGroups"
],
"Resource": "*"
}
]
}
```
JSON 構造化ロギングの設定の詳細については、「」を参照してください[サーバーのログ記録の作成、更新、表示](log-server-manage.md)。
**ログ記録ロール**
サーバーにアタッチされているマネージドワークフローとコネクタのイベントをログに記録するには、ログ記録ロールを指定する必要があります。アクセス権を設定するには、リソースベースの IAM ポリシー、およびアクセス情報を提供する IAM ロールを作成します。以下は、サーバーイベント AWS アカウント を記録できる のポリシーの例です。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:DescribeLogStreams",
"logs:CreateLogGroup",
"logs:PutLogEvents"
],
"Resource": "arn:aws:logs:*:*:log-group:/aws/transfer/*"
}
]
}
```
ワークフローイベントをログに記録するようにログ記録ロールを設定する方法の詳細については、「」を参照してください[ワークフローのログ記録の管理](cloudwatch-workflows.md)。
# サーバーのログ記録の作成、更新、表示
すべての AWS Transfer Family サーバーについて、構造化ログ記録を提供します。すべての新規および既存の Transfer Family サーバーには、構造化ログ記録を使用することをお勧めします。構造化ログ記録を使用する利点は次のとおりです。
+ 構造化された JSON 形式でログを受信します。
+ Amazon CloudWatch Logs Insights を使用してログをクエリすると、JSON 形式のフィールドが自動的に検出されます。
+ AWS Transfer Family リソース間でロググループを共有すると、複数のサーバーからのログストリームを 1 つのロググループに結合できるため、モニタリング設定とログ保持設定を簡単に管理できます。
+ CloudWatch ダッシュボードに追加できる集約されたメトリクスとビジュアライゼーションを作成します。
+ ロググループを使用して使用状況とパフォーマンスデータを追跡し、統合されたログメトリクス、ビジュアライゼーション、ダッシュボードを作成します。
サーバーにアタッチされているワークフローのログ記録を有効にするには、ログ記録ロールを使用する必要があります。
**注記**
ログ記録ロールを追加する場合、ログ記録グループは常に であり`/aws/transfer/your-serverID`、変更することはできません。つまり、構造化サーバーログを同じグループに送信しない限り、2 つの個別のロググループにログ記録されます。
ワークフローをサーバーに関連付けることがわかっていて、ログ記録ロールを追加する必要がある場合は、 のデフォルトのロググループにログ記録するように構造化ログ記録を設定できます`/aws/transfer/your-serverID`。
ログ記録グループを変更するには、 *AWS Transfer Family API リファレンス*の[StructuredLogDestinations](https://docs.aws.amazon.com/transfer/latest/APIReference/API_UpdateServer.html#TransferFamily-UpdateServer-request-StructuredLogDestinations)」を参照してください。
Transfer Family コンソールを使用して新しいサーバーを作成する場合、ログ記録がデフォルトで有効になります。サーバーを作成したら、 `UpdateServer` API オペレーションを使用してログ記録設定を変更できます。詳細については、「[構造化ログ送信先](https://docs.aws.amazon.com/transfer/latest/APIReference/API_UpdateServer.html#TransferFamily-UpdateServer-request-StructuredLogDestinations)」を参照してください。
現在、ワークフローでロギングを有効にする場合は、ロギングロールを指定する必要があります。
+ `CreateServer` または `UpdateServer` API オペレーションを使用してワークフローをサーバーに関連付けると、システムは自動的にログ記録ロールを作成しません。ワークフローイベントをログに記録する場合は、ロギングロールをサーバーに明示的にアタッチする必要があります。
+ Transfer Family コンソールを使用してサーバーを作成し、ワークフローをアタッチすると、ログは名前にサーバー ID を含むロググループに送信されます。形式は`/aws/transfer/server-id`で、例えば、`/aws/transfer/s-1111aaaa2222bbbb3`です。サーバーログは、同じロググループに送信することも、別のロググループに送信することもできます。
**コンソールでサーバーを作成および編集する際のロギングに関する考慮事項**
+ コンソールによって作成された新しいサーバーは、ワークフローがサーバーにアタッチされていない限り、構造化された JSON ロギングのみをサポートします。
+ コンソールで作成する新しいサーバーでは、ログを記録しないという選択肢はありません。
+ 既存のサーバーでは、いつでもコンソールによって構造化された JSON ロギングを有効にすることができます。
+ コンソールによって構造化された JSON ロギングを有効にすると、既存のロギング方法が無効になるため、顧客への二重請求を防ぐことができます。ワークフローがサーバーにアタッチする場合は例外です。
+ 構造化 JSON ロギングを有効にした場合、後でコンソールから無効にすることはできません。
+ 構造化 JSON ロギングを有効にすると、コンソールからロググループの送信先をいつでも変更できます。
+ 構造化 JSON ロギングを有効にした場合、API を使用して両方のロギングタイプを有効にしていれば、コンソールからロギングロールを編集することはできません。例外は、サーバーにワークフローがアタッチされている場合です。ただし、ロギングロールは引き続き **[その他の詳細]** に表示されます。
**API または SDK を使用してサーバーを作成および編集する際のロギングに関する考慮事項**
+ API を使用して新しいサーバーを作成する場合、ロギングのどちらかまたは両方のタイプを設定することも、ロギングなしを選択することもできます。
+ 既存のサーバーでは、構造化 JSON ロギングをいつでも有効または無効にできます。
+ ロググループは、API を使用していつでも変更できます。
+ ログ記録の役割は、API を使用していつでも変更できます。
**構造化ログ記録を有効にするには、以下のアクセス許可でアカウントにログインする必要があります**
+ `logs:CreateLogDelivery`
+ `logs:DeleteLogDelivery`
+ `logs:DescribeLogGroups`
+ `logs:DescribeResourcePolicies`
+ `logs:GetLogDelivery`
+ `logs:ListLogDeliveries`
+ `logs:PutResourcePolicy`
+ `logs:UpdateLogDelivery`
ポリシーの例は、「」セクションで入手できます[CloudWatch ログ記録ロールを設定する](configure-cw-logging-role.md)。
**Topics**
+ [サーバーのログ記録の作成](#log-server-create)
+ [サーバーのロギングを更新します。](#log-server-update)
+ [サーバー設定の表示](#log-server-config)
## サーバーのログ記録の作成
新しいサーバーを作成する場合、「**詳細の設定**」ページで、既存のロググループを指定するか、新しいロググループを作成できます。
![\[サーバー作成ウィザードの [追加情報の詳細] を構成するためのログペイン。既存のロググループを選択します。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/logging-server-choose-existing-group.png)
**[ロググループの作成]** を選択すると、CloudWatch コンソール ([「https://console.aws.amazon.com/cloudwatch/」](https://console.aws.amazon.com/cloudwatch/)) が開き、**[ロググループの作成]** ページが表示されます。詳細は「[CloudWatch Logsでロググループを作成する](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#Create-Log-Group)」を参照してください。
## サーバーのロギングを更新します。
ロギングの詳細は、更新のシナリオによって異なります。
**注記**
構造化JSONロギングを選択した場合、まれに、TTransfer Family ilyが古い形式でのロギングを停止し、新しいJSON形式でのロギングを開始するまでに時間がかかるという遅延が発生することがあります。その結果、イベントが記録されないことがあります。サービスが中断されることはありませんが、ログ記録方法を変更してから最初の 1 時間はログが削除される可能性があるため、ファイルの転送には注意が必要です。
既存のサーバーを編集する場合、オプションはサーバーの状態によって異なります。
+ サーバーではすでにロギングロールが有効になっていますが、Structured JSON ロギングは有効になっていません。
![\[ロギングペイン。既存のロギングロールが表示されます。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/logging-server-choose-role.png)
+ サーバーでログ記録が有効になっていません。
![\[ロギングペイン (サーバーでロギングが有効になっていない場合)。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/logging-server-edit-none.png)
+ サーバーでは既に Structured JSON ロギングが有効になっていますが、ロギングロールは指定されていません。
![\[サーバーでまだロギングが有効になっていない場合はロギングペインになります。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/logging-server-edit-add-json-02.png)
+ サーバーでは既に Structured JSON ロギングが有効になっており、ロギングロールも指定されています。
![\[サーバーで構造化ログが有効になっており、ログの役割も指定されている場合は、ロギングペインになります。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/logging-server-edit-both.png)
## サーバー設定の表示
サーバー設定ページの詳細は、シナリオによって異なります。
シナリオによっては、サーバー設定ページが以下のいずれかの例のようになる場合があります。
+ ログは有効になっていません。
![\[ロギングが設定されていない場合のロギング設定。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/logging-server-config-none.png)
+ 構造化 JSON ロギングが有効になっています。
![\[構造化ロギングによって設定されたロギング設定。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/logging-server-config-structured.png)
+ ロギングロールは有効ですが、構造化 JSON ロギングは有効になっていません。
![\[ロギングロールによって設定されたロギング設定。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/logging-server-config-legacy.png)
+ どちらの種類のロギング (ロギングロールと構造化 JSON ロギング) も有効になっています。
![\[両方のタイプのロギング (ロギングロールと構造化 JSON ロギング) によって設定されたロギング設定。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/logging-server-config-both.png)
# ワークフローのログ記録の管理
CloudWatch は、ワークフローの進行状況と結果に関する統合監査とログ記録を提供します。さらに、 はワークフローの複数のメトリクス AWS Transfer Family を提供します。過去 1 分間に開始された、正常に完了した、失敗したワークフロー実行の数を示す指標を表示できます。Transfer Family の CloudWatch メトリクスについては、[Transfer Family サーバーの CloudWatch メトリクスの使用](metrics.md)で説明しています。
**ワークフローの Amazon CloudWatch Logs を表示する**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) で Amazon CloudWatch コンソールを開きます。
1. 左側のナビゲーションペインで、「**ログ**」を選択し、「**ロググループ**」を選択します。
1. **ロググループ**ページのナビゲーションバーで、 AWS Transfer Family サーバーに適したリージョンを選択します。
1. サーバーに対応するロググループを選択します。
例えば、サーバー ID が `s-1234567890abcdef0` であれば、ロググループは `/aws/transfer/s-1234567890abcdef0` です。
1. サーバーのロググループの詳細ページに、最新のログストリームが表示されます。調査対象のユーザーには 2 つのログストリームがあります。
+ Secure Shell (SSH) File Transfer Protocol (SFTP) セッションごとに 1 つずつ。
+ 1 つはサーバーで実行中のワークフロー用です。ワークフローのログストリームの形式は `username.workflowID.uniqueStreamSuffix` です。
例えば、ユーザーが `mary-major` である場合、以下のようなログストリームがある：
```
mary-major-east.1234567890abcdef0
mary.w-abcdef01234567890.021345abcdef6789
```
**注記**
この例に挙げた 16 桁の英数字の識別子は架空のものです。Amazon CloudWatch に表示される値は異なります。
`mary-major-usa-east.1234567890abcdef0`の **[ログイベント]** ページには各ユーザーセッションの詳細が表示され、`mary.w-abcdef01234567890.021345abcdef6789`ログストリームにはワークフローの詳細が含まれます。
以下は、コピーステップを含むワークフロー（`w-abcdef01234567890`）に基づく、`mary.w-abcdef01234567890.021345abcdef6789` のログストリームのサンプルです。
```
{
"type": "ExecutionStarted",
"details": {
"input": {
"initialFileLocation": {
"bucket": "amzn-s3-demo-bucket",
"key": "mary/workflowSteps2.json",
"versionId": "version-id",
"etag": "etag-id"
}
}
},
"workflowId":"w-abcdef01234567890",
"executionId":"execution-id",
"transferDetails": {
"serverId":"s-server-id",
"username":"mary",
"sessionId":"session-id"
}
},
{
"type":"StepStarted",
"details": {
"input": {
"fileLocation": {
"backingStore":"S3",
"bucket":"amzn-s3-demo-bucket",
"key":"mary/workflowSteps2.json",
"versionId":"version-id",
"etag":"etag-id"
}
},
"stepType":"COPY",
"stepName":"copyToShared"
},
"workflowId":"w-abcdef01234567890",
"executionId":"execution-id",
"transferDetails": {
"serverId":"s-server-id",
"username":"mary",
"sessionId":"session-id"
}
},
{
"type":"StepCompleted",
"details":{
"output":{},
"stepType":"COPY",
"stepName":"copyToShared"
},
"workflowId":"w-abcdef01234567890",
"executionId":"execution-id",
"transferDetails":{
"serverId":"server-id",
"username":"mary",
"sessionId":"session-id"
}
},
{
"type":"ExecutionCompleted",
"details": {},
"workflowId":"w-abcdef01234567890",
"executionId":"execution-id",
"transferDetails":{
"serverId":"s-server-id",
"username":"mary",
"sessionId":"session-id"
}
}
```
# CloudWatch ログ記録ロールを設定する
アクセス権を設定するには、リソースベースの IAM ポリシー、およびアクセス情報を提供する IAM ロールを作成します。
Amazon CloudWatch ログ記録を有効にするには、CloudWatch ログ記録を有効にする IAM ポリシーの作成から開始します。次いで、IAM ロールを作成して、ポリシーをアタッチします。そのためには、[サーバーを作成](getting-started.md#getting-started-server)するか[既存のサーバーを編集](edit-server-config.md)します。CloudWatch の詳細については、Amazon CloudWatch ユーザーガイドの「[Amazon CloudWatch とは何か](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)」と「[Amazon CloudWatch Logs とは何か](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)」を参照してください。
CloudWatch のロギングを許可するには、以下の IAM ポリシーの例を使用します。
------
#### [ Use a logging role ]
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:DescribeLogStreams",
"logs:CreateLogGroup",
"logs:PutLogEvents"
],
"Resource": "arn:aws:logs:*:*:log-group:/aws/transfer/*"
}
]
}
```
------
#### [ Use structured logging ]
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"logs:CreateLogDelivery",
"logs:GetLogDelivery",
"logs:UpdateLogDelivery",
"logs:DeleteLogDelivery",
"logs:ListLogDeliveries",
"logs:PutResourcePolicy",
"logs:DescribeResourcePolicies",
"logs:DescribeLogGroups"
],
"Resource": "*"
}
]
}
```
前述のサンプルポリシーでは、**Resource** について「*region-id*」と「*AWS アカウント*」を自分の値に置き換えます。例: **"Resource": "arn:aws::logs:us-east-1:111122223333:log-group:/aws/transfer/\$1"**
------
次いで、ロールを作成し、作成した CloudWatch Logs ポリシーをアタッチします。
**IAM ロールを作成し、ポリシーをアタッチするには**
1. ナビゲーションペインで [**Roles**] (ロール) を選択してから [**Create role**] (ロールの作成) を選択します。
[**Create role**] (ロールの作成) ページで [**AWS service**] (サービス) が選択されていることを確認します。
1. サービスリストから [**Transfer**] (転送) を選択してから [**Next: Permissions**] (次へ: アクセス許可) を選択します。これにより、 AWS Transfer Family と IAM ロールとの信頼関係が確立されます。さらに、`aws:SourceAccount` と `aws:SourceArn` のコンディション・キーを追加し、「混乱する代理」問題から守ります。詳細は以下のドキュメントを参照のこと：
+ 以下との信頼関係を確立する手順 AWS Transfer Family: [信頼関係を確立するには](requirements-roles.md#establish-trust-transfer)
+ 混乱した代理問題の説明:[混乱した代理問題](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)
1. [**Attach permissions policies**] (アクセス許可ポリシーをアタッチする) セクションで、先ほど作成した CloudWatch Logs ポリシーを選択し、[**Next: Tags**] (次へ: タグ) を選択します。
1. (オプション) タグのキーと値を入力し、[**Next: Review**] (次へ: 確認) を選択します。
1. [**Review**] (確認) ページで新しいロールの名前と説明を入力してから [**Create role**] (ロールの作成) を選択します。
1. ログを表示するには、[**Server ID**] (サーバー ID) を選択してサーバー設定ページを開き、[**View logs**] (ログの表示) を選択します。ログストリームを確認できる CloudWatch コンソールにリダイレクトされます。
サーバー用の CloudWatch ページで、ユーザー認証のレコード (成功と失敗)、データアップロード (`PUT` オペレーション) のレコード、およびデータダウンロード (`GET` オペレーション) のレコードを表示できます。
# Transfer Family ログストリームの表示
**Transfer Familyのサーバーログを表示するには**
1. サーバーの詳細ページに移動します。
1. [**ログを表示**] を選択します。これにより Amazon CloudWatch が開きます。
1. 選択したサーバーのロググループが表示されます。
![\[\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/log-example-01.png)
1. ログストリームを選択すると、そのストリームの詳細と個々のエントリを表示できます。
+ 「**エラー**」のリストがある場合は、それを選択してサーバーの最新のエラーの詳細を表示できます。
![\[\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/log-example-errors.png)
+ 他のエントリを選択すると、ログストリームの例が表示されます。
![\[\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/log-example-02.png)
+ サーバーにマネージド型ワークフローが関連付けられている場合は、ワークフロー実行のログを表示できます。
**注記**
ワークフローのログストリームの形式は `username.workflowId.uniqueStreamSuffix` です。例えば、「**decrypt-user.w-a1111222233334444.aaaa1111bbbb2222**」は、ユーザー **decrypt-user** とワークフロー **w-a1111222233334444** のログストリームの名前になる可能性があります。
![\[\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/log-example-workflow.png)
**注記**
拡張されたログエントリについては、**[コピー]** を選択してエントリをクリップボードにコピーできます。CloudWatch ログの詳細については、「[ログデータの表示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData)」を参照してください。
## Amazon CloudWatch アラームの作成
次の例は、 AWS Transfer Family メトリクス を使用して Amazon CloudWatch アラームを作成する方法を示しています`FilesIn`。
------
#### [ CDK ]
```
new cloudwatch.Metric({
namespace: "AWS/Transfer",
metricName: "FilesIn",
dimensionsMap: { ServerId: "s-00000000000000000" },
statistic: "Average",
period: cdk.Duration.minutes(1),
}).createAlarm(this, "AWS/Transfer FilesIn", {
threshold: 1000,
evaluationPeriods: 10,
datapointsToAlarm: 5,
comparisonOperator: cloudwatch.ComparisonOperator.GREATER_THAN_OR_EQUAL_TO_THRESHOLD,
});
```
------
#### [ CloudFormation ]
```
Type: AWS::CloudWatch::Alarm
Properties:
Namespace: AWS/Transfer
MetricName: FilesIn
Dimensions:
- Name: ServerId
Value: s-00000000000000000
Statistic: Average
Period: 60
Threshold: 1000
EvaluationPeriods: 10
DatapointsToAlarm: 5
ComparisonOperator: GreaterThanOrEqualToThreshold
```
------
## Amazon S3S3 API オペレーションのログ記録
**注記**
このセクションは、Transfer Family ウェブアプリケーションには適用されません。
ユーザーに代わってファイル転送を要求した [S3 リクエストを Amazon S3 アクセスログで特定](https://docs.aws.amazon.com/AmazonS3/latest/dev/using-s3-access-logs-to-identify-requests.html)しようとする場合、ファイル転送を処理すると想定された IAM ロールを表示する際には `RoleSessionName` が使用されます。また、転送に使用されるユーザー名、セッション ID、サーバー ID などの追加情報も表示されます。形式は `[AWS:Role Unique Identifier]/username.sessionid@server-id` で [Requester] (リクエスタ) フィールドに含まれています。たとえば、次に示すのは S3 バケットにコピーされたファイルの S3 アクセスログから得た[Requester] (リクエスタ) フィールドのコンテンツの例です。
`arn:aws:sts::AWS-Account-ID:assumed-role/IamRoleName/username.sessionid@server-id`
上記の [Requester] (リクエスタ) フィールドには、`IamRoleName` と呼ばれる IAM ロールが表示されます。IAM ロールの一意の識別子の詳細については、*AWS Identity and Access Management ユーザーガイド*の「[一意の識別子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids)」を参照してください。
# 混乱する代理問題の防止
混乱した代理問題は、アクションを実行する許可を持たないエンティティが、より特権のあるエンティティにアクションを実行するように強制できるセキュリティの問題です。では AWS、サービス間のなりすましにより、混乱した代理問題が発生する可能性があります。詳細については、[サービス間の混乱した代理の防止](confused-deputy.md)を参照してください。
**注記**
次の例では*ユーザー入力プレースホルダー*をユーザー自身の情報で置き換えます。
これらの例では、サーバーにワークフローがアタッチされていない場合、ワークフローの ARN の詳細を削除できます。
次のログ記録/呼び出しポリシーの例では、アカウント内のすべてのサーバー (およびワークフロー) がロールを引き受けることを許可します。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowAllServersWithWorkflowAttached",
"Effect": "Allow",
"Principal": {
"Service": "transfer.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333"
},
"ArnLike": {
"aws:SourceArn": [
"arn:aws:transfer:us-west-2:111122223333:server/*",
"arn:aws:transfer:us-west-2:111122223333:workflow/*"
]
}
}
}
]
}
```
次のログ記録/呼び出しポリシーの例では、特定のサーバー (およびワークフロー) がロールを引き受けることを許可します。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSpecificServerWithWorkflowAttached",
"Effect": "Allow",
"Principal": {
"Service": "transfer.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333"
},
"ArnEquals": {
"aws:SourceArn": [
"arn:aws:transfer:us-west-2:111122223333:server/server-id",
"arn:aws:transfer:us-west-2:111122223333:workflow/workflow-id"
]
}
}
}
]
}
```
# Transfer Family の CloudWatch ログ構造
このトピックでは、Transfer Family ログに入力されるフィールドについて説明します。JSON 構造化ログエントリとレガシーログエントリの両方についてです。
**Topics**
+ [Transfer Family の JSON 構造化ログ](#json-log-entries)
+ [Transfer Family のレガシーログ](#legacy-log-entries)
## Transfer Family の JSON 構造化ログ
次の表に、Transfer Family SFTP/FTP/FTPS アクションのログエントリフィールドの詳細を、新しい JSON 構造化ログ形式で示します。
| フィールド | 説明 | エントリ例 |
| --- |--- |--- |
| activity-type | The action by the user | 使用可能なアクティビティタイプは、`AUTH_FAILURE`、、`CONNECTED`、`DISCONNECTED`、`ERROR`、、`EXIT_REASON`、、`CLOSE``CREATE_SYMLINK``DELETE`、、`MKDIR`、、`OPEN``PARTIAL_CLOSE``RENAME`、`SETSTAT`、、`RMDIR`、 です`TLS_RESUME_FAILURE`。 |
| bytes-in | Number of bytes uploaded by the user | 29238420042 |
| bytes-out | Number of bytes downloaded by the user | 23094032490328 |
| ciphers | Specifies the SSH cipher negotiated for the connection (available ciphers are listed in [暗号アルゴリズム](security-policies.md#cryptographic-algorithms)) | aes256-gcm@openssh.com |
| client | The user's client software | SSH-2.0-OpenSSH\$17.4 |
| home-dir | The directory that the end user lands on when they connect to the endpoint if their home directory type is PATH: if they have a logical home directory, this value is always / | /user-home-bucket/test |
| kex | Specifies the negotiated SSH key exchange (KEX) for the connection (available KEX are listed in [暗号アルゴリズム](security-policies.md#cryptographic-algorithms)) | diffie-hellman-group14-sha256 |
| message | Provides more information related to the error | ＜文字列＞ |
| method | The authentication method | publickey |
| mode | Specifies how a client opens a file | CREATE \$1 TRUNCATE \$1 WRITE |
| operation | The client operation on a file | OPEN \$1 CLOSE |
| path | Actual file path affected | /amzn-s3-demo-bucket/test-file-1.pdf |
| ssh-public-key | The public key body for the user that is connecting | AAAAC3NzaC1lZDI1NTE5AAAAIA9OY0qV6XYVHaaOiWAcj2spDJVbgjrqDPY4pxd6GnHl |
| ssh-public-key-fingerprint | ユーザーキーを一覧表示するときのサービスマネージドユーザー向けの コンソールに表示されるパブリックキーフィンガープリント。 コンソールでは、末尾に 0 から 3 の等号 (=) までのパディング文字 (存在する場合) を含むフィンガープリントが表示されます。ログエントリでは、このパディングは出力から削除されます。 | SHA256:BY3gNMHwTfjd4n2VuT4pTyLOk82zWZj4KEYEu7y4r/0 |
| ssh-public-key-type | Type of public key: Transfer Family supports RSA-, ECDSA-, and ED25519-formatted keys | ssh-ed25519 |
| resource-arn | A system-assigned, unique identifier for a specific resource (for example, a server) | arn:aws:transfer:ap-northeast-1:12346789012:server/s-1234567890akeu2js2 |
| role | The IAM role of the user | arn:aws:iam::0293883675:role/testuser-role |
| session-id | A system-assigned, unique identifier for a single session | 9ca9a0e1cec6ad9d |
| source-ip | Client IP address | 18.323.0.129 |
| user | The end user's username | myname192 |
| user-policy | The permissions specified for the end user: this field is populated if the user's policy is a session policy. | The JSON code for the session policy that is being used |
## Transfer Family のレガシーログ
次の表に、さまざまな Transfer Family アクションのログエントリの詳細を示します。
**注記**
これらのエントリは、新しい JSON 構造化ログ形式ではありません。
次の表に、さまざまな Transfer Family アクションのログエントリの詳細を、新しい JSON 構造化ログ形式で示します。
| アクション | Amazon CloudWatch Logs 内の対応するログ |
| --- | --- |
| 認証の失敗 | エラー AUTH\$1FAILURE METHOD=PUBLICKey user=LHR message=「RSA SHA256: LFZ3R2NMLY4RAK\$1B7RB1RSVUIBAE\$1A\$1HXG0C7L1JIZ0" SourceIP =3.8.172.211 |
| コピー/タグ/削除/復号ワークフロー | \$1"タイプ」:「ステップ開始」,「詳細」: \$1"入力」: \$1"ファイルロケーション」: \$1"バッキングストア」: "EFS」,「ファイルシステム ID」: "fs-12345678"," パス」:」/lhr/regex.py「\$1\$1," ステップタイプ」: "TAG」,「stepName」:「succes"\$1," workflowId」:「w-1111aaaa2222bbbb3",「executionId」:「81234abcd-1234-efgh-5678-ijklmnopqr90",「転送詳細」: \$1"サーバーId」:「s-1234abcd5678efghi」,「ユーザー名」:「lhr」,「sessionId」:「1234567890abcdef0"\$1\$1 |
| カスタムステップワークフロー | \$1「タイプ」:「カスタムステップが呼び出されました」,「詳細」: \$1"出力」: \$1"token」:「mzm4mjg5ywutytezmy00yjizlwi3ogmtyzu4ogi2ZJQYMZE5"\$1,「StepType」:「CUSTOM」,「SstepName」:「efs-s3\$1copy\$12"\$1," workflowId ID」:「w-9283e49d33297c3f7",「ExecutionID」:「1234abcd-1234-efgh-5678-ijklmnopqr90",「転送詳細」: \$1"serverId」:「s-zzzz1111aaaa22223",「ユーザー名」:「lhr」,「sessionId」:「1234567890 abcdef0\$1\$1 |
| 削除 | lhr.33a8fb495ffb383b DELETE Path=/bucket/user/123.jpg |
| ダウンロード | lhr.33a8fb495ffb383b オープンパス=/bucket/user/123.jpg mode=READ llhr.33a8fb495ffb383b CLOSE Path=/bucket/user/123.jpg BytesOut=3618546 |
| ログイン/ログアウト | user.914984e553bcddb6 CONNECTED SourceIP=1.22.111.222 User=lhr HomeDir=LOGICAL Client=SSH-2.0-OpenSSH\$17.4 Role=arn:aws::iam::123456789012:role/sftp-s3-access ユーザー.914984e553bcddb6 接続解除 |
| Renames | lhr.33a8fb495ffb383b 名前変更 path=/bucket/user/lambo.png newpath=/bucket/user/ferrari.png |
| ワークフローエラーログの例 | \$1「タイプ」:「ステップエラー」,「詳細」: \$1"errorType」:「BAD\$1REQUEST」,「errorMessage」: "Efs ファイルにタグを付けることができません」,「ステップタイプ」:「TAG」,「stepName」:「successful\$1tag\$1step"\$1,「ワークフローId」:「w-1234abcd5678efghi」,「実行 ID」:「81234abcd-1234-efgh-5678-ijklmnopqr90"、「転送詳細」: \$1"serverId」:「s-1234abcd5678efghi」,「ユーザー名」:「lhr」,「セッションId」:「1234567890abcdef0"\$1\$1 |
| Symlinks | lhr.eb49cf7b8651e6d5 CREATE\$1SYMLINK LinkPath=/fs-12345678/LHR/PQR.jpg targetPath=abc.jpg |
| アップロード | lhr.33a8fb495ffb383b OPEN PATH=/bucket/user/123.jpg mode=create\$1truncate\$1Write lhr.33a8fb495ffb383b CLOSE path=/bucket/user/123.jpg BytesIn =3618546 |
| ワークフロー | \$1「タイプ」:「ExecutionStarted」,「詳細」: \$1"入力」: \$1"初期ファイルの場所」: \$1"バッキングストア」: "EFS」,「ファイルシステム ID」:「fs-12345678",「パス」:」/lhr/regex.py「\$1\$1\$1,「workflowId」:「w-1111aaaa2222bbb3",「実行 ID」: "1234 abcd-1234-efgh-5678-ijklmnopqr90",「転送詳細」: \$1"serverId」:「s-zzzz1111aaaa22223",「ユーザー名」:「lhr」,「sessionId」:「1234567890abcdef0"\$1\$1 \$1"タイプ」:「ステップ開始」,「詳細」: \$1"入力」: \$1"ファイルロケーション」: \$1"バッキングストア」: "EFS」,「ファイルシステム ID」: "fs-12345678"," パス」:」/lhr/regex.py「\$1\$1," ステップタイプ」: "CUSTOM」,「stepName」:「efs-s3\$1copy\$12"\$1," workflowId ID」:「w-9283e49d33297c3f7",「ExecutionID」:「1234abcd-1234-efgh-5678-ijklmnopqr90",「転送詳細」: \$1"serverId」:「s-18ca49dce5d842e0b」,「ユーザー名」:「lhr」,「sessionId」:「1234567890abcdef0"\$1\$1 |
# CloudWatchログエントリの例
このトピックでは、ログエントリの例を示します。
**Topics**
+ [転送セッションのログエントリの例](#session-log-examples)
+ [SFTP コネクタのログエントリの例](#example-sftp-connector-logs)
+ [VPC Lattice コネクタのログエントリの例](#example-vpc-lattice-connector-logs)
+ [キー交換アルゴリズムの失敗のログエントリの例](#example-kex-logs)
## 転送セッションのログエントリの例
この例では、SFTP ユーザーが Transfer Family サーバーに接続し、ファイルをアップロードしてから、セッションから切断します。
次のログエントリは、Transfer Family サーバーに接続する SFTP ユーザーを反映しています。
```
{
"role": "arn:aws:iam::500655546075:role/transfer-s3",
"activity-type": "CONNECTED",
"ciphers": "chacha20-poly1305@openssh.com,chacha20-poly1305@openssh.com",
"client": "SSH-2.0-OpenSSH_7.4",
"source-ip": "52.94.133.133",
"resource-arn": "arn:aws:transfer:us-east-1:500655546075:server/s-3fe215d89f074ed2a",
"home-dir": "/test/log-me",
"ssh-public-key": "AAAAC3NzaC1lZDI1NTE5AAAAIA9OY0qV6XYVHaaOiWAcj2spDJVbgjrqDPY4pxd6GnHl",
"ssh-public-key-fingerprint": "SHA256:BY3gNMHwTfjd4n2VuT4pTyLOk82zWZj4KEYEu7y4r/0",
"ssh-public-key-type": "ssh-ed25519",
"user": "log-me",
"kex": "ecdh-sha2-nistp256",
"session-id": "9ca9a0e1cec6ad9d"
}
```
次のログエントリは、Amazon S3 バケットにファイルをアップロードする SFTP ユーザーを反映しています。
```
{
"mode": "CREATE|TRUNCATE|WRITE",
"path": "/test/log-me/config-file",
"activity-type": "OPEN",
"resource-arn": "arn:aws:transfer:us-east-1:500655546075:server/s-3fe215d89f074ed2a",
"session-id": "9ca9a0e1cec6ad9d"
}
```
次のログエントリは、SFTP ユーザーが SFTP セッションから切断していることを反映しています。まず、クライアントはバケットへの接続を閉じ、次にクライアントは SFTP セッションを切断します。
```
{
"path": "/test/log-me/config-file",
"activity-type": "CLOSE",
"resource-arn": "arn:aws:transfer:us-east-1:500655546075:server/s-3fe215d89f074ed2a",
"bytes-in": "121",
"session-id": "9ca9a0e1cec6ad9d"
}
{
"activity-type": "DISCONNECTED",
"resource-arn": "arn:aws:transfer:us-east-1:500655546075:server/s-3fe215d89f074ed2a",
"session-id": "9ca9a0e1cec6ad9d"
}
```
**注記**
使用可能なアクティビティタイプは、`AUTH_FAILURE`、、`CONNECTED`、`DISCONNECTED`、`ERROR`、`EXIT_REASON`、、`CLOSE`、`CREATE_SYMLINK``DELETE`、、`MKDIR`、、`OPEN``PARTIAL_CLOSE`、`RENAME``RMDIR``SETSTAT`、、、、 です`TLS_RESUME_FAILURE`。
## SFTP コネクタのログエントリの例
このセクションでは、転送の成功と失敗の両方のログの例を示します。ログは という名前のロググループに生成されます。ここで`/aws/transfer/connector-id`、*connector-id* は SFTP コネクタの識別子です。SFTP コネクタのログエントリは、 `StartFileTransfer`または `StartDirectoryListing` コマンドを実行すると生成されます。
このログエントリは、正常に完了した転送用です。
```
{
"operation": "RETRIEVE",
"timestamp": "2023-10-25T16:33:27.373720Z",
"connector-id": "connector-id",
"transfer-id": "transfer-id",
"file-transfer-id": "transfer-id/file-transfer-id",
"url": "sftp://192.0.2.0",
"file-path": "/remotebucket/remotefilepath",
"status-code": "COMPLETED",
"start-time": "2023-10-25T16:33:26.945481Z",
"end-time": "2023-10-25T16:33:27.159823Z",
"account-id": "480351544584",
"connector-arn": "arn:aws:transfer:us-east-1:account-id:connector/connector-id",
"local-directory-path": "/connectors-localbucket",
"bytes": 514,
"egress-type": "SERVICE_MANAGED"
}
```
このログエントリは、タイムアウトした転送のため、正常に完了しませんでした。
```
{
"operation": "RETRIEVE",
"timestamp": "2023-10-25T22:33:47.625703Z",
"connector-id": "connector-id",
"transfer-id": "transfer-id",
"file-transfer-id": "transfer-id/file-transfer-id",
"url": "sftp://192.0.2.0",
"file-path": "/remotebucket/remotefilepath",
"status-code": "FAILED",
"failure-code": "TIMEOUT_ERROR",
"failure-message": "Transfer request timeout.",
"account-id": "480351544584",
"connector-arn": "arn:aws:transfer:us-east-1:account-id:connector/connector-id",
"local-directory-path": "/connectors-localbucket",
"egress-type": "SERVICE_MANAGED"
}
```
このログエントリは、成功した SEND オペレーション用です。
```
{
"operation": "SEND",
"timestamp": "2024-04-24T18:16:12.513207284Z",
"connector-id": "connector-id",
"transfer-id": "transfer-id",
"file-transfer-id": "transfer-id/file-transfer-id",
"url": "sftp://server-id.server.transfer.us-east-1.amazonaws.com",
"file-path": "/amzn-s3-demo-bucket/my-test-folder/connector-metrics-us-east-1-2024-01-02.csv",
"status-code": "COMPLETED",
"start-time": "2024-04-24T18:16:12.295235884Z",
"end-time": "2024-04-24T18:16:12.461840732Z",
"account-id": "255443218509",
"connector-arn": "arn:aws:transfer:us-east-1:account-id:connector/connector-id",
"bytes": 275,
"egress-type": "SERVICE_MANAGED"
}
```
前のログ例のいくつかのキーフィールドの説明。
+ `timestamp` は、ログが CloudWatch に追加されるタイミングを表します。 `start-time`と は、コネクタが実際に転送を開始および終了するタイミング`end-time`に対応します。
+ `transfer-id` は、`start-file-transfer`リクエストごとに割り当てられた一意の識別子です。ユーザーが 1 つの `start-file-transfer` API オペレーションで複数のファイルパスを渡すと、すべてのファイルが同じ を共有します`transfer-id`。
+ `file-transfer-id` は、転送されるファイルごとに生成される一意の値です。の最初の部分は `file-transfer-id`と同じであることに注意してください`transfer-id`。
## VPC Lattice コネクタのログエントリの例
このセクションでは、VPC Lattice コネクタのログの例を示します。VPC Lattice コネクタの場合、ログにはコネクタの設定とネットワーク設定に関する情報を提供する追加のフィールドが含まれます。
このログエントリは、正常に完了した VPC Lattice コネクタ SEND オペレーション用です。
```
{
"operation": "SEND",
"timestamp": "2025-09-05T14:20:19.577192454Z",
"connector-id": "connector-id",
"transfer-id": "transfer-id",
"file-transfer-id": "transfer-id/file-transfer-id",
"file-path": ""/amzn-s3-demo-bucket/my-test-folder/connector-vpc-lattice-us-east-1-2025-03-22.csv"",
"status-code": "COMPLETED",
"start-time": "2025-09-05T14:20:19.434072509Z",
"end-time": "2025-09-05T14:20:19.481453346Z",
"account-id": "account-id",
"connector-arn": "arn:aws:transfer:us-east-1:account-id:connector/connector-id",
"remote-directory-path": "/test-bucket/test-folder/",
"bytes": 262,
"egress-type": "VPC_LATTICE",
"vpc-lattice-resource-configuration-arn": "arn:aws:vpc-lattice:us-east-1:account-id:resourceconfiguration/resource-configuration-arn-id,
"vpc-lattice-port-number": 22
}
```
VPC Lattice コネクタログには、次の追加フィールドが含まれます。
+ `egress-type` - コネクタの出力設定のタイプ
+ `vpc-lattice-resource-configuration-arn` - ターゲット SFTP サーバーの場所を定義する VPC Lattice リソース設定の ARN
+ `vpc-lattice-port-number` - VPC Lattice 経由で SFTP サーバーに接続するためのポート番号
## キー交換アルゴリズムの失敗のログエントリの例
このセクションでは、キー交換アルゴリズム (KEX) が失敗したログの例を示します。以下は、構造化ログの **ERRORS** ログストリームの例です。
このログエントリは、ホストキータイプエラーがある例です。
```
{
"activity-type": "KEX_FAILURE",
"source-ip": "999.999.999.999",
"resource-arn": "arn:aws:transfer:us-east-1:999999999999:server/s-999999999999999999",
"message": "no matching host key type found",
"kex": "ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519,ssh-rsa,ssh-dss"
}
```
このログエントリは、KEX の不一致がある例です。
```
{
"activity-type": "KEX_FAILURE",
"source-ip": "999.999.999.999",
"resource-arn": "arn:aws:transfer:us-east-1:999999999999:server/s-999999999999999999",
"message": "no matching key exchange method found",
"kex": "diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group14-sha256"
}
```
# Transfer Family サーバーの CloudWatch メトリクスの使用
**注記**
Transfer Family コンソール自体で Transfer Family のメトリクスを取得することもできます。詳細については、「[コンソールで使用状況をモニターする](monitor-usage-transfer-console.md)」を参照してください
CloudWatch メトリクスを使用して、サーバーに関する情報を取得できます。*メトリクス*は、CloudWatch に発行された時系列のデータポイントのセットを表します。メトリクスを使用するには、Transfer Family の名前空間、メトリクス名、および[ディメンション](#cw-dimensions)を指定する必要があります。Amazon CloudWatch メトリクスの詳細については、*Amazon CloudWatch ユーザーガイド*の「[メトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Metric)」を参照してください。
次の表は Transfer Family の CloudWatch メトリクスについての説明です。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/metrics.html)
## Transfer Family ディメンション
*ディメンション*は、メトリクスのアイデンティティの一部である名前と値のペアです。ディメンションの詳細については、*Amazon CloudWatch ユーザーガイド*の「[ディメンション](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension)」を参照してください。
次の表に、Transfer Family の CloudWatch ディメンションを示します。
| ディメンション | 説明 |
| --- | --- |
| `ServerId` | サーバーに付けられた一意の ID。 |
| `ConnectorId` | コネクタの一意の ID。AS2、 `OutboundMessage`および に使用されます。 `OutboundFailedMessage` |
## AWS User Notifications での の使用 AWS Transfer Family
AWS Transfer Family イベントに関する通知を受け取るには、 [AWS User Notifications](https://docs.aws.amazon.com/notifications/latest/userguide/what-is.html)を使用してさまざまな配信チャネルを設定できます。指定したルールにイベントが一致すると、通知を受け取ります。
イベントの通知は、Eメール、[チャットアプリケーション内の Amazon Q Developer](https://docs.aws.amazon.com/chatbot/latest/adminguide/what-is.html)のチャット通知、[AWS Console Mobile Application](https://docs.aws.amazon.com/consolemobileapp/latest/userguide/what-is-consolemobileapp.html)のプッシュ通知などの複数のチャネルで受け取ることができます。[コンソール通知センターで通知](https://console.aws.amazon.com/notifications/)を確認することもできます。 User Notifications は集約をサポートしているため、特定のイベント中に受け取る通知の数を減らすことができます。
詳細については、「 *AWS User Notifications ユーザーガイド*」の[AWS Transfer Family 「マネージドワークフローを使用したファイル配信通知のカスタマイズ](https://aws.amazon.com/blogs/storage/customize-file-delivery-notifications-using-aws-transfer-family-managed-workflows/)」ブログ記事[「 とは AWS User Notifications](https://docs.aws.amazon.com/notifications/latest/userguide/what-is.html)」を参照してください。
# クエリを使用してログエントリをフィルタリングする
CloudWatch クエリを使用して、Transfer Family のログエントリをフィルタリングおよび識別できます。このセクションでは、いくつかの例を示します。
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) で CloudWatch コンソールを開きます。
1. クエリまたはルールを作成できます。
+ **Logs Insights** クエリを作成するには、左側のナビゲーションパネルから **Logs Insights** を選択し、クエリの詳細を入力します。
+ **Contributor Insights** ルールを作成するには、左側のナビゲーションパネルから Insights > Contributor Insights を選択し、ルールの詳細を入力します。
1. 作成したクエリまたはルールを実行します。
**認証失敗の上位寄与要因を表示する**
構造化ログでは、認証失敗ログエントリは次のようになります。
```
{
"method":"password",
"activity-type":"AUTH_FAILURE",
"source-ip":"999.999.999.999",
"resource-arn":"arn:aws:transfer:us-east-1:999999999999:server/s-0123456789abcdef",
"message":"Invalid user name or password",
"user":"exampleUser"
}
```
次のクエリを実行して、認証失敗の上位の寄与要因を表示します。
```
filter @logStream = 'ERRORS'
| filter `activity-type` = 'AUTH_FAILURE'
| stats count() as AuthFailures by user, method
| sort by AuthFailures desc
| limit 10
```
**CloudWatch Logs Insights** を使用する代わりに、**CloudWatch Contributors Insights** ルールを作成して認証の失敗を表示できます。次のようなルールを作成します。
```
{
"AggregateOn": "Count",
"Contribution": {
"Filters": [
{
"Match": "$.activity-type",
"In": [
"AUTH_FAILURE"
]
}
],
"Keys": [
"$.user"
]
},
"LogFormat": "JSON",
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
},
"LogGroupARNs": [
"arn:aws:logs:us-east-1:999999999999:log-group:/customer/structured_logs"
]
}
```
**ファイルが開かれたログエントリを表示する**
構造化ログでは、ファイルの読み取りログエントリは次のようになります。
```
{
"mode":"READ",
"path":"/fs-0df669c89d9bf7f45/avtester/example",
"activity-type":"OPEN",
"resource-arn":"arn:aws:transfer:us-east-1:999999999999:server/s-0123456789abcdef",
"session-id":"0049cd844c7536c06a89"
}
```
次のクエリを実行して、ファイルが開かれたことを示すログエントリを表示します。
```
filter `activity-type` = 'OPEN'
| display @timestamp, @logStream, `session-id`, mode, path
```