AWS Lambda関数newrelic-log-ingestion
を使用して、 AmazonCloudWatchログをNewRelicに送信できます。これは、AWSサーバーレスアプリケーションリポジトリから簡単にデプロイできます。
CloudWatchのログをNew Relicに転送することで、ログデータの収集、処理、探索、クエリ、アラートなどのログ管理機能が強化されます。
CloudWatch ログ Lambda 関数をインストールして設定する
以下の設定は、環境変数を設定するための一つの方法です。 Functions のページからも設定できます。
次の項目を完了します。
あなたが持っていることを確認してください
.
AWS Serverless Application Repository をブラウザで開きます。
newrelic
を検索し、 [カスタムIAMロールまたはリソースポリシーを作成するアプリを表示する]をオンにして、newrelic-log-ingestion
を見つけます。newrelic-log-ingestion
の詳細を開き、[デプロイ]をクリックします。機能の Configure メニューの Environment Variables に進み、以下の環境変数を使ってログフォワーディングを設定します。
鍵 | 説明 |
---|---|
| CloudWatchコンソールにデバッグメッセージを出力するかどうかを決定するブール値です。 任意です。 デバッグログをオンにするには、これを |
| New Relic にデータを送信するために使用されます。 必要。 |
| ログをNewRelicに転送するかどうかを決定します。必須。ロギングをオンにするには、これを |
| すべてのログイベントに追加するタグを指定します。 オプションです。 各タグは、コロンで区切られたキーと値で構成されます。複数のキーと値のペアはセミコロンで区切られます。たとえば、 |
|
|
|
|
- アプリがカスタムIAMロールを作成することを確認してから、 Deploy をクリックします。
処理が完了したら、 Lambdaトリガーを作成して、Lambda関数とCloudWatchログを連携させます。
Lambdaトリガーの作成
取り込み機能では、ログサブスクリプションではなく、必ずトリガーを設定してください。Lambdaコンソールでサブスクリプションが設定されている場合、これにより、ログが生成されてNewRelicに転送されるカスケードが発生する可能性があります。
ログをNew Relicにストリーミングするには、Lambdaにトリガーを取り付けます。
- 左側のメニューから「 Functions 」を選択します。
- 以前に作成した
newrelic-log-ingestion
関数を見つけて選択します。 - Triggers [トリガー]でAdd Triggers [トリガーの追加]をクリックし、ドロップダウンからCloudWatch Logsを選択します。
- お客様のアプリケーションに適切な Log group を選択してください。
- フィルターの名前を入力します。
- オプションです。 フィルターパターンを入力.
- Enable trigger のチェックボックスをチェックし、 Add をクリックしてトリガーを作成します。
このドキュメントはインストールで役立ちましたか。
オプション: さまざまなログ エンドポイントを構成する
必要に応じてカスタム ロギング エンドポイントを設定できます。これにより、たとえば、FedRAMP 準拠のエンドポイントを使用できるようになります。
そのためには、上記で説明したアプリケーションをデプロイしてから、次のことを行う必要があります。
AWS で最近デプロイされたラムダ関数ビューに移動します。
下にスクロールして
Configuration
タブをクリックします。Configuration
タブ内の左側のメニューで、Environment Variables
をクリックします。ここで、既存の環境変数のリストを確認できます。
Environment Variables
テーブルの右上にある Edit[編集] をクリックするだけです。適切なエンドポイントで
NR_LOGGING_ENDPOINT
を更新します。- 米国の場合:
https://log-api.newrelic.com/log/v1
- EUの場合:
https://log-api.eu.newrelic.com/log/v1
- FedRAMPの場合:
https://gov-log-api.newrelic.com/log/v1
- 米国の場合:
クリック 保存.
オプション: 再試行を構成する
通信の問題で機能がデータの送信に失敗した場合に実行するリトライの回数を設定することができます。推奨数は3回ですが、以下のパラメーターを変更することで、リトライの動作を変更することができます。
ヒント
リトライの回数が多いほど、関数の実行時間が長くなります。そのため、Lambdaのコストが高くなる確率が高くなります。しかし、リトライ回数を減らすと、データ損失の可能性が高くなります。
MAX_RETRIES = 3 # Defines the number of retries after lambda failure to deliver dataINITIAL_BACKOFF = 1 # Defines the initial wait seconds until next retry is executedBACKOFF_MULTIPLIER = 2 # Time multiplier between the retriesAs an example, in default above configuration, first retry will happen after 1 second, second retry after 2 seconds and third retry will happen after 4 seconds.
SAMテンプレートで作成されたリソース
リポジトリからアプリケーションを作成すると、以下のリソースも作成されます。
- ラムダ関数自体
- CloudWatch Logsに基づいてLambda関数に実行権限を与えるために使用されるロールです。
記載されていないその他のLambdaの設定は、デフォルトのままで構いません。
ログデータを表示する
すべてが正しく構成され、データが収集されている場合は、次の両方の場所にログ データが表示されるはずです。
SELECT * FROM Log
ログ管理機能を有効にしてもデータが表示されない場合は、標準のログトラブルシューティング手順に従ってください。
次は何ですか?
- ログインコンテキスト機能を使用してログを転送することにより、アプリケーションとプラットフォームのパフォーマンスデータの両方をより深く把握できます。
- アラートを設定します。
- データをクエリし、ダッシュボードを作成します。
ログ転送を無効にする
ログ転送機能を無効にするには、 Amazon CloudWatch documentation の標準的な手順に従います。New Relic では、他に何もする必要はありません。