社内LT用

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

2. 各種サーバのログを一元的に管理し、可視化するブラウザ
ベースのログモニタリングツール
つくったもの
2

3. モチベーション
• アプリ実行環境をマネージドサービスとして提供するため
利用者にSSHでログイン等はさせない世界観
⇒利用者が各種ログを管理・閲覧できる仕組みが必要
3
①サーバにSSH
$ view /var/log/xxxx.log
②viewコマンド等でログを閲覧
オンプレの世界観
①ブラウザからログを
選択するだけ
PaaSの世界観

4. • シンプルかつオープンをコンセプト
– データストアは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

5. Elasticsearch構成
• 物理構成
– クラスタはプロジェクト単位
• 論理構成
– インデックス（RDBのデータベース相当）はログ収集対象の
各サーバ毎、年月日単位で作成
– タイプ（RDBのデーブル相当）はログファイル単位
– ドキュメント（RDBの行相当）はログファイルの1行単位
5
Elasticsearch
インデックス
＝サーバ名_年月日
タイプ
＝ログの種類
ドキュメント
=ログ1行
…
…

6. 特徴・機能
• 認証・認可（LDAP）
• 多様なログ検索
– 文字列指定検索
– 日付・時刻指定検索
– 複数ログ同時検索
• ファイルダウンロード
• リアルタイムログ出力（tail –fコマンド相当）
• マテリアルデザイン・レスポンシブデザイン
6

7. Demo
7

8. 裏話というか細かい話（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

9. 裏話というか細かい話（2/2）
• elasticsearchの@timestampフィールドはミリ秒まで
しか保持できないため、時系列表示が完全に担保できない
⇒ ログファイル自体にナノ秒まで保持させ、logstashでパースして
elasticsearchに食わせるか？
⇒ logstash使いたくないし、そもそもログ自体にナノ秒を保持できない
ケースもある
⇒ filebeatのoffsetを利用
• ファイル行番号表示を実現しようとするとパフォーマンス
が大幅に劣化する
⇒ filebeatではログデータの行番号は連携できない仕様
⇒ 元ファイル通りに行番号を表示しようとすると1ファイル分のドキュメント
を総なめして、ドキュメントIDと行番号の紐付きをキャッシュしておく
必要がある（条件検索で一部のログデータのみがヒットする場合も、連番
ではなく元ファイルの行番号を表示したいため）
⇒ ログが100万行とかあるといろいろキツイ
⇒ あきらめ（とりあえずoffsetを表示） 9

10. 今後やりたいこと
• オーケストレーションの実現
– 対象サーバ、ファイルパス等を入力して画面をポチると
エージェント（filebeat）のインストール、設定が自動で実行
• エージェントレスな世界の実現
• ログ分析用のビュー
どなたか知見・アドバイスを・・・
10