はじめに
本記事は、BIG-IP を扱い始めた初心者である私が、運用の中で最低限知っておきたいログの種類について調べ、自分なりに整理・理解した内容をポートフォリオブログとしてまとめたものです。
BIG-IP は高い接続性やセキュリティ管理機能を提供するネットワーク製品ですが、実際の運用フェーズでは「ログの確認」が必須となります。
私も実務ではログの取得はする機会がありますが、調査はベンダー様に実施していたため、どのログが何のために取得しているかの理解が不足しており、補足する必要があると考えていました。
不具合発生時や調査必要の場面で、どのログに何が記録されるのかを知っておくことは、効率的な問題解決につながります。本記事では、特に自分が実務でよく使う LTM や APM を中心に、基本的なログの種類とその対応例をまとめています。
基礎的なログファイルと応用例
| ログファイル | 含まれる情報 | 応用例 |
|---|---|---|
/var/log/ltm | LTM設定の変更、VIP/プールのステータス、エラー | ヘルスモニタ失敗やサービス不実時の調査 |
/var/log/apm | APMによる認証成否、ポリシー処理状況 | SSO失敗時のユーザ調査、ポリシーデバッグ |
/var/log/audit | CLI/GUでの作業記録 | 誰が何をしたかの証跡調査 |
/var/log/messages | OSレベルや各デーモンの通知 | システム障害発生時の初期調査 |
/var/log/tmm | 通信コアのクラッシュや統計 | パフォーマンス問題や内部エラーの調査 |
運用での利用例
/var/log/ltm
/var/log/ltm は、BIG-IP の LTM（Local Traffic Manager）に関連するイベントやエラー、設定変更の履歴が記録される最重要ログのひとつです。
たとえば、仮想サーバ（Virtual Server）が応答しないとき、「プールメンバーが down になっていないか？」「ヘルスモニタが失敗していないか？」といった調査の起点になります。
実際の現場では、次のような使い方をしています：
- 障害報告を受けたとき、まず
tail -f /var/log/ltmを実行し、最新のログを追いかけて状況を把握 - ログ内のエラーコードや IP アドレスから、対象の仮想サーバやノードを特定
- 過去のログも含めて
grepで検索し、発生タイミングや頻度を把握
tail -f /var/log/ltmまた、設定変更があった際の「変更検知」にも役立ちます。tmsh で何かを変更すると、その内容が記録されるため、「誰かが何かを変えた形跡がある」というヒントにもなります。
/var/log/apm
/var/log/apm は、APM（Access Policy Manager）に関連するログが記録される場所で、主にユーザー認証やアクセス制御の成功・失敗に関する情報が含まれます。
実際のトラブル対応では、次のような調査に役立ちます：
- SSO（シングルサインオン）でログインに失敗したユーザーがいた場合、どのステップで止まっているかを確認
- 「AD 認証は通っているのに、リダイレクト後に落ちる」といった現象の切り分け
- セッション情報の残存（セッションタイムアウトや破棄漏れ）を確認
ログには、ユーザー名・クライアント IP・アクセス先 URI などが記録されるため、非常に具体的なデバッグが可能です。
tail -f /var/log/apmまた、APMのアクセスポリシーに設定した分岐条件（例：グループ判定やクライアント証明書検査）がどこで失敗しているかも、ログから追えます。視覚的なポリシービルダーだけでは見えない内部処理が見える点でも、非常に重宝します。
/var/log/audit
何らかの構成変更があった場合に、誰が実行したのかを調べることができます。誰が何をしたかの証跡調査や責任分析に有用です。
たとえば、設定変更によって通信が止まってしまったり、ポリシーが意図せず変更されていた場合、誰かがその変更を行ったかどうかを /var/log/audit から追跡することができます。
tail -f /var/log/auditこのログには、例えば以下のようなエントリが記録されます：
Jul 27 10:15:42 bigip notice mcpd[1234]: 01070727:5: AUDIT - user 'admin' modify net self 192.168.1.10 { netmask 255.255.255.0 }このように、「admin」ユーザーが net self の設定を変更したという事実が、日時と共に残されます。
注：あくまで「誰が」というのは、BIG-IPでのアカウント単位までです。
アカウントが root や admin のみの場合、そのアカウントを誰が操作したのかまでは判別ができません。
そのため、複数人で 1 つのアカウント（特に admin）を使い回している環境では、ログ上の「誰が」は本当の意味では特定できず、内部的な責任の所在が曖昧になります。
実務では、TACACS+ や RADIUS などの外部認証システムと連携し、個人ごとのアカウントで操作させることで、より厳密な追跡が可能となります。
ログ監視との連携
これらのログファイルはHinemosやZabbixなどの監視ツールと連携することで、異常をリアルタイムで通知することも可能です。既存の監視系にsyslogで送信する様に設定を詰めるのが常套です。
まとめ
BIG-IPは、コンポーネントとしての機能が多層に分かれているため、ログも種類別に分かれています。
この記事で解説した /var/log/ltm や /var/log/apm などは、運用の中でよく取得するログなので今回学べて大変為になりました。
問題発生時に早期対応を行うためにも、日頃から日常のログを読む習慣や監視の自動化を進めておくことが大切だと感じました。
※この記事はあくまで私の疑問をもとに、自学自習しながらまとめた内容です。間違いや不足があれば、ご指摘いただけると幸いです。
コメント