Node.js 用の AWS Lambda ネイティブ・トレース

Node.js で記述された AWS Lambda 関数に対して、 Instana トレースを設定できます。

サポートされるランタイム

  • Node.js 24.x
  • Node.js 22.x
  • Node.js 20.x
  • Node.js 18.x
注: 古いバージョンの Node.js をご利用の場合は、サポートに関する情報は 「古いバージョンの Instana に関するドキュメント」をご確認ください。

Node.js のLambda関数に対するトレースの設定

Instana AWS Lambda 関数でトレースを有効にするための複数の方法を提供します。 以下の設定オプションが利用可能です:

Instana AutoTrace のセットアップ

Node.js 向けの Instana ( AutoTrace )の設定により、 Instana のLambdaレイヤーとカスタム関数ハンドラーを使用して、 AWS Lambda の関数をトレースできるようになります。

この方法では、Lambda 関数コードを変更する必要はなく、構成だけを使用して行います。 この方法は、自動化するのにも、Lambda デプロイメント・パイプラインに組み込むのにも適しています。

Node.js Lambda 関数のトレースを有効にするには、以下のステップを実行します。

  1. Instana Lambda レイヤーを関数に追加します。
    1. ラムダ関数の構成ページで、 Layers ボックスをクリックし、次に Add a layerをクリックします。
      層
    2. 表示されるポップアップで、「レイヤーバージョンのARNを指定」を選択し、ご利用のリージョンに対応する「 Instana 」LambdaレイヤーのARNをコピーして貼り付けてください。「 Instana 」Lambdaレイヤーの正しいARNは、「 Instana 」の「Lambdaレイヤー」セクションで確認できます。
      層の選択
  2. Lambda ハンドラーを構成します。

    CommonJS を使用する場合は、ハンドラー instana-aws-lambda-auto-wrap.handler を に設定してください。

    ESモジュール( ES6 ) を使用する場合は、ハンドラー instana-aws-lambda-auto-wrap-esm.handler を に設定してください(レイヤーバージョン223以降で利用可能)。

    ラムダハンドラーの設定を変更するには、構成ページで「基本設定」セクションを見つけます。

    基本設定セクション編集ボタン

    「編集」をクリックし、「ハンドラー」というラベルのフィールドに instana-aws-lambda-auto-wrap.handler を挿入します。

    基本設定を編集して、 Instana のハンドラーを設定します

    Instana のLambdaレイヤーは、デフォルトの Node.js ランタイムハンドラーを自動的に index.handlerトリガーします。 カスタムハンドラーを使用する場合は、環境変数 LAMBDA_HANDLER にハンドラーを指定して、 Instana のLambdaレイヤーに通知してください。 設定する必要があるすべての環境変数については、次のセクションを参照してください。

    注: Lambdaの設定ページに、「Lambdaがファイル instana-aws-lambda-auto-wrap.js を見つけられません」といった警告が表示される場合があります。設定ページに戻った際にも、同様の警告が表示されることがあります。 この警告を無視して構いません。 ハンドラーは Instana Lambda レイヤーに含まれますが、AWS Lambda 構成ページでは考慮されません。
  3. 環境変数を構成します。

    以下の環境変数を追加します。

    • INSTANA_ENDPOINT_URL: この変数は、 サーバーレス監視のエンドポイントです。 該当するリージョン用の、https://serverless- で始まる適切な値を使用していることを確認してください。
    • INSTANA_AGENT_KEY: エージェント・キー
    • LAMBDA_HANDLER: カスタム・ハンドラーを設定します。 メインファイルが myModule.js(関数 myHandlerをエクスポートする) の場合は、環境変数を myModule.myHandlerに設定します。 デフォルト値はindex.handlerです。

    次の例では、元のメインのLambdaハンドラーは であるため index.js、環境変数 LAMBDA_HANDLER を設定する必要はありません。

    サーバーレス監視エンドポイント

    次の例では、元のメインのLambdaハンドラーは server.jsであるため、環境変数 LAMBDA_HANDLER を に設定する必要があります server.handler

    カスタム環境変数の設定

    また、 Instana のインストール先へ移動し、...をクリックすることで、これらの環境変数の正しい値を確認することもできます。 詳細 -> エージェント -> 「 Instana 」エージェントのインストール -> プラットフォーム: AWS -> テクノロジー: AWS Lambda。

  4. ラムダ関数定義を保存します。
    保存

前述の手順はすべて、 AWS のWebコンソール、または次のような一般的な AWS 管理ツールのいずれかを使用して実行できます

以下に、AWS Lambdas の Instana 統合を自動化する場合に開始点として役立つ、aws CLI コマンドの例を示します。

# Do not copy and paste this verbatim!
# It will overwrite any previously defined collection of layers and
# environment variables.
aws --region $YOUR_REGION lambda update-function-configuration \
  --function-name $YOUR_LAMBDA_FUNCTION_NAME \
  --layers $INSTANA_LAYER_ARN \
  --handler instana-aws-lambda-auto-wrap.handler \
  --environment "Variables={INSTANA_ENDPOINT_URL=... , INSTANA_AGENT_KEY=... , ...}"

Instana Lambda レイヤー

Node.js レイヤーには、 Instana AWS Lambda 拡張機能が含まれています。 モニタリングデータとトレースは、ローカルで Instana のLambda拡張機能にオフロードされ、そこから Instana のバックエンドに転送されます。 この機能には次のような利点があります。ハンドラーの処理が完了すると、Lambda関数は Instana バックエンドへのデータ送信を待たずに、直ちに呼び出し元クライアントに応答します。

この機能は限定メモリが設定されたLambda関数に256 MB以上。 Lambda関数に対して環境変数を INSTANA_DISABLE_LAMBDA_EXTENSION 空でない文字列に設定することで、 Instana のLambda拡張機能を無効にできます。

注:Instana Lambdaレイヤーを使用するには、 Instana ( AutoTrace )の設定手順に従ってください。
注:Instana は、 GovCloud のリージョン(us-gov-west-1 および us-gov-east-1)ではLambdaレイヤーを提供していません。 GovCloud リージョンで Instana を使用するには、「 Instana 」パッケージ( Node.js ) @instana/aws-lambda を手動でインストールし、 「@instana/aws-lambdaの手動インストール」 のセクションに記載されている手順に従ってハンドラ関数をラップする必要があります。

アーキテクチャー x86_64

サポートされているランタイム 」に記載されているLambdaランタイム用の AWS Lambda レイヤーの最新バージョンのARNは、リージョンごとに以下の通りです

リージョン ARN @instana/aws-lambda バージョン
af-south-1 arn:aws:lambda:af-south-1:410797082306:layer:instana-nodejs:161 5.4.3
ap-east-1 arn:aws:lambda:ap-east-1:410797082306:layer:instana-nodejs:160 5.4.3
ap-east-2 arn:aws:lambda:ap-east-2:410797082306:layer:instana-nodejs:47 5.4.3
ap-northeast-1 arn:aws:lambda:ap-northeast-1:410797082306:layer:instana-nodejs:316 5.4.3
ap-northeast-2 arn:aws:lambda:ap-northeast-2:410797082306:layer:instana-nodejs:314 5.4.3
ap-northeast-3 arn:aws:lambda:ap-northeast-3:410797082306:layer:instana-nodejs:160 5.4.3
ap-south-1 arn:aws:lambda:ap-south-1:410797082306:layer:instana-nodejs:314 5.4.3
ap-south-2 arn:aws:lambda:ap-south-2:410797082306:layer:instana-nodejs:160 5.4.3
ap-southeast-1 arn:aws:lambda:ap-southeast-1:410797082306:layer:instana-nodejs:314 5.4.3
ap-southeast-2 arn:aws:lambda:ap-southeast-2:410797082306:layer:instana-nodejs:313 5.4.3
ap-southeast-3 arn:aws:lambda:ap-southeast-3:410797082306:layer:instana-nodejs:159 5.4.3
ap-southeast-4 arn:aws:lambda:ap-southeast-4:410797082306:layer:instana-nodejs:159 5.4.3
ap-southeast-5 arn:aws:lambda:ap-southeast-5:410797082306:layer:instana-nodejs:108 5.4.3
ap-southeast-6 arn:aws:lambda:ap-southeast-6:410797082306:layer:instana-nodejs:29 5.4.3
ap-southeast-7 arn:aws:lambda:ap-southeast-7:410797082306:layer:instana-nodejs:65 5.4.3
ca-central-1 arn:aws:lambda:ca-central-1:410797082306:layer:instana-nodejs:312 5.4.3
ca-west-1 arn:aws:lambda:ca-west-1:410797082306:layer:instana-nodejs:140 5.4.3
cn-north-1 arn:aws-cn:lambda:cn-north-1:107998019096:layer:instana-nodejs:80 5.4.2
cn-northwest-1 arn:aws-cn:lambda:cn-northwest-1:107998019096:layer:instana-nodejs:84 5.4.3
eu-central-1 arn:aws:lambda:eu-central-1:410797082306:layer:instana-nodejs:290 5.4.3
eu-central-2 arn:aws:lambda:eu-central-2:410797082306:layer:instana-nodejs:136 5.4.3
eu-north-1 arn:aws:lambda:eu-north-1:410797082306:layer:instana-nodejs:290 5.4.3
eu-south-1 arn:aws:lambda:eu-south-1:410797082306:layer:instana-nodejs:136 5.4.3
eu-south-2 arn:aws:lambda:eu-south-2:410797082306:layer:instana-nodejs:136 5.4.3
eu-west-1 arn:aws:lambda:eu-west-1:410797082306:layer:instana-nodejs:290 5.4.3
eu-west-2 arn:aws:lambda:eu-west-2:410797082306:layer:instana-nodejs:290 5.4.3
eu-west-3 arn:aws:lambda:eu-west-3:410797082306:layer:instana-nodejs:290 5.4.3
il-central-1 arn:aws:lambda:il-central-1:410797082306:layer:instana-nodejs:133 5.4.3
me-central-1 arn:aws:lambda:me-central-1:410797082306:layer:instana-nodejs:null null
me-south-1 arn:aws:lambda:me-south-1:410797082306:layer:instana-nodejs:null null
mx-central-1 arn:aws:lambda:mx-central-1:410797082306:layer:instana-nodejs:63 5.4.3
sa-east-1 arn:aws:lambda:sa-east-1:410797082306:layer:instana-nodejs:289 5.4.3
us-east-1 arn:aws:lambda:us-east-1:410797082306:layer:instana-nodejs:289 5.4.3
us-east-2 arn:aws:lambda:us-east-2:410797082306:layer:instana-nodejs:289 5.4.3
us-west-1 arn:aws:lambda:us-west-1:410797082306:layer:instana-nodejs:289 5.4.3
us-west-2 arn:aws:lambda:us-west-2:410797082306:layer:instana-nodejs:289 5.4.3

つまり、パターンは arn:aws:lambda:${region}:410797082306:layer:instana-nodejs:${layer-version} (中国の AWS 地域の場合は arn:aws-cn:lambda:${region}:107998019096:layer:instana-nodejs:${layer-version} ) です。

常に最新バージョンを使用し、使用しているレイヤー・バージョンを定期的に更新してください。これにより、レイヤーの新規バージョンを公開する際に提供される新機能とフィックスのメリットが得られます。

アーキテクチャー arm64

リージョン ARN @instana/aws-lambda バージョン
af-south-1 arn:aws:lambda:af-south-1:410797082306:layer:instana-nodejs-arm64:1334 5.4.3
ap-east-1 arn:aws:lambda:ap-east-1:410797082306:layer:instana-nodejs-arm64:134 5.4.3
ap-east-2 arn:aws:lambda:ap-east-2:410797082306:layer:instana-nodejs-arm64:46 5.4.3
ap-northeast-1 arn:aws:lambda:ap-northeast-1:410797082306:layer:instana-nodejs-arm64:173 5.4.3
ap-northeast-2 arn:aws:lambda:ap-northeast-2:410797082306:layer:instana-nodejs-arm64:173 5.4.3
ap-northeast-3 arn:aws:lambda:ap-northeast-3:410797082306:layer:instana-nodejs-arm64:134 5.4.3
ap-south-1 arn:aws:lambda:ap-south-1:410797082306:layer:instana-nodejs-arm64:173 5.4.3
ap-south-2 arn:aws:lambda:ap-south-2:410797082306:layer:instana-nodejs-arm64:134 5.4.3
ap-southeast-1 arn:aws:lambda:ap-southeast-1:410797082306:layer:instana-nodejs-arm64:173 5.4.3
ap-southeast-2 arn:aws:lambda:ap-southeast-2:410797082306:layer:instana-nodejs-arm64:173 5.4.3
ap-southeast-3 arn:aws:lambda:ap-southeast-3:410797082306:layer:instana-nodejs-arm64:134 5.4.3
ap-southeast-4 arn:aws:lambda:ap-southeast-4:410797082306:layer:instana-nodejs-arm64:134 5.4.3
ap-southeast-5 arn:aws:lambda:ap-southeast-5:410797082306:layer:instana-nodejs-arm64:91 5.4.3
ap-southeast-6 arn:aws:lambda:ap-southeast-6:410797082306:layer:instana-nodejs-arm64:29 5.4.3
ap-southeast-7 arn:aws:lambda:ap-southeast-7:410797082306:layer:instana-nodejs-arm64:64 5.4.3
ca-central-1 arn:aws:lambda:ca-central-1:410797082306:layer:instana-nodejs-arm64:173 5.4.3
ca-west-1 arn:aws:lambda:ca-west-1:410797082306:layer:instana-nodejs-arm64:118 5.4.3
cn-north-1 arn:aws-cn:lambda:cn-north-1:107998019096:layer:instana-nodejs-arm64:76 5.4.3
cn-northwest-1 arn:aws-cn:lambda:cn-northwest-1:107998019096:layer:instana-nodejs-arm64:83 5.4.3
eu-central-1 arn:aws:lambda:eu-central-1:410797082306:layer:instana-nodejs-arm64:170 5.4.3
eu-central-2 arn:aws:lambda:eu-central-2:410797082306:layer:instana-nodejs-arm64:131 5.4.3
eu-north-1 arn:aws:lambda:eu-north-1:410797082306:layer:instana-nodejs-arm64:170 5.4.3
eu-south-1 arn:aws:lambda:eu-south-1:410797082306:layer:instana-nodejs-arm64:131 5.4.3
eu-south-2 arn:aws:lambda:eu-south-2:410797082306:layer:instana-nodejs-arm64:131 5.4.3
eu-west-1 arn:aws:lambda:eu-west-1:410797082306:layer:instana-nodejs-arm64:170 5.4.3
eu-west-2 arn:aws:lambda:eu-west-2:410797082306:layer:instana-nodejs-arm64:170 5.4.3
eu-west-3 arn:aws:lambda:eu-west-3:410797082306:layer:instana-nodejs-arm64:170 5.4.3
il-central-1 arn:aws:lambda:il-central-1:410797082306:layer:instana-nodejs-arm64:129 5.4.3
me-central-1 arn:aws:lambda:me-central-1:410797082306:layer:instana-nodejs-arm64:131 5.4.3
me-south-1 arn:aws:lambda:me-south-1:410797082306:layer:instana-nodejs-arm64:null null
mx-central-1 arn:aws:lambda:mx-central-1:410797082306:layer:instana-nodejs-arm64:61 5.4.3
sa-east-1 arn:aws:lambda:sa-east-1:410797082306:layer:instana-nodejs-arm64:170 5.4.3
us-east-1 arn:aws:lambda:us-east-1:410797082306:layer:instana-nodejs-arm64:170 5.4.3
us-east-2 arn:aws:lambda:us-east-2:410797082306:layer:instana-nodejs-arm64:170 5.4.3
us-west-1 arn:aws:lambda:us-west-1:410797082306:layer:instana-nodejs-arm64:170 5.4.3
us-west-2 arn:aws:lambda:us-west-2:410797082306:layer:instana-nodejs-arm64:170 5.4.3

手動での @instana/aws-lambda インストール

Instana Node.js コレクターを手動でインストールするには、次のコマンドを実行します:

npm install --save @instana/aws-lambda@latest
以下の環境変数を追加します。
  • INSTANA_ENDPOINT_URL: この変数は、 サーバーレス監視のエンドポイントです。 該当するリージョン用の、https://serverless- で始まる適切な値を使用していることを確認してください。
  • INSTANA_AGENT_KEY: エージェント・キー

「ハンドラを手動でラップする」 のセクションに従って、関数のコードを変更してください。

ハンドラーの手動ラップ

自動改行ハンドラーを使用しない場合、または使用できない場合は、 Node.jsAWS Lambda 関数のコードを少し修正し、 Instana のトレースを有効にする必要があります。

注: このセクションで説明するコードの変更は、「 AutoTrace AWS Lambdas 」セクションに記載されているように、 Instana Lambdaレイヤーとauto-wrapハンドラーを使用する場合は必要ありません。
注: Web パックを使用して ラムダハンドラーをバンドルする場合は、 ない この方法をお勧めします。Instana のコア・パッケージは、Web パックでのプリプロセスをサポートしていないためです。 AutoTrace AWS のラムダ ・アプローチは、webpack を使用するラムダに適しています。 別の方法として、手動ラップを使用して、webpack による前処理から少なくともパッケージ @instana/aws-lambda (またはすべての依存関係) を除外できます。 Node.js のドキュメントのこのセクションを参照してください。Serverless Frameworkについては、 「Serverless Framework」のセクションも参照してください。
  1. const instana = require('@instana/aws-lambda'); をハンドラー JavaScript ファイルの先頭に追加します。
  2. instana.wrap() 呼び出しでハンドラー関数をラップします。
  3. AWS Lambda のドキュメント『 Instana AutoTrace 』に記載されている手順に従い、 Instana バックエンドへの接続用環境変数を設定してください。

以下に、Node.js ベースの AWS Lambda に使用できる、さまざまなハンドラー関数スタイルの適用前および適用後の例をいくつか示します。

async 関数スタイルのハンドラー

async 関数をハンドラーとして使用する場合、ハンドラーは以下のようになります。

exports.handler = async (event, context) => {
  // your code
};
 

結果のコードは以下のようになります。

const instana = require('@instana/aws-lambda');

exports.handler = instana.wrap(async (event, context) => {
  // your code
}); // <- don't forget the closing ) for the instana.wrap(
 

promise スタイルの Lambda ハンドラー

promise スタイルのハンドラーを使用する場合、ハンドラーは以下のようになります。

exports.handler = (event, context) => {
  // your code, which returns a promise
};
 

結果のコードは以下のようになります。

const instana = require('@instana/aws-lambda');

exports.handler = instana.wrap((event, context) => {
  // your code, which returns a promise
}); // <- don't forget the closing ) for the instana.wrap(
 

callback スタイルの Lambda ハンドラー

callback スタイルのハンドラーを使用する場合、ハンドラーは以下のようになります。

exports.handler = (event, context, callback) => {
  // your code
};
 

結果のコードは以下のようになります。

const instana = require('@instana/aws-lambda');

exports.handler = instana.wrap((event, context, callback) => {
  // your code
}); // <- don't forget the closing ) for the instana.wrap(
 

構成オブジェクト

ハンドラをラップする際、最初の引数としてオプションの設定オブジェクトを渡すこともできます:

exports.handler = instana.wrap({
    // ... your configuration, for example:
    tracing: {
      stackTraceLength: 10
    }
  },
  async (event, context) => {
  // your code
});
 

ネイティブ ラムダトレース ( agentHostagentPortreportUnhandledPromiseRejectionsなど) でサポートされない構成値は、サイレントに無視されます。

なお、「 追加の環境変数」 のセクションに記載されている環境変数や、 Node.js の設定ページに記載されている環境変数のほとんども使用できます。

Instana コンテナベースの関数向けLambdaレイヤー

チームでコンテナベースのLambdaデプロイを使用している場合は、 Instana のベースコンテナを利用するか icr.io/instana/aws-lambda-nodejs 、Dockerfileに以下のスニペットを追加し、 ビルド時の引数を適切なバージョンに設定してください。

Instana 現在、この x86_64 アーキテクチャのみをサポートしています。

# This is the container image that delivers Instana's monitoring capabilities.
# It will not become the base image for your Lambda container image, it just provides a few files.
FROM icr.io/instana/aws-lambda-nodejs:latest as instana-layer

# This is the actual base image for your Lambda container image. You can also use any other base image that is suitable
# for container image based Lambda functions.
FROM public.ecr.aws/lambda/nodejs:22

# Copy Instana's Node.js monitoring components into your Lambda container image.
COPY --from=instana-layer /opt/extensions/ /opt/extensions/
COPY --from=instana-layer /opt/nodejs/ /opt/nodejs/

# The remainder of your Dockerfile, as it was without adding the Instana layer. The following is just an example:
COPY index.js package.json package-lock.json /var/task/
WORKDIR /var/task
RUN npm install

# Override the CMD. This can also be done as a parameter override outside of the Dockerfile, for example in the AWS console.
# If you use ES modules, use CMD [ "instana-aws-lambda-auto-wrap-esm.handler" ] instead.
CMD [ "instana-aws-lambda-auto-wrap.handler" ]

バージョン管理

利用可能なすべてのバージョンを確認するには、次のコマンドを実行してください:

curl -s https://icr.io/v2/instana/aws-lambda-nodejs/tags/list | jq .

詳しくは、 Node.js バージョン管理を参照してください。

Instana トレースと Serverless Framework の統合

Instana のトレース機能をServerless Frameworkに統合 serverless.yml するために、を編集します。 以下の手順に従います。

  1. リストから 「層 ARN」 をコピーし、ターゲット関数定義の 層セクション に ARN を追加します。
  2. 環境変数 INSTANA_AGENT_KEYINSTANA_ENDPOINT_URL 、および LAMBDA_HANDLERを追加します。 詳細については、 Instana AutoTrace setup をご覧ください。

以下の serverless.ymlの例を参照してください。

service: service-a

provider:
  name: aws
  runtime: nodejs16.x
  stage: dev
  region: us-east-2

functions:
  with-layer:
    environment:
      INSTANA_ENDPOINT_URL: INSTANA_ENDPOINT_URL
      INSTANA_AGENT_KEY: INSTANA_AGENT_KEY
      LAMBDA_HANDLER: src/index.handler
    layers:
      - arn:aws:lambda:us-east-2:410797082306:layer:instana-nodejs:111
    handler: instana-aws-lambda-auto-wrap.handler

サーバーレス(オフライン)

前提条件: 「Serverless Framework への Instana トレースの統合 」セクションの手順 1 および 2 を確実に実行していることを確認してください。

Instana をServerless Frameworkおよび Serverless Offline と統合するために、ファイルを serverless.yml 編集してください。 以下の手順に従います。

  1. NODE_PATH 環境変数を $NODE_PATH:/opt/nodejs/node_modulesに設定します。
  2. custom セクションで useDocker フィールドを true に設定します。 すると、 Instana レイヤーが自動的に Docker コンテナにダウンロードされます。

以下の serverless.ymlの例を参照してください。

service: service-b

provider:
  name: aws
  runtime: nodejs12.x
  stage: dev
  region: us-east-2

plugins:
  - serverless-offline

custom:
  serverless-offline:
    useDocker: true

functions:
  with-serverless-offline:
    environment:
      NODE_PATH: $NODE_PATH:/opt/nodejs/node_modules
      INSTANA_ENDPOINT_URL: INSTANA_ENDPOINT_URL
      INSTANA_AGENT_KEY: INSTANA_AGENT_KEY
      LAMBDA_HANDLER: src/index.handler
    layers:
      - arn:aws:lambda:us-east-2:410797082306:layer:instana-nodejs:111
    handler: instana-aws-lambda-auto-wrap.handler

サーバーレス Webpack

前提条件: 「Serverless Framework への Instana トレースの統合 」セクションの手順 1 および 2 を確実に実行していることを確認してください。

Instana をServerless Frameworkおよび serverless.yml Serverless Webpack と統合するために、ファイルを編集します。

entrypoint をターゲット Lambda 関数定義に追加します。 エントリポイントは、元の Node.js のLambdaハンドラーであり、これは Instana のLambdaレイヤーによって自動的にトリガーされます。 詳細については、 Instana AutoTrace setup をご覧ください。

以下の serverless.ymlの例を参照してください。

service: service-c

provider:
  name: aws
  runtime: nodejs12.x
  stage: dev
  region: us-east-2

plugins:
  - serverless-webpack

package:
  individually: true

functions:
  with-serverless-webpack:
    environment:
      INSTANA_ENDPOINT_URL: INSTANA_ENDPOINT_URL
      INSTANA_AGENT_KEY: INSTANA_AGENT_KEY
      LAMBDA_HANDLER: src/index.handler
    layers:
      - arn:aws:lambda:us-east-2:410797082306:layer:instana-nodejs:110
    handler: instana-aws-lambda-auto-wrap.handler
    entrypoint: src/index.handler
注:
  • 最新バージョンの serverless-webpackを使用する必要があります。
  • プレーンな Instana Agent キーを. に記述 serverless.ymlすることを避けるため、 AWS System Manager Parameter Store (SSM) for serverless を使用することをお勧めします。 詳しくは、 Serverless Framework ブログを参照してください。

SSMのサポート

AWS SSM (System Manager) パラメーター・ストアを介して Instana エージェント・キーを指定することもできます。

  1. Instana エージェント・キーを SSM パラメーター・ストアに追加します。 パラメーター名を覚えておくか、コピーしてください。
  2. 環境変数から INSTANA_AGENT_KEY を削除します。
  3. コピーしたパラメーター名を使用して、環境変数に INSTANA_SSM_PARAM_NAME を追加します。
  4. パラメーターを「SecureString」として追加した場合は、 INSTANA_SSM_DECRYPTION=trueも設定する必要があります。 「ストリング」型を使用した場合は、追加の変数を設定する必要はありません。
注: 重要:SSMのサポートに関しては、以下の点に留意してください。環境変数からINSTANA_AGENT_KEYを削除しない場合、SSMの環境変数は無視されます。 Lambda関数の実行時間が短い場合、関数が終了する前にSSMフェッチが完了しない可能性があります。 そのような場合、 Instana エージェントキーが取得できない可能性があります。 この問題を回避するには、環境変数 INSTANA_AGENT_KEY を通じてキーを直接指定してください。

Lambda 関数での Instana API の使用

@instana/collectorを使用する単純なバニラ Node.js アプリの場合と同様に、ラムダコードで Instana API 全体にアクセスして使用することができます。

const instana = require('@instana/aws-lambda');
 
注: AutoTrace のセットアップを選択した場合、この @instana/aws-lambda パッケージはLambda関数内で自動的に依存関係として利用可能になります。

その他の環境変数

名前 Default 説明
INSTANA_DISABLE_LAMBDA_EXTENSION false 空でない任意のストリング。 ラムダ拡張を無効にするかどうか。
INSTANA_ENABLE_LAMBDA_TIMEOUT_DETECTION false trueまたはfalse この機能はデフォルトでは無効になっている。なぜなら、タイムアウト・ハンドラーの実行が別の実行時に起こる可能性があるからだ。 デバッグにのみ使用する。 それを可能にすることは、意図しない結果をもたらす可能性がある。 ですから、自己責任で有効にしてください。
INSTANA_MINIMUM_LAMBDA_TIMEOUT_FOR_TIMEOUT_DETECTION_IN_MS 2000 年 タイムアウト(ミリ秒 最小タイムアウト検出をミリ秒単位で増やす。
INSTANA_DEBUG false trueまたはfalse デバッグモードを有効にします。
INSTANA_TIMEOUT 1000 数値 Instana バックエンドへのデータ送信のタイムアウト(ミリ秒単位)。