みなりん*のブログ

内容はなんでもありです。暗号通貨に特化している訳ではありません。

トップ > NEM スーパーノード > NEM スーパーノードの構築 第4回（ログファイルの管理）

NEM スーパーノードの構築 第4回（ログファイルの管理）

NEM スーパーノード NEM 暗号通貨 IT

今回はUNIXサーバで動いているNISサーバ及びservantサーバのログファイルについて解説します。多分NEMの公式サイトを見ても載ってない内容になるかと思います。

1. サーバに保存されるログファイル

NISサーバ及びservantサーバは、アプリケーションが独自で保存しているログファイルと、UNIXシステムが保存しているログファイルがあります。これらのログは同一のもので敢えて2箇所に保存しなくても良いと思います。 そして一番の問題はNISサーバのログがかなり多いという事です。

ここでは、次の様なディレクトリ構造を仮定して話を進めていきます。

設定の方針としては、サーバアプリケーションが保存するログを優先して保存を行い、システム側のログを少なくします。そして、システムの設定は変えずアプリケーション側の設定変更だけを行います。

1.1 アプリケーションに保存されるログファイル

アプリケーション側の設定として、ログファイルについて記載されているファイルは、以下のものがあります。

nem@localhost:~$ cd nemServer
nem@localhost:~/nemServer$ find . -name "*logalpha.properties" -print
./nis/logalpha.properties
./servant/logalpha.properties
./nix.logalpha.properties
./logalpha.properties
nem@localhost:~/nemServer$

これらのファイルの中身を書き換えながらテストを行なったところ、影響のあったファイルは次の2つです。

  • NISサーバのログ設定ファイル： ~nem/nemServer/nis/logalpha.properties
  • Servantサーバのログ設定ファイル： ~nem/nemServer/servant/logalpha.properties

ここでNISサーバのログ設定ファイルの中身を見ます。

handlers = java.util.logging.ConsoleHandler, java.util.logging.FileHandler
.level = INFO　（← A）

java.util.logging.ConsoleHandler.formatter = org.nem.deploy.ColorConsoleFormatter
java.util.logging.ConsoleHandler.level = INFO　（← B）

java.util.logging.FileHandler.formatter = org.nem.deploy.NemFormatter
java.util.logging.FileHandler.limit = 100000000　（← C）
java.util.logging.FileHandler.count = 100　（← D）
java.util.logging.FileHandler.pattern = ${nem.folder}/nis/logs/nis-%g.log

java.util.logging.SimpleFormatter.format = %1$tY-%1$tm-%1$td %1$tH:%1$tM:%1$tS.%1$tL %4$s %5$s%6$s (%2$s)%n

ここでA〜Dについて説明します。

  • A：監視するログレベルを記載します。ここでの設定で監視する対象をを絞ってしまうと、アプリケーションログ及びシステムログ両方の出力に影響を及ぼします。前提条件として、アプリケーションログは全て保存するという条件で良いならば、このまま変更せずINFOのままにしておきます。
  • B：システムログに出力するログファイルの対象を記述します。私の場合はログを1段階絞る設定をする為に、WARNINGと書き換えました。
  • C：ログファイルがこのByte数になったらローテートを行います（またサービスの再起動を行なった場合にもローテートされる様です）。流石に現在の設定ですと、1つのログファイルが最大で100MBになってしまいます。私の場合はこちらを10MBに設定を変更しました。
  • D ：保存するログファイルの個数です。こちらは設定変更しませんでした。なお、NISサーバのアプリケーションログは、最新のものがnis-0.log というファイル名になります。ここから100個保存するので、ローテートされて出来る最古のファイルはnis-99.logとなります。 なおこちらの数値を少なく設定変更しても、既に出来てしまっているファイルは消去されませんので、必要に応じて削除を行なって下さい。

Bの設定については私的に推奨します。システムのログを作成するUNIXシステムの実装又は設定方法によって色んな形態が考えられますが、色々なログが1つのファイルに混ざってしまう事により、検索に時間がかかったり他の重要なログを見逃す事になります（httpdのログがシステムのログと混ざって保存されている様な感じと捉えていただければ分かりやすいと思います）。

C及びDの部分の設定で、ログファイルの最大サイズが決まります。初期状態の設定では100MBのファイルが100個作成されますので、最大で10GBのログを保存する事になります。 最近では、25GBのディスク容量のレンタルVPSサーバがある時代です。 ディスク容量が元々少ない場合には、ログを溢れさせない様にする1つの手段としてCの値の変更を行なっています。 逆に言えば、容量が十分あるのであれば、保存するサイズを小さくする必要はありません。

以下が上記の説明にあった私の変更点を反映したNISサーバのログ設定ファイルです。なお、変更する場合は念のためcp -p logalpha.properties logalpha.properties.orgとしてコピーを保存しておくと良いでしょう。

handlers = java.util.logging.ConsoleHandler, java.util.logging.FileHandler
.level = INFO

java.util.logging.ConsoleHandler.formatter = org.nem.deploy.ColorConsoleFormatter
java.util.logging.ConsoleHandler.level = WARNING　（←変更点）

java.util.logging.FileHandler.formatter = org.nem.deploy.NemFormatter
java.util.logging.FileHandler.limit = 10000000　（←変更点）
java.util.logging.FileHandler.count = 100
java.util.logging.FileHandler.pattern = ${nem.folder}/nis/logs/nis-%g.log

java.util.logging.SimpleFormatter.format = %1$tY-%1$tm-%1$td %1$tH:%1$tM:%1$tS.%1$tL %4$s %5$s%6$s (%2$s)%n

servantのログファイルもほぼ同一ですので、同じように書き換えて下さい。

なお、アプリケーション側が保存するログファイルは、下記のディレクトリに入っていますので参照して参考にしていただければと思います。

  • NISサーバ：~nem/nem/nis/logs
  • Servantサーバ：~nem/nem/node-rewards/servant/logs

そして、この設定を反映するために、NISサーバ及びServantサーバの再起動を行なって下さい。

1.2. システムに保存されるログファイル

ここは、使っているOS及び設定によって色々なパターンがありますが、基本的には下記の種類に分けられると思います。

  • /var/log/syslog
  • /var/log/messages
  • upstart （/var/log/upstart の配下のログ）
  • systemd（journalctl -f 等で参照）

NEM スーパーノードの構築 第2回 の場合はupstart、第3回の場合は、systemdとなります。

システムのログファイルを参照し、INFOレベルのログが出力されてなければ、正常にログファイルの設定ファイルが反映されている事となります。

2. サーバシステムを運用しているという心構え

ログファイルの増大は、システムの安定性に関わります。サーバを運用するにあたっては、定期的にログファイルを見る事でシステムの異常を感知する事が出来ます。しかしながらログファイルも増え続ければディスクを圧迫し、システムが不安定になったりサービスが終了する事もあります。自動でログファイルが増大しない様に処理をしていても、異常が起きてログファイルが膨大に生成される可能性もあります。

特にNISサーバのログは大変多くのディスク領域を消費し2箇所に保存しているという事から、ログファイルを減らすという事を主眼としてこちらの記事を作成しております。

NEMのスーパーノードは、スーパーノード報酬を得たいという理由から構築する側面もありますが、それはスーパーノードがNEMのネットワークに必要とされているからです。サーバが停止する事で、スーパーノード報酬が得られないのではなく、構築されたサーバを利用しているノードが存在している事も忘れない様にしていただきたいと考えます。