
はじめに
こんにちは。マネージドサービス部の福田です。
今回は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アカウント開設を含めた伴走型のNew Relic導入支援サービスをご提供しております。 もしご興味をお持ちの方は、こちらのお問合せフォームよりお問合せ頂けましたら幸いでございます。
・福田 圭(記事一覧)
・マネージドサービス部 所属・X(Twitter):@soundsoon25
2023 New Relic Partner Trailblazer。New Relic Trailblazer of the Year 2025受賞。New Relic User Group運営。