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

© 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 まとめ

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

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

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

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

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

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

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

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

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