監視と可視化と通知と分析：ログ監視は結局PowerShellに行き着いたという話

PowerShell

システムやアプリケーションのログを適切に監視することは、セキュリティやパフォーマンスの向上、問題の早期発見と早期の対策につながります。ログ監視ツールを利用することで、自動的にログの収集、解析、アラート通知ができるようになります。本記事では、ログ監視の基本的な方法や代表的なツールについて簡単に触れた後、結局はPowershellによる自作での監視に行き着いた経緯を解説します。制約が多い企業内での困っている社内SEの方は特に、実際に導入するためのヒントになると思いますので、ぜひ適切なツールの導入の参考にしてください。

ログ監視の方法

ログ監視は主に次の方法に分類できます。

  1. 手動確認する
  2. スクリプトを使用してログを解析する
  3. ログ監視ツールを使用する

多くの場合は、現状は1の手動での監視または、監視を行っていない状態であり、その状態を解決するために３のログ監視ツールを使う選択になると思います。私自身もその流れで検討していました。

ツールの紹介

ツールは有料のものや、企業がサービスとして提供するもの、最近ではクラウド型の監視サービスというものもあります。私が監視したい対象は主に社内のサーバーになりますが、一般的な検討対象になるツールは以下のようなものがあります。

  1. Nagios – オープンソースの監視ツールで、さまざまなログを監視できます。
  2. Splunk – あらゆる種類のログデータを収集、検索、分析、視覚化することができるツールです。
  3. Graylog – ログ収集、処理、監視を行うオープンソースのプラットフォームです。
  4. Datadog – クラウドモニタリングプラットフォームで、ログ監視にも対応しています。
  5. Fluentd – オープンソースのログ収集エージェントで、大量のログデータを収集、処理、転送できます。
  6. ELK Stack – ElasticSearch、Logstash、Kibanaの3つのオープンソースソフトウェアで構成されるログ監視・可視化ツールです。
  7. Prometheus – オープンソースの監視ツールで、分散システムやコンテナ化されたアプリケーションに適したツールです。
  8. Zabbix – オープンソースの監視ツールで、ネットワークやサーバーの監視に適しています。
  9. SolarWinds – 商用のネットワーク監視ツールで、広範囲のシステムやアプリケーションを監視できます。
  10. Dynatrace – 商用のクラウドモニタリングツールで、AIを活用した自己学習機能を備え、高度なログ解析が可能です。

実際に何を導入するか

既存サーバーに導入する場合の課題

個人的な環境やテスト環境であれば、各種ツールの導入も容易となりますが、会社内ですでに稼働中のサーバーに対して、ツールを導入するのは意外と壁があります。

  1. システムの安定性に影響を与えるリスク 新しいツールを導入する際には、システムの安定性に影響を与える可能性があります。特に、既存のアプリケーションやサービスとの互換性に問題がある場合には、想定外のトラブルが発生することがあります。
  2. パフォーマンスに影響を与えるリスク 新しいツールを導入することで、システムやアプリケーションのパフォーマンスが低下する可能性があります。例えば、ログ監視ツールを導入する場合には、ログデータの収集や処理に時間がかかり、システム全体のレスポンスが遅くなることがあります。
  3. セキュリティに関するリスク 新しいツールを導入することで、システムやアプリケーションのセキュリティに影響を与える可能性があります。例えば、ログデータが外部に漏洩することがないよう、ログ監視ツールの設定に注意する必要があります。
  4. 運用管理に関するリスク 新しいツールを導入することで、システムやアプリケーションの運用管理に関する問題が発生する可能性があります。例えば、ツールの操作や設定方法に不慣れな場合には、トラブルが発生した際に対応できないことがあります。

特に、社内だとインターネットとの接続の問題、OSSなどフリーのツールについていえば、関連するソフトウェアのインストール（Rubyやコンパイラ、DBなど）の依存関係が意外と多く、またそれらの依存関係にはバージョンを考慮する必要性も生じます。

ツール以外の選択肢

そうなってくると、冒頭で紹介した2.スクリプト という選択が意外と導入しやすいということになります。

スクリプトの自作は、機能が限定されて自力開発が大変。アプリケーション側の変更に追従が必要。スクリプトのバグ。などがデメリットとなる反面、ブラックボックス化されている機能が少なく影響範囲が想像しやすかったり、依存関係が少なくて済むというメリットがあります。

PowerShell が意外と使えた

Powershell は運用上使用することもありましたが、あまり機能を広く調査したことがなく、必要になった場合にネットで調べる程度でした。つまり自分ができると思っている範囲でしか活用できていませんでした。

そのため、知っている方からしたら今更と思われることだと思いますが、ログ監視でPowershell を使用するのは、特に会社内の制約が多く新しいツールを導入することが難しい場合は特に、良い選択に思えます。

イベントログ監視

PowerShellのスクリプトを使用して、イベントログを定期的に監視し、必要なイベントに対して自動的にアクションを実行するには、以下の手順を実行します。

  1. 監視するイベントログとフィルター条件を定義する。
  2. 定期的にイベントログを監視するループを作成する。
  3. 監視ループ内で、新しいイベントを収集する。
  4. 収集したイベントが必要な条件に一致する場合、アクションを実行する。

以下は、この手順を実現するスクリプトの例です。この例では、SystemログからEvent ID 1074のイベントを検索して、必要な条件に一致する場合にメールを送信します。

$smtpServer = "smtp.example.com"
$to = "admin@example.com"
$from = "eventlog@example.com"
$subject = "システムがシャットダウンされました"

$logName = "System"
$eventId = "1074"

while ($true) {
    $events = Get-EventLog -LogName $logName -InstanceId $eventId -Newest 1
    if ($events) {
        $event = $events[0]
        $body = "システムがシャットダウンされました。"
        $smtp = New-Object Net.Mail.SmtpClient($smtpServer)
        $msg = New-Object Net.Mail.MailMessage($from, $to, $subject, $body)
        $smtp.Send($msg)
    }
    Start-Sleep -Seconds 60
}

任意のアプリケーションのログファイル監視

任意のログファイルについて監視しアクションをすることもできます。

$file = "C:\example.txt"

function Process-FileChange {
    # 何らかのアクションを実行する
    Write-Host "ファイルに変更が加えられました。"
}

while ($true) {
    $content = Get-Content $file -Raw -Wait
    if ($content -ne $null) {
        Process-FileChange
    }
}

このコードは、$file変数に監視するファイルのパスを設定し、ループ内でGet-Contentコマンドレットを使用して、ファイルの内容を監視しています。Get-Contentコマンドレットには、”-Wait”パラメーターを使用して、リアルタイムで変更を監視するように指定しています。また、”-Raw”パラメーターを使用して、ファイルの内容を一度に読み込むように指定しています。

ファイルの内容が変更された場合、Process-FileChange関数を呼び出して、必要なアクションを実行します。この例では、Write-Hostコマンドレットを使用して、ファイルに変更が加えられたことをコンソールに表示しています。

PowerShell で作成したスクリプトのサービス化

イベントログや任意のファイルを監視を行い、メール通知やアクションをするよにできることはわかりましたが、こうなるとやりたいことはサービス化です。PowerShellスクリプトをWindowsサービスとして実行するには、次の手順を実行します。

  1. PowerShellスクリプトを作成します。
  2. PowerShellスクリプトをバッチファイルに保存します。
  3. サービスを作成します。

以下は、具体的な手順です。

  1. PowerShellスクリプトを作成します。
    例えば、次のようなPowerShellスクリプトを作成し、”C:\Scripts\SampleScript.ps1″に保存します。

    Write-Host "Hello, world!"
  2. PowerShellスクリプトをバッチファイルに保存します。
    次に、バッチファイルを作成し、PowerShellスクリプトを実行します。バッチファイルを作成し、”C:\Scripts\SampleScript.bat”に保存します。

    powershell.exe -NoProfile -ExecutionPolicy Bypass -File “C:\Scripts\SampleScript.ps1”
  3. サービスを作成します。
    管理者権限を持つコマンドプロンプトを開き、次のコマンドを入力して、サービスを作成します。
    startパラメータにはautoを指定して、OS起動時に自動でサービスが開始するように指定します。

    sc create MyService binPath= “C:\Scripts\SampleScript.bat” start= auto

以上の手順を実行することで、PowerShellスクリプトをWindowsサービスとして実行し、OSの起動時に自動的に開始することができます。

まとめ

今回の記事をまとめると以下になります。監視の条件や条件合致後のアクション、可視化や分析について、もう少し詳しく書きたいですが、それはまた別の記事で紹介しようと思います。

  • 会社内のシステムだとインストールなどに制約が多く、ログ監視するにもOSS導入などハードルが高い
  • PowerShellであれば既にインストールされていて、スクリプトを必要なも機能だけ作りこめばよく、影響範囲も把握しやすい。社内の制約に苦しんでいるSEは一考する余地あり。
  • PowerShellでは、
    Get-EventLog
    Get-Content -Wait
    などで簡単にログ監視化が可能
  • scコマンドでサービス登録すれば、OS起動時の自動起動が可能

スポンサーリンク
タイトルとURLをコピーしました