2021年3月23日火曜日

Splunkバージョンアップ手順③ (インデクサをクラスタ構成している場合)

Splunkの各バージョンは、リリース後24か月でサポート終了となるライフサイクルポリシーとなっている。

2021年3月現在、サポート中のバージョンは7.2以降となっており、2021年内に7.2、7.3、8.0がサポート終了となる。

バージョン サポート期限
7.2 2021/4/30
7.3 2021/6/4
8.0 2021/10/22
8.1 2022/10/19

このような状況であるため、以下記事にてSplunkのバージョンアップ手順を記載した。この記事のSplunkは単体構成となっており、1台のサーバに対してバージョンアップすることで対応が完了した。

一方、Splunkは複数のインデクサをクラスタ構成にして負荷分散と冗長化構成とすることが可能であり、そのような構成の場合、バージョンアップ順序が存在し、多少ではあるがバージョンアップ手順が複雑となる。本記事では、Splunkのインデクサをクラスタ構成とした環境におけるバージョンアップ手順の検証結果を記載する。

環境

今回の検証では、ログ送信元となるUniversal Forwarderのサーバを含めると5台のサーバが必要となる。OSはすべてCentOS 7.8を使用する。インデクサのクラスタ構成のインストール手順は以下記事を参照いただきたい。

Splunkは8.0.5で構築済みの状態とし、8.1.2へバージョンアップを行う。

ホスト名 IPアドレス 種類 台数 説明
t1073spmg 192.168.11.73 Manager Node 1 Splunkの各コンポーネントを管理する。
t1074spsh 192.168.11.74 Search Head 1 Indexerに対して検索を行い結果を表示する。
t1075spin 192.168.11.75 Peer Node (Indexer#1) 1 ログの受信とSearch Headからの検索を受け付ける。Peer Node間でデータがレプリケーションされ冗長化される。
t1076spin 192.168.11.76 Peer Node (Indexer#2) 1 ログの受信とSearch Headからの検索を受け付ける。Peer Node間でデータがレプリケーションされ冗長化される。
t1077spfw 192.168.11.77 Universal Forwarder 1 Peer Nodeに対してログを送信する。

Splunkバージョンアップ手順

1. Splunkのインストーラを配置

Splunkを構成するすべてのサーバに対して、バージョンアップ対象となるインストーラファイル (tgz形式) を配置する。今回は8.1.2にバージョンアップするため、splunk-8.1.2-545206cc9f70-Linux-x86_64.tgzを配置する。

# ls -l
-rw-r--r--. 1 root root 511869044  8月  1  2020 splunk-8.0.5-a1a6394cc5ae-Linux-x86_64.tgz
-rw-r--r--. 1 root root 511782642  3月  3 05:59 splunk-8.1.2-545206cc9f70-Linux-x86_64.tgz

2. Manager Nodeをバージョンアップ

バージョンアップはManager Nodeから実施する。Splunkを停止したのち、tgzファイルを上書きインストールする。その後、Splunkを起動すればバージョンアップの処理が実行されたのち、Splunkが起動する。

なお、初回起動時はライセンス規約への同意とバージョンアップ前確認を求められるので、処理をスキップするために、--accept-license--answer-yesのオプションを付与している。

# /opt/splunk/bin/splunk stop
# tar xvzf splunk-8.1.2-545206cc9f70-Linux-x86_64.tgz -C /opt
# /opt/splunk/bin/splunk start --accept-license --answer-yes

Manager Node起動後、念のためManager NodeのSplunk Webにログインし、[設定]→[インデクサークラスターリング]にて、以下のステータスが「成功」であることを確認しておこう。

  • すべてのデータがサーチ可能
  • サーチ可能データ保持数を満たしています
  • 複製データ保持数を満たしています

Manager Node再起動直後しばらくはエラー表示となるため不安となるものの、数分待機すれば「成功」に変わるはずだ。

▼再起動直後


▼数分後

3. Search Headをバージョンアップ

Manager Nodeがバージョンアップ完了したら、次にSearch Headをバージョンアップする。手順はManager Nodeと同様となる。

# /opt/splunk/bin/splunk stop
# tar xvzf splunk-8.1.2-545206cc9f70-Linux-x86_64.tgz -C /opt
# /opt/splunk/bin/splunk start --accept-license --answer-yes

4. クラスタをメンテナンスモードに変更

次にPeer Nodeをバージョンアップするが、バージョンアップ時はクラスタをメンテナンスモード (保守モード) に変更する必要がある。

メンテナンスモードへの変更はManager Nodeから以下コマンドにて実施する。

# /opt/splunk/bin/splunk show maintenance-mode -auth admin:my_password
  Maintenance mode is : 0,  primaries backup and restore is : 0

# /opt/splunk/bin/splunk enable maintenance-mode --answer-yes
Maintenance mode set

# /opt/splunk/bin/splunk show maintenance-mode
  Maintenance mode is : 1,  primaries backup and restore is : 0

5. Peer Nodeをバージョンアップ

クラスタがメンテナンスモードに変更されたら、Peer Nodeをバージョンアップする。手順はManager Nodeと同様となるが、クラスタのすべてのPeer Nodeで並行して作業を実施する必要があるので注意。

まずは、すべてのPeer NodeにてSplunkを停止する。

# /opt/splunk/bin/splunk stop

次に、すべてのPeer Nodeにてtgzファイルを上書きインストールする。

# tar xvzf splunk-8.1.2-545206cc9f70-Linux-x86_64.tgz -C /opt

最後に、すべてのPeer NodeにてSplunkを起動する。

# /opt/splunk/bin/splunk start --accept-license --answer-yes

6. クラスタのメンテナンスモードを解除

Peer Nodeのバージョンアップが完了したら、Manager Nodeにてメンテナンスモードを解除する。

# /opt/splunk/bin/splunk disable maintenance-mode
No longer in Maintenance mode

# /opt/splunk/bin/splunk show maintenance-mode
  Maintenance mode is : 0,  primaries backup and restore is : 0

最後に、Manager NodeのSplunk Webにて[設定]→[インデクサークラスターリング]を確認し、クラスタの状態が「成功」ステータスとなっていれば問題ない。

以上でSplunkのバージョンアップは完了となる。この後はSplunk Universal Forwarderをバージョンアップすればよい。Universal Forwarderのバージョンアップ手順は以下を参照。

動作確認

最後にバージョンアップ中のログの状態を確認する。今回、Universal Forwarderから1秒間隔でログを送信しながらバージョンアップを行った際にログが欠落していないことを確認してみたところ、一時的にメンテナンスモードにしたことによる影響と想定されるが、一部ログに重複が発生していることを確認した。ただし、ログの欠落はなかったことから、バージョンアップによる停止が発生したとしても、ログの取りこぼしは発生しないことが確認できた。

参考

2021年3月18日木曜日

Linux操作時のコンソールやTera Termにてマウスを使わずページスクロールする方法

LinuxのコンソールやTera TermによるSSH接続時などにおいて、過去の出力結果を参照したい場合がある。Tera Termは取得したログやマウス操作で過去の実行結果に表示をスクロールさせることで、比較的簡単に確認することができるが、コンソールの場合は確認ができないため、再度同じコマンドを実行して画面に出力させることで確認を行うといった無駄な作業もよくやっていた。

実はコンソールもTera Termも、キーボード操作にて画面をスクロールさせることで、過去の出力結果を表示させることができる。これを使うことで作業効率が上がるので、以下に簡単にまとめることにする。

環境

OSはESXi上のCentOS 7とUbuntu 20.04にて動作を確認した。

CentOSはデスクトップ環境をインストールしない状態におけるコンソール操作とデスクトップ環境 (Gnome) インストール後のデスクトップ環境の「端末」にて動作を確認した。

Ubuntuはデスクトップ環境の「端末」にて動作確認を行った。

コンソールでのページスクロール

  • 上にページスクロール:Shift + PageUp
  • 下にページスクロール:Shift + PageDown
  • 上に1行スクロール:Ctrl + Shift + ↑ ※デスクトップ環境の「端末」のみ動作
  • ↓に1行スクロール:Ctrl + Shift + ↓ ※デスクトップ環境の「端末」のみ動作
  • プロンプトに戻る:↓またはESC

Tera Termでのページスクロール

  • 上にページスクロール:Ctrl + PageUp
  • 下にページスクロール:Ctrl + PageDown
  • 上に1行スクロール:Ctrl + ↑
  • ↓に1行スクロール:Ctrl + ↓
  • プロンプトに戻る:↓またはESC
2021年3月16日火曜日

Splunk 8.1.2を使ってインデクサをクラスタ構成で構築する

以前、Splunkのインストール手順を以下記事にて記載した。

前回は1台のサーバ上にSplunkのすべての機能を持たせる構成としていたが、Splunkは機能単位でサーバを分割し負荷分散と冗長化を実現することができる。

よくある構成として、受信したログを保管する「インデクサ (Indexer)」を複数台のサーバで構成することにより、ログのサーチ時の負荷分散と冗長化を実現することができる。この構成をインデクサのクラスタ構成 (Indexer clusters) と呼ぶ。

本記事では、Splunk 8.1.2を使って2台のインデクサをクラスタ構成として構築する手順を記載する。

環境

インデクサをクラスタ構成にするにあたり、Manager Nodeと呼ばれる管理ノードやSearch Headを個別のサーバに分けて導入する必要がある。

これは、マニュアルにも以下の通り記載されている。

These are the main issues to note:

  • Each cluster node (manager, peer, or search head) must reside on a separate Splunk Enterprise instance.
  • Each node instance must run on a separate machine or virtual machine, and each machine must be running the same operating system and version.
  • All nodes must be connected over a network.
  • There are strict version compatibility requirements between cluster nodes.

引用元 : Managing Indexers and Clusters of Indexers

今回の検証では、ログ送信元となるUniversal Forwarderのサーバを含めると5台のサーバが必要となる。OSはすべてCentOS 7.8、Splunkは8.1.2を使用する。

ホスト名 IPアドレス 種類 台数 説明
t1073spmg 192.168.11.73 Manager Node 1 Splunkの各コンポーネントを管理する。
t1074spsh 192.168.11.74 Search Head 1 Indexerに対して検索を行い結果を表示する。
t1075spin 192.168.11.75 Peer Node (Indexer#1) 1 ログの受信とSearch Headからの検索を受け付ける。Peer Node間でデータがレプリケーションされ冗長化される。
t1076spin 192.168.11.76 Peer Node (Indexer#2) 1 ログの受信とSearch Headからの検索を受け付ける。Peer Node間でデータがレプリケーションされ冗長化される。
t1077spfw 192.168.11.77 Universal Forwarder 1 Peer Nodeに対してログを送信する。

インデクサのクラスタ構成手順

1. CentOS 7構築 (4台)

Splunkは実行に必要なモジュールがインストーラ内にすべて含まれているため、CentOSのインストールは最小限のインストールを選択すれば問題ない。

インストール作業簡略化のため、firewalldとSELinuxは停止しておく。

# systemctl stop firewalld
# systemctl disable firewalld
# sed -i "s/SELINUX=enforcing/SELINUX=disabled/g" /etc/sysconfig/selinux
# setenforce 0

2. 各サーバ (4台) にSplunkインストール

Splunkのインストーラであるtgz形式のファイルを/optに解凍し、初回起動及び自動起動設定を行うことでインストールを完了させる。

初回起動時は、通常ではライセンス規約への同意と管理ユーザのパスワード設定が求められるが、CLIではオプションとして指定することができる。

設定項目 説明
--accept-license ライセンス規約へ同意する。
--answer-yes Yes/Noで回答かのうな質問はすべてYesで回答する。
--seed-passwd <パスワード> 管理ユーザadminのパスワードを設定する。
# tar xvzf splunk-8.1.2-545206cc9f70-Linux-x86_64.tgz -C /opt
# /opt/splunk/bin/splunk start --accept-license --answer-yes --seed-passwd my_password
# /opt/splunk/bin/splunk enable boot-start

3. Manager Node構築

まずはSplunkの各コンポーネントの管理を司るManager Nodeを構築する。今回はPeer Nodeは2台となるためreplication_factorsearch_factorは2で設定する。secretはこの後構成するPeer NodeやSearch Headで同一のものを指定する。

設定項目 (CLI) 設定項目 (GUI) 設定値
mode - manager ※8.1未満の場合はmasterで指定
replication_factor 複製データ保持数 2
search_factor サーチ可能データ保持数 2
secret セキュリティキー P@ssw0rd
cluster_label クラスターラベル Cluster-01

SplunkWebのGUIによる設定できるが、今回はCLIを使って設定する。

[root@t1073spmg ~]# /opt/splunk/bin/splunk edit cluster-config -mode manager -replication_factor 2 -search_factor 2 -secret P@ssw0rd -cluster_label Cluster-01 -auth admin:my_password
The cluster-config property has been edited.
You need to restart the Splunk Server (splunkd) for your changes to take effect.
[root@t1073spmg ~]# /opt/splunk/bin/splunk restart

4. Peer Node構築

Peer Nodeは2台構築する。それぞれのサーバで同じコマンドにて設定することができる。設定項目は以下の通りとなる。

設定項目 (CLI) 設定項目 (GUI) 設定値
mode - peer ※8.1未満の場合はslaveで指定
master_uri マスターURI https://192.168.11.73:8089
replication_port ピア複製用ポート 9887
secret セキュリティキー P@ssw0rd

1台目 : t1075spin

CLIにてPeer Nodeを構成する。

[root@t1075spin ~]# /opt/splunk/bin/splunk edit cluster-config -mode peer -master_uri https://192.168.11.73:8089 -replication_port 9887 -secret P@ssw0rd -auth admin:my_password
The cluster-config property has been edited.
You need to restart the Splunk Server (splunkd) for your changes to take effect.
[root@t1075spin ~]# /opt/splunk/bin/splunk restart

デフォルトでは受信用のポートがないため、9997番ポートを開放する設定を行う。

[root@t1075spin ~]# /opt/splunk/bin/splunk enable listen 9997 -auth admin:my_password
Listening for Splunk data on TCP port 9997.
[root@t1075spin ~]# /opt/splunk/bin/splunk restart

2台目 : t1076spin

CLIにてPeer Nodeを構成する。

[root@t1076spin ~]# /opt/splunk/bin/splunk edit cluster-config -mode peer -master_uri https://192.168.11.73:8089 -replication_port 9887 -secret P@ssw0rd -auth admin:my_password
The cluster-config property has been edited.
You need to restart the Splunk Server (splunkd) for your changes to take effect.
[root@t1076spin ~]# /opt/splunk/bin/splunk restart

デフォルトでは受信用のポートがないため、9997番ポートを開放する設定を行う。

[root@t1076spin ~]# /opt/splunk/bin/splunk enable listen 9997 -auth admin:my_password
Listening for Splunk data on TCP port 9997.
[root@t1076spin ~]# /opt/splunk/bin/splunk restart

5. Search Head構築

CLIにてSearch Headを構成する。

設定項目 (CLI) 設定項目 (GUI) 設定値
mode - searchhead
master_uri マスターURI https://192.168.11.73:8089
secret セキュリティキー P@ssw0rd
[root@t1074spsh ~]# /opt/splunk/bin/splunk edit cluster-config -mode searchhead -master_uri https://192.168.11.73:8089 -secret P@ssw0rd -auth admin:my_password
The cluster-config property has been edited.
You need to restart the Splunk Server (splunkd) for your changes to take effect.
[root@t1074spsh ~]# /opt/splunk/bin/splunk restart

6. Manager NodeのログをPeer Nodeに転送

特に何も設定しない場合、Manager NodeのSplunkの内部ログは、Manager Node内のIndexerに保存されてしまう。この場合、Manager Nodeの内部ログはManager Nodeから検索しなければ表示させることができず管理面で煩雑となることから、Peer Nodeにログを転送することでログを統合しSearch Headから検索できるようにする。

設定はManager Nodeのoutputs.confを直接編集する。

[root@t1073spmg local]# cat << EOF >> /opt/splunk/etc/system/local/outputs.conf
# Turn off indexing on the manager node
[indexAndForward]
index = false

[tcpout]
defaultGroup = my_peers_nodes
forwardedindex.filter.disable = true
indexAndForward = false
 
[tcpout:my_peers_nodes]
server = 192.168.11.75:9997,192.168.11.76:9997
EOF
[root@t1073spmg local]# /opt/splunk/bin/splunk restart -auth admin:my_password

7. Universal ForwarderからPeer Nodeにログ転送

最後にUniversal ForwarderからPeer Nodeにログを転送する設定を行う。設定はoutputs.confを直接編集する。

[root@t1077spfw ~]# cat << EOF >> /opt/splunkforwarder/etc/system/local/outputs.conf
[tcpout]
defaultGroup = my_peers_nodes

[tcpout:my_peers_nodes]
server=192.168.11.75:9997,192.168.11.76:9997
useACK=true
EOF
[root@t1077spfw ~]# /opt/splunkforwarder/bin/splunk restart -auth admin:my_password

splunk list forward-serverコマンドにて転送先のPeer Nodeを確認することができる。Universal Forwarder再起動直後はInactive forwardsと表示されるが、しばらくすると2台のPeer NodeがActive forwardsに表示されるようになるはずだ。

[root@t1077spfw ~]# /opt/splunkforwarder/bin/splunk list forward-server
Active forwards:
        192.168.11.75:9997
        192.168.11.76:9997
Configured but inactive forwards:
        None

動作確認

それでは、実際にUniversal ForwarderからPeer Nodeにログを送信し、Search Headからサーチできることを確認してみよう。

ログの送信はsplunk add oneshot <ログファイル>にて実施する。

[root@t1077spfw local]# /opt/splunkforwarder/bin/splunk add oneshot /var/log/messages -auth admin:my_password
Oneshot '/var/log/messages' added

Search Headでサーチすると、送信したログが表示されることを確認できた。

以上でSplunkのインデクサをクラスタ構成で構築する手順は完了となる。慣れてしまえば、30分あれば構築することができる。

2021年3月9日火曜日

Splunkバージョンアップ手順② (Universal Forwarderのバージョンアップ)

前回、Splunkの本体のバージョンアップ手順を記載した。

★前回の記事はこちら↓

Splunk本体のバージョンアップが問題なくできたので、今回はUniversal Forwarderのバージョンアップする手順を記載する。

環境

  • OS : CentOS 7
  • Splunk : 8.1.2 ※バージョンアップ済み
  • Splunk Universal Forwarder : 8.0.5から8.1.2へのバージョンアップ
  • Universal Forwarderインストール方法 : tgzファイルを/optに展開

Universal Forwarderバージョンアップ手順

1. Splunkのインストールファイルをダウンロード

インストーラは以下URLからダウンロードできる。ダウンロードするためにはSplunkサイトのユーザ登録が必要となるので注意

ダウンロードしたファイル名はsplunkforwarder-8.1.2-545206cc9f70-Linux-x86_64.tgzとなる。

2. インストールファイルをサーバへアップロード

Tera Termなどのscp機能を使用して、Universal Forwarderのインストールファイルをアップロードする。

今回は/tmpにファイルを配置した。

# ls -l /tmp/splunkforwarder-8.1.2-545206cc9f70-Linux-x86_64.tgz
-rw-r--r--. 1 root root 43433924  3月  3 05:59 /tmp/splunkforwarder-8.1.2-545206cc9f70-Linux-x86_64.tgz

3. Splunkサービス停止

バージョンアップ時は各種ファイルが上書きされるため、Universal Forwarderサービスを停止させる。

# cd /opt/splunkforwarder/bin/
# ./splunk status
splunkd is running (PID: 6480).
splunk helpers are running (PIDs: 6489).

# ./splunk stop
Stopping splunkd...
Shutting down.  Please wait, as this may take a few minutes.
                                                           [  OK  ]
Stopping splunk helpers...
                                                           [  OK  ]
Done.
# ./splunk status
splunkd is not running.

4. ファイルを上書きしてインストール

以下コマンドにて、Universal Forwarderのインストールディレクトリに対して、最新のUniversal Forwarderのファイルを解凍して上書きインストールを行う。

# tar xvzf /tmp/splunkforwarder-8.1.2-545206cc9f70-Linux-x86_64.tgz -C /opt

5. Universal Forwarderを起動

初回起動時はライセンス同意とバージョンアップ前の変更内容確認が求められる。どちらも「y」を入力することでバージョンアップが実行される。

# ./splunk start
~(省略)~

SPLUNK GENERAL TERMS (v1.2020)


Do you agree with this license? [y/n]: y ←★「y」を入力

This appears to be an upgrade of Splunk.
--------------------------------------------------------------------------------)

Splunk has detected an older version of Splunk installed on this machine. To
finish upgrading to the new version, Splunk's installer will automatically
update and alter your current configuration files. Deprecated configuration
files will be renamed with a .deprecated extension.

You can choose to preview the changes that will be made to your configuration
files before proceeding with the migration and upgrade:

If you want to migrate and upgrade without previewing the changes that will be
made to your existing configuration files, choose 'y'.
If you want to see what changes will be made before you proceed with the
upgrade, choose 'n'.


Perform migration and upgrade without previewing configuration changes? [y/n] y
 ↑★「y」を入力
-- Migration information is being logged to '/opt/splunkforwarder/var/log/splunk/migration.log.2021-03-03.07-16-52' --

~(省略)~

All preliminary checks passed.

Starting splunk server daemon (splunkd)...
Done
                                                           [  OK  ]

バージョンアップ後のバージョンを念のため確認しておく。

# ./splunk version
Splunk Universal Forwarder 8.1.2 (build 545206cc9f70)

なお、ライセンス同意やバージョンアップ確認の「y」を選択する作業が面倒な場合は、以下のようにオプションを付与することで、手順をスキップすることができる。

# #ライセンス同意、変更内容確認のみ
# ./splunk start --accept-license --answer-no

# #ライセンス同意、バージョンアップ実施
# ./splunk start --accept-license --answer-yes

6. Splunkにてログが受信できていることを確認

最後にバージョンアップ後にSplunk上でログが受信できていることを検索して確認する。以下の通り、バージョンアップ以降もログ受信ができていることを確認できた。

以上でSplunk本体と同様に、Universal Forwarderのバージョンアップ作業もあっさりと完了となる。

参考

2021年3月4日木曜日

Splunkバージョンアップ手順① (Splunk本体のバージョンアップ)

以前Splunk及びSplunk Universal Forwarderのインストール手順を以下に記載した。

上記記事の中で、Splunkはtgz形式のインストーラの中に必要なモジュールや実行ファイルがすべて含まれており、tgzファイルを所定のディレクトリに解凍するだけでインストールがすぐに完了することを述べた。

さて、Splunkの各バージョンは、リリース後24か月でサポート終了となるライフサイクルポリシーとなっている。

2021年3月現在、サポート中のバージョンは7.2以降となっており、2021年内に7.2、7.3、8.0がサポート終了となるため、該当バージョンを使っている場合はバージョンアップが必要となる。

バージョン サポート期限
7.2 2021/4/30
7.3 2021/6/4
8.0 2021/10/22
8.1 2022/10/19

前回導入したバージョンは8.0.5であり、2021年内にサポート期限を迎えることから、最新の8.1.2にバージョンアップをすることにした。

本記事では2回に分けて①Splunkのバージョンアップ手順と②Universal Forwarderのバージョンアップ手順を記載する。なお、バージョンアップはインストール手順とほぼ同様であり、新しいバージョンのtgzファイルをSplunkのインストールディレクトリに展開するだけですぐに完了することを確認した。

★Splunk Universal Forwarderのバージョンアップ手順はこちら↓

環境

  • OS : CentOS 7
  • Splunk : 8.0.5から8.1.2へのバージョンアップ
  • Splunk Universal Forwarder : 8.0.5 ※本体バージョンアップ後にバージョンアップ実施
  • Splunkインストール方法 : tgzファイルを/optに展開

Splunkバージョンアップ手順

Splunk本体とUniversal Forwarderが存在する場合は、まずSplunk本体 (Indexer) をバージョンアップする。Splunk本体がバージョンアップしたとしても、よほどバージョンが離れていなければ、Universal Forwarderとの互換性が保たれている。互換性の詳細は以下URLにて記載されているが、たとえば本体 (Indexer) が8.xのバージョンであれば、7.x以降のUniversal Forwarderであれば問題なく受信が可能となっている。

1. Splunkのインストールファイルをダウンロード

インストーラは以下URLからダウンロードできる。無料トライアル版もFree版も同じものがダウンロードできる。ダウンロードするためにはSplunkサイトのユーザ登録が必要となるので注意

今回ダウンロードしたファイル名はsplunk-8.1.2-545206cc9f70-Linux-x86_64.tgzとなる。

2. サーバのバックアップを取得

万が一インストールに失敗した場合を想定して、サーバのバックアップを取得する。仮想マシンで構成されている場合は、仮想マシンのスナップショットを取得する。物理サーバの場合は、バックアップソフトなどを利用してバックアップをすること。

3. インストールファイルをサーバへアップロード

Tera Termなどのscp機能を使用して、Splunkのインストールファイルをアップロードする。

今回は/tmpにファイルを配置した。

# ls -l /tmp/splunk-8.1.2-545206cc9f70-Linux-x86_64.tgz
-rw-r--r--. 1 root root 511782642  3月  3 05:59 /tmp/splunk-8.1.2-545206cc9f70-Linux-x86_64.tgz

4. Splunkサービス停止

バージョンアップ時は各種ファイルが上書きされるため、Splunkサービスを停止させる。

# cd /opt/splunk/bin/
# ./splunk status
splunkd is running (PID: 1640).
splunk helpers are running (PIDs: 1642 1659 1795 1857).

# ./splunk stop
Stopping splunkd...
Shutting down.  Please wait, as this may take a few minutes.
..                                                         [  OK  ]
Stopping splunk helpers...
                                                           [  OK  ]
Done.
# ./splunk status
splunkd is not running.

5. ファイルを上書きしてインストール

以下コマンドにて、Splunkのインストールディレクトリに対して、最新のSplunkファイルを解凍して上書きインストールを行う。

# tar xvzf /tmp/splunk-8.1.2-545206cc9f70-Linux-x86_64.tgz -C /opt

6. Splunkを起動

初回起動時はライセンス同意とバージョンアップ前の変更内容確認が求められる。どちらも「y」を入力することでバージョンアップが実行される。

# ./splunk start

SPLUNK GENERAL TERMS

Last updated: February 13, 2020

These Splunk General Terms ("General Terms") between
Splunk Inc., a Delaware corporation, with its principal place
of business at 270 Brannan Street, San Francisco,
California 94107, U.S.A ("Splunk" or "we" or "us" or "our")
and you ("Customer" or "you" or "your") apply to the
purchase of licenses and subscriptions for Splunk's
Offerings. By clicking on the appropriate button, or by
downloading, installing, accessing or using the Offerings,
you agree to these General Terms. If you are entering into
these General Terms on behalf of Customer, you represent
that you have the authority to bind Customer. If you do not
agree to these General Terms, or if you are not authorized
to accept the General Terms on behalf of the Customer, do
not download, install, access, or use any of the Offerings.

See the General Terms Definitions Exhibit attached for
definitions of capitalized terms not defined herein.

1. License Rights

~(省略)~

Do you agree with this license? [y/n]: y ←★「y」を入力

This appears to be an upgrade of Splunk.
--------------------------------------------------------------------------------)

Splunk has detected an older version of Splunk installed on this machine. To
finish upgrading to the new version, Splunk's installer will automatically
update and alter your current configuration files. Deprecated configuration
files will be renamed with a .deprecated extension.

You can choose to preview the changes that will be made to your configuration
files before proceeding with the migration and upgrade:

If you want to migrate and upgrade without previewing the changes that will be
made to your existing configuration files, choose 'y'.
If you want to see what changes will be made before you proceed with the
upgrade, choose 'n'.


Perform migration and upgrade without previewing configuration changes? [y/n] y
 ↑★「y」を入力

-- Migration information is being logged to '/opt/splunk/var/log/splunk/migration.log.2021-03-03.06-20-15' --

~(省略)~

Waiting for web server at http://127.0.0.1:8000 to be available.. Done


If you get stuck, we're here to help.
Look for answers here: http://docs.splunk.com

The Splunk web interface is at http://t1071splk:8000

バージョンアップ後のバージョンを念のため確認しておく。

# ./splunk version
Splunk 8.1.2 (build 545206cc9f70)

なお、ライセンス同意やバージョンアップ確認の「y」を選択する作業が面倒な場合は、以下のようにオプションを付与することで、手順をスキップすることができる。

# #ライセンス同意、変更内容確認のみ
# ./splunk start --accept-license --answer-no

# #ライセンス同意、バージョンアップ実施
# ./splunk start --accept-license --answer-yes

7. 管理Web画面へのアクセスと動作確認

Splunkの管理Web画面 (http://<インストールしたホスト名 or IPアドレス>:8000) にアクセスしログインを行う。管理Web画面からもSplunkのバージョン確認をしたところ問題なく8.1.2になっていることを確認できた。

また、ログのサーチもバージョンアップ以降も問題なく実施できることが確認できた。

以上でSplunkのバージョンアップ作業はあっさりと完了となる。バージョンアップ完了後は、事前に取得したスナップショットやバックアップを削除しておこう。

2021年3月2日火曜日

Dockerのコンテナ停止時にExit 137になる問題を解消する

現在、自宅環境には以下のコンテナを起動させて運用をしている。

  • プロキシ用コンテナ : Squid
  • DNS用コンテナ : Unbound
  • メール用コンテナ : Postfix

この中でSquidとPostfixにおいて、docker stopdocker-compose stopなどで停止処理した際に、停止はするもののExit 137というExitコードになる事象が発生した
※以下★箇所。

# docker-compose stop
Stopping centos-postfix ... done
Stopping centos-unbound ... done
Stopping centos-squid   ... done

# docker-compose ps
     Name                   Command                State     Ports
------------------------------------------------------------------
centos-postfix   /startup.sh                      Exit 137 ←★
centos-squid     /bin/sh -c /usr/sbin/squid ...   Exit 137 ←★
centos-unbound   /usr/sbin/unbound -d             Exit 0  

調べたところ、SquidとPostfixのコンテナで、それぞれExit 137となる原因が違っていた。

今回は、Docker停止時にExit 137になる原因の説明と解消方法を記載する。

環境

  • DockerホストOS : CentOS 8.2
  • Docer : 19.03.14
  • Docker Compose : 1.27.4

Dockerのコンテナ停止時にExit 137になる理由

そもそもコンテナがExit 137で停止する理由について記載する。

Dockerのデフォルト設定ではコンテナ停止を行う際に、まずPID 1のプロセスに対してSIGTERMのシグナルを送信しプロセス終了を促す。Dockerは10秒待機し、それでもプロセスが終了しない場合は、SIGKILLシグナルにて強制終了を行う。

Exit 137SIGKILLによるプロセスの終了を実施した際に出力されるExitコードとなる。

SquidコンテナのExit 137の原因と解消方法

SquidのコンテナがExit 137となる理由は、Squidのキャッシュをディスクに書き込みするための待機時間としてデフォルトで30秒待機してから停止が完了するためである。Dockerは10秒でSIGKILLにて強制終了をしてしまうため、通常のSIGTERMによる停止処理が間に合わない。

そのため、解消方法としては、Docker側のコンテナ停止処理時のタイムアウトを30秒より多い時間に延長するか、Squid側の待機時間を10秒未満とするか、どちらかの手法で対応できる。今回は後者にて対応する。

Squidの停止処理の待機時間は、shutdown_lifetimeというパラメータで設定できるので、デフォルトの30秒から5秒に変更する。
※参考:squid : shutdown_lifetime configuration directive

具体的にはsquid.confに以下を追加すればよい。

shutdown_lifetime 5 seconds

設定変更した内容でコンテナを再作成し、docker stopコマンドでコンテナを停止してみたところ、以下の通り、Exit 0で正常に停止できていることがわかる。

# docker stop centos-squid
centos-squid

# docker ps -a
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                     PORTS                                          NAMES
bb34a12ed7bc        centos-squid:1      "/usr/sbin/squid -N …"   13 hours ago        Exited (0) 5 seconds ago                                                  centos-squid

PostfixコンテナのExit 137の原因と解消方法

Postfixのコンテナでは、maillogにメール送受信のログを出力させるためにrsyslogを起動させている。この際に、以下のようなstartup.shというラッパースクリプトを作成して、rsyslogとPostfixの起動を実現していた。

#!/bin/bash

/usr/sbin/rsyslogd
/usr/sbin/postfix start-fg

上記スクリプトでプロセスを起動した際のコンテナにおけるpsの結果を以下に記載する。Postfixの一部プロセスのPID/PPIDが1以外の番号で動作していることがわかる。

# ps -ef
UID          PID    PPID  C STIME TTY          TIME CMD
root           1       0  0 05:46 ?        00:00:00 /bin/bash /startup.sh
root           7       1  0 05:46 ?        00:00:00 /usr/sbin/rsyslogd
root           9       1  0 05:46 ?        00:00:00 /bin/sh /usr/libexec/postfix
root          76       9  0 05:46 ?        00:00:00 /usr/libexec/postfix/master
postfix       77      76  0 05:46 ?        00:00:00 pickup -l -t unix -u
postfix       78      76  0 05:46 ?        00:00:00 qmgr -l -t unix -u
postfix       79      76  0 05:46 ?        00:00:00 smtpd -n smtp -t inet -u -o
postfix       81      76  0 05:46 ?        00:00:00 tlsmgr -l -t unix -u
root          85       0  5 05:52 pts/0    00:00:00 bash
root          98      85  0 05:52 pts/0    00:00:00 ps -ef

前述したとおり、Dockerは、PID 1のプロセスに対してSIGTERMのシグナルを送信するが、PID/PPIDが1以外のプロセスが存在することにより停止処理が失敗することが、Exit 137となる原因となる。

本事象を解消させるために、ラッパースクリプトのPostfixの起動コマンドにexecを付与することで解消する (★箇所)。execコマンドを使うことで、すべてのプロセスが、もとのラッパースクリプトと同じPID/PPID、すなわちPID/PPIDが1で動作するようになる。

#!/bin/bash

/usr/sbin/rsyslogd
exec /usr/sbin/postfix start-fg ★

実際にコンテナでpsを実行した結果は以下の通りとなる。Postfix関連のプロセスはすべてPID/PPIDが1となっている。

# ps -ef
UID          PID    PPID  C STIME TTY          TIME CMD
root           1       0  0 05:51 ?        00:00:00 /usr/libexec/postfix/master
root           8       1  0 05:51 ?        00:00:00 /usr/sbin/rsyslogd
postfix       76       1  0 05:51 ?        00:00:00 pickup -l -t unix -u
postfix       77       1  0 05:51 ?        00:00:00 qmgr -l -t unix -u
postfix       78       1  0 05:51 ?        00:00:00 smtpd -n smtp -t inet -u -o
postfix       79       1  0 05:51 ?        00:00:00 proxymap -t unix -u
postfix       80       1  0 05:51 ?        00:00:00 tlsmgr -l -t unix -u
root          81       0  4 05:52 pts/0    00:00:00 bash
root          95      81  0 05:52 pts/0    00:00:00 ps -ef

設定変更した内容でコンテナを再作成し、docker stopコマンドでコンテナを停止してみたところ、以下の通り、Exit 0で正常に停止できていることがわかる。

# docker stop centos-postfix
centos-postfix

# docker ps -a
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                     PORTS                                          NAMES
f4050d7cdc6d        centos-postfix:1    "/startup.sh"            3 minutes ago       Exited (0) 3 seconds ago                                                  centos-postfix

参考

人気の投稿