翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# CloudWatch のよくある質問を使用したロギングとモニタリングの設計と実装
このセクションでは、CloudWatch のロギングおよびモニタリングソリューションの設計と実装について、よくある質問にお答えしています。
## CloudWatch 設定ファイルはどこに保存すればよいですか?
Amazon EC2 の CloudWatch エージェントは、CloudWatch 設定ディレクトリに保存されている複数の設定ファイルを適用できます。CloudWatch の設定は、複数のアカウントや環境でバージョン管理し、再度使用することができるため、ファイルセットとして保存することが理想的です。詳細については、このガイドの [CloudWatch 設定の管理](create-store-cloudwatch-configurations.md#store-cloudwatch-configuration-s3) セクションを参照してください。または、設定ファイルを GitHub のリポジトリに保存しておき、新規 EC2 インスタンスがプロビジョニングされる時に設定ファイルを自動取得することもできます。
## アラームが発生した時に、サービス管理ソリューションでチケットを作成するにはどうすればよいですか？
サービス管理システムを Amazon Simple Notification Service (Amazon SNS) トピックに統合し、アラームが発生したときに SNS トピックを通知するように CloudWatch アラームを設定します。統合システムは SNS メッセージを受信し、サービス管理システムの API または SDK を使用してチケットを作成できます。
## CloudWatch を使用してコンテナ内のログファイルをキャプチャするにはどうすればよいですか？
Amazon ECS タスクと Amazon EKS ポッドは、STDOUT および STDERR 出力を CloudWatch に自動的に送信するように設定できます。コンテナ化されたアプリケーションをログに記録するためには、コンテナの出力をSTDOUT および STDERR に送信する方法が推奨されています。これは、[Twelve-Factor アプリケーションマニフェスト](https://12factor.net/) もカバーしています。
ただし、特定のログファイルを CloudWatch に送信する場合は、アプリケーションがロットファイルを書き込む場所に Amazon EKS ポッドまたは Amazon ECS タスク定義にボリュームをマウントし、Fluentd または Fluent Bit のサイドカーコンテナを使用して CloudWatch にログを送信できます。コンテナ内の特定のログファイルを `/dev/stdout` と `/dev/stderr` にシンボリックリンクすることを考慮する必要があります。詳細については、Docker ドキュメントの [コンテナまたはサービスのログを表示する](https://docs.docker.com/config/containers/logging/) を参照してください。
## AWS サービスのヘルス問題をモニタリングするにはどうすればよいですか?
を使用して AWS ヘルスイベント[AWS Health Dashboard](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html)をモニタリングできます。また、 AWS ヘルスイベントに関連するサンプルオートメーションソリューション用の、[aws-health-tool](https://github.com/aws/aws-health-tools) GitHub リポジトリも参照できます。
## エージェントサポートが存在しない場合、カスタム CloudWatch メトリクスを作成するにはどうすればよいですか？
埋め込みメトリクスフォーマットを使用して、メトリクスをCloudWatch に取り込むことができます。 AWS SDK ([put\_metric\_data](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/cloudwatch.html#CloudWatch.Client.put_metric_data) など）、 AWS CLI ([put-metric-data](https://docs.aws.amazon.com//cli/latest/reference/cloudwatch/put-metric-data.html) など）、または AWS API ([PutMetricData](https://docs.aws.amazon.com//AmazonCloudWatch/latest/APIReference/API_PutMetricData.html) など) を使用してカスタムメトリクスを作成することもできます。カスタムロジックが長期的に維持される方法を考慮する必要があります。1 つのアプローチとしては、組み込みメトリクスフォーマットサポートを統合した Lambda を使用して、メトリックの期間を設定するために CloudWatch Events イベント [スケジュールルール](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule-schedule.html) と共にメトリクスを作成することです。
## 既存のログ記録およびモニタリングツールを と統合するにはどうすればよいですか AWS?
との統合については、ソフトウェアまたはサービスベンダーが提供するガイダンスを参照してください AWS。エージェントソフトウェア、SDK、または提供された API を使用して、ログとメトリクスをソリューションに送信できる場合があります。また、ベンダーの仕様に合わせて構成された Fluentd や Fluent Bit などのオープンソースソリューションを使用することもできます。また、Lambda および Kinesis Data Streams の AWS SDK および CloudWatch Logs サブスクリプションフィルターを使用して、カスタムログプロセッサとシッパーを作成することもできます。最後に、複数のアカウントとリージョンを使用している場合は、ソフトウェアをどのように統合するかについても考慮する必要があります。