re:Inventに行っても僕は、ブースで一日中demoをしているので、講演は1つも聴いていません。Advent Calenderの記事を書くことを機に、DatadogのエバンジェリストのMatt Williamsが、"Lambdaの監視"に関して講演した内容を、Datadog視点で振り返って見ようと思いました。
先ずは、セッションに関するリンク:
- Video: AWS re:Invent 2016: Monitoring, Hold the Infrastructure: Getting the Most from AWS Lambda (DEV205)
- Slide: AWS re:Invent 2016: Monitoring, Hold the Infrastructure: Getting the Most from AWS Lambda (DEV205)
- プレゼンのPDF
- プレゼン内のソースコード
Videoを見ていると、セッションの80％の40分はlambdaの話をしているですよね。残りの20％で監視をしているのですが、lambdaの話は、5分くらいしか話していないので、なんとなく消化不良ではないですか？
ということで、僕が分かっている限りで、情報を補足します。
Lambdaの監視って、CloudWatchでもできるよね！
AWS Lambdaのドキュメントを読んでいると、メトリクスの一覧が出ていますね。
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/monitoring-functions-metrics.html
これらは、DatadogのAWS integrationを収集することができます。下記に示すメトリクス名が、AWS integrationを有効にし、インテグレーションタイルで、Lambdaにチェックマークを入れた際にDatadogのクローラーが集取していくるメトリクス。
Metrics:
| メトリクス名 | メトリクスタイプ | 概要 | 単位 |
|---|---|---|---|
| aws.lambda.duration | (gauge) | Measures the average elapsed wall clock time from when the function code starts executing as a result of an invocation to when it stops executing. | shown as millisecond |
| aws.lambda.duration.maximum | (gauge) | Measures the maximum elapsed wall clock time from when the function code starts executing as a result of an invocation to when it stops executing. | shown as millisecond |
| aws.lambda.duration.minimum | (gauge) | Measures the minimum elapsed wall clock time from when the function code starts executing as a result of an invocation to when it stops executing. | shown as millisecond |
| aws.lambda.duration.sum | (gauge) | Measures the total execution time of the lambda function executing. | shown as millisecond |
| aws.lambda.errors | (count every 60 seconds) | Measures the number of invocations that failed due to errors in the function (response code 4XX). | |
| aws.lambda.invocations | (count every 60 seconds) | Measures the number of times a function is invoked in response to an event or invocation API call. | |
| aws.lambda.throttles | (count every 60 seconds) | Measures the number of Lambda function invocation attempts that were throttled due to invocation rates exceeding the customer’s concurrent limits (error code 429). Failed invocations may trigger a retry attempt that succeeds. |
DLQ errorが載っていないのが気になります。なぜ載っていないのかに関しては、現在調査中です。追って、updateしたいと思います。
本当に欲しいモノは、Lambda内のカスタムなメトリクス！
あったらら良いなと思うサービスを準備してくるのがDatadogなので、Lambda関数内からもカスタムメトリクスを集取する仕組みを持っています。DatadogのAPIを使ってカスタムメトリクスをLambda関数からDatadogに送信することができるのは、なんとなく発想できると思います。しかしこの方法では、関数の実行に遅延を発生させたり、関数を複雑化することになります。
そこで、AWS Lambda用クローラーには、次に示すフォーマットに従ってCloudWatch logsに出力した行を、パースしカスタムメトリクスとして保存する機能を持っています。(クローリングのタイミングは、AWS integrationのタイミングに準拠しています。クローリング周期を調整したい場合は、support@datadog.comに問い合わせてみてくいださい。)
出力フォーマット
CloudWatch logsへの出力フォーマットは、次になります。
MONITORING|unix_epoch_timestamp|value|metric_type|my.metric.name|#tag1:value,tag2
| フォーマット内名称 | 概要 |
|---|---|
| MONITORING | パースの対象である宣言 |
| unix_epoch_timestamp | 秒単位のunixタイムスタンプ |
| value | メトリクスの値 |
| metric_type | メトリクスのタイプ |
| my.metric.name | メトリクス名 |
| #tag1:value,tag2 | Datadogでメトリクスの分類に使うタグ |
node.jsの場合、デバッグメッセージを出力するのと同じように、次にようにconsole.logでコード化します。
console.log("MONITORING|%d|1|count|mattlambda.images.count|#demo:matt, imagefcn:convert", Math.floor(Date.now()/1000));
コードの全体像は、下記を参照してください。
https://github.com/DataDog/monitorlambdasession/blob/master/index.js#L60-L61
上記に紹介した方法で、Lambda関数からDatadogへカスタムメトリクスを送信する際の注意する点は、IAMロールにlogs:DescribeLogGroups, logs:DescribeLogStreams, logs:FilterLogEventsの権限を付与することです。Lambda用のクローラーは、CloudWatch logsから情報を取得しています。この設定がを忘れると定期的にlogにアクセスし、それらをパースすることができません。
まとめ
50分のセッションでLambda監視の説明が5分しかなかったのは、それほど簡単にできるようになっているということでした。
Datadogを使えば、Lambdaのからのカスタムメトリクスは送信は、CloudWatch logsに出力するだけで完了です。最初のメトリクスの到着が確認できれば、そこから先は、他のインテグレーションと同様に可視化したり、アラート設定することができるようになっています。
AWS Lambdaを使ったインフラの運用にの監視に、是非この監視機能を使ってみてください。