サーバ/インフラエンジニア養成読本

Fluentd を使いたいが、何をどうすればいいのか全くわからんので購入。

サーバ/インフラエンジニア養成読本 ログ収集~可視化編 [現場主導のデータ分析環境を構築!] (Software Design plus)

まず Fluentd の部分だけ読んだ。 とてもわかりやすい。 が、まだデータ溜めるところだけなので、まだまだ。

サーバインフラエンジニア養成読本

特集1 ログ解析からはじめるサービス改善

第1章 はじめに

1. 収集
2. 変換
3. 保存
4. 分析
5. 表示
6. 運用

第2章 サービス改善に必要なこと

• 【収集】どのデータを集めるべきか、どのようにデータを格納していくか
• 【変換】データをどのように前処理し、分析しやすい形式にするか
• 【保存】どういったデータが入っていて、どこに保存しておくか
• 【分析】どのように基盤に入れたデータを分析し、活用してもらうか
  データを入れるだけでなく、分析のために快適な環境を用意するにはどのようにすればよいか
• 【表示】どのようにデータを可視化し、結果を伝えられるようにするか
• 【運用】データを分析するための基盤を長期に渡って運用していくにはどのようにすればよいか
  エンジニアでなくても活用しやすい環境を用意するにはどのようにすればよいか
• DAU = Daily Active Users
• MAU = Monthly Active Users
• メトリクス
• 仮説を導く
• サービスの現状を知るメトリクス
• 仮説の検証
• 分析を行うことの目的は、数値を扱うことではなく意思決定
• 可視化は結果を出すための手段で、思考の道具
• 長期的にログを残す
• 行動パターン

第3章 なぜ今可視化なのか

• 「戦略的データマネジメント」 Thomas C. Redman

  データと情報の視点から見てみると、意思決定とは不確実性、 そして、それに関連する不利益と利益を管理することである

• Web上での可視化の特長

  • インタラクティブなデータの取り扱いができ、ドリルダウン・ドリルアップが可能である
  • 任意のデータおよび分析状態についてURIを発行することが可能である
  • URIを共有することで複数人での分析を容易に行うことができる
• Kibana

第4章 ログデータ入門

• データの鮮度
  • hot data
    • 発生した直後のログデータ
    • 発生してすぐに利用される
    • または高頻度でアクセスされる
    • 準リアルタイムな分析を可能にする
  • cold data
    • 作成されてから利用されるまでにある一定の時間がかかるログデータ
    • 長期的なバックアップのためのデータを示すことも
  • 中間的な存在の warm data
  • hot data と cold data で扱う方法を 変えなければならない
• ログの整理
  • 全てのログを流す
  • 取得できるメトリクスを整理する
  • マスタデータと行動ログ

  • ファンダメンダル

    株式投資においては、銘柄の基礎的な情報を指す。 販売動向や、投資計画などがそれにあたる。 これらを分析することをファンダメンタル分析と呼び、 主にチャートや需給を元に判断するテクニカル分析と共に銘柄選定の基本となる。

  • メトリクスをデザイン

  • QPS（Queries Per Second）によっては他のデータソースを参照していると処理が間に合わない場合も
    • その場合はログデータに属性をいれてしまう
    • ログデータを デザイン する
• ログを活かす仕組みのデプロイについて
  • 本番のログのストリームを一部だけ受け付けることのできるノードを作成
    • Fluentd の copy プラグイン、sampling filter プラグイン

第5章 はじめての Fluentd, Elasticsearch, Kibana

環境は CentOS 7.0
Fluentd, Elasticsearch のインストールについては yum リポジトリに追加しインストール

Fluentd

バージョン 2.1.5
http://docs.fluentd.org/articles/install-by-rpm

rpm で入る場所は2系から変わったらしい
インストール箇所は /opt/td-agent 以下で、設定ファイルもそこにあるが、弄るのはそこじゃないので注意

Elasticsearch

バージョン 1.5.0 がでたようだが、まだ rpm で入るのは 1.4.4
http://www.elastic.co/guide/en/elasticsearch/reference/current/setup-repositories.html

Java

バージョン 8u40
http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

gihyo-coffee-sample

ちゃんと動かない？Kibanaでindex貼るページから何も進まない
php のバージョンなのか、Proxyを越えられないことが原因か？
代替えとして、Rubyを用いて適当にデータを入力してみる gem で fluent-logger をインストールしておく

• substitute_ruby.rb

require 'fluent-logger'

log = Fluent::Logger::FluentLogger.new(nil, host: 'localhost', port: 24224)

10.times do |i|
  log.post("log.success", { "hello" => "world" })
  log.post("log.show_item", { "type" => "show_item" })
  log.post("log.user_login", { "type" => "user_login" })
end

Kibana4

書籍は 3 ベースだが、最新の4で
特に設定ファイルについては弄っていない https://www.elastic.co/downloads/kibana

Kibana4 については デフォルトで noge.js を使用し、Web Serverが起動する

$ bin/kibana

初期状態では Unable to fetch mapping. Do you have indices matching the pattern? と なって先に進めない
elasticsearch 上にデータが入っていないとダメ
今回は fluentd の match セクションにて logstash_prefix demo-log と設定していることと、 時間項目がないので、チェックは全て外し、index 名には demo-log* などとしてやる

第6章 Elasticsearch と Kibana を超えて

• Aggregator ノード
• in_tail プラグイン
• GrowthForecast
• Elasticsearch にも格納している理由は hot data の解析が行いやすいため
  • S3 に格納してしまうと取り出し難い
• MPP（Massively Parallel Processor）アーキテクチャ
• 分析システム
  • Dremel(Google)
  • Apache Drill
  • Cloudera Impala
  • Presto(Facebook)
• MPPデータベース
  • Amazon Redshift
  • Vertica(HP)
  • PureData(IBM)
  • TeraData(IBM)
• BIツール
  • Tableau
  • QlikView
  • Pentaho
• データストア(サービス)
  • TreasureData
  • BigQuery(Google)
  • Qubole
• ストリーム処理
  • Esper
    • CEO（Complex Event Processing：複合イベント処理）エンジン
  • Norikra
  • Apache Kafka
  • Apache Storm
  • Amazon Kinesis
• スキーマの柔軟性
  • Schema on write - 書き込み時にデータスキーマが固定される
  • Schema on read - 読み込み時にデータスキーマを決定する

第7章 まとめと参考文献

• エンジニアからデータの活用方法を発信

特集2 ログ収集ミドルウェア Fluentd 徹底攻略

第1章 ログ収集の目的とミドルウェアの特長

• 推移、傾向、変化
• AARRR モデル
  • Acquisition : ユーザ獲得
  • Activation : 活性化
  • Retention : 継続
  • Referral : 紹介
  • Revenue : 収益化
• SAF(Store and forward)
  • QoS(Quality of Service)
    • at most once : メッセージが重複することなく最高1回の配信を行うが到達は保証しない
    • at least once : メッセージが失われることがないことを保証するが重複する可能性がある
    • exactly once : メッセージを正確に1回だけ配信する最も高い QoS

第2章 はじめてみよう Fluentd

• データ構造
  • tag : 文字列
  • time : 数値型で病の表現精度を持つ Unix タイム
  • record : オブジェクト型で Key-Value 形式
• バッチ処理との違いはリアルタイム性
• 多様なプラグイン
  • in_exec : http://docs.fluentd.org/articles/in_exec
  • out_exec_filter : http://docs.fluentd.org/articles/out_exec_filter
  • out_exec : http://docs.fluentd.org/articles/out_exec
  • 個別に独自 plugin を使いたい場合は /etc/td-agent/plugin に in*.rb out*.rb として配置
    • デフォルト状態では空（ディレクトリだけはあるが、中身は無し）
• match ディレクティブ
  • ** は0個以上の タグ要素に合致
  • {X, Y, Z} X も Y も Z も

第3章 Fluentd 設計のコツ

• ノードごとの役割
  • Forwarder Node : 収集したログをAggregatorへ転送する
  • Aggregator Node : Forwarderからのログを集約する
  • Processor Node : ログのデータ加工や集計などの処理を行う
  • Watcher Node : ログ内容を基に監視連携や通知などを行う
• ノートの構成例
  • シングル構成 : 多少のダウンタイムが許容され、可用性が求められないもの
  • 汎用構成 : 複数の Fluentd インスタンスのデータを集約して各種データ保存先へ
    • Aggregator ノードを配置
    • アクティブ、スタンバイを用意
    • Processor、Watcher ノード役は兼務
  • 応用構成 : 演算コストのかかるリアルタイム集計などの処理
    • Processer ノードや Watcher ノード を追加
• EFK（Elasticsearch、Fluentd、Kibana）

第4章 Fluentd 運用ノウハウ

• プロセス監視
  • Nagios、Zabbix、Cacti などで監視
• 死活監視
  • fluent-plugin-ping-message
• リソース管理
  • 標準添付の monitor_agent
  • Munin を用いてグラフ表示ができるプラグインもある
    • munin-fluentd
• 性能監視
  • fluent-plugin-delay-inspector
    • Fluentd ノード間でのメッセージ到着ラグ時間
• ログ欠損を減らす工夫
  • ネットワーク断に強くする
  • プロセスダウンに強くする
  • 終了前にバッファをフラッシュする
  • SPOF（Single Point of Failure）のないログアグリゲータを用意する
  • 余裕を持ったバッファ設計を用いる
  • メモリバッファのある言語を利用する
• スタンバイ系ホストを指定するブロックにはstandbyを記述
• 正規表現でログ取り込みするよりもログの形式をLTSVにし取り込む
• 基本的に型は文字列になるので types オプションで型指定をする
• fluentular : Fluentd向け正規表現エディタ
• fluent-tail : ログビューア

第5章 逆引き Fluentd プラグイン

• 色々