ログについて改めて考えてみた

© Opt, Inc. All Rights Reserved.
ログについて改めて考えてみた話
株式会社オプト　仙台テクノロジー開発部
第11回タガヤス登壇資料

自己紹介
- 佐藤宏
- 株式会社オプト仙台テクノロジー開発部所属
- 2011年入社
- シニアエンジニア
- 直近5年くらいはバックエンドしかやってない

目次
1. What is a ログ？
2. ログの蓄積方法
3. ログの使い方
4. まとめ

#0 きっかけ

そもそもなんでログの事を考え始めたか？
- 性能改善やチューニングをする機会があった
- 前後での性能比較
- バックエンド側のバッチを主に担当していた
- 日々動いている事の確認
- 実行結果を後から調べる機会が多かった

今日のゴール
以下の事を考えるきっかけになればゴール達成
- ログのことを考え直すきっかけ
- 様々なログの保存方法を知るきっかけ
- ログの使い方について考えるきっかけ

#1 What is a ログ？

データログ
履歴、情報を記録に残すこと。また、その記録自体を
指す。
元々は航海日誌の意味であり、語源は「丸太」を海
に流して船の速さを測ったことから
（Wikipediaより）

コンピュータのログファイル。
アプリケーション、OS、サービスが処理内容、警告な
どの履歴を逐一記録し、障害発生時や開発時（デ
バッグ）などに参照できるようにするため作成する
（Wikipediaより）

逐一記録して、
　使いたい時に参照するもの

記録したいもの
- アプリケーションの処理履歴（イベントログ）
- 障害（エラー）内容
- 開発時のデバッグ情報
など
目的によって、記録したいログは色々ある

目的＝ログレベル
ログレベルを用いたログ管理の仕組みは、
syslog（プロトコル）が由来といわれている。
※syslog は、ログメッセージをIPネットワーク上で転送するための
標準規格である

RFC 5424
Emergency: system is unusable
Alert: action must be taken immediately
Critical: critical conditions
Error: error conditions
Warning: warning conditions
Notice: normal but signiﬁcant condition
Informational: informational messages
Debug: debug-level messages

ロギングツール
例えば
- Java：Apache log4j
- PHP：Monolog
- Ruby：Logging
などなど色々ある

log4jのログレベル
FATAL 致命的なエラー
ERROR エラー
WARN 警告
INFO 情報
DEBUG デバッグ用の情報
TRACE トレース情報

１章まとめ

1章まとめ
【再掲】
逐一記録して、
　使いたい時に参照するもの

1章まとめ
- ログは明確な目的（エラーレベル）で出力している
か？
- ログに出力する内容は誰が決めている？
- ログの目的は誰が決めている？

1章まとめ
- ログを使うのは誰か？利用用途は明確か？
- 開発者
- 運用保守担当者
- 非エンジニアのモニタリング用途

問題

例えば
Webアプリケーションで、ログイン失敗しました。
この時、ログレベルはどうするべきか？

ログイン失敗
- ログイン出来ていないから、Error？
- ログイン処理として異常では状態じゃないけど、
正常とは異なるから、Warning(Notice)?
- サービスに影響はないから、Info？

答え
- 一概には言えない
- 認証サービスが落ちているならError以上
- IDやパスワードの入力ミスならInfo以下

#2 ログの蓄積方法

2. ログの蓄積方法
- サーバ上のファイル
- テキストフォーマット（text,csv,json）
- 列指向(カラムナ)フォーマット（Parquet）
- データベース
- RDB、NoSQL
- クラウドサービス

何を保存する？
- Webアプリケーション
- Accessログ
- Eventログ
- Errorログ
- Info/Debugログ

サーバ上のファイルにためる

サーバ上のファイル
- テキストファイル
- 区切り文字（空白、カンマ、タブ）ファイル
- JSONファイル
- XMLファイル
- バイナリファイル（列指向フォーマット）
- Parquet

テキストファイル
メリット：
- ライブラリが対応しているフォーマットであれば用
意に出力可能
- 各Editor/Viewerで閲覧可能

テキストファイル
デメリット：
- ファイルがサイズが大きくなる
- 圧縮
- ローテーション
- 検索しづらい（用途による）
- 集計しづらい（用途による）

サーバ上のファイル
所感：
- 区切り文字のファイルは拡張性に難がある
- jsonが好き（メタデータを含めた形で保存可）
- Parquet形式も便利（テキストファイルと比較すべ
きではないかも？）

データベースにためる

データベース
メリット
- クエリが使える
- 検索、集計が出来る
- GUIツールや、クエリ等で閲覧可能

データベース
デメリット
- テーブル定義をする必要がある
- ログ蓄積機能の開発
- トランザクション管理（性能劣化の可能性?）
- テーブルサイズが肥大化する
- テーブル定義の変更コスト

クラウドサービスにためる

クラウドサービス
メリット
- ロギングサービスを外に出せる
- サービス本体と切り離して考えられる
- 既存のサービスを利用して、提供されている機能
がすぐ利用できる

デメリット
- コスト（使い方によっては有料）
- クラウドサービス側の障害の影響を受ける
- 各サービスのSLA次第
- 用途に合わないケース

- Fluentd + α
- Sentry
- Amazon CloudWatch Logs

Fluentd

Fluentdとは
- オープンソースのデータログ収集ツール
- ログの取り込み（Input）と出力先（Output）を制
御（エージェントという形で常駐）
- Pluginという形で Input と Output を様々な組み
合わせ
- https://www.ﬂuentd.org/plugins

引用：https://www.ﬂuentd.org/architecture

Fluentd
- ログを保存するシステムではない
- td-agent.confファイルを設定するだけで、　任意
のInputとOutputを繋げられる
- 様々なPluginが用意されている
- Input: ApacheLog/Webアプリのログ（テキストファイル）
- Output: TreasureData

Sentry

Sentry とは
- ログの収集、監視サービス
- 言語ごとに用意されたSDKを使用してログをAPI
で送信
- エラー通知をSlackに連携することも可能

引用：https://github.com/getsentry/sentry

Sentry
- 個人用と開発初期のアプリケーション用途として、
無料版もあり
- プランごとにログイベントを受信できる制限が設け
られている

Amazon CloudWatch Logs

Amazon CloudWatch Logs とは
- AWSのログをためるサービス
- Lambda等、マネージドサービスのログは
CloudWatch Logsへ
- オンプレサーバ等でもCloudWatch Agentを利用
して、ログを流し込める
- Fluentdでも可

Amazon CloudWatch Logs
{
“aaa”: “hogehoge”,
“bbb”: 12345,
“ccc”: {
“c1”: 111,
“c2”: “222”
}
}
{$.aaa=hogehoge}
や
{$.ccc.c1 > 100}
など

２章まとめ

2章まとめ
- ログのため方は色々ある

#3 ログの使い方

3. ログの使い方
- イベントの監視/モニタリング
- 障害時のログ
- 開発時のログ

クラウドサービス（モニタリング）
- DataDog
- Amazon CloudWatch Logs Insights
- Kibana

DataDog
- サーバの監視/モニタリングツール
- 似たサービスとしてMackerel（マカレル）
- Freeプラン（サーバ5台、データ保管期間は1日）
- 様々なサービスと連携するための設定が用意さ
れている

引用：https://docs.datadoghq.com/ja/guides/overview/
Host Map

引用：https://docs.datadoghq.com/ja/guides/overview/
イベントの時系列表示

Amazon CloudWatch Logs Insights
- 2018年末のre:Inventで発表されたサービス
- CloudWatch Logs のログデータを検索＆分析
- クエリ言語を用いる
- 料金：0.0076 USD/GB（スキャンされたデータ）

24時間で1分でコールされたAPIの回数

24時間で1分でコールされたAPIの平均応答速度

Amazon CloudWatch Logs Insights（印象）
- 現状では、CloudWatch Logs データをクエリで検
索しビジュアライズできるが、おまけ機能レベル

Kibana
デモ

#4 まとめ

ログは、使い方にあった
　　ため方をすることが大事

定量的に計りたいイベントログは
常にモニタリング

改善は
　モニタリングのその先に

ご清聴ありがとうございました

ログについて改めて考えてみた

More Related Content

What's hot

Similar to ログについて改めて考えてみた

More from 株式会社オプト 仙台ラボラトリ

ログについて改めて考えてみた

More from 株式会社オプト　仙台ラボラトリ