サーバーの運用に従事していると、ログとの付き合いは避けることができません。
サーバーは基本的に無人で動かすものですから、どういう風に稼働していたかを知るにはログだけが頼りと言っても過言ではありません。
障害対応のみならず、正常に稼働していることや、CPU・メモリ・ディスク・ネットワークの資源をどのくらい使っていたかを確認するのもやはりログを使うことになります。
なので、ログ自体がとても大事、運用ではリアルタイムにログを取得することも大事、ログを綺麗に保存していつでも見られる状態にしておくことも大事です。
一方でログを出す側では、OSは自前の機能でログを作り、DBなどのミドルウェアも以下同文、アプリケーションソフトも以下同文です。
その結果、ログのフォーマットはバラバラ、置いてある場所もバラバラ、保存されている形もバラバラ、と 2022年になってもこれは変わっておらず、システムの運用担当者を悩ませています。
ここではサーバー運用の仕事で経験したログの話をします。
●ログのフォーマット形態
一口にログと言っても全然画一化されいなくて、てんでバラバラ、一体いくつのログを見ないといけないのか？と思います。
私が知る限りでは、概ねこの5つに分類できると思います。
・1行のテキストタイプ
テキストファイルに対して、1件のメッセージを1行で表現しますので、テキストエディタ等で閲覧できます。
Unix/LinuxのOSのログは基本的にこれ。
OSSの開発に使われるロギング用ライブラリはこの形態を取っているものが多いようです。
どこかログに対する通底した思想が感じられます。
但し文字数が少ないだけに表現力は低く、コードを表示して「詳しくはマニュアルで」とログだけだと意味が分からないものもあります。
ベテランになるとコードが示す内容を暗記してしまっていたり。
自動検出に強いです。
・複数行のテキストタイプ
テキストファイルに対して、1件のメッセージを複数行で表現しますので、テキストエディタ等で閲覧できます。
有償のソフトウェアにこの形態が多いです。
表現力は高く、ログとしては使いやすいです。
自動検出に弱いです。
・ツリー形式のテキストタイプ
1件のメッセージに複数の要素を含んでいて、木構造で管理されています。
XML形式や JSON形式でテキストファイルに出力しています。
持っている情報が多い上に構成がしっかりしているので、役に立つ度合いは高いです。
複雑な構成をしているので、基本的にパースと呼ばれる編集作業をしてくれるツールを使って閲覧します。
自動検出に強いです。
・ツリー形式のバイナリタイプ
ツリー形式のテキストタイプと同じですが、特定のツールがないと閲覧できません。
Windowsのイベントログはこれです。
自動検出に強いです。
・コンピューターのリソース使用状況を定期的に記録するもの
最近はサーバーメトリクスなんて呼ばれています。
これは上の4つとは違って、何かのツールを使ってグラフ化しないと使い物になりません。
CSV形式・JSON形式で記録しておいて、グラフ作成ツールに喰わせてやります。
コイツはここで言うログとはちょっと違うような気がするので、これ以上ここで論じないことにします。
自動検出のことに言及しているのは、近頃はその手段が多様化してきて比較的簡単にできるようになっているからです。
まぁ現場では多くのログを一々見ていられないので、自動検出の採用は当然の成り行きです。
昔は本当に一々見ていて、朝出社したらサーバーにログインしてログの確認から、なんて暮らしをしていました。
それでも現場では、ログ確認の手間をなるべく減らそうと、スクリプトを書いたりして省力化に励んできた歴史があります。
現代では技術が進歩したおかげで、ログに特定の文言が現れたら自動検出、チャットツールに書き込みしたり、メールを送ったりして運用担当者に伝えることができます。
こういう時代ですからログの方も自動検出に親和性の高いものが欲しいのですが、そうでもないのです。
ログの目的は動作状況を簡潔に分かり易く記録しておくことで、自動検出に寄り添うことではないので、仕方ありません。
運用者の負担とログの目的の間にはこのように埋めがたいギャップがあり、それは今後もなくなりそうもありません。
そこで fluentd のようにログを収集した上で統一フォーマットにしてデータベースに入れてやるような仕組みが作られました。
この仕組みのおかげで、複数のサーバーやネットワーク機器の運用の省力化がはかどりました。
パブリッククラウドでもこの思想は踏襲されていて、動かしているサービスが何であれ、何かしらのログ収集基盤にログを送信する仕組みが用意されているはずです。
現代のサーバー運用において、ログの扱いは自動化するのがセオリーとなっており、このホームページでもそういった環境の構築をやっていこうと考えています。
これは fluentdで集めたログを統一フォーマットに変換し Elasticsearchに投入して、データ分析ツールの Kibana でログを見ようという本です。
Elastic社は fluentdの対抗馬である Logstash というツールを持っているんですがね。
私は Elastic社の WinlogBeat というツールを使って Wondowsサーバーのイベントログを収集する環境を作ったことがありますが、Kibanaでログを見た時「こりゃ便利だ！」と思いましたね。
残念ながら導入には至りませんでしたが。
 | データ分析基盤構築入門［Fluentd，Elasticsearch，Kibanaによるログ収集と可視化］【電子書籍】[ 鈴木健太 ] 価格:3,278円 |
