Graylog ではじめるログ管理

こんにちは。インフラストラクチャー部 セキュリティグループの星 (@kani_b) です。 主に "セキュリティ" や "AWS" といったタグのつきそうなこと全般を担当しています。

Fluentd などのデータコレクタ、Kibana やその他 SaaS による可視化、Kafka, Kinesis, Spark などのストリーム処理といった様々な分野で「ログの処理」がホットですが、アプリケーションのログ (行動ログなど) に関する話題が多くを占めています。

そうしたログの他に重要なのが OS や各種ミドルウェアのシステムログです。これらはトラブルシューティングであったり、セキュリティ上の問題を見つけたり、といったことに使われますが、最低限 syslog でどこかに集約しているだけ、といった例をよく見かけます。 これらのログをきちんと検索可能にし、分析することで、今まで気づかなかったような問題をキャッチすることができるようになります。

ログ管理システムとしては、商用の Splunk などが特に有名ですが、 今回は OSS のログ管理システムである Graylog について紹介します。 Graylog は概ね以下のような機能を持っています。

  • ログの収集
  • ログの検索
  • ダッシュボードの作成
  • ログを基にしたアラートの発報

これらの機能をユーザやグループに応じて、権限を分割しながら利用することが可能です。 この記事では、執筆時点で最新安定版の Graylog 1.2.2 について説明します。

Graylog の構成とインストール

ドキュメント に記載されていますが、Graylog は以下のようなコンポーネントで構成されています。

  • graylog2-server
    • ログの受け口であり、API を通じて検索などのサービスを提供します
  • graylog2-web-interface
    • Web UI です。graylog2-server とは API 経由で通信します
  • Elasticsearch
    • ログの格納先として利用されています
  • MongoDB
    • 設定の格納や Dead Letter Queue として利用されています

それぞれ単体のサーバとして動作させても問題ないので、例えば graylog2-server, graylog2-web-interface を複数用意しての負荷分散や Elasticsearch のクラスタ化も可能です。MongoDB についても可能ですが、設定などのデータが格納されているだけですので、クックパッドで利用している環境においては非常に負荷が小さいです。

Elasticsearch ということで、Amazon Elasticsearch Service などを使いたい!と思う方もいらっしゃると思いますが、graylog は master node に HTTP 経由でクエリするわけではなく、graylog2-server が対象の Elasticsearch cluster に join して各種操作を行うようになっているため、現在は利用できません。 適宜、自分で Elasticsearch 環境を用意する必要があります。

試しつつ良さそうであればそのまま運用したい、という方であれば、まず graylog2-server と MongoDB が一緒になったインスタンス + Elasticsearch インスタンス という構成にしておくと後々楽なのではと思います。

インストール方法はディストリビューションのパッケージや Docker image, VM image など色々と用意されていますので、環境に合わせて選択します。 詳細はドキュメントを参照いただくとして、具体的なインストール手順についてはここでは割愛します。

Graylog へのデータ入力

Graylog へデータを入力する方法はいくつかありますが、クックパッドでは現在 Syslog 入力と GELF 入力、そして CloudTrail input plugin を利用しています。 input の設定は、図のように設定画面から簡単に行うことができるようになっています。 f:id:kani_b:20151125184455p:plain

以下では、個々の入力について説明します。

Syslog 入力

Syslog 入力を有効にすると、Syslog メッセージをそのまま受け付けられるようになります。既に rsyslog などで転送設定をしているのであれば、転送先に追加するだけで入力できるようになり、お手軽です。UDP はもちろん TCP にも対応しています。syslog-ng から AMQP で投げたり Apache Kafka 経由でのデータ投入にも対応しているようですが、検証はしていません。 インスタンスへのログインログ、各種エラーメッセージなどのログはこちらで入力すると良いでしょう。

GELF 入力

GELF (Graylog Extended Log Format) は Graylog 独自のログフォーマットで、syslog と比較してデータ長の制限が大きい、データ型を持つ、圧縮など、アプリケーションのログを転送するのに適したフォーマットとして設計されています。 詳細は公式ドキュメント を参照ください。 gelf-rb などライブラリも用意されているので、アプリケーションから直接投入することも可能です。 また、 fluent plugin を公開している方がおり、Fluentd 経由でデータを投入することもできるようになっています。 クックパッドでは、以前このブログでご紹介した OSSEC という IDS のログや WAF のログなどを fluentd 経由で格納しています。

CloudTrail input plugin

Graylog は、入力や出力、ログのパースなどにプラグインが使えるようになっており、 そのうちの一つに CloudTrail input plugin があります。 CloudTrail の SNS notification を使い、SNS 経由で SQS にメッセージを格納しておくと、このプラグインが対象の S3 オブジェクトを取得・パースして格納してくれます。

ストリームの作成

入力設定を行うとデータが流れ始めますが、そこにはシステムログや CloudTrail のログなど種類の違う様々なデータが流れるため、そのままだと目的のログを探したりダッシュボードを作るのが非常に難しくなります。 そのため、Graylog には、流れてきたログを特定の条件に基づいて振り分けることのできる機能 (Stream) があります。 例えば、syslog input を流すストリームに対して図のような設定をすると、syslog のうち sshd のログだけが流れるストリームなどを作ることができます。 f:id:kani_b:20151125184517p:plain

また、このルールを作成する画面でログのサンプリングを行うことも可能です。 f:id:kani_b:20151125184529p:plain

ダッシュボードの作成

Stream からグラフを作成してダッシュボードに貼り付けることができます。 作成したダッシュボードはこのように表示することができます。 f:id:kani_b:20151125184538p:plain

グラフの種類は Kibana ほどではありませんが、ドキュメントで紹介されているように、アプリケーションやセキュリティログを監視するためのダッシュボードなどを作成するには十分だと思っています。

アラートの発報

個々の Stream にはアラートを設定することができます。 ログに含まれる文字列に特定の文字列があった場合、特定のフィールドを持つログがある場合、などの条件をもとに、さらにx分以内にy回合致した場合はアラート、といった形で、ある程度高度な条件を作ることも可能です。 f:id:kani_b:20151125184551p:plain

また、アラートはメールで送信する他に任意のコールバック先を指定できます。プラグインをインストールする必要がありますが、 HipChat, Slack, PagerDuty などが利用可能です。

権限管理

ここまでの機能を見てみると、特にログの検索やダッシュボードの作成については「それ Kibana でできるよ」という方も多いのではと思います。 しかし、 Graylog ではこれらの作成、表示に加えて、ユーザごとの権限管理ができるようになっています。つまり、特定のダッシュボードのみ参照できるユーザA、特定のストリームとダッシュボードのみ参照できるユーザB、といった形で権限を分割することが可能です。

また、Graylog のユーザ管理は LDAP/Active Directory と連携することができます。もともとユーザの管理のみ連携されていたのですが、先日発表された 1.2 からグループも利用することができるようになりました。

注意点

Graylog はあくまでログ管理のためのシステムであり、ログを保存するためのシステムではありません。ログの保全は別のものとして考慮し、例えば、テキストファイルとしてポリシ設定をした S3 にアップロードしておくなど、その仕組みを別途きちんと作っておく必要があります。

まとめ

OSS のログ管理システムである Graylog について簡単にご紹介しました。

ログ集約や検索、そして OSS といえば最近では Fluentd などを経由して Elasticsearch に投入し Kibana で可視化する、という構成がとても有名です。 用途や構成をきちんと限定すればとても便利ですが、例えば先述の権限管理であったり、細かな条件付けやパフォーマンスなどを考えていくと無理が生じてくると個人的には考えています。

Graylog のドキュメントに、Graylog の基本的なコンセプトなどについて書かれた章がありますので、興味のある方はご一読ください。

また、今回紹介しきれなかったものとして、以下のような機能も持っています。

  • ログコレクタ
  • Stream からの出力 (syslog -> Stream -> syslog など)

現在クックパッドでは主に IDS や CloudTrail のログ分析などのために利用されていますが、Graylog 含め、ログ管理についてはまだ色々と試しているところでもありますので、より良いノウハウを共有していければと考えています。

最後になりましたが、インフラストラクチャー部ではエンジニアを積極募集中ですので、ログに興味があってもなくても是非ご検討ください。