LogrotateとS3cmdを使用してログをUbuntu 16.04のオブジェクトストレージにアーカイブする方法

前書き

サーバーとアプリケーションによって生成されるログファイルには、ソフトウェアのデバッグ、セキュリティインシデントの調査、および洞察に富んだメトリックと統計の生成に役立つ可能性のある情報が満載されています。

今日の典型的なロギング戦略は、the Elastic stackGraylogなどのログ集約サービスを介してこのすべての情報を一元化することです。 これは、リアルタイム分析や短期から中期の履歴調査には適していますが、ストレージの制約やその他のサーバーリソースの問題により、これらのシステムに長期データを保持することはできません。

これらの長期的なストレージニーズに対する一般的なソリューションは、オブジェクトストレージサービスでログをアーカイブすることです。 ログは、後の分析、法的保存要件、またはバックアップの目的で無期限に利用可能です。

このチュートリアルでは、Ubuntu 16.04サーバーでLogrotateを使用して、syslogログをオブジェクトストレージサービスに送信します。 この手法は、Logrotateによって処理されるすべてのログに適用できます。

前提条件

このチュートリアルを完了するには、次のものが必要です。

  • Initial Server Setup with Ubuntu 16.04で説明されているように、root以外のsudo対応ユーザーがいるUbuntu16.04サーバー。 このチュートリアルの構成は、さまざまなLinuxディストリビューションでより広く機能するはずですが、多少の調整が必要になる場合があります。

  • Logrotateと、Ubuntu 16.04でのデフォルト構成の設定方法に精通している必要があります。 詳細については、How To Manage Logfiles with Logrotate on Ubuntu 16.04をお読みください。

  • オブジェクトストレージサービスに関する次の詳細を知る必要があります。

    • アクセスキー

    • 秘密鍵

    • サーバー(または「エンドポイント」)URL

    • バケット名

      DigitalOcean Spacesを使用している場合は、How To Create a DigitalOcean Space and API Keyを読み取って新しいバケットを作成し、上記の情報を取得できます。

前提条件を完了したら、サーバーにSSHで接続して開始します。

[[step-1 -—- installing-s3cmd]] ==ステップ1—S3cmdのインストール

S3cmdというツールを使用して、ログをS3互換のオブジェクトストレージサービスに送信します。 S3cmdをインストールする前に、Pythonプログラムのインストールを支援するいくつかのツールをインストールする必要があります(S3cmdはPythonで記述されています)。

sudo apt-get update
sudo apt-get install python-setuptools

次に、書き込み可能なディレクトリに移動し、S3cmd.tar.gzファイルをダウンロードします。

cd /tmp
curl -LO https://github.com/s3tools/s3cmd/releases/download/v2.0.1/s3cmd-2.0.1.tar.gz

[.note]#Note:their Releases page on Githubにアクセスすると、S3cmdの新しいバージョンが利用可能かどうかを確認できます。 新しいバージョンを見つけた場合は、.tar.gzのURLをコピーして、上記のcurlコマンドに置き換えてください。

ダウンロードが完了したら、tarユーティリティを使用してファイルを解凍および解凍します。

tar xf s3cmd-*.tar.gz

次に、結果のディレクトリに移動し、sudoを使用してソフトウェアをインストールします。

cd s3cmd-*
sudo python setup.py install

s3cmdにバージョン情報を要求して、インストールをテストします。

s3cmd --version
Outputs3cmd version 2.0.1

同様の出力が表示される場合、S3cmdは正常にインストールされています。 次に、オブジェクトストレージサービスに接続するようにS3cmdを構成します。

[[step-2 -—- configuring-s3cmd]] ==ステップ2—S3cmdの構成

S3cmdには、オブジェクトストレージサーバーに接続するために必要な構成ファイルを作成できるインタラクティブな構成プロセスがあります。 rootユーザーはこの構成ファイルにアクセスする必要があるため、sudoを使用して構成プロセスを開始し、構成ファイルをrootユーザーのホームディレクトリに配置します。

sudo s3cmd --configure --config=/root/logrotate-s3cmd.config

対話式セットアップが開始されます。 必要に応じて、ENTERを押すことにより、デフォルトの回答(括弧内)を受け入れることができます。 以下のオプションと、DigitalOceanのNYC3リージョンのスペースに対する推奨される回答を順に説明します。 他のDigitalOceanデータセンターまたは他のオブジェクトストレージプロバイダーの必要に応じて、S3エンドポイントとバケットテンプレートを置き換えます。

  • アクセスキー:your-access-key

  • 秘密鍵:your-secret-key

  • デフォルトの地域[米国]:ENTER

  • S3エンドポイント[s3.amazonaws.com]:nyc3.digitaloceanspaces.com

  • DNSスタイルのバケット+ホスト名:バケットにアクセスするためのポートテンプレート[%(bucket)s.s3.amazonaws.com]:%(bucket)s.nyc3.digitaloceanspaces.com

  • 暗号化パスワード:ENTER、または暗号化するパスワードを指定します

  • GPGプログラムへのパス[/ usr / bin / gpg]:ENTER

  • HTTPSプロトコルを使用[はい]:ENTER

  • HTTPプロキシサーバー名:ENTER、またはプロキシ情報を入力します

この時点で、s3cmdは応答を要約し、接続をテストするように要求します。 yを押してからENTERを押して、テストを開始します。

OutputTest access with supplied credentials? [Y/n] y
Please wait, attempting to list all buckets...
Success. Your access key and secret key worked fine :-)

テスト後、設定を保存するよう求められます。 ここでも、yと入力してからENTERと入力します。 構成ファイルは、--configコマンドラインオプションを使用して以前に指定した場所に書き込まれます。

次のステップでは、S3cmdを使用してログをアップロードするようにLogrotateを設定します。

[[step-3 -—- setting-up-logrotate-to-send-rotated-logs-to-object-storage]] ==ステップ3—ローテーションされたログをオブジェクトストレージに送信するようにLogrotateを設定する

Logrotateは、ログファイルのローテーションと圧縮を管理するための強力で柔軟なシステムです。 Ubuntuはデフォルトでこれを使用して、/var/logにあるすべてのシステムログを維持します。

このチュートリアルでは、ローテーションされるたびにsyslogログをオブジェクトストレージに送信するように構成を更新します。

まず、システムログプロセッサであるrsyslogのLogrotate構成ファイルを開きます。

sudo nano /etc/logrotate.d/rsyslog

2つの構成ブロックがあります。 /var/log/syslogを扱う最初のものに興味があります。

/etc/logrotate.d/rsyslog

/var/log/syslog
{
    rotate 7
    daily
    missingok
    notifempty
    delaycompress
    compress
    postrotate
        invoke-rc.d rsyslog rotate > /dev/null
    endscript
}
. . .

この構成では、/var/log/syslogが毎日ローテーションされ(daily)、7つの古いログが保持される(rotate 7)ように指定されています。 ログファイルが欠落している場合(missingok)はエラーを生成せず、空の場合(notifempty)はログをローテーションしません。 回転したログは圧縮されますが(compress)、最新のログは圧縮されません(delaycompress)。 最後に、postrotateスクリプトは、古いログファイルがローテーションされた後、新しいログファイルに切り替えるようにrsyslogに指示します。

新しい構成ディレクティブを追加する前に、上で強調表示されているdelaycompress行を削除してください。 古いログはすべて、オブジェクトストレージに送信する直前に圧縮する必要があります。

次に、構成ブロックの最後に次の行を追加します(postrotateendscriptブロックの外側で、閉じている}ブラケットの内側)。

/etc/logrotate.d/rsyslog

. . .
        dateext
        dateformat -%Y-%m-%d-%s
        lastaction
                HOSTNAME=`hostname`
                /usr/local/bin/s3cmd sync --config=/root/logrotate-s3cmd.config /var/log/syslog*.gz "s3://your-bucket-name/$HOSTNAME/"
        endscript
. . .

上記の強調表示された部分を正しいバケット名に置き換えてください。 これらのオプションは、日付ベースのファイル名拡張子(dateext)をオンにするため、ログファイルにタイムスタンプを付けることができます。 次に、これらの拡張機能の形式をdateformatで設定します。 ファイルは、syslog-2017-11-07-1510091490.gzのようなファイル名で終わります:年、月、日付、そしてタイムスタンプ。 タイムスタンプにより、ファイル名が競合することなく、同じ日に2つのログファイルを出荷できます。 これは、何らかの理由でログのローテーションを強制する必要がある場合に必要です(これについては次のステップで詳しく説明します)。

lastactionスクリプトは、すべてのログファイルが圧縮された後に実行されます。 サーバーのホスト名で変数を設定し、s3cmd syncを使用してすべてのsyslogファイルをオブジェクトストレージバケットに同期し、ホスト名で名前が付けられたフォルダーに配置します。 "s3://your-bucket-name/$HOSTNAME/"の最後のスラッシュは重要であることに注意してください。 これがないと、s3cmd/$HOSTNAMEをログファイルでいっぱいのディレクトリではなく、単一のファイルとして扱います。

構成ファイルを保存して閉じます。 次回Logrotateが毎日実行するとき、/var/log/syslogは日付ベースのファイル名に移動され、圧縮されてアップロードされます。

これをすぐに強制的に実行して、正常に機能していることをテストできます。

sudo logrotate /etc/logrotate.conf --verbose --force
Outputrotating pattern: /var/log/syslog
. . .
considering log /var/log/syslog
  log needs rotating
. . .
running last action script
switching euid to 0 and egid to 0
upload: '/var/log/syslog-2017-11-08-1510175806.gz' -> 's3://example-bucket/example-hostname/syslog-2017-11-08-1510175806.gz'  [1 of 1]
 36236 of 36236   100% in    0s   361.16 kB/s  done
Done. Uploaded 36236 bytes in 1.0 seconds, 35.39 kB/s.

これにより、多くのログファイルに関する多くの情報が出力されます。 syslogログとアップロードに関連する部分は上記から抜粋されています。 出力は、アップロードが成功したことを示すいくつかの証拠とともに、同じように見えるはずです。 サーバーが新品でない場合、アップロードされるファイルが増える可能性があります。

次に、システムをシャットダウンする前にログをアップロードできるように、オプションでサービスを設定します。

[[step-4 -—- sending-logs-on-shutdown]] ==ステップ4—シャットダウン時にログを送信する

この手順はオプションであり、頻繁にシャットダウンおよび破棄される一時サーバーを設定する場合にのみ必要です。 この場合、サーバーを破棄するたびに最大1日分のログが失われる可能性があります。

これを修正するには、システムがシャットダウンする前にLogrotateを最後に実行する必要があります。 これを行うには、停止時にlogrotateコマンドを実行するsystemdサービスを作成します。

まず、テキストエディターで新しいサービスファイルを開きます。

sudo nano /etc/systemd/system/logrotate-shutdown.service

次のサービス定義を貼り付けます。

/etc/systemd/system/logrotate-shutdown.service

[Unit]
Description=Archive logs before shutdown
After=network.target

[Service]
RemainAfterExit=yes
ExecStop=/usr/sbin/logrotate /etc/logrotate.conf --force

[Install]
WantedBy=multi-user.target

このファイルは、開始時に何も実行せず(ExecStartステートメントがない)、停止時に(--forceオプションを使用して)logrotateを実行するサービスを定義します。 After=network.target行が原因でネットワーク接続がシャットダウンされる前に実行されます。

ファイルを保存してテキストエディタを終了し、systemctlを使用してstartおよびenableサービスを終了します。

sudo systemctl start logrotate-shutdown.service
sudo systemctl enable logrotate-shutdown.service

新しいサービスのステータスを確認します。

sudo systemctl status logrotate-shutdown.service
Output● logrotate-shutdown.service - Archive logs before shutdown
   Loaded: loaded (/etc/systemd/system/logrotate-shutdown.service; enabled; vendor preset: enabled)
   Active: active (exited) since Wed 2017-11-08 20:00:05 UTC; 8s ago

Nov 08 20:00:05 example-host systemd[1]: Started Archive logs before shutdown.

activeであることを確認したいと思います。 exitedがあるという事実は問題ありません。これは、ExecStartコマンドがないためです。

手動で停止することにより、新しいサービスが機能していることをテストできます。

sudo systemctl stop logrotate-shutdown.service

または、システムを再起動してください。

sudo reboot

いずれの方法でもLogrotateコマンドがトリガーされ、新しいログファイルがアップロードされます。 これで、異常なシャットダウンがなければ、サーバーを破壊してもログは失われません。

[.note]#Note:多くのクラウドプラットフォームdo notは、サーバーが破壊または終了されているときに正常なシャットダウンを実行します。 特定のセットアップでこの機能をテストし、正常なシャットダウン用に構成するか、最終的なログローテーションをトリガーするための別のソリューションを見つける必要があります。

結論

このチュートリアルでは、S3cmdをインストールし、オブジェクトストレージサービスに接続するように構成し、/var/log/syslogが回転したときにログファイルをアップロードするようにLogrotateを構成しました。 次に、シャットダウン時にlogrotate --forceを実行するようにsystemdサービスを設定し、エフェメラルサーバーを破棄するときにログが失われないようにします。

Logrotateで使用可能な構成の詳細については、コマンドラインでman logrotateと入力して、そのマニュアルページを参照してください。 S3cmdの詳細については、their websiteを参照してください。

Related