$30 off During Our Annual Pro Sale. View Details »

ログモニタリングツールを自作した話

Hiroki Takeda
September 13, 2016

 ログモニタリングツールを自作した話

社内LT用

Hiroki Takeda

September 13, 2016
Tweet

More Decks by Hiroki Takeda

Other Decks in Technology

Transcript

  1. • シンプルかつオープンをコンセプト – データストアはelasticsearch – ログ収集エージェントはbeatsシリーズのfilebeat – REST APIはSpark Framework(Java)をベースに構築

    – 画面はRiot.jsをベースに構築 アーキテクチャ 4 Client View HTTPS Websocket API Server REST API Data Store HTTPS HTTPS Log Agent
  2. Elasticsearch構成 • 物理構成 – クラスタはプロジェクト単位 • 論理構成 – インデックス(RDBのデータベース相当)はログ収集対象の 各サーバ毎、年月日単位で作成

    – タイプ(RDBのデーブル相当)はログファイル単位 – ドキュメント(RDBの行相当)はログファイルの1行単位 5 Elasticsearch インデックス =サーバ名_年月日 タイプ =ログの種類 ドキュメント =ログ1行 … …
  3. 特徴・機能 • 認証・認可(LDAP) • 多様なログ検索 – 文字列指定検索 – 日付・時刻指定検索 –

    複数ログ同時検索 • ファイルダウンロード • リアルタイムログ出力(tail –fコマンド相当) • マテリアルデザイン・レスポンシブデザイン 6
  4. 裏話というか細かい話(1/2) • リアルタイムのログ出力では通信コストを低くし、リアル タイム性を向上させるためWebsocketを利用 ⇒ Client⇔APIサーバは双方向通信 ⇒ ElasticsearchがWebsocket対応していないため、 APIサーバ⇔Elasticsearch間は別スレッドでポーリング •

    Elasticsearchのindexのサフィックス日付はUTC時刻で 決定されるため、日付検索で一部のログが引っかからない ⇒ 例えば日本時間の2016/8/10の03:00に出力されたログは、 xxxx-2016.08.10ではなくxxx-2016.08.09のインデックスに格納される ⇒ 日付指定検索時に指定された日付のみでインデックスを絞るとダメ ⇒ タイムゾーンオフセットを元に指定日付の前or後1日のインデックスも 検索対象に含める 8
  5. 裏話というか細かい話(2/2) • elasticsearchの@timestampフィールドはミリ秒まで しか保持できないため、時系列表示が完全に担保できない ⇒ ログファイル自体にナノ秒まで保持させ、logstashでパースして elasticsearchに食わせるか? ⇒ logstash使いたくないし、そもそもログ自体にナノ秒を保持できない ケースもある

    ⇒ filebeatのoffsetを利用 • ファイル行番号表示を実現しようとするとパフォーマンス が大幅に劣化する ⇒ filebeatではログデータの行番号は連携できない仕様 ⇒ 元ファイル通りに行番号を表示しようとすると1ファイル分のドキュメント を総なめして、ドキュメントIDと行番号の紐付きをキャッシュしておく 必要がある(条件検索で一部のログデータのみがヒットする場合も、連番 ではなく元ファイルの行番号を表示したいため) ⇒ ログが100万行とかあるといろいろキツイ ⇒ あきらめ(とりあえずoffsetを表示) 9