リリースから随分日が経っていますが、改めてCloudWatchLogsの良さを書きます。今回はLogs Agentや取り込みの話しは触れません。Logsに取り込んだは良いけど、どうしよう にフォーカスします。
その前にCWLogsの概要
長いのでCWLogsと略記。 CWLogsは文字通り、システムログやアプリケーションログ、Windowsはイベントログも含むを、CloudWatchLogs(AWS側の基版と言い換え可能)に投げます。CloudWatchはカスタムメトリックスといって、ユーザーが任意のメトリックスを送信することが出来ますが、CWLogsはそれのLog版となります。Logですので、メトリックス値(数値)ではなく、ログそのもの=文字列です。
ログをCWLogsに投げる処理は、CWL-Agent等を使います。前述の通りCWLogsに投げるまでの話しはこの記事では触れません。
CWLogsの代替
ここまでの 「Logを何処か一箇所に投げる」という機能だけみれば、fluentdや、同じくAWSのkinesis、kafkaなどでも実現出来ます。逆に言うと、「Logを何処か一箇所にに投げる」という目的だけで使ってしまうと、ある程度の量を越えると割高で、kinesisの方がお得です。
これより、CWLogsの利点です。
用語説明
その前に用語説明を
ロググループ 後述のログストリームを束ねるものです。一般的にログの種類でロググループを分けます。
e.g. /var/log/messages や /var/log/http/access_log 毎に1ロググループ
ログストリーム 必ずどこかのロググループに所属します。一般的にはホスト毎に1ストリームとします。そうしない設計も可能ですが、その場合ログの中にホスト名を書くなど考慮が必要です。(どのホストのログか見かけが付けられないので)
The Log group has some Log streams .
A Log stream belong to one Log group.
CWLogsの利点
1.マネジメントコンソールからログの検索
2.メトリックスフィルタにより、ログをメトリックス(数値)化、そこからClowdWatch アラート発報
3.ロググループをサブスクライブして、Lambdaでリアルタイム処理
マネジメントコンソールからログの検索
ロググループ単位で検索可能です。つまり複数のホストのログをまとめて、時間と検索文字列を指定して探すことができます。触ればわかる機能ですので、詳しく説明しませんが。これはこれで便利だと思います。
メトリックスフィルタについて
CWLogsがリリースされたすぐに使えた機能です。先の説明どうりですが、Log中の特定の値を含んだものをカウントし、Logを数値化します。これを ClowdWatchで閾値を指定、アラーム発報とします。メトリックスフィルタは、ロググループ単位で指定します。
メトリックスフィルタの特徴
Pros
- 1つのロググループに対して、複数のメトリックスフィルタを指定可能
- フィルタルールは結構柔軟。複合条件に似たような記載も可能(後述)
- 検出・通知までプログラミングは一切不要
Cons
- ログ -> 数値化し、その数値に対してアラート発報をするだけなので、
ログのアラート発報の原因となったレコード自体はわからない
簡単に指定出来る点は有利ですが、ログそのものはアラートに含まれないという欠点があります。
つまり、
アラート飛んできたら、どのログ(種類)でアラートを検出したかや、発生の時間帯はわかるが、どのノードで発生した?/一部なの？全体なの？ログの中身は？
と言った利用者が本当に欲しいものはそのアラートだけでは得らず、わざわざマネージメントコンソールにログインしてログ検索する必要があります。
それでも最低限の監視、何かが起こっているの検知にはなると思います。
ロググループのサブスクライブの特徴
CWLogs出たてのころはlambdaは存在しなかったため、この機能は後発で実装されました。この機能もロググループ単位で指定出来ます。
Pros
- 生のログを処理出来るので、ログの内容をアラートに込めることが出来る
- フィルタルールだけでなく、lambdaで処理できるので、自由自在
Cons
- lambda必須 = プログラミング必須
- 1つのロググループに対して、1つののサブスクライバしか指定できない
メトリックスフィルタで出来ないことは実現できるのが強力です。が、ロググループ1つに付き1つのサブスクライバとなるので、この点は注意です。
1つの記事にまとめるつもりでしたが、結構な長編になってしまいました。 次回はメトリックスフィルタ編、次にサブスクライブ編と続けます。
