2022年06月12日(日) - 23:07 | カテゴリ:
Linux
自鯖のメイン機はさくらの専用サーバにデュアルアクティブの2台構成で稼働しているが、
サブ用に純粋な自鯖も依然として稼働しており、ディスク装置にはQNAPのNASを使っている。
ちょっと前に、NASのOSをQTS 5.0にアップロードした所、
ファイルサーバへのアクセスログも普通に取得出来る様になったので、
機能を有効化して実際にファイルを読み書きしつつログを取ってみた。
QTS 5.0はQuLog Centerからイベントログとアクセスログの取得を設定出来る様になった。
以前のバージョンだと設定が各々独立しておりシステムログとプラグインを併用していた筈。
筆者は元からイベントログを外部のログサーバへsyslog転送していた為、
コレに加える形でアクセスログ取得を追加した。
ログサーバにマルチバイト文字を送信するとバグりやすい気がするのと、
QNAPのサポートへエラー報告する際に都合が良いので、ログの言語はEnglishにしている。
とは言っても、アクセスログで取得するファイルパスがマルチバイトなら、
English設定でもちゃんとマルチバイトなどのディレクトリ名が取れていた。
適当なファイルをファイル共有領域へ保存した後、10秒程度してから削除したログが上の通り。
横に長いので見えにくい人は右クリックから別窓確認を推奨。
ファイルを書き込む作業がAddとWriteの2行で記録されつつ、削除動作はDeleteになっていた。
画像には載っていないが、10万個の画像を1個のフォルダに置いて丸ごと読み込んでみた所、
今度はReadログが10万行分一気にログサーバへ飛んできた。
………
今回取得したログはQNAP本体でそのまま蓄積する事も出来るのと、
QTSにもログサーバのオプションが存在するので自身でそのまま蓄積するのも良さそう。
だが、一般家庭ではNASのアクセスログなんて取らないだろうし、
その上で取るなら本職の人だと思うので外部ログサーバへ転送するのが本筋だと思う。
結果としてNAS本体で蓄積するよりログサーバへ飛ばす事で真価を発揮する設定だと感じる。
アクセス数とファイルサーバ規模にもよると思うが、
エンタープライズ環境でフルロードをかけた際に耐えられるのかは未知数。
あくまで筆者の経験上だが、そこまで大規模になるならこの機能では耐えられない気がする。
そもそも、アクセスログ取得の前にNAS自体の処理限界を迎えて頭打ちになると思うが、
この辺りは何処かの企業がレポートを出してくれれば嬉しい。
« 続きを隠す
