SPring-8 制御メッセージログ分析基盤の開発
松本崇博#(公益財団法人) 高輝度光科学研究センター 制御・情報部門

概要
SPring-8 の加速器・ビームライン運転を安定に運用するためには、障害発生時にその原因をただちに特定し速やかに問題解決を行うことが必要不可欠である。SPring-8 では障害発生時の原因把握・対応のため、機器制御に用いられる約 400 の計算機ホストからメッセージログを収集し活用している。しかしながら、収集されるメッセージログは１日に 30 億行に及び、ログサーバ上のファイルからログ検索を行っていることから、障害原因の分析に現在多くの手間と時間がかかっている。この状況を改善するため、本匠プロジェクト
課題では簡易、かつ迅速に制御メッセージログ分析を行うためのログ分析基盤を開発した。本基盤では、
NoSQL データベース elasticsearch [1]にログを蓄積し、Web インターフェース kibana [2]を活用してデータの可視化を行う。メッセージ経路などのログ検索を柔軟に行うことができ、障害発生状況の確認をエラー件数オンラインモニタから簡易に行うことができる。SPring-8 制御系の一部に本ログ分析基盤を試験導入し、ログ検索の大幅な時間削減、障害に対する理解向上などその有用性を確認した。今後は SPring-8 運転での障害把握・対応に本ログ分析基盤を常時適用できるよう整備を進めていきたい。

1.

はじめに

SPring-8 は夏季・冬季の長期点検調整期間やサイクル間の停止などを除き基本的に 24 時間連続運転を行っている。SPring-8 における高性能の放射光を長期間安定にユーザーに提供するためには、加速器・ビームライン機器の制御を高い信頼性・安定性のもとで運用しなければならない。このため、SPring-8 では 独自に開 発した MADOCA (Message
And Database Oriented Control Architecture)と呼ばれる制御フレームワークを用いている[3][4]。MADOCAは機器制御の際にテキスト形式のメッセージを用いており、加速器・ビームラインの複数機器の分散制
Figure 1: 現状のログファイルサーバを用いた御を安定に行う。この MADOCA の高い堅牢制は、
SPring-8 制御ログメッセージ蓄積・分析システムの今までの SPring-8 の長期運転において発生してきた概念図。
障害事象をしっかりと把握し、その対策を検討してきた結果培われてきた側面もある。
この制御ログ蓄積・分析システムは障害発生時のSPring-8 機器制御での障害発生の原因特定のため、 原因調査、対策を立てる際のツールとして非常に役
我々は Figure 1 に示す制御メッセージログ蓄積・分 立っている。しかしながら、扱うデータ量は機器数
析システムを活用している。制御に用いられたメッ の増加により日々増加し、また、ログ分析時に大量セージのログは rsyslogd [5]を用いてログファイル のファイル処理のためのプログラムを各個人が独自サーバに転送し、各ホスト、アプリケーション毎に に整備する必要がある場合もあるため、ログ分析に１時間毎に纏められたファイルとして記録している。 多くの手間と時間がかかっている状況にある。よりログ収集対象となるホストは、約 300 ホストの機器 迅速な障害対応を行うためには現システムの改善が制御計算機(VME など)、及び約 80 ホストの制御端 強く望まれる。
末から構成され、ログ出力数は 1 日当たり 30 億行
本匠プロジェク課題では制御メッセージログを(1 秒あたり 3 万 5000 行)程度、データ量に換算する NoSQL データベース elasticsearch に蓄積し、Web イと 1 日あたり 360GB (1 秒あたり 4.2MB)程度になる。 ンターフェース kibana を用いてデータの可視化を行
ログデータは障害原因の把握の目的で利用している うことで現状のログ分析の課題を解消することを試ため永久には蓄積していない。収集してから 15 日 みた。本報告書ではその成果について述べる。この間のデータのみログファイルサーバ上に残している。 後、2 章において現在のログ分析システムにおける___________________________________________# matumot@spring8.or.jp

課題を示す。3 章ではその課題を解消するために開発したログ分析基盤について述べる。4 章では開発したログ分析基盤の SPring-8 制御系の一部への導入とその有用性について述べ、最後にまとめを行う。

2.

現在のログ分析システムにおける課題

現在、SPring-8 の加速器・ビームライン機器の制御で発生したメッセージログ分析は Figure 1 に示されるようにログファイルサーバ上に収集されたファイルの検索により行っている。このファイル検索に基づくログ分析システムでは、障害メッセージがログに出力されていてもすぐに気づくことができない、ログ検索に時間がかかる、他には制御関係者以外のログ確認がやりにくい、などの課題を抱えている。
これらの詳細について以下に記す。
2.1 障害メッセージがログに出力されていてもすぐに気づくことができない
現ログ分析システムは制御障害による被害(データ収集においてデータ蓄積に抜けがあった、特定の機器が制御できない等)が明らかになってから、事後に該当するログを検索しその原因を追跡している。このため、いつも対応が後手に回っている状況にある。可能であれば制御メッセージログに異変が発生した際にすぐに気づき、迅速に障害対応ができるようにしておきたい。
2.2 ログ検索に時間がかかる

Figure 2: MADOCA II における GUI と Equipment
Manager (機器制御プログラム)間での Message Serverを介した制御メッセージ送受信。メッセージングに関わる各アプリケーションのメッセージログはログファイルサーバに転送される。MADOCA II では各メッセージにメッセージ固有番号(msg_id)を定義し、メッセージログに出力している。msg_id でログを検索することでメッセージの経路を辿ることができる。
2.3 制御関係者以外のログ確認ができない
現ログ分析システムでは制御メッセージログは専用のログサーバに蓄積しており、ログデー
タのアクセスは制御関係者が ssh で専用のログサーバにログインすることにより行っている。
しかし、緊急時においては制御関係者以外、例えばビームライン担当者にその状況を確認して頂きたい場合もある。制御関係者以外でも必要に応じてログへのアクセスができるようにしておきたい。

現ログ分析システムは特定のホスト・アプリケーションのある時間での検索など単純なログ検索は比較的容易である。しかし実際のログ分析においては、障害事象をより深く理解するため、類似障害が他のホスト、アプリケーションでも同様に発生しているのか、その統計情報を取得したい場合もある。現状のシステムでこのような障害検索の統計処理を行うためには担当者が各自に独自のファイル分析プログラムを作 3.
制御メッセージログ分析基盤の開発成し対応する必要がある。このため、ログ分析に１時間程度、またはそれ以上の時間を要する2 章で挙げた現ログ分析システムにおける課題を場合もある。
解消するため、本匠プロジェクト課題においてログ他に、MADOCA の制御 では Figure 2 に示されるように制御を制御端末と機器制御計算機間 分析基盤を新たに開発した。以下に示す準リアルタとのメッセージの送受信を行っていることから、 イムでの障害検知、高速かつ柔軟なログ検索、ログ障害発生時にメッセージ経路のどの部分でエ データの可視化が現在の課題を克服するために必要ラーが発生したのかを理解する必要がある場合 となる技術要素であると考え、それらを実現できるがある。(2014 年から SPring-8 に導入された ように設計を行った。
MADOCA の 次 世 代 制 御 フ レ ー ム ワ ー ク
MADOCA II では制御のメッセージ経路も辿る 3.1.1
準リアルタイムでの障害検知ことができるようになった [4]。) 現システム
では、この場合、メッセージ経路に関わった各制御に障害が発生した際にすぐに気づくことアプリケーションのログファイル群を検索し、ができるようにする。このため制御メッセージその中から特定のメッセージ情報を相互に結びログ中のエラーを準リアルタイムで検出し、エつける必要がある。このようログ分析も手間がラー発生頻度をオンラインでモニタする。障害かかり 10 分程度の時間を要している。
発生時にはこのエラー発生統計情報に基づき障害のパターンを把握する。詳細の確認は該当するエラー事象の元データとなる制御メッセージのログ検索により行う。

3.1.2高速かつ柔軟なログ検索

障害時にはさまざまな条件で制御メッセージログを検索してその状況を知ることが重要である。このため、制御ログメッセージはさまざまな値(ホスト、アプリケーション名、時間帯、他にはメッセージ中のエラーコード等)とセットでデータベースに保存しておく。すぐ障害把握ができるように、ログ検索は単純な条件であれば数秒程度で行うことができるようにする。
3.1.3

ログデータの可視化

ログデータ閲覧は制御関係者以外のユーザーでも簡易に行うことができるようにする。このため、現在のファイル閲覧ではなく、汎用のWeb インターフェースを用いる。Web インターフェースを介してログデータの検索、エラー発生の統計情報閲覧等のデータ可視化を柔軟に行う。

保存する項目の構成変更にも柔軟に対応できる。
開発したログ分析基盤は 4 つの要素(ログ集計、ログストリーム処理、ログ蓄積、及びログ閲覧)から構成される。以下にこれらの各要素について記す。
3.2.1

ログ集計

ログ集計部では、ログファイルサーバ上のログファイルに更新されたデータを読み出し、必要な情報を抽出・加工してデータベースへのデータ出力を行う。我々は fluentd [6] をこのログ集計管理に用いた。fluentd はログ集計においてデータのやりとりを行うオープンソースのソフトウェアである。目的に応じて各種プラグインが用意されており、それらを組み合わせることで多様なケースのログ集計に対応できる。本ケースでは、Figure 4 に示されるように in_tail,record_reformer, out_elasticsearch の fluentd プラグインを用いた。in_tail ではログファイルの tailをとり更新されたログ情報を取り出す。in_tail
ではデータファイル自身の情報も取り出すことができるため、メッセージログと共にホスト名、アプリケーション名を抽出しレコードに書き出す。record_reformer ではログデータから正規表
現を用いてメッセージ中のエラーコード、メッセージ経路情報抽出に必要となる msg_id を抽出してレコードに追記する。out_elasticsearch では得られたレコードを elasticsearch に出力する。
これらの fluentd の 各 plugin はコンフィグレー
ションファイルの設定のみで動作させることができるため、容易に利用することができる。本ケースで用いている fluentd はプロセス起動の管理にも対応している td-agent (バージョンは0.12.12)を用いた。

Figure 3: 匠プロジェクト課題で開発したログ分析システムの概念図。ログファイルサーバ上のファイルからデータを読み出してログ集計を行い、データベースへのデータ蓄積及び Web を介したログ閲覧を行う。
これらの技術要素を満たすために開発したログ分
析システムの概念図を Figure 3 に示す。最小限の構成変更で必要となる要件を満たすため、現在収集されているログファイルサーバ上のファイルのデータを読み出してログ集計を行い、その結果をドキュメ
ント指向の NoSQL データベースである elasticsearch[1]に蓄積し Web インターフェース kibana [2]でデータ閲覧をする枠組みをとった。
メッセージログは非構造データであり状況により自身にさまざまなデータを含む。分析の用途に応じてメッセージログから必要となるメトリクスを適宜抽出し、それらの値で柔軟にログ検索することが必要な場合も考えられる。採用した elasticsearch はスキーマレスのデータベースであるためテーブルにFigure 4: fluentd を用いたログ集計。
3.2.2

ログストリーム処理

ログストリーム処理では障害発生事象の統計情報を抽出する。このため、 fluentd と共に ス
ト リ ー ム 処 理 を 行 う norikra [7] を 利 用 し た(バージョンは 1.3.1)。 norikra を用いたログスト
リーム処理のフローを Figure 5 に示す。 障害事

象を事前選択するため、fluentd で grep プラグ memory、4TB disk) 1 台を用いた。中央制御室端末
インを用いてログデータから “fail”, “err”文字を 20 ホスト、モニタ用機器制御計算機 27 ホスト用の抽出した後、ログストリーム処理を norikra を用 ログ集計のため、それぞれ専用のサーバを１台ずついて行う。norikra ではユーザーが SQL を設定す 割り当てた。ログ発生量は Table 1 に示されるようるのみで簡易にログストリーム処理を行うこと に合計で 1 秒あたり 3280 行である。全体でのログができる。Figure 5 の例では norikra に設定した収集量 約 35,000 行/秒に対して 10 分の 1 程度の規SQL により 1 分毎のエラー発生件数を抽出して模のデータ量を扱っている。ログ蓄積の計算機ではいる。エラー発生件数の集計時には、ホスト名、アプリケーション名、エラーコードなど多様な データ可視化を行う Web サーバ kibana も稼働させ項目によるグループ処理も SQL を介して柔軟に ている。
行うことができる。得られた統計情報は同様にelasticsearch に出力する。

Figure 6: ログ分析システムの SPring-8 制御系の一部(中央制御室運転端末、及びモニタ系機器制御計算機)への試験導入。
Figure 5: norikra を用いたログデータ中のエラー件数集計。
3.2.3

Table 1: ログ分析システム試験導入で対象としたホスト数、及びログ集計量。

ログ蓄積、ログ閲覧
ログデータの蓄積にはドキュメント指向の対象
ホスト数
ログ集計量
NoSQL データベース elasticsearch (バージョン
中央制御室運転端末
20
1,280 行/秒
は 1.7.1)を利用した。スキーマレスであるためモニタ計算機
27
2,000 行/秒
ログ分析に必要となるメトリクスを適宜テーブ
合計
473,280 行/秒
ルに追加保存して検索することができる。また、
NoSQL であることから、データ量の増加に対本試験で扱うログ量は全体の 10 分の 1 程度である
しても複数の計算機のクラスタ構成をとりス が、今後必要となるログ量の増加にも対応できるよ
ケールアウト化することで対応できる。
うに、fluentd の multiprocess プラグインを用いてロ
elasticsearch に は デ ー タ 可 視 化 を 行 う kibana
グ集計のマルチプロセス化を行った。各プロセスで(バージョンは 4.1.1)が整備されている。汎用のWeb インターフェース kibana で elasticsearch に 扱うログのアプリケーション数は合計のログ出力数
蓄積したーデータを柔軟に検索したり集計情報 が均一になるように調整した。この時、ログ集計計を抽出したりできる。これらの利用の詳細につ 算機では CPU 負荷が高く(60%程度)、ログ蓄積計算機ではメモリ使用量が多い(総量 128GB の半分程度)
いては次の 4 章で述べる。
状態であった。今回のログ量では現在の計算機構成で対応できるが、より多くのログ収集を行うために4. SPring-8 加速器制御系への一部の試験導 は計算機のスペックの増強、または複数の計算機によるクラスタ構成など対応が必要になると考えられ入3 章で述べたログ分析基盤の有用性を確認するた る。
め、Figure 6 に示すように SPring-8 加速器制御系の一部にログ分析システムを小規模で試験導入した。
ログ集計には DELL PowerEdge R420 (4 core CPU、16GB memory、500 GB disk) 2 台を用い、ログ蓄積には DELL PowerEdge R510 (12 core CPU 、 128GB

ようになった。

Figure 7: kibana を用いた SPring-8 制御メッセージログの全ログ閲覧。

Figure 8: メッセージ固有番号(msg_id)によるMADOCA II メッセージ経路検索。

Figure 9: SPring-8 制御メッセージログの全エラー発生統計情報の閲覧。

Figure 10 : 10 回以上/分のエラー件数で検索した場合におけるエラー発生統計情報閲覧。

kibana では制御メッセージログ検索のみでなく制
fluentd で収集し elasticsearch に蓄積されたデータは kibana を用いてログ閲覧を行った。Figure 7 に 御障害発生件数のオンラインモニタも行う。Figure 9
kibana を用いた SPring-8 制御メッセージの全ログ閲 に SPring-8 制御メッセージログの全エラー発生統計
覧の例を示す。kibana では制御メッセージの生ログ 情報の閲覧例を示す。1 分間ごとのエラー件数・エ(ログ時間、ホスト名、アプリ名、ログメッセージ) ラーメッセージ(1 分間の間に検知された最新値)を、を表示するだけでなく、各種集計情報も同時に表示 時間、ホスト、アプリ名別に表示している。また、させられるため、データの特徴を容易に把握するこ各種集計情報(エラー発生頻度の時間変動、エラー発とができる。図上部には時間毎のログ発生頻度のヒ生したホスト、アプリケーション構成)の表示よりエストグラムも表示されており、予想通り約 3,000 行/秒のログデータが処理されていることがわかる。図 ラー発生状況をわかりやすく把握することができる。
左には TopN クエリでの集計結果が表示されており、 図では多くのエラー発生が確認されるが、これは本データ中のホスト構成割合等の集計情報を簡易に知 データを加速器の試験調整時に収集したためである。
同様に検索窓に Apache Lucene のクエリを入力することができる。上部の検索窓では Apache Lucene[8]を用いたクエリを実行することでデータを各種条 ることでさまざまな条件でのエラー発生状況が確認件でインタラクティブに検索できる。
できる。Figure 10 には毎分 10 回以上エラーが発生
ログデータの検索例として Figure 8 にメッセージ している場合のエラー発生事象検索の例を示した。
固有番号(msg_id)による MADOCA II メッセージ経 エラーメッセージやエラーID 構成から、制御端末と路検索の例を示す。msg_id を検索窓で指定して検索 特定の機器制御用計算機間のメッセージングサーバすることにより 2 秒程度でメッセージ経路のログ情 接続エラーが障害の原因であることが理解できる。
報を検索することができた。2 章 Figure 2 で説明したようにログファイル検索にもとづくメッセージ経路検索は手間がかかり 10 分程度の時間がかかっていたが、大幅に検索速度を向上させることができる5.

Figure 11: ホスト毎、エラーID 毎のエラー発生頻度のトレンドグラフ。

まとめSPring-8 の加速器・ビームラインの制御の障害発生時の原因把握・対応をより迅速に行うため、fluentd、norikra、elasticsearch 及び kibana を活用した制御メッセージログ分析基盤を開発した。本ログ分
析基盤では今までのファイル検索に基づくログ分析での課題を解消するため、準リアルタイムでの障害検知、高速かつ柔軟なログ検索、及び Web インターフェースによるログデータの可視化を実現できるように設計した。本ログ分析基盤を SPring-8 制御システムの一部に試験導入し目的の用途を満たすことを確認した。試験で対象としたログ収集量は約3,000 行/秒と総量の 10 分の 1 程度ではあったが、既に中央制御室の制御端末の全てをカバーしており実運用で利用する価値は十分にあると考えている。今後は SPring-8 運転における制御障害把握・対応において常時活用できるように加速器運転員など制御関係者以外の利用も考慮して整備を進めていきたい。

制御メッセージログ中のエラー発生状況をより簡便にモニタするため、Figure 11 に示されるようにホスト毎、及びエラーID 毎のエラー発生頻度のトレンドグラフ閲覧用のダッシュボードを作成した。グラフでエラー発生頻度にスパイクがみられるが、発生したホスト名やエラーID から特定の Libera 機器の Appendix. 当初の採択課題名「MongoDB を通信エラーが原因であることがわかった。他には、活用した加速器制御メッセージログ分先に述べたメッセージングサーバ接続のエラー発生
析基盤の開発」とは異なる方向へ研究状況が確認できる。試験運用時はエラー発生状況をが進展した理由についてこのトレンドグラフで確認し、その後に元のメッセージログの検索により詳細を確認する手続きで障本 匠 プロ ジェ ク ト 課 題の当 初 の採 択課 題 名は害把握をスムーズに行うことができた。
このエラー発生頻度のモニタは障害発生パターン 「MongoDB を活用した加速器制御メッセージログを理解するためにも利用できる。ある障害が発生し 分析基盤の開発」という題目であった。最終的に目た際、同様の原因で発生した障害事象がどのホスト、 指した研究目標は当初と変わらなかったが、目標をアプリケーションでどの時間帯で発生しているのか 実現するための分析基盤として用いるデータベースを容易に検索することができる。このようなログ分 に は 当 初 予 定 し て い た MongoDB[10] で は な く 、析システムの特徴を活用することにより、SPring-8 elasticsearch を採用した。MongoDB も elasticsearch
で発生している障害事象をより系統的に理解し、そ と同様のドキュメント指向の NoSQL データベースの対応について具体的な検討を速やかに行うことが であり、ログ分析で必要となるさまざまなメトリクスを適宜追加して保存し、柔軟に検索することがでできるようになってきた
しかしながら、いくつかの課題も見つかってきて きる。本研究で MongoDB でなく、elasticsearch を採いる。エラー発生事象のうち大部分はその発生パ 用した大きな理由は、elasticsearch にはデータ可視化ターンが決まっており発生しても深刻な問題とはな のための Web インターフェース kibana が 付随するらない。稀に発生するエラー事象の方が、重要度が 形で予め整備されていた点が挙げられる。kibana を高くすぐに気づく必要があるケースが多い。今後は 用いることで、ログ分析で必要となる様々なデータ
SPring-8 運転で実際に発生している障害発生事象を 可視化を Web インターフェース上のダッシュボー
分類化し、より重要度の高い障害事象に対してすぐ ドを用いて手間・時間をかけずに簡易に実装するこに気づき対応ができるように整備していく必要があ とができる。このことにより、ログ分析基盤でデーる。また、制御メッセージログに障害が発生した際 タ可視化に必要とされた様々なログ分析機能を短期に、関連する計算機やネットワーク環境のモニタ情 の研究期間内で実装し、その有益性を確認すること
報と比較したい場合もある。現在はこれらの情報は ができるようになった。
Zabbix [9]を用いて監視しているが、elasticsearch のデータと連携してデータ相関を閲覧できるような仕謝辞組みが今後必要になると考えられる。
本匠プロジェクト課題を進めるにあたり、fluentd、elasticsearch、kibana を用いたログ収集・蓄積・可視化に関しては(公財)高輝度光科学研究センター制

御・情報部門 藤原綾潜氏のご協力を頂きました。
ここに感謝致します。

参考文献[1] https://www.elastic.co/products/elasticsearch[2] https://www.elastic.co/products/kibana[3] R. Tanaka, et al., “The first operation of control system at
the SPring-8 storage ring”, Proceedings of ICALEPCS1997,
Beijing, China, 1997, p.1[4] T.Matsumoto, et al., “Next-Generation MADOCA SPring-8Control Framework”, Proceedings of ICALEPS2013, San
Francisco, California, USA, 2013, p.944[5] http://www.rsyslog.com/[6] http://www.fluentd.org/[7] http://norikra.github.io/[8] https://lucene.apache.org/core/[9] http://www.zabbix.com/[10] https://www.mongodb.com/