はじめに
こんにちは。マネージドサービス部の福田です。
今回はCloudWatchLogsのログをNew Relicへの転送方法についてご紹介いたします。
New Relicへのログ転送には、主に以下のパターンがあります
- Amazon Data Firehose
- AWS Lambda
今回は各パターンを使用したCloudWatchLogsのログ転送機能について説明します。
※2024/09/02 Amazon Data Firehoseの設定で使用するIAM情報の例を追記
Amazon Data Firehose経由
概要
このパターンでは、CloudWatch LogsのログをAmazon Data Firehoseを経由してNew Relicに転送します。
実装手順
Amazon Data Firehoseの作成
- 以下ドキュメントを参考にAmazon Data Firehoseを作成します
手順の流れ
作成した設定例
バッファーの設定について注意
- 公式ドキュメントに以下記載があるのでバッファーの設定はデフォルト値(5MiB)から変更すること
New Relicは、LogsAPIへの個々のHTTPPOSTリクエストに対して最大1MB(1.000.000バイト)のペイロードを受け入れます。蓄積されたログのサイズが60秒間の蓄積期間中に1MBを超えると、 413 HTTPエラーでそれらのログを拒否します。
Amazon Data Firehose用のIAMロール例
IAMポリシー内容(エラーログ用)
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": [ "★CloudWatchLogsのARN:*" ] }, { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:ListBucketMultipartUploads", "s3:AbortMultipartUpload", "s3:ListBucket", "s3:PutObjectAcl", "s3:GetBucketLocation" ], "Resource": [ "arn:aws:s3:::★S3バケット名★/*", "arn:aws:s3:::★S3バケット名★" ] } ] }
信頼関係
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "firehose.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "ArnEquals": { "aws:SourceArn": "★Amazon Data FirehoseのARN★" } } } ] }
補足情報
Firehoseは通常、エラーの詳細情報をCloudWatch Logsに記録します。
このため、S3にはすべてのエラーが記録されるわけではありません。
S3へのエラーログ出力は主に「配信先へのデータ送信が完全に失敗した場合」に行われます
- 送信先への配信が完全に失敗した場合
- 例: New Relic APIがダウンしていて接続できない、またはネットワーク障害でリクエストが送信できない場合。
- HTTP 413エラー
- Firehoseは、New Relic APIからのHTTP 413エラー(Payload Too Large)を「接続自体が失敗した」とは見なさず、データサイズが大きすぎるために拒否されたと処理をし「S3へのエラーログ出力の対象外」となり、S3にはログが記録されない可能性があります
手順の流れ
作成した設定例
サブスクリプションフィルター用のIAMロール例
{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "firehose:ListDeliveryStreams", "Resource": "*" }, { "Sid": "VisualEditor1", "Effect": "Allow", "Action": "firehose:*", "Resource": "★Amazon Data FirehoseのARN★" } ] }
信頼関係
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "logs.ap-northeast-1.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
ログがNew Relicに転送されていることの確認
New Relicで確認できたログ内容
{ "id": "xxxx", "log_message": "serverworks test swx-test.log:ERROR", "logGroup": "NewRelic-Sample-Logs", "logStream": "NewRelic-Sample01", "logtype": "NewRelic-Sample-logs", "message": "serverworks test swx-test.log:ERROR", "messageType": "DATA_MESSAGE", "newrelic.logPattern": "nr.DID_NOT_MATCH", "newrelic.source": "api.logs.awsFirehose", "owner": "xxxx", "plugin.type": "aws-firehose", "requestId": "xxxx", "subscriptionFilters": "[\"Sample\"]", "timestamp": 1721211785963 }
(参考)AWS CLIを用いたサブスクリプションフィルタ設定
多数のロググループに対してサブスクリプションフィルタを設定できるスクリプトを紹介します。
スクリプト内容
# 変数の設定 log_groups=("★CloudWatchロググループ名①★" "★CloudWatchロググループ名②★") filter_name="★設定したいサブスクリプションフィルター名★" filter_pattern=" " destination_arn="★Kinesis Data Firehoseの ARN★" role_arn="★サブスクリプションフィルターに使用する IAM ロールの ARN★" # エラーハンドリング関数 handle_error() { echo "エラーが発生しました: $1" >&2 exit 1 } # サブスクリプションフィルターの作成 for log_group in "${log_groups[@]}"; do echo "ロググループ $log_group にサブスクリプションフィルターを作成しています..." aws logs put-subscription-filter \ --log-group-name "$log_group" \ --filter-name "$filter_name" \ --filter-pattern "$filter_pattern" \ --destination-arn "$destination_arn" \ --role-arn "$role_arn" || handle_error "サブスクリプションフィルターの作成に失敗しました" echo "サブスクリプションフィルターが正常に作成されました。" done
実行結果
スクリプトにより作成されたサブスクリプションフィルター設定
AWS Lambda経由
概要
このパターンでは、CloudWatch LogsのログをLambdaを経由してNew Relicに転送します。
実装手順
以下ドキュメントを参考にLambdaを作成します
※デプロイする際に対象のAWSアカウントIDであることと実行リージョンを注意してください
2024/07/25追記 「CloudWatchログ送信用のAWS Lambda」のドキュメントが消えていましたので代わりのドキュメントに差し替えました
基本的な流れは同じはずです。
手順の流れ
`
トリガーのフィルターパターン例
(str = "AAA" || str = "BBB" )
- 以下のいずれかの文字列を含んだログを抽出
・AAA
・BBB
- 以下のいずれかの文字列を含んだログを抽出
(str = "AAA" || str = "BBB" )&&(str != "CCC")
- 以下のいずれかの文字列を含んだログを抽出
・AAA
・BBB - さらに以下の文字列を含まないログに限定します
・CCC
- 以下のいずれかの文字列を含んだログを抽出
作成した設定例
ログがNew Relicに転送されていることの確認
New Relicで確認できたログ内容
{ "aws.logGroup": "aws-cloudtrail-logs-xxxxx-51a10c88", "aws.logStream": "xxxxx_CloudTrail_ap-northeast-1", "awsRegion": "ap-northeast-1", "eventCategory": "Data", "eventID": "xxxxx", "eventName": "GetMetricData", "eventSource": "monitoring.amazonaws.com", "eventTime": "2024-07-17T10:49:17Z", "eventVersion": "1.09", "managementEvent": false, "newrelic.source": "api.logs", "plugin.type": "lambda", "plugin.version": "1.0.3", "readOnly": true, "recipientAccountId": "xxxxxxxxx", "requestID": "xxxxx", "requestParameters.endTime": "Jul 17, 2024, 10:40:00 AM", (中略) "userIdentity.type": "AssumedRole" }
Amazon Data FirehoseとAWS Lambdaどちらを利用すればいいのか
個人的な結論
Amazon Data Firehoseがいいのかなと思います。
Amazon Data Firehoseはスケーリングやバッファリング機能をもっております。
またLambdaの場合ランタイムの更新などLambda自体の運用も必要になります。
以下はそれぞれの観点で比較した内容になります。
コスト面については利用環境に依存しますが、大きく違いはでないと思われます。
宣伝
弊社では、お客様環境のオブザーバビリティを加速するための伴走型のNew Relic導入支援サービスなどもご提供しております。 もしご興味をお持ちの方は、こちらのサービスご紹介ページの一番下にあるお問合せフォームよりお問合せ頂けましたら幸いでございます。