ブログ

PrometheusとSysdigを使用したAWS Lambdaのモニタリング

PrometheusとSysdigを使用したAWS Lambdaのモニタリング

本文の内容は、2020年7月14日にDavid de Torres Huertaが投稿したブログ(https://sysdig.com/blog/monitor-aws-lambda-prometheus/)を元に日本語に翻訳・再構成した内容となっております。

この投稿では、Sysdig Monitor を使用してAWS Lambdaを簡単に監視する方法を示します。既存のPrometheusの取り込みをSysdigで活用することにより、サーバーレスサービスを単一のペインオブグラスで監視できるようになり、これらのサービスを本番環境で実行する自信が得られます。

20200715-1.png

サーバーレスの台頭

現在、AWS Lambdaなどのサーバーレスコンピューティングの台頭を目撃しています。Lambdaは、サービスとしての機能(FaaS)リソースであり、FTPサーバーに到着するファイルなどのイベント、キュー内のイベント、または別のLambdaファンクションに基づいてコードを実行します。このように、Lambdaは非常にスケーラブルなコンピューティングインフラストラクチャーを提供しています。計算負荷がないときに予備のサーバーを維持して支払う必要はありません。

これらのサービスがビジネスの一部になると、他の本番ワークロードと同じように監視して、正常性とパフォーマンスを確保する必要があります。しかし、Sysdigエージェントをインストールできない場合、サーバーレスサービスをどのように監視できますか?AmazonのモニタリングサービスであるAWS Cloudwatchのような仲介者に依存する必要があります。

AWS LambdaとPrometheus

AWS LambdaはサーバーレスFaaSサービスであり、開発者はコードをコンテナイメージにパックしてイベントを通じてトリガーする必要なくコードをデプロイできます。また、CloudWatchサービスがネームスペースAWS/Lambdaの下で収集できる特定のメトリクスも出力します。

Prometheusは、エクスポーターを作成して統合を簡単に作成する手段を提供する、業界をリードするオープンソースモニタリングソリューションです。Prometheusを使用すると、単一のペインオブグラスアプローチに従って、複数のクラウドプロバイダーに分散している可能性のあるインフラストラクチャー全体からメトリクスを収集できます。

Prometheusエクスポーターは、サービスからメトリクスを収集し、PrometheusサーバーとSysdigエージェントの両方がネイティブにスクレイピングできる標準化された形式で公開します。AWS CloudWatchからメトリクスを取得するために、これらのエクスポーターの1つ、すなわちyet-another-cloudwatch-exporterを使用します。私たちは、このエクスポーターをより効率的で信頼できるものにするためにコントリビュートしました。

20200715-2.png

このユースケースでは、CloudWatchエクスポーターをKubernetesクラスターにデプロイし、AWSでLambdaのメトリクスを収集するように構成します。このエクスポーターにはPrometheusタグでアノテーションが付けられるため、PrometheusサーバーとSysdigエージェントの両方がスクレイプことができます。次の図に、システムの全体図を示します。

20200715-3.png

Prometheus CloudWatchエクスポーターのインストールと設定

エクスポーターはAWS CloudWatch APIに接続してメトリクスを要求しますが、正しい答えを得るには、いくつかのアクセス許可を設定する必要があります。このセクションでは、この接続を可能にするアクセス許可と認証情報を使用してAWSアカウントを設定する手順について説明します。

CloudWatchメトリクスにアクセスするためのアクセス許可を設定する

最初に、次のアクセス許可を含むAWS IAMポリシーを作成する必要があります。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "CloudWatchExporterPolicy",
            "Effect": "Allow",
            "Action": [
                "tag:GetResources",
                "cloudwatch:ListTagsForResource",
                "cloudwatch:GetMetricData",
                "cloudwatch:ListMetrics"
            ],
            "Resource": "*"
        }
    ]
}

AWS IAMポリシーの設定

また、AWS IAMアカウントの認証情報をCloudWatchエクスポーターに提供する必要があります。これは、$HOME/.aws/credentialsファイルを介して標準的な方法で行うことができます。

# CREDENTIALS FOR AWS ACCOUNT
aws_region = us-east-1
aws_access_key_id = AKIAQ33BWUG3BLXXXXX
aws_secret_access_key = bXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

$HOME/.aws/credentialsファイル。

IAMポリシーをIAMアカウントに直接割り当てるか、IAMロールに割り当てて、エクスポーターにアクセス許可を付与できます。

エクスポーターの設定

Goで記述され、安定したバージョンのデプロイ可能なイメージを備えた、yet-another-cloudwatch-exporter (YACE) を選択しました。

このエクスポーターはAWS CloudWatchからメトリクスをフェッチし、それらをOpen Metrics形式で公開します。次に、Sysdigエージェントのprometheus取り込みコンポーネント、またはPrometheusサーバーによってそれらをスクレイピングできます。

YACEエクスポーターは、任意のCloudWatchネームスペースからメトリクスを収集できます。したがって、Lambdaをモニタリングするには、正しいネームスペースとメトリクスを定義して、スクレイピングするLambdaメトリクスを選択する必要があります。

これを行うには、まず、エクスポーターの設定ファイルを作成する必要があります。 この設定では、エクスポーターがスクレイピングするメトリクス、リージョン、およびCloudWatchに集約を行うために要求するディメンションを定義します。 この例では、リージョンus-east-1を使用します。

次にconfig.yml設定ファイルの例を示します。

discovery:
 jobs:
 - regions:
   - us-east-1
   type: lambda
   enableMetricData: true
   metrics:
     - name: Duration
       statistics:
       - Sum
       - Maximum
       - Minimum
       - Average
       period: 300
       length: 3600
     - name: Invocations
       statistics:
       - Sum
       period: 300
       length: 3600
     - name: Errors
       statistics:
       - Sum
       period: 300
       length: 3600
     - name: Throttles
       statistics:
       - Sum
       period: 300
       length: 3600 
     - name: DeadLetterErrors
       statistics:
       - Sum
       period: 300
       length: 3600
     - name: DestinationDeliveryFailures
       statistics:
       - Sum
       period: 300
       length: 3600
     - name: ProvisionedConcurrencyInvocations
       statistics:
       - Sum
       period: 300
       length: 3600
     - name: ProvisionedConcurrencySpilloverInvocations
       statistics:
       - Sum
       period: 300
       length: 3600
     - name: IteratorAge
       statistics:
       - Average
       - Maximum
       period: 300
       length: 3600
     - name: ConcurrentExecutions
       statistics:
       - Sum
       period: 300
       length: 3600
     - name: ProvisionedConcurrentExecutions
       statistics:
       - Sum
       period: 300
       length: 3600
     - name: ProvisionedConcurrencyUtilization
       statistics:
       - Maximum
       period: 300
       length: 3600
     - name: UnreservedConcurrentExecutions
       statistics:
       - Sum
       period: 300
       length: 3600

設定ファイルでは、パラメーターenableMetricDataがtrueに設定されていることに注意してください。これは、このAPI関数により、エクスポーターが1回の呼び出しで複数のメトリクスを取得できるためです。これは、AWS APIサービスをブロックする可能性があるCloudWatch APIへのスロットリングシナリオを防ぐために重要です。

以下を念頭において注意してください。

  1. 追加のメトリクスを追加する場合は、AWS Lambdaメトリクスを読んで、正しい統計情報を使用してください。
  2. CloudWatchは、さまざまなディメンションによる集計を提供します。YACEエクスポーターは、メトリクスを集計するデフォルトのディメンションとしてFunctionNameを自動的に選択します。
  3. CloudWatchメトリクスを収集すると、AWSで一定の費用がかかる場合があります。CloudWatchサービスのクォータ制限に関するAWSドキュメントを必ず確認してください。

IAMアカウントの認証情報と設定ファイルの準備ができたら、次のようにKubernetes YAMLファイルを作成できます。

apiVersion: v1
kind: Namespace
metadata:
 name: yace
---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: yace-lambda
 namespace: yace   
spec:
 selector:
   matchLabels:
     app: yace-lambda
 replicas: 1
 template:
   metadata:
     labels:
       app: yace-lambda
     annotations:
       prometheus.io/scrape: "true"
       prometheus.io/port: "5000"
   spec:
     containers:
     - name: yace
       image: quay.io/invisionag/yet-another-cloudwatch-exporter:v0.16.0-alpha
       ports:
       - containerPort: 5000
       volumeMounts:
         - name: yace-lambda-config
           mountPath: /tmp/config.yml
           subPath: config.yml
         - name: yace-lambda-credentials
           mountPath: /exporter/.aws/credentials
           subPath: credentials
       resources:
         limits:
           memory: "128Mi"
           cpu: "500m"
     volumes:
       - configMap:
           defaultMode: 420
           name: yace-lambda-config
         name: yace-lambda-config
       - secret:
           defaultMode: 420
           secretName: yace-lambda-credentials
         name: yace-lambda-credentials
---
apiVersion: v1
kind: ConfigMap
metadata:
 name: yace-lambda-config
 namespace: yace
data:
 config.yml: |
   discovery:
     jobs:
     - regions:
       - us-east-1
       type: lambda
       enableMetricData: true
       metrics:
         - name: Duration
           statistics:
           - Sum
           - Maximum
           - Minimum
           - Average
           period: 300
           length: 3600
         - name: Invocations
           statistics:
           - Sum
           period: 300
           length: 3600
         - name: Errors
           statistics:
           - Sum
           period: 300
           length: 3600
         - name: Throttles
           statistics:
           - Sum
           period: 300
           length: 3600 
         - name: DeadLetterErrors
           statistics:
           - Sum
           period: 300
           length: 3600
         - name: DestinationDeliveryFailures
           statistics:
           - Sum
           period: 300
           length: 3600
         - name: ProvisionedConcurrencyInvocations
           statistics:
           - Sum
           period: 300
           length: 3600
         - name: ProvisionedConcurrencySpilloverInvocations
           statistics:
           - Sum
           period: 300
           length: 3600
         - name: IteratorAge
           statistics:
           - Average
           - Maximum
           period: 300
           length: 3600
         - name: ConcurrentExecutions
           statistics:
           - Sum
           period: 300
           length: 3600
         - name: ProvisionedConcurrentExecutions
           statistics:
           - Sum
           period: 300
           length: 3600
         - name: ProvisionedConcurrencyUtilization
           statistics:
           - Maximum
           period: 300
           length: 3600
         - name: UnreservedConcurrentExecutions
           statistics:
           - Sum
           period: 300
           length: 3600
---
apiVersion: v1
kind: Secret
metadata:
 name: yace-lambda-credentials
 namespace: yace
data:
 # Add in credentials the result of: 
 # cat ~/.aws/credentials | base64
 credentials: |

このファイルでは、以下を見つけることができます。

  • ネームスペース 'yace'
  • エクスポーターによるデプロイメント。このデプロイメントには2つのボリュームがあり、1つは設定ファイルを使用し、もう1つは資格情報を使用します。デプロイメントには、スクレイピング用のPrometheusタグとポートのスクレイピングのアノテーションが付けられていることに注意してください。
  • エクスポーター設定用の ConfigMap
  • IAMアカウントの認証情報でのシークレット

簡単なテストとして、ポッドのポート5000を転送してCloudWatchエクスポーターを確認し、yace-lambdaの場所でページを閲覧できます。

http://<our machine>:5000/metrics

すべてが問題なければ、次のようなメトリクスのWebページが表示されます(サイズの都合で出力を切り捨ててます)。

# HELP aws_lambda_concurrent_executions_sum Help is not implemented yet.
# TYPE aws_lambda_concurrent_executions_sum gauge
aws_lambda_concurrent_executions_sum{dimension_FunctionName="90-percent-success-10-percent-fail",name="arn:aws:lambda:us-east-1:059797578166:function:90-percent-success-10-percent-fail",region="us-east-1"} 5
# HELP aws_lambda_duration_average Help is not implemented yet.
# TYPE aws_lambda_duration_average gauge
aws_lambda_duration_average{dimension_FunctionName="90-percent-success-10-percent-fail",name="arn:aws:lambda:us-east-1:059797578166:function:90-percent-success-10-percent-fail",region="us-east-1"} 3.5199999999999996

AWS Lambda関数のモニタリング:何を探すべきですか?

エラー:AWS Lambdaを監視している間、監視する4つのゴールデンシグナルの1つとしてエラーを探すことが重要です。CloudWatchは、メトリクスerrorsの関数エラーを引き起こす呼び出しを登録します。関数が同期的に呼び出されると(関数を呼び出すプロセスは、関数が終了するのを待って結果を受け取ります)、エラーが関数の呼び出し元に返され、処理または再試行できます。

また、Lambda関数はイベントから非同期でトリガーできます。このモードでは、関数はキュー、ファイル、またはその他の方法で結果を返します。しかし、非同期と呼ばれる関数が、権限エラーまたは設定ミスのためにイベントを宛先に送信できなかった場合はどうなりますか?これが発生すると、メトリクスDestinationDeliveryFailuresに登録されます。

同時実行性とスロットル:AWS Lambda関数を監視するときに探すべきもう1つの重要なシグナルは、システムのサチュレーションです。Lambda関数は同時に呼び出されるように設計されていますが、アカウントとリージョンで同時に実行できる関数の量があり、通常は1,000です。この制限に達した場合、関数は実行されず、メトリクスThrottlesに登録されます。

一部の関数に特定の数の同時実行があることを保証したい場合はどうなりますか? Lambdaでは、同時実行性を予約して関数に割り当てることができます。このようにして、予約済みの同時実行性を持つ関数は、常にその量の可能な関数を同時に実行し、残りの同時実行性はアカウント内の残りの関数に使用されます。ただし、関数が予約済みの同時実行性を超えると、呼び出しが抑制されるため、注意が必要です。ConcurrentExecutions関数の予約済みキャパシティを調整し、スロットルを減らすために、メトリクスを監視することが重要です。

同期実行では、関数が抑制された場合、呼び出し元は関数を再起動できますが、非同期実行ではどうなりますか? Lambdaは、関数を2回トリガーするイベントの処理を再試行します。その後、イベントは配信不能キューに送信され、後でエラーを調べるように設定できます。この配信不能キューは誤って設定されているか、権限が正しく設定されていない可能性があり、Lambdaはキューへのイベントの投稿に失敗する可能性があります。メトリクスDeadLetterErrorsは、登録されたこれらのエラーの数を示します。

レイテンシーとトラフィック:Lambda関数のレイテンシは、Durationメトリクスで測定できます。これにより、関数が正しく終了するまでにかかったミリ秒(初期化時間を含む)がわかります。このメトリクスは、最小、最大、平均などのさまざまな統計をサポートします。また、トラフィック(4番目のゴールデンシグナル)を、Invocationsメトリクスで関数が実行された回数(正しく終了したか、エラーで終了したか)として確認することもできます。このメトリクスは、AWS CloudWatchによって請求されたリクエストの数と同じです。

関数の実行時間が長い場合、プロビジョニングされた同時実行を使用して最適化できます。これは予約済みの同時実行性に似ていますが、関数にはすべてのライブラリと依存関係がプリロードされています。これにより、関数を初期化する時間が短縮されます。各関数のプロビジョニングされた同時実行性を適切に調整するには、メトリクスProvisionedConcurrencyInvocationsとProvisionedConcurrencyUtilizationが使用できます。関数がプロビジョニングされた同時実行数の制限を超えても、利用可能な同時実行性がある場合、実行ではプロビジョニングされていない(標準)同時実行が使用されます。これらの実行はProvisionedConcurrencySpilloverInvocationsメトリクスに登録され、関数のプロビジョニングされた同時実行性のサチュレーションについてのアイデアを提供します。

最後に、関数がストリームソースから読み取っている場合、メトリクスIteratorAgeはシステムのサチュレーションの良いメトリクスです。このデータは、最後のイベントがLambda関数によって処理される前にストリームで費やした時間(秒単位)です。イテレータの経過時間が長いということは、ストリーム内のデータが、関数によって処理されているよりも高いレートで到達していることを意味します。

考えられる問題とそれらを検出するためのアラート

コード内のエラー:関数の新しいデプロイメント、または入力の変更により、制御不能なエラーが発生する可能性があります。この場合、相対エラー率でエラーの絶対数よりも適切に警告することをお勧めします。次のようなpromQL文を使用して、関数のコードによって生成されたエラーが合計呼び出しの15%を超えていることを検出できます。

(aws_lambda_errors_sum / aws_lambda_invocations_sum) > 0.15

設定の問題:メトリクスで検出できるいくつかの設定エラーがあり、それらの値がゼロでないときにアラートを出すことができます。これは、関数が非同期で呼び出され、実行時にエラーを処理できない場合に特に便利です。これらのpromQLクエリは以下を検出できます。

イベントを宛先配信に送信する際の問題:

aws_lambda_destination_delivery_failures_sum > 0

配信不能キューへのイベント送信の問題:

aws_lambda_dead_letter_errors_sum > 0

同時実行性の問題:アラートが発生する主な問題は、関数がスロットルしているときです。これは、AWSアカウントがそのリージョンの同時実行性の合計を超えたため、または割り当てられていた予約済みの同時実行性がすべて関数によって終了したことが原因である可能性があります。このシナリオでは、関数またはアカウントの同時実行性がサチュレートし、関数が実行されています。これは、次のクエリーで検出できます。

aws_lambda_throttles_sum  > 0

関数のパフォーマンスが低い:このpromQLクエリを使用すると、平均して関数の実行が遅すぎる場合(たとえば、250ミリ秒)にアラートを出すことができます。

aws_lambda_duration_average{dimension_FunctionName='yourFunctionName'} > 250

また、ストリーム内の受信イベントがLambda関数の処理速度よりも高い速度で到着したときにアラートを出すことができます。これは、同時実行性がプロビジョニングされた関数の実行時間を短縮して初期化時間を最小限に抑え、関数のメモリを増やすことで軽減できます。この問題は、イテレータのageが高い(たとえば1秒)ことで明らかになります。これは、それを検出するためのpromQLクエリーです。

aws_lambda_iterator_age_average > 1000

警告とさらなる改善

これは、Prometheusエクスポーターを使用してAWS Lambdaを監視し、少しの労力でいくつかのカスタムメトリクスを取得する方法の単純化したプレゼンテーションでした。

いくつかの警告と制限がまだ残っています:

#1:この例では、粒度が300秒のメトリクスを要求するようにエクスポーターを設定しました。これは、エクスポーターに、デフォルトで300秒ごとにCloudWatchへの呼び出しをプロキシできる機能があるためです。ただし、これは異なる値に変更および調整できます。タグでサービスをフィルタリングすると、5分では不十分な重要なタスクのデータを60秒の粒度とプロキシリフレッシュで設定し、その他の重要度の低いサービスでは1時間の粒度を設定できます。このようにして、CloudWatchアカウントの請求を最適化できます。

#2:機能の数が多いアカウントでは、CloudWatchによって提供されるメトリクスの数も多い可能性があります。これは、CloudWatchの使用量が予想外に増える可能性があります。これを回避するために、提示したCloudWatchエクスポーターは、タグでメトリクスを要求するリソースをフィルターするように設定できます。たとえば、本番環境のメトリクスに関心があるかもしれませんが、開発環境のメトリクスには関心がないかもしれません。

#3:この例では、Lambdaで使用できる最も関連性の高いメトリクスを含めました。ただし、必要がない場合は、設定をカスタマイズして、それらの一部をドロップすることができます。

CloudWatchメトリクスをSysdigモニターに取り込む

Sysdigエージェントのセットアップ

このセクションでは、これらのメトリクスをSysdigモニターに取り込む方法を示します。これはかなり簡単で、インストール後はSysdigエージェントの最小構成が必要なので、Prometheusメトリクスをキャプチャーします。

以下は/opt/draios/etc/dragent.yaml、エクスポーターでコンテナのスクレイピングを実行するファイルに挿入する必要があるいくつかのサンプルコードです。

10s_flush_enable: true
use_promscrape: true
prometheus:
 enabled: true
 histograms: true
 ingest_raw: true
 ingest_calculated: false
 interval: 10
 log_errors: true
 max_metrics: 3000
 max_metrics_per_process: 20000
snaplen: 512
tags: role:cluster

主な項目は次のとおりです。

  1. Prometheusメトリクスの収集をオンにします。
  2. Prometheusスクレーパーのプロセスフィルターを指定します。スクレイプ、パス、ポートのPrometheusアノテーションは、エクスポーターを起動したコマンドでも定義されていることに注意してください。

設定が保存されると、エージェントはそれを自動的に取得します。

数分以内に、メトリクスが徐々に流れ始め、Sysdigモニターインターフェイスに表示されます。

ダッシュボードとアラートによるAWS Lambdaのモニタリング

Sysdig MonitorでLambdaメトリクスを取得したら、ダッシュボードを使用してそれらを視覚化できます。そのために、Sysdigは一般的な概要と詳細なダッシュボードを提供しています。Lambda Golden Signals Dashboardは、アカウントの関数の全体的な動作の概要を提供し、潜在的な問題を簡単に識別できるようにします。

20200715-4.png

Sysdigモニター- AWS Lambda Golden Signalsダッシュボード

では関数詳細ダッシュボード、あなたが詳細に検査したい機能を選択するために、変数を使用することができます。

20200715-5.png

Sysdigモニター- AWS Lambda関数詳細ダッシュボード

まとめ

CloudWatchメトリクスをSysdigモニターに統合することで、AWS Lambdaを監視するのが本当に簡単であることを実証しました。これは、Prometheusメトリクスをネイティブに取り込み、この記事で紹介したCloudWatchエクスポーターなどの既存のエクスポーターを活用するための標準化されたインターフェイスを持つことで可能になります。

この統合を試してみたい場合は、無料トライアルにサインアップしてください。

また、エクスポーターのインストール方法と、PromCat.ioでAWS Lambdaを監視するための設定を使用する手順についても確認できます。ここには、GrafanaとSysdigの両方の形式で提示したダッシュボードと、サービスのアラートの例もあります。

Prometheus統合の詳細については、ドキュメントまたはブログをご覧ください。

関連コンテンツ

最近の投稿

カテゴリー

アーカイブ

ご質問・お問い合わせはこちら

top