こんにちは。ここに初めて登場するエンジニアの北野です。業務の半分くらいがエンジニアで、エンジニアとしてクローラーの開発とサーバー運用などを行っています。今回はカメリオを動かしているサーバーのログ、イベント収集と解析・表示をどのように行っているかを書きたいと思います。

カメリオを動かすサーバー構成

最初に白ヤギではカメリオをどのようなサーバー構成で動かしているのかを説明します。
カメリオのサービスを提供するために利用しているサーバーは現在全てAmazon Web Service上で動かしています。

カメリオを動かすサーバー概要

かなり省略した図になりますが四角い部分がサーバーを表しています。現在は次のような３つの機能を持つサーバー群

• フロント用APIサーバー
• 記事検索・タグ付けサーバー
• 記事クローラーサーバー

などと、この図には無い

• サーバー監視とログ収集・解析を行うサーバー

の大きつ４つのサーバーを稼働してサービスを提供しています。

もう少し詳しいことを知りたい方は、以前弊社の伊藤が書いたこちらの記事を参考にしてください。細かいとこは変わっていますが大枠は変わっていません。

今回は主にこれらのサーバー運用に関するログ収集・解析とイベント収集・検知に関して説明します。

ログ、イベント収集の構成概要

ログやイベントの収集、登録、集計、表示などを一連して行うために次のような構成になています。インストールや簡単な使い方はネットでさまざまな情報が入手できるのでここでは説明せずに、どのような使われ方をしているだけ説明します。

ログ、イベントの収集・解析・可視化の流れ

現在このような構成で運用をしています。それぞれの用途は、

Redis – Key-Valueストア

Logstashのブローカーおよびキューとして利用しています。

Zabbbix – 統合サーバー管理システム

主にサーバーやアプリケーションの異常検知にのみに使っています。

Elasticsearch – 検索エンジン

ログストア権ログ検索サーバー。カメリオではこのほかにテーマ検索や重複記事判定などの用途にも使っています。

Logstash – ログコレクター

データを収集するShipperと収集したデータをElasticsearchに格納するIndexerの2つの機能に分けて動かしています。

Kibana – データ可視化ツール

ログの検索と表示およびサーバーログをベースにしたダッシュボードとして利用しています。

Influxdb – 時系列データベース

サーバーのstat情報と、MySQL, Redshiftなどに格納されている各種ログなどのサマリーデータを入れています。

Grafana – Influxdbのフロントエンド

Influxdbに格納したサマリーデータを見るためのダッシュボードとして利用しています。

余談

日本ではLogstashよりもFluentdを利用している方が多いですが、カメリオではLogstashをメインに使っています。
Logstashを使うきっかけは、Kibanaを使うためにElasticsearchを入れてログの収集を行うという目的からきているのでELKスタックを使うのが普通だと思ったのと、ここらへんの古い記事などを参考にそれほど高い信頼性が必要ないのであればLogstashでも問題ないだとうという判断がありました。

サーバーからログデータやイベントが大量に出力されるのでElasitcsarchには現在過去2週間分のログのみ残しています。2週間を超えた分はElasitcsarchのインデックスのスナップショットをとってS3に保存しています。
Logstashを介して、Elasticsearch – Kibana、Influxdb – Grafanaの2つの解析・可視化環境を使い分けています。

Elasticsearch – Kibana

• １日2000万件程度のログ、イベントデータ
• ２週間程度の短期データを利用して解析、可視化
• リアルタイムデータ

Influxdb – Grafana

• バッチデータ＋リアルタイムデータ
• 長期データを利用した解析、可視化
• ログ、イベント以外のデータ（MySQL, Redshift）との組み合わせ

収集したデータの活用法

収集したデータはサーバー監視や運用、カメリオのアプリケーションとしての運用などに活用しています。1つの例として白ヤギでは毎週オペレーションミーティングという社員全員が参加する20分〜30分程度のミーティングを行っています。このミーティングではサービスの稼働やユーザーの利用状況などを改めて把握し問題や改善点があった場合には次のアクションを決めています。

ダッシュボード例

このミーティングではサービスの稼働やユーザーの利用状況などを改めて把握し問題があった場合には次のアクションを決めています。

Logstashを使ってきて

とりあえず動かすだけだったら簡単にできるが、取り扱うログの種類やサーバー台数などが多くなってくるとノウハウが必要になります。

Logstashを各サーバーでログ・イベントを集めるShipperとShipperから送られてきたログ・イベントをElasticsearchやInfluxdbに送るIndexerの2つに役割を分けて構成しています。ShipperとIndexerをつなぐブローカーとしてRedisを利用しています。

Indexerとして使っているLogstashのアウトプット先はElasticsearch、Influxdb以外にもcsvファイル(S3)、Zabbixの4つありますが、アウトプット先を多くすると何か1つのアウトプット先にトラブルがあるとIndexerが止まってしまうためイベントの登録処理が遅いZabbixに対してはもう一度Redisを介してZabbixへ送るという構成しています。

これまであった大きなトラブル

Elasticsearchへの書き出しが遅くなりBrokerのRedisが溢れる

使い始めた最初の頃によく発生していました。heapメモリーの設定やファイルディスクリプタ数上限値を変更して解決しました。

アプリケーショントラブルでZabbixへ送るイベント量が急激に増えた時にBrokerのRedisが溢れる

Zabbixのhistoryレーコードが溜まりすぎクリーニングプロセスが重くなった原因でZabbixへのイベント登録が遅くなりLogstashが処理しきれなくなるという問題でした。Zabbixのhistoryの保存期間を下げてhistoryテーブルのoptimizeを行ったのと、ZabbixへはIndexerから直接送るのではなく一旦Redisを介して送るように変更しました。
Influxdbが異常終了しLogstashのoutputがが遅くなりBrokerのRedisが溢れる

これまで２回ほどInfluxdbが異常終了してLogstashが処理しきれなくなったことがありました。Influxdbの監視を強化して止まった時にすぐに対応できるようにしています。

Elasticsearch、Logstash-indexer、Redisは同一サーバーで稼働させている関係で、何かトラブルがあるとRedisが溢れれメモリが足りなくなりElasticsearchのインデックスがおかしくなり始めるというものばかりでした。現状の構成でトラブルがあると一番の問題はデータが欠落してしまうことなのですがFluentdを使っていればこのような場合でも欠落を防げたかも思っていますが、おそらくLogstashでも解決?されるだとろうと心待ちにしています。

まとめ

カメリオを動かすサーバーのカメリオのログ、イベントの収集・解析・可視化の概要を紹介しました。

今回説明した環境は実はここ半年ほど手付かずの状態なので、ELKスタック、Influxdb、Grafanaのバージョンアップなどに対応できていいません。次々とリリースされる新しい機能が指をくわえて見ているだけの状態になっています。

Influxdbは以前のバージョンでContinuous Queriesを使うとCPUを100%食ってしまうという不具合があって今は使っていないので復活させたいし、GrafanaはデータソースにElasticsearchが使えるようになったのでElasticsearchとInfluxdbのデータを一緒に表示させることが可能になっています。
また、ElasticのBeatやInfluxdbのKapacitor、KibanaをベースにしたSIREnのKibiなどを使ってみたいと思っています。