みなさんこんにちは。マネージドサービス部MSS課の塩野（正）です。
つい先週まで真夏のような暑さだったのに、今週になって秋らしい気温になりましたね。 涼しいくてとても快適なのはうれしいのですが、寒暖差で体調を崩さないように注意したい今日この頃です。
さてさて、今回はCloudwatchLogsのお話となります。みなさんCloudwatchLogsはご活用されていますでしょうか。 とりあえずCloudwatchエージェントからログ転送設定をしてS3に長期保存保存するまでの流れは作ったけど、CloudwatchLogsの設定はよくわからん！という方も少なからずいらっしゃるのではないでしょうか。 今回はそのあたりに切り込んでCloudwatchLogsのメトリクスフィルタ、サブスクリプションフィルタってどのように使い分ければいいかといったのを記事にまとめてみました。
目次
想定読者
- CloudwatchLogsの画面でメトリクスフィルタ、サブスクリプションフィルタの違いがわからない方
- ログフィルタの設定の違いを知りたい方
Amazon CloudWatchとは
まず、基本の部分でAmazon CloudWatchとは何かという点をさらっと振り返ってみましょう。公式サイトの情報を確認すると以下のように記載されていました。
Amazon CloudWatch は、Amazon Web Services (AWS) リソースと、AWS で実行されているアプリケーションをリアルタイムでモニターリングします。CloudWatch を使用してメトリクスを収集し、追跡できます。メトリクスとは、リソースやアプリケーションに関して測定できる変数です。 docs.aws.amazon.com
端的にはEC2にインストールされているWindowsやLinuxなどのOSの状態を監視するエージェントとその関連機能という風に理解いただければ問題ないかと思います。例えばアプリケーションを提供しているユーザーからたくさんアクセスがありCPUが80%に跳ね上がったとか、何かのファイル転送が増えてネットワークの使用量が急激に増えたぞといったような状況が、Amazon CloudWatchを設定していると監視対象にいつ、どのくらい負荷がかかったといった情報をAWSマネジメントコンソールから確認することができるようになります。もちろんAmazon CloudWatchを使用しなくても同様にシステムの監視を行う製品もありますが、監視専用のソフトウェアや監視専用SaaS製品の場合はメトリクスの種類や取得できる情報、マルチクラウド対応といったようなより便利に使える機能が増える反面、ライセンス費用（SaaS利用料）などの料金が追加で必要となりますので、監視の規模や監視に対して何を求めるかといったような点でどのように監視するかを検討いただくのがいいのではないかと考えています。
Amazon CloudWatchLogs機能
さて、Amazon CloudWatchの概要部分は上記でご説明した通りになりますが、今回はAmazon CloudWatchのログ機能にフォーカスして話を進めたいと思います。統合CloudWatchエージェントにはCPUやネットワークの使用状況などのメトリクスを取得してデータを送信する以外にログファイルに書き込まれたログを送信する機能も含まれております。このCloudWatchエージェントで取得したログは任意のロググループに転送されてAWSのマネジメントコンソールから確認することができます。このログを別のサービスに転送したり、メトリクスに変換したものをCloudwatchアラームで検知したりできます。
CloudWatchロググループとログストリーム
CloudWatchLogsにはロググループやログストリームがあり、そういえばこれらの違いってなんだっけ？となりましたので、一旦公式ドキュメントの記載内容を見てみましょう。
ロググループ
ロググループは、保持、監視、アクセス制御について同じ設定を共有するログストリームのグループを定義します。
ログストリーム
ログストリームは、同じソースを共有する一連のログイベントです。より具体的には、ログストリームは一般的に、モニタリングされているアプリケーションインスタンスやリソースから送信された順序でイベントを表すものです。
正直、よくわかりません（汗）
端的に言うならロググループは一連のログを管理するための大きな器で、同じグループ内のログイベントを検索できます。ログストリームはその中のもう少し小さい管理グループの器になります。例えるならロググループはApacheやらNginxなどのアプリケーションが作成したログ出力用のフォルダで、ログストリームは個別のログファイルのような感じになるのではないかと思います。
メトリクスフィルタとは
こちらも公式ドキュメントを見てみましょう。
メトリクスフィルターを使用して、取り込まれたイベントからメトリクスの観測値を抽出し、メトリクス内のデータポイントに変換できます docs.aws.amazon.com
うぅ・・わかりにくい・・（汗）
端的に言うなら、ログは文字列情報となるので、例えばたくさんあるログの中でERRORという文字列を検知した際に、システムでERRORという文字列がログの中にあったよということを認識させる必要があります。もし文字列があったことを検知した場合に、メールやSlackなどで通知するのが一般的かと思いますが、この際に使用するCloudwatchアラームでは文字列有無を検知することができませんので、一定期間内に出力されたログの中に検知すべき文字列（ERROR など）が何個あったよという数値情報に変換する必要があります。この変換を行うのがメトリクスフィルタの機能になり、Cloudwatchロググループの中に指定された文字列を検知した場合にメトリクスという数値情報で値を返してくれます。
メトリクスという数値情報であれば、例えば「5分以内に1件以上ログの中から検知文字列が見つかったらメールを鳴らしてね」というCloudwatchアラームを設定することで、ログ監視を行うことができますね。
サブスクリプションフィルタとは
こちらも公式ドキュメントを見てみましょう。
サブスクリプションを使用して、 CloudWatch ログからのログイベントのリアルタイムフィードにアクセスし、Amazon Kinesis ストリーム、Amazon Data Firehose ストリーム、または AWS Lambda カスタム処理、分析、他のシステムへのロードなどの他の サービスに配信できます。 docs.aws.amazon.com
メトリクスフィルタは検知した文字列を数値に変換する機能でしたが、サブスクリプションフィルタは別の場所に転送（ルーティング）する機能になります。転送先は公式ドキュメントの記載通り、Amazon Kinesis ストリーム、Kinesis Data Firehose ストリーム、または AWS Lambda カスタム処理とAmazon OpenSearch Serviceの4か所に転送ができます。ドキュメントを見る限りはAWSサービス内しか転送できないように見えますが、Kinesis Data Firehose ストリームやAWS Lambdaを経由して、S3やSaaSの監視サービス（例えばNew RelicやDatadog、Splunk、HTTPエンドポイントなど）にログを転送することができますので、サブスクリプションフィルタを使う一番の理由は、このログ転送といっても過言ではないでしょう。
メトリクスフィルタとサブスクリプションフィルタの違い
上記をまとめてみると下記のようになります。
| 特徴 | メトリクスフィルター | サブスクリプションフィルター |
|---|---|---|
| 目的 | ログデータを CloudWatch メトリクスに変換する | 指定された送信先にリアルタイムでログデータをストリーミングする |
| 出力先 | CloudWatch メトリクス | AWS Lambda、Amazon Kinesis Data Streams、Amazon Kinesis Data Firehose |
| データ形式 | 数値メトリクス | base64 エンコードされ、gzip 形式で圧縮されたログデータ |
| 制限 | ロググループあたり100個 | ロググループあたり2個 |
| ユースケース | - ログ内のエラー数のモニタリング - 特定のイベントの発生頻度の追跡 - カスタムメトリクスの作成 |
- リアルタイムログ分析 - 複数アカウント間でのログの集約 - ログデータの長期保存 |
| フィルターパターン | 正規表現、JSON、スペース区切りのログイベントに対応 | 正規表現、JSON、スペース区切りのログイベントに対応 |
上記に記載した通りメトリクスとして数値変換したいのか、別の場所に転送したいのかによって差があることがわかりました。
ログ送信とフィルタ機能
CloudwatchLogs機能では、事前に設定したフィルタ条件に基づいてログをフィルタすることができます。やっぱりERRORログだけ検知したいのにそれ以外のログを検知されたら鬱陶しいですもんね。ですので、たくさんあるログの中から、例えば「ERROR」という文字列を含むログだけをフィルタしたい場合は、フィルタ設定することで対象文字列を含むログを検知したりログ送信することができます。
この時にどこでフィルタするかによってその後の挙動が変わってきます。
こちらの絵を見ていただくのが早いのですが、フィルタはCloudwatchエージェント側でもメトリクスフィルタやサブスクリプションフィルタ側でも行うことができます。これらにはどのような違いがあるのでしょうか。CloudWatchログエージェント側のログフィルタとメトリクスフィルタ、サブスクリプションフィルタの特徴とメリット・デメリットを表形式でまとめてみました。
| フィルタの種類 | 特徴 | メリット | デメリット |
|---|---|---|---|
| CloudWatchエージェント側のログフィルタ | ログの収集時点でフィルタリングを行う | - ログの転送量を削減できる - ネットワーク帯域幅の使用を抑えられる - CloudWatchへの保存コストを削減できる |
- フィルタの変更にはエージェントの再設定が必要 |
| メトリクスフィルタ | CloudWatchに転送されたログからメトリクスを生成する | - ログデータを数値化してモニタリングできる - カスタムメトリクスの作成が可能 - アラームと連携しやすい |
- 全ログが転送されるため、コストが高くなる可能性がある - 複雑なフィルタリングには向かない |
| サブスクリプションフィルタ | ログをリアルタイムで他のAWSサービスに転送する | - リアルタイムでのログ分析が可能 - 複数アカウント間でのログの集約ができる - 長期保存や詳細な分析が可能 |
- 設定の複雑さが増す - 追加のAWSサービスのコストが発生する |
それぞれメリットとデメリットがあるため、メリット・デメリットを考慮すると、以下のような使い分けがよさそうです。
- セキュリティ上重要なログや詳細な分析が必要なログは、エージェント側でフィルタリングせずにCloudWatchに転送し、メトリクスフィルタやサブスクリプションフィルタを活用する。
- 重要度の低いログや大量に生成されるログは、エージェント側でフィルタリングして転送量を抑える。
- リアルタイム性が求められる場合や、他のAWSサービスと連携が必要な場合は、サブスクリプションフィルタを活用する。
まとめ
CloudWatchLogsの機能について調べた結果をまとめてみましたが、どのように運用するかによってどこの設定を変えればいいかというポイントが理解できました。監視の中でもログ監視は必須の項目のひとつではありますが、ログ種別によってはコストダウンが図れたり、他のサービスに連携してログ保管したりアラート検知させたりとうまく使えば色々できそうですね。
この記事がどなたかのお役に立てれば幸いでございます。
