こんにちは、Luup SREチームのにわです。
経緯
LuupではAWS IoT CoreのログをDatadogに入れて分析をしようと取り組んでいます。その中で、AWS IoT CoreのログはAWSIotLogsV2として送信されます。Luupでは、このAWSIotLogsV2に含まれるログには、 イベントごとにPublish-In, RuleExecution, Publish-Out, Disconnectなどのログが含まれています。
現時点では公式のLog PipelineはPipeline Libraryにないため、Datadogのサービスがひと固まりのAWSIotLogsV2として記録されるため、非常に見づらく検索性が悪く、Ingested logの種類分けによるDatadogのコスト分析も難しい状態になっていました。
本題
私の過去の経験として、以前Graylogというログ管理ツールを運用していたことがありました。その中にはLog Pipeline機能があり、Grokパーサーや様々なルールを使ってログを分割または結合できるようになっていました。今回私が初めてDatadogを使うことになり、その機能があるか探してみたところ似た機能があったのでLog Pipelineを利用してみることにしました。
目的
- Datadogで
AWSIotLogsV2のログをイベントごとに分類した上で、サービスの登録 - Cloud Functionsから送られてくる開錠・施錠関連のログの可視化
概要
DatadogでAWSIotLogsV2のログをイベントごとに分類した上で、サービスの登録
上部で記載しましたが、Datadog公式のLog PipelineはPipeline Libraryにない状態のため、以下の設定がどなたかの役に立てばと思い、一例として詳細に記載します。
-
source:awsiotlogsv2として設定し、Pipelineを作成する。 - Message Remapperの
message attributeにdetailsを設定する。
- String Builder Processorに以下を設定する。
- target attribute path:
aws.iot.core.serviceEventType - target attribute value:
AWSIoTCore-%{eventType}
- target attribute path:
- Service Remapperの
service attributeにaws.iot.core.serviceEventTypeを設定する。
結果として、以下の画像のようにイベントごとにサービス分類が可能となりました。
Cloud Functionsから送られてくる開錠・施錠関連のログの可視化
Luupでは、Cloud Functionsを多く採用し、開錠や施錠にかかわるアプリケーションも動いています。
その中のログには車両のIDが書かれています。それをDatadogのLog Pipleineを利用して、グルーピングを行いどの車両がどれだけ失敗したかなどを分析するために役立てています。
一例として以下のように設定しました。
-
source:gcp.cloud.functionとして設定し、Pipeline#1を1つ作成する。 - Pipeline#1において、Message Remapperの
message attributeにdata.jsonPayload.messageを設定する。
-
Service:<target_functions>として設定し、Pipeline#2を1つ作成する。 - Pipeline#2において、Grok Parserを以下のように設定する。
Grok parserにおける正規表現の公式ガイドはこちらrule_deviceId ^.*device:%{regex("[a][0-9]*"):data.labels.deviceId}.*$
-
data.labels.deviceIdをログの検索画面において、facetを登録する。
このようにすることで、ログ検索においてしたTop Listを利用した場合に、例として以下のようにグルーピングされた車両IDの一覧が集計された形で出てきます。
最後に
上記を設定したことによって、より鮮明化されたメトリクスやログ情報によって分析がしやすくなっています。
今後のSREの活動の中で、SLOを含めユーザーさんによりいい体験をしていただくべく、DatadogのLog Pipelineも活用して、改善と可観測性（Observability）を向上していきたいと思っています。
Discussion