朝から昼寝

ITや家計、身近なことの整理

[お知らせ]
当サイトは、2024年1月1日に
新URL(happynap.net)に引っ越しました





このページの内容は、最新ではない場合がありますので、新URLをご確認ください。






当サイトには広告を含みます。"オススメ"として紹介している商品やサービスは、個人的にそう思えたものだけです。
共感、興味をもっていただけるものがあればご利用ください (広告掲載ポリシー)。

Excelのデフォルト日付形式をYYYY-MM-DDにする(ISO8601)

ツール、スクリプト Windows 標準、規格、仕様 [IT]

概要

身の回りの資料に記載する日付を、なるべくISO8601に沿って"YYYY-MM-DD"に統一しておこうと思い、調べていたときのことです(参考：Wikipedia)。よく使うツールの1つであるExcelでは、デフォルトの日付の表示形式が"YYYY/MM/DD"(月や日の0埋め無し)であり、これを"YYYY-MM-DD"に修正するには少し変わった工夫が必要でした。
本記事は、日本語環境のWindows上で使用するExcelのデフォルト日付形式を"YYYY-MM-DD"にする方法について記載します。環境は、日本語版Windows 10上のExcel 2016/2019ですが、以降のバージョンでも同様の動作になると思われます。Webブラウザ版Excelは対象外になるかもしれません。
なお、ISO8601は、日付だけでなく時刻の表示形式も定めていますが、本記事では日付について記載します。時刻についての設定方法が分からないので解決方法を知りたいです。

本記事の目的

  • Excelで日付データを扱う際、デフォルトの表示形式を"YYYY-MM-DD"にする。


目次

基本

今回、「Excelで日付データを入力時、セルの書式設定を変更しなくても表示形式が"YYYY-MM-DD"になる方法」という観点で調べました。

YYYY-MM-DDの表示形式
YYYY-MM-DD形式

例えば、Excelではキー操作Ctrl + ;により、その日の日付を入力することができます。このCtrl + ;と確定のEnterだけで、"YYYY-MM-DD"の形式で日付入力したいということです。日付データを入力したセルの書式設定からユーザー定義にて"yyyy-mm-dd"という形式に修正すれば、個々のセルの表示形式を変更できますが、それは非効率です。

色々調べた結果、本記事で説明する設定方法は、以下の通りです。
※この方法を採用するに至った経緯は後述します。

Windows OSの地域設定の変更 ＋ データ形式を変更する

注意点として、この設定を行った際の影響については後述します。気になる方は合わせてご確認ください。

OS設定の地域画面のうち、地域設定(Regional format)のみを"英語"にした上で、日付や時刻に関するデータ形式を変更するの設定を行うと、デフォルトの表示形式を"YYYY-MM-DD"にでき、0埋めもされるようになります。
※国または地域(Region)は日本のままで大丈夫です。基本的には日付と時刻の表示形式のみを、英語にするということです。 ※また、OS設定である地域設定(Regional format)を変更しないといけなかった理由についても、後述します。

手順を記載します。

1.　最初に、OS設定の言語画面で、"英語"を追加しておきます。追加された言語は、地域設定で選択できるようになります。

"言語"の追加
"言語"の追加

"言語"を追加時のダウンロード
"言語"を追加時のダウンロード

"言語"の追加が完了
"言語"の追加が完了

2.　次に、OS設定の地域画面のうち、地域設定(Regional format)のみを"英語(米国)"にします。(試していませんがおそらく米国以外の英語でも変わらない気がします)

"地域設定"の変更
"地域設定"の変更

3.　最後に、地域画面のデータ形式を変更するで"YYYY-MM-DD"の形式を選択します。

Excelのデフォルトの時刻や日付の表示形式は、WindowsのOS設定が引き継がれます。
下記の画像にある設定箇所です。

設定 -> 時刻と言語 -> 地域
設定 -> 時刻と言語 -> 地域

"データ形式を変更する"画面(英語)
"データ形式を変更する"画面(英語)

4.　以上の設定により、Excel上の日付のデフォルト表示形式が"YYYY-MM-DD"になります。日付データを入力した際に、都度データ形式を変更する必要性はありません。

Excel上の日付のデフォルト表示形式が"YYYY-MM-DD"に
Excelの日付のデフォルト表示形式が"YYYY-MM-DD"に

詳細

地域設定を"英語"に変更する影響

地域設定(Regional format)のみを"英語"にした場合、日付、時刻の表示形式が変わります。
※後日追記：この他、少なくともExcel内では、通貨の表示形式の記号が"￥"でなく"$"になったり、印刷設定の余白がセンチ表記からインチ表記に変わったりもします。

もちろん表示形式が変わると困る方にはお勧めできませんが、実際には日付の曜日表記が英語に変わるくらいで(月曜日→Monday等)、残りは数字データなので変わりません。あとは午前/午後がAM/PMに変わったりします。こういった差異に抵抗が無ければ、大丈夫かと思います。
※後日追記：同じく、少なくともExcel内では、上記のように通貨や印刷設定にも若干影響が出ます。私はあまり困らないので、そのままにしています。

その他、マイナーな影響としては、アプリケーションによっては表示言語の切り替えが、OS設定の国または地域(Region)でなく、地域設定(Regional format)に連動してしまうものもあるようです(これは、そのアプリの方が修正されて欲しいです)。
例えば、"7-Zip"というアプリでは、地域設定(Regional format)が"英語"の場合に、表示言語が英語になるようです(これは、7-Zip内の言語設定を手動で日本語にすることで元に戻せます)。
※後日追記：さらにマイナーな影響として、"筆王"という年賀状ソフトで文字化けや、そのデータ移行機能でエラーが出たりします。データ移行機能の方は、いったん地域設定(Regional format)を"日本語"に戻さないとエラー回避できませんでした。

このように、従来に比べ動作が多少変わることがありますが、普段の業務で多少英語に慣れている方であれば問題無い範囲かと思います。
※後日追記：他にも影響が出ても、乗り切れそうだという方には大丈夫かと思います。

やはりMicrosoft製品として、不便なく日本語環境向けにISO8601対応して欲しいですね…。

(補足)時刻のAM/PM表示を24時間表示にする

本記事の方法に沿って地域設定(Regional format)を"英語"にすると、時刻の表示形式が"HH:MM AM or PM"になります。タスクバーの時計部分に表示される時刻です。
これを24時間表示のHH:MM(0埋めあり)に変更する手順を記載します。ただし、この設定は、残念ながらExcelで時刻を入力した際のデフォルトの表示形式には反映されません(解決策ががあったら知りたいです)。

1.　OS設定の地域画面で"日付、時刻、地域の追加設定"を選択します。

日付、時刻、地域の追加設定
日付、時刻、地域の追加設定

2.　時計と地域画面で"日付、時刻、数値形式の変更"を選択します。

日付、時刻、数値形式の変更
日付、時刻、数値形式の変更

3.　地域画面で"追加の設定"ボタンを選択します。

"追加の設定"ボタン
"追加の設定"ボタン

4.　形式のカスタマイズ画面の時刻タブにて、時刻(短い形式)が"h:mm tt"になっているので、これを"HH:mm"に変更します。

"時刻(短い形式)"の変更
"時刻(短い形式)"の変更

この設定により、タスクバーに表示される時刻がHH:MM(0埋めあり)の形式になります。

書式は、画像にある"表記の意味"の通りです。

  • "h"を"HH"に変更：12時間表示を24時間表示(0埋めあり)に変更
  • "tt"を削除：午前または午後を削除

書式の詳細については後述します。

5.　(参考)形式のカスタマイズ画面の日付タブでは、日付の短い形式が"yyyy-MM-dd"になっていることが確認できます。

日付の"短い形式"
日付の"短い形式"

補足として、"yyyy-MM-dd"のように小文字と大文字が混ざった書式になっています。 この書式の詳細については後述します。

Windows OSのカスタム日時形式文字列の書式

形式のカスタマイズ画面で指定できる書式は、Microsoftのdocs、カスタム日時形式文字列に説明があります。

.Netのdocsですが、"yyyy-MM-dd"のように小文字と大文字が混ざった書式についての仕様を確認できます。

Excelのデフォルト表示形式を変更する方法の選択肢

前述の設定方法を採用するに至った経緯を記載します。

調べてみたところ、Excelのデフォルト表示形式を変更するには、以下のような設定方法があります。

  • Excelのテンプレートの利用 (不採用)
  • Windows OSのデータ形式を変更する (惜しいけど不採用)
  • Windows OSの地域設定の変更 ＋ データ形式を変更する　(本記事で紹介した内容)

順に説明します。

Excelのテンプレートの利用 (不採用)

目的の表示形式等を設定したExcelファイルをテンプレートとして保存し、それをもとにブックを作成する方法です。
テンプレートによる書式設定は、そのテンプレートをもとに新規作成するExcelファイルにしか適用できないため、これは不採用です。

Windows OSのデータ形式を変更する (惜しいけど不採用)

Excelのデフォルトの時刻や日付の表示形式は、WindowsのOS設定が引き継がれます。
下記の画像にある設定箇所です。

設定 -> 時刻と言語 -> 地域
設定 -> 時刻と言語 -> 地域
"データ形式を変更する"画面
"データ形式を変更する"画面

上記の日付(短い形式)で指定した形式が、Excelで日付データを入力したときのデフォルトの表示形式になります。
しかし、この設定を上記のように"yyyy-MM-dd"に変更しても、Excel上ではなぜか月や日の0埋めがされません。つまり、8月は"08"でなく"8"が、2日は"02"でなく"2"が表示されてしまいます。

08でなく8に、02でなく2になる
08でなく8に、02でなく2になる

このように、OS側で指定した日付(短い形式)のMMやddが、Excelの短い日付形式に反映される際、0が消えてしまいます。
一方で、OS側で指定した日付(長い形式)の方でMMやddを指定すると、Excelの長い日付形式に反映される際、0は消えないようです。
しかし、Excelの日付データはデフォルトで短い日付形式で表示されるので、やはり短い日付形式がうまく反映されるようにしたいです。

この、月や日が0埋めされない事象は、Windows OS側の地域設定(Regional format)が"英語"以外の場合に発生するようです。
Excelのローカライズに関する仕様かと思われます(不思議な動作ですが、Microsoft製品のこの手の動作は修正されないでしょう…)。

この動作を踏まえて検討した設定方法が次です。

Windows OSの地域設定の変更 ＋ データ形式を変更する

OS設定の変更は避けたかったですが、月や日が0埋めされない事象を回避するため、やむを得ず採用しました。 設定手順は前述の通りです。

参考URL等

仮想ディスクの未使用領域が解放される仕組み

運用管理 仮想基盤 [IT]

概要

仮想環境のストレージ空き容量を管理する上で、未使用領域の解放に関する各レイヤの仕様を理解しておくことは重要です。

本記事は、ゲストOS上で削除したファイルの容量分、ストレージの空き容量が確保されるまでの仕組みをとめたものです。対象は主にシンプロビジョニング(スパース)が有効なストレージ環境を使用するVMware vSphere 6系や7系以降ですが、仕組みは他の仮想環境でも同様です。

なお本記事では、圧縮機能や重複排除機能等、またストレージ自体やバックアップの設計については触れていませんが、それらを考慮する上でも本記事の内容は基礎的な要素の一つです。

注記

本記事では、ゲストOSが未使用領域をゼロクリアする方式について言及していますが、近年の環境は基本的にUNMAPやTRIMがサポートされているので、未使用領域を解放するという目的においてはOS側でゼロクリアを実行する必要性はありません。

本記事の内容は、ゼロクリアに言及しているため、少し古い実装についての説明ということになります。ただし、仮想環境におけるストレージレイヤというものの基本的な概念自体は変わっておらず、また古い実装についての記事があること自体は問題ではないので、改変せずそのままにしておきます。

よって、本記事のゼロクリア部分は、環境に応じ適宜UNMAPやTRIMに読み替えていただけたらと思います。

機会があればUNMAPやTRIMについては別記事にまとめます。

本記事の目的

  • ゲストOS側でディスク使用量を削減した際に、ストレージの空き容量が確保されるまでの仕組みを把握する。

基本

おおまかな理解

仮想環境において、特に高集約化を図る場合、ストレージ利用効率を高めるためシンプロビジョニング機能が使用されることが多いです。
ただし、仮想マシンに割り当てたディスク容量の合計が、ストレージの物理容量を超える設計(オーバーコミット)になることもあるため、ストレージ空き容量を適切に管理することは重要です。

仮想環境では、主に以下の2か所でシンプロビジョニング機能が使用されます。

  • シンプロビジョニング(スパースファイル)が有効な仮想ディスク(仮想基盤のレイヤ)
  • シンプロビジョニングが有効なストレージボリューム(仮想基盤が使用するストレージのレイヤ)

本記事では、上記環境における下記動作の仕組みについて記載します。

  • ゲストOS上で不要ファイルを削除し、(ゲストOSから見て)ディスク空き容量を十分に確保したのに、仮想基盤上で仮想ディスクのサイズが小さくならない。
  • ゲストOS上で不要ファイルの削除後、仮想ディスクのサイズを小さくしたい場合には、ゲストOS上で未使用領域のゼロクリアを行ってから、仮想基盤上で未使用領域の解放(vSphereの場合はpunchzero)を行う必要性がある。
  • 最近のVMFS(6以降)では、未使用になった領域に対するストレージボリューム上の割り当てを自動的に解放(マッピング解除)し、ストレージボリューム上の空き領域を確保してくれる。

これらの仕組みは、長期間に渡ってディスクの書き込みと削除が繰り返し行われるシンプロビジョニング環境では把握しておいた方が良いものです。

ゲストOS上で不要ファイルを削除したのに、仮想ディスクのサイズが小さくならない

まず、なぜゲストOS上で不要ファイルを削除しただけでは仮想ディスクのサイズが小さくならず、ストレージの空き容量を確保できないのかについて記載します。

シンプロビジョニングが有効な仮想環境におけるファイル削除
シンプロビジョニングが有効な仮想環境におけるファイル削除

  • (図中の左) ゲストOS上でファイルを削除した場合、そのインデックス情報が削除されるだけで、ファイルのデータは通常残ります。別の言い方では、ゲストOSが使用するファイルシステム(WindowsであればNTFS等)のメタデータにおいて、そのファイルが存在しないものとして扱われるようになるだけで、ディスクに書き込まれたデータ自体は削除されません。
  • (図中の中央) このままでは、VMFS(仮想基盤のファイルシステム)上は、そのゲストOSの仮想ディスクサイズが小さくなることはありません。仮想基盤としては、ファイルを削除したことも、それによって空き領域を増やせることも検知できないためです。
  • (図中の右) ストレージ側のボリュームがシンプロビジョニング対応であったとしても、VMFS上で仮想ディスクのサイズが小さくならないのであれば、その使用量が削減されることはありません。

ゲストOS上でのゼロクリアと、仮想基盤上での未使用領域の解放により空き容量を確保可能

シンプロビジョニングが有効な仮想環境における空き容量確保
シンプロビジョニングが有効な仮想環境における空き容量確保

  1. ゲストOS上で削除されてもディスクに残ったままになっているファイルのデータを削除する方法は、ゼロクリア(0埋め)です。WindowsのSDeleteコマンド、Linux/Unixではddコマンドによりゼロクリアが可能です(後述)。
    ゼロクリアにより、対象ファイルシステムの未使用領域全てに0が書き込まれます。0を書き込んでも、あくまで未使用領域は未使用のままなので、ゼロクリアの前後で基本的にファイルシステムの使用量は変化しません(ゼロクリア処理中は一時的に使用量が増える場合があります(細かい話なのでこれも後述))。
  2. ゼロクリアが実行された仮想ディスクに対し、仮想基盤上でpunchzero (vmkfstools -Kコマンド)を実行することにより、その仮想ディスクの容量を小さくすることができます。仮想ディスク容量のうち、ゼロクリアされた領域(未使用領域)分の容量は削減され、それ以外の使用済み領域分の容量のみが残ります。仮想ディスクの容量が小さくなった分、VMFS上の空き領域が増えます。
    このような仮想ディスクのゼロクリア領域を解放する方法は、仮想環境ごとに異なります。vSphereの場合はvmkfstools -Kコマンドですが、Hyper-Vの場合はOptimize-VHDコマンドレット、VirtualBoxの場合はvboxmanage modifyhd [UUID] --compactコマンドがあります。
    この他に、Storage vMotionにより同様にゼロクリア領域を解放できる場合がありますが、条件等の詳細はVMware社のdocsに記載があります。
    ゼロクリア以外に、TRIMやUNMAPといった処理もありますが、本記事では記載していません。
  3. VMFSの空き領域が増えると、(VMFS6以降の場合は)自動的にストレージ側でもその分の容量が解放されるよう処理され、ストレージ上のボリュームの空き領域が増えます。
    この処理はストレージに対するSCSI UNMAP(マッピング解除)やReclaim(再クレーム、レクラメーション)と呼ばれ、VMFS6未満の場合はesxcli storage vmfs unmapコマンドにより手動実行する必要性がありましたが、VMFS6から自動的に実行されるようになりました。詳細はVMware社のdocsに説明があります。この処理は、ストレージ側のボリュームにおいてシンプロビジョニングが有効であり、マッピング解除操作をサポートしている場合に実行可能です。

上記のように、未使用領域の解放に関する各レイヤの仕様を理解することで、VMのディスク使用量を削減した際にストレージの空き容量が確保されるまでの仕組みを把握できます。

詳細

SDelete、ddによるゼロクリア

ゲストOS上で以下のコマンドを実行することで、未使用領域のゼロクリアが可能です。
これらのコマンドの実行時には、一時的にファイルシステムの空き容量が枯渇するため、重要なデータの書き込みエラーによるデータロス等が発生しないよう、必要に応じサービス停止して実行することをお勧めします。

WindowsでCドライブの未使用領域をゼロクリアする場合、以下のコマンドを実行します。

> SDelete -z C:

SDeleteコマンドは以下ページから入手できます。
- MicrosoftのSDelete配布ページ
仕組みは、上記URLの解説を理解しきれてはいないので一部推測になりますが、指定したドライブの空き領域と同じだけのサイズのファイルを作成(おそらくゼロ書き込み)し、その後それを削除するものと思われます。未使用領域を直接操作することは難しいので、そのような仕組みになると考えられます。

Linuxで/(ルート)パーティションの未使用領域をゼロクリアする場合、以下のコマンドを実行します。

# dd if=/dev/zero of=/zerofile; rm -f /zerofile

/dev/zeroの内容(0)を任意のファイル(/zefofile)に書き出した後、空き容量が無くなり次第ddコマンドがエラーで終了します。その後すぐにrmコマンドで作成したファイルを削除するというものです。

まとめ

仮想環境におけるレイヤごとの容量の消費と解放に関する基本的な仕組みについてまとめてみました。

ゼロクリア以外に、TRIM(fstrim等)やUNMAPといった処理もあるので、機会があれば別記事にまとめたいと思います。

ZabbixでMQTTのデータを監視

IoT 運用管理 [IT]

概要

IoT機器等で使用されるPub/Sub型プロトコル、MQTT。監視ソフトウェアとして広く使用されているZabbixでもMQTT経由で取得したデータを監視できます。
本記事は、ZabbixでMQTTのデータを監視する方法をまとめたものです。対象は主にZabbix 6系＋Zabbixエージェント2です。OSはRHEL8系ですが他のバージョンでも同様のはずです。
参考として、MQTTブローカーのMosquitto導入についてこちらの記事に、また簡単にセットアップできるZabbix Applianceの導入についてこちらの記事にまとめてあります。

本記事の目的

  • Zabbixにおいて、MQTTで取得したデータを監視する。


目次

基本

ZabbixによるMQTT監視方法

Zabbix.comに、ZabbixのMQTT対応方法について説明があります。

  • Zabbix Agent 2のMQTT plugin (本記事の対象)
  • 3rd Party Solutions (Agent、個別スクリプト等)

Zabbixの標準機能で対応できるのは、MQTT Plugin(Zabbix Agent 2)です。Zabbix Agent (2ではない方)ではありません。

Zabbix Agent 2の導入

別途Zabbixサーバは導入済みであるものとします。

Zabbix Agent 2は、Zabbixサーバと同じサーバでも、別サーバでも、どちらにインストールしても大丈夫です。
なお、Zabbix Agent 2を動作させるサーバは、目的のMQTTブローカーに対して通信できる必要性があります。Agent 2の機能でMQTTブローカーに対しSubscribeするためです。

Zabbix Agent 2のインストール

以下のZabbixマニュアルを参考に、Zabbix Agent 2を導入します。

Zabbixダウンロードとインストール方法の説明ページを参考に、dnfによるパッケージインストールが可能です。

以下、インストール時のコマンド例です。
# rpm -Uvh https://repo.zabbix.com/zabbix/6.0/rhel/8/x86_64/zabbix-release-6.0-1.el8.noarch.rpm
# dnf install zabbix-agent2.x86_64

Zabbixのリポジトリを登録し、Agent 2のみをインストールしています。

Zabbix Agent 2の初期設定

インストール後、Agent 2の設定ファイルを編集します。
# cp -p /etc/zabbix/zabbix_agent2.conf /etc/zabbix/zabbix_agent2.conf.org
# vi /etc/zabbix/zabbix_agent2.conf
以下の行を編集します。

…
Server=(ZabbixサーバのFQDN/IPアドレス)
…
ServerActive=(ZabbixサーバのFQDN/IPアドレス)
…
Hostname=(後でZabbixサーバで監視対象を指定する際のHostnameと同じ文字列)  
…
  • MQTT Pluginのみを使用する場合、RefreshActiveChecksの設定は不要でした。
  • 別途、/etc/zabbix/zabbix_agent2.d/plugins.d/mqtt.confという設定ファイルがありますが、これは基本的に修正不要です。本記事の作成時点で、Plugins.MQTT.Timeoutというタイムアウト値のオプションが指定できるのみです。

次に、サービス設定をします。(ちなみに、マニュアルに"Agent 2 does not have built-in daemonization support on Linux; it can be run as a Windows service."とあるのですが、以下のようにサービスの登録は可能のようなので、具体的に何ができないのか不明です)

# systemctl enable zabbix-agent2.service
Created symlink /etc/systemd/system/multi-user.target.wants/zabbix-agent2.service → /usr/lib/systemd/system/zabbix-agent2.service.

# systemctl start zabbix-agent2.service

# systemctl status zabbix-agent2.service
● zabbix-agent2.service - Zabbix Agent 2
  Loaded: loaded (/usr/lib/systemd/system/zabbix-agent2.service; enabled; vendor preset: disabled)
  Active: active (running) since Fri 2022-07-17 12:01:25 JST; 2s ago
Main PID: 12800 (zabbix_agent2)
    Tasks: 5 (limit: 23520)
  Memory: 5.6M
  CGroup: /system.slice/zabbix-agent2.service
          mq12800 /usr/sbin/zabbix_agent2 -c /etc/zabbix/zabbix_agent2.conf
…

Agent 2 を自動起動する設定と、手動でのサービス起動確認ができました。

続いて、MQTTのSubscribe等の設定は、Zabbixサーバ側の監視設定の中で行います。

Zabbixサーバにて、Agent 2からMQTTデータ取得

Zabbixサーバ側で、Agent 2からMQTTのデータを取得できるよう設定します。

ホスト、アイテムの登録

先ほどAgent 2を導入したサーバを監視対象として登録します。

まずホスト設定です。

Agent 2 ホスト登録
Agent 2 ホスト登録

  • Host Nameは、Agent 2側のzabbix_agent2.confのHostnameで指定した文字列と同じものを指定します。この文字列が一致していないと、データを取得できません。
  • Groupsの内容は任意です。
  • Interfacesは"Agent"としてAgent 2をインストールしたサーバのFQDNやIPアドレスを指定します。

次にアイテム設定です。

Agent 2 アイテム登録
Agent 2 アイテム登録

  • Nameの内容は任意です。
  • Typeは、"Zabbix agent (active)"を指定します。MQTT Pluginによる監視はActive Check用アイテムの指定が必須です。
    • Active Check用アイテムの詳細は、Zabbixマニュアルに記載されています。
    • Active Check用アイテムは、Zabbixサーバで指定した監視内容に沿って、Agent側からデータ送信するものです。なお、MQTT Pluginによる監視の場合は、Agent 2が定期的(RefreshActiveChecks)にデータ送信するのではなく、MQTTブローカーからデータを受け取った際に、都度Zabbixサーバにデータを送信するようです。
  • Keyは、取得したいMQTTのトピック等を指定します。
    • 基本的な書式：mqtt.get[tcp://(MQTTブローカーのFQDNやIPアドレス):1883,"(トピック名)"]
    • Agent 2が動作するサーバから、MQTTブローカーに対して指定のトピックをSubscribeするよう指示します。1883はMQTTの標準的なポート番号です。
    • mqtt.getキーの詳細は、Zabbixマニュアルに記載されています。ワイルドカード指定や認証、TLS等についての説明があります。
  • Type of Informationは、取得するデータの型に合わせて指定します。

以上の設定により、Zabbixサーバ側で、Agent 2からMQTTのデータを取得できるようになりました。
あとは他のデータと同じようにZabbixサーバ側で監視やグラフ化などが可能ですが、MQTT固有の手順は不要なので本記事では省略します。

参考として、Zabbixでの監視データの加工についてこちらの記事にまとめてあります。MQTT経由で受信したデータに対し、計算やJSONデータのパースなどが必要な場合に使える設定例です。

参考URL等

MQTTの運用や設計について調べてみる

運用管理 IoT 標準、規格、仕様 [IT]

概要

IoT機器等で使用されるPub/Sub型プロトコル、MQTT。運用や設計についてのノウハウが気になるところです。
本記事は、(雑記として)MQTTの運用や設計に関して調べた際のメモです。今後調べ直す機会があれば更新するかもしれません。
参考として、MQTTブローカーのMosquitto導入についてこちらの記事にまとめてあります。

本記事の目的

  • MQTTの運用や設計に関する調査状況をメモしておく。


目次

基本

MQTTの構成と実装

MQTTを使用するシステムは、MQTTクライアント(Subscriber、Publisher)と、MQTTブローカーから構成されます。
フリーソフトやライブラリ、あるいはクラウドサービスとして、多くのMQTTの通信機能(ブローカー、クライアント)の実装があります(参考)。
IoT機器やそのゲートウェイ製品としても、MQTTによる通信を想定したものが多いです。

余談ですが、監視ソフトウェアのZabbixは、Zabbix Agent 2においてMQTTのSubscriberとして動作し取得したデータをZabbixサーバに送信する機能があります(機会があれば別途記事を掲載します)。

MQTT動作状況の確認

仮に、とあるシステムがMQTTを使用して動作中であるとして、その動作状況を把握したいケースを考えてみます。

どんなMQTTクライアントがいるかの確認

どんなMQTTクライアント(Publisher、Subscriber)が動作しているのか、確認する方法について調べた範囲でメモしておきます。

  • Subscriberとしては、受信したメッセージ自体には、どのPublisherから送信されたものかの情報は無い。
    • 設計として、どのPublisherから送信されたものかを識別するための情報をメッセージに含めることは可能。
      • ただし、全MQTTクライアントの接続状況を把握したい場合は、全MQTTクライアントが必ずPublishするよう設計が必要。
    • 接続中のMQTTクライアントを管理する用のトピックを作成するといった手法も。
      • 各MQTTクライアントが接続時にトピックstatus/(クライアントID)にPublishし、管理する側はstatus/#(#はワイルドカード指定)をSubscribeしておく(参考)。
  • MQTTブローカーとしては、MQTTクライアントからクライアントID(thingId的なもの)を含むパケットを受信している。
    • MQTTブローカーの実装次第だが、基本的にはデバッグログや、少なくともネットワークトレースから通信しているクライアントIDを確認可能。
    • クライアントIDから、それがどのデバイスかを識別できるかどうかは設計次第。
      • 予めデバイスごとのクライアントIDを決めておき、その通りに各デバイスを設定しMQTT通信させる。
      • デバイスごとのユニークな値(MACアドレス等)を予め把握しておき、各デバイスがその値をもとにクライアントIDを自動生成しMQTT通信させる。
      • ただ、IoTは自律的に動作しスケールできる方が良い場面も多そうなので、このあたりは自動化しやすい方式を要考慮(何かあるだろう)。

以下のLWT機能は、MQTTクライアントを把握するための方法ではないですが補足として記載します。

  • MQTTにはLWT(Last Will And Testament)、"遺言"的な意味の機能あり。
    • MQTTブローカーは、意図しない原因でPublisherと通信できなくなった場合に、予めLWTに指定されたメッセージをSubscriberへ送信する。
    • LWT機能を使用する場合、LWTメッセージはMQTTクライアントからのCONNECTメッセージ内で指定される。
    • OASISの文書内の"3.1.3.2 Will Properties"などに記載あり("LWT"とは書かれていない)。
    • LWTの動作説明は、mqtt.orgのFAQから参照可能(HiveMQの説明ページへのリンク)。

アクティブなトピックの確認

次に、どんなトピックのやり取りがされているのか、リアルタイムで確認する方法について調べた範囲でメモしておきます。

  • MQTTとしては、アクティブなトピックの一覧を取得する方法自体は無さそう。
  • MQTTクライアントで全トピックをサブスクライブし続けることで、実質的にアクティブなトピックを可能(参考)。
    • Mosquittoでの実行例
      • mosquitto_sub.exe -h (MQTTブローカー) -t "#" -d
        • -t "#"で全トピックを指定しサブスクライブ。-dにてデバッグ表示。全トピック(#)にPUBLISHされたメッセージを受信する。
        • 上記コマンド実行時のメッセージ受信例：
          Client null received PUBLISH (d0, q0, r0, m0, 'test/Topic1', ... (77 bytes))
  • その他、ネットワークトレースの取得等。

管理用トピック($SYSなど)

MQTTの動作状況を把握に役立ちそうな、管理用トピック(トピック名が$から始まるもの)というものがあるようです。ただ、細かく標準化はされていないようで、各ブローカーの実装次第のように思われます。

以下、Mosquittoでの確認例です。

`"c:\Program Files\mosquitto\mosquitto_sub.exe" -h (MQTTブローカー) -t "$SYS/broker/clients/active"`
2

上記の例では、アクティブなクライアント数が2であることが確認できます。

詳細

MQTTのトピック設計(メモ)

いくつか参考URLを記載します。

以下、トピック設計に関するメモです。

  • トピック名は"/"で区切られた階層構造
    • 例：france/office/3F/temp、japan/factory/6F/humid
    • ある区域内のデータは1つのトピックにして、その中で細分化する等も
  • ワイルドカードサブスクリプション(#)の活用
  • 以下AWSドキュメントのベストプラクティスより引用+メモ
    • MQTT トピックレベルでは、小文字、数字、ダッシュのみ
    • MQTT 経由でデバイスとして接続するための MQTT クライアント ID として AWS IoT のモノの名前を使用する
    • MQTT メッセージのペイロードに、特定のメッセージに関する追加のコンテキスト情報を含める (場合によっては、クライアントIDをペイロードに含めても良いかも)
    • テレメトリとコマンド(温湿度情報はテレメトリ、機器の制御などはコマンド)
  • 複数データのトピックをどのようにまとめるか
    • 1トピックに複数のデータを(JSON等で)まとめて送るかどうか。
      • 温度トピック、湿度トピックのように、各データでトピックを分ける方法が基本と思われる。
      • 同時に取得されたデータをまとめてセットで送受信することが重要なデータはまとめても良いかも。
  • MQTTのトピック名の変換機能
    • そのような機能は見当たらない。以下、メモ程度。
    • 例えば、複数のセンサー(Publisher)が、同一トピックにPublishする構成の場合に、ブローカー側でPublisherごとにトピック名を変換(自動振り分け)し、Subscriberが各センサーごとにトピックを分けてデータ受信したりすることができたら便利かも。
    • 参考：トピック名の変換が可能なMQTTブリッジ(詳細は未確認、クライアントIDを埋め込むことはできなさそう)

参考URL等

Windows上で手軽にMQTTブローカーを立ち上げる(Mosquitto)

運用管理 IoT [IT]

概要

IoT機器等で使用されるPub/Sub型プロトコル、MQTT。構成上必要となるMQTTブローカーとして、Mosquittoなどがあります。
本記事は、Windows版Mosquittoを用いてMQTTブローカーを立ち上げる方法について記載します。環境は、Mosquitto 2.0.14をWindows 10上で動作させたものです。おそらくLinux版でも大きな違いは無いと思います。

本記事の目的

  • MQTTブローカーとしてMosquittoをインストールし、動作させる。
  • 簡単な構成変更や、WebSocket設定、デバッグログ設定の方法を把握する。


目次

基本

インストール

mosquitto.orgからWindows版インストーラをダウンロードします。今回はmosquitto-2.0.14-install-windows-x64.exeを使用しました。
基本的にデフォルトのままインストールウィザードを実行するだけでインストール完了です。

インストール直後の動作確認

インストールが終わったら、ひとまず簡単に動作確認をします。

コマンドによるMQTTブローカー起動

コマンドプロンプトのウィンドウを3つ使用します。

1つ目のコマンドプロンプト(ブローカー用)で以下のコマンドを実行します。

>"c:\Program Files\mosquitto\mosquitto.exe" -v

MQTTブローカーのサービスがlocalhostのインタフェースでlistenされます(詳細は後述)。

次に、2つ目のコマンドプロンプト(Subscribe用)で以下のコマンドを実行します。

>"c:\Program Files\mosquitto\mosquitto_sub.exe" -h localhost -t "test/Topic1"

localhostのインタフェース上で起動したMQTTブローカーに対し、"test/Topic1"というトピックのSubscribeを開始します。

さらに、3つ目のコマンドプロンプト(Publish用)で以下のコマンドを実行します。

>"c:\Program Files\mosquitto\mosquitto_pub.exe" -h localhost -t "test/Topic1" -m "test desu."

localhostのインタフェース上で起動したMQTTブローカーに対し、"test/Topic1"というトピック宛に"test desu."というメッセージをPublishします。
ここで、2つ目のコマンドプロンプト(Subscribe用)の画面に、"test desu."というメッセージが表示されたらOKです。MQTTブローカーの起動と、PublishとSubscribeの簡易的な動作確認ができました。

サービスによるMQTTブローカー起動

Mosquittoをインストールすると、Windows上に"Mosquitto Broker"というサービスが登録されます。このサービスを起動させておくと、先ほどの"1つ目のコマンドプロンプト(ブローカー用)"でmosquitto.exe" -vを実行したときと同じようにMQTTブローカーが起動した状態になります。
あとは、先ほどと同様に"2つ目のコマンドプロンプト(Subscribe用)"でmosquitto_sub.exeコマンドと、"3つ目のコマンドプロンプト(Publish用)"でmosquitto_pub.exeコマンドを実行し、PublishとSubscribeの簡易的な動作確認が可能です。

本記事の以降の説明は、基本的にMosquitto Brokerサービスを使用した環境に関するものです。

詳細

設定変更

listenするインタフェースや使用するプロトコル等の変更

インストール直後の状態でMosquittoを起動すると、localhostのインタフェースでのみMQTTのサービスをlistenする動作になるようです(local only mode)。

mosquitto.conf内の説明文から少し読み取りづらいですが、このlocal only modeはallow_anonymousの箇所に説明があり、listenerを設定しない場合はlocalhostからのみ認証無し(allow_anonymousが"true"相当)で接続可能な旨の記載があります。

以下のように設定する例を記載します。ポート番号は任意です。

  • すべてのIPインタフェース(IPv4、IPv6両方)で、MQTTサービスを起動(1883/tcp)
  • すべてのIPインタフェース(IPv4のみ)で、MQTT on WebSocketサービスを起動(9090/tcp)

MQTT on WebSocketサービスの設定は行わなくても、通常のMQTTを使用することが可能です。詳細については本記事では省略しますが、WebSocket経由でMQTTを使用するためのものです。

管理者権限でテキストエディタを起動し、以下ファイルを開きます。
C:\Program Files\mosquitto\mosquitto.conf

以下の行を追加します。

listener 1883

listener 9090
protocol websockets
socket_domain ipv4

allow_anonymous true
  • 追加する内容は、confの該当設定の説明がある箇所への追記、あるいは、まとめて最終行への追記、どちらでも大丈夫です。
    • ただし、listener行は複数定義できるので、各行の記載順序について注意が必要です。
      listener行の"直後"に、そのlistener行で指定したポート番号(やIPアドレス)に対して適用したい内容のprotocol行やsocket_domain行をセットで記載する必要性があります。"直後"というのは、次のlistener行の前という意味です。
  • listener 1883：すべてのIPインタフェース(IPv4、IPv6両方)で、MQTTサービスを起動(1883/tcp)する設定です。
  • listener 9090：MQTT on WebSocketサービスを起動(9090/tcp)する設定です。IPアドレスの指定を省略しているので、すべてのIPインタフェースでlistenする動作となりますが、IPv4インタフェースでのみ動作させるよう後述のsocket_domain ipv4を加えてあります。WebSocketを使用しない場合は、この設定は不要です(protocol websockets、socket_domain ipv4も)。
    • protocol websockets：通常のMQTTでなく、WebSocketを使用する設定です。protocol行を省略すると通常のMQTTが動作します。
    • socket_domain ipv4：このサービスをIPv4でのみlistenする指定です。mosquitto.conf内の説明文によると、WebSocketはライブラリの都合で、IPv6インタフェースでのみListenしようとするようなので、IPv4インタフェースを使用したい場合はこの設定が必須です。socket_domain行の省略時は、すべてのIPインタフェース(IPv4,IPv6)でlistenします。
  • allow_anonymous true：認証無しでの接続を許可する設定です。本記事の説明では認証を行わない構成としています。※listener行を定義すると、デフォルトのallow_anonymous falseが有効になります。
  • その後：必要に応じWindowsファイアウォールで1883/tcpと9090/tcp宛の通信を許可しましょう。環境に応じ、許可する接続元IPアドレスは絞っておきましょう。
    また、他にも設定可能な項目はたくさんありますが、詳細はマニュアル等を参照願います。本記事では通信のTLS対応は行っていません。

上記設定により、意図通りにlistenされます。

> netstat -an | findstr 1883
            TCP         0.0.0.0:1883           0.0.0.0:0              LISTENING
            TCP         [::]:1883              [::]:0                 LISTENING
> netstat -an | findstr 9090
            TCP         0.0.0.0:9090           0.0.0.0:0              LISTENING

サービスの自動起動設定

OS起動時にサービスを自動起動させたい場合は、Windowsのサービスの管理画面(コンピューターの管理)で、Mosquitto Brokerサービスのスタートアップの種類を"自動"にしておきます。

デバッグログの確認

デバッグログの有効化

Mosquitto動作時の詳細ログを記録したい場合には、mosquitto.confに以下の行を反映(追記)し、Mosquitto Brokerサービスを再起動します。

log_dest file C:\xxx\mosquitto.log
log_type debug
connection_messages true
log_timestamp true
log_timestamp_format %Y-%m-%dT%H:%M:%S
  • log_dest：ログファイルのパスを指定します。
  • log_type：ログレベルを指定します。"debug, error, warning, notice, information, none, subscribe, unsubscribe, websockets, all"を指定可能のようです。複数のlog_type行を設定できるようです("debug"には全てのログが含まれると思いますが詳細は未確認です)。
  • connection_messages：MQTTクライアントの接続、切断をログに記録するかどうかを指定します。
  • log_timestamp、log_timestamp_format：ログの各行にタイムスタンプを記録するかどうか、またそのフォーマットを指定します。

上記設定により、log_destで指定したパスにログファイルが作成されます。debugを指定するとログの出力量が増えるため、通信量が多い環境ではログファイルの肥大化に注意が必要です。

デバッグログの出力例

以下は、log_typeに"debug"を指定した場合のログ出力例です。

2022-XX-XXT12:34:55: Sending CONNACK to M5Stack (0, 0)
2022-XX-XXT12:34:55: Sending CONNACK to auto-xxxxxx-xxxx-xxxx-xxxx-xxxxxxxx (0, 0)
2022-XX-XXT12:34:55: Sending CONNACK to Browser-xx (0, 0)

2022-XX-XXT12:34:56: Received SUBSCRIBE from auto-xxxxxx-xxxx-xxxx-xxxx-xxxxxxxx
2022-XX-XXT12:34:56:    test/Topic1 (QoS 0)
2022-XX-XXT12:34:56: Sending SUBACK to auto-xxxxxx-xxxx-xxxx-xxxx-xxxxxxxx

2022-XX-XXT12:34:57: Received SUBSCRIBE from Browser-xx
2022-XX-XXT12:34:57:    test/Topic1 (QoS 0)
2022-XX-XXT12:34:57: Sending SUBACK to Browser-xx

2022-XX-XXT12:34:58: Received PUBLISH from M5Stack (d0, q0, r0, m0, 'test/Topic1', ... (73 bytes))

2022-XX-XXT12:34:58: Sending PUBLISH to auto-xxxxxx-xxxx-xxxx-xxxx-xxxxxxxx(d0, q0, r0, m0, 'test/Topic1', ... (73 bytes))
2022-XX-XXT12:34:58: Sending PUBLISH to Browser-xx (d0, q0, r0, m0, 'test/Topic1', ... (73 bytes))

上記のログは、以下動作時の記録です。

  • 各MQTTクライアントから接続があった(CONNACK)。
    それぞれのクライアントID(thingId的なもの)は"M5Stack"、"auto-xxxxxx-xxxx-xxxx-xxxx-xxxxxxxx"、"Browser-xx"。
    この例では、"auto-xxxxxx-xxxx-xxxx-xxxx-xxxxxxxx"は前述のmosquitto_sub.exeコマンド実行時のMQTT接続、"Browser-xx"は、JavaScriptのMQTTライブラリを使用しWebSocket経由でのMQTT接続。
  • 各MQTTクライアントから、トピック"test/Topic1"に対しSubscribe要求があった(SUBSCRIBE、SUBACK)。
  • MQTTクライアント"M5Stack "から、トピック"test/Topic1"に対しPublishされた(Received PUBLISH)。
  • Publishされたトピック"test/Topic1"に対するメッセージを、SubscribeしているMQTTクライアント"auto-xxxxxx-xxxx-xxxx-xxxx-xxxxxxxx"、"Browser-xx"に送信した(Sending PUBLISH)。

参考URL等

Zabbixで受信したデータの加工TIPS

運用管理 IoT [IT]

概要

監視ソフトウェアとして広く使用されているZabbix。監視対象サーバやIoT系のセンサー機器等から取得したデータを加工したいケースがあるかと思います。
本記事は、Zabbixで受信したデータの計算や、JSON形式データからの値の取り出し等について記載します。対象は主にZabbix 6系ですが、基本的な機能なので他のバージョンでも同様かと思います。
参考として、簡単にセットアップできるZabbix Applianceの導入についてこちらの記事にまとめてあります。

本記事の目的

  • Zabbixで受信したデータの計算や、JSON形式データからの値の取り出し等の方法を把握する。


目次

基本

計算アイテム(Calculated items)

Zabbixに登録したホスト(エージェントなど)から受信した値に対し、足し算や掛け算などの四則演算、あるいは他のアイテムとの演算、また関数を使用した各種計算を行った結果を取得する方法です。
Zabbixマニュアルに詳細が記載されています。

なお、100倍や100分の一など、一律の倍率を指定するだけであれば、後述の乗数(Custom Multiplier)で十分です。

計算アイテムの定義例を説明します。画像はアイテムの定義画面です。

Zabbix Calculated items
Zabbix Calculated items

以下、ポイント要約です。

  • Typeは「Calculated」を選択します。
  • Name、Keyには任意の文字列を指定します。
  • Type of informationは、計算した後の値の種類を指定します。図では小数を扱いたい場合を想定し、浮動小数点数(「Numeric(float)」)を指定してあります。整数の場合は「Numeric (unsigned)」を指定します。
  • Formulaでは計算式を指定します。詳細は後述します。
  • Unitsは単位を指定します。
  • Update Intervalはこの計算アイテムの更新間隔を指定します。詳細は後述します。

Formulaは、以下のように入力します。

  • 例1：host1のアイテム(キー名：key1)の最新値を100で割った値を取得する場合
    last(/host1/key1)/100
    last()関数は、指定したキーの最新の値を取得する関数です。
  • 例2：例1と同じ計算をするが、key1の値が30秒以上更新されていない場合はゼロを取得する場合
    last(/host1/key1)/100*(1-nodata(/host1/key1,30))
    nodata(キー、期間(秒))関数は、指定したキーの値が指定した期間より長い間、取得されていない場合に1を返し、取得されている場合には0を返します。
    計算式に*(1-nodata(…))を加えることで、例えば監視対象ホストとの通信が不可になる等のトラブルが発生した際には計算の結果が必ずゼロになるので、トラブル発生前に取得した古いデータが使い続けられてしまうといった動作を防ぐことができます。

計算アイテムには、以下の注意点があります。

  • 計算式に含める要素(キー)は、予め別途定義しておく必要性があります。
  • 計算アイテムの更新間隔は、計算式に含めるキー自体の更新間隔より短く指定しても意味がありません。計算アイテムの計算を頻繁に行っても、その計算に使用される要素(キー)が更新されていないケースが生じるためです。

計算アイテムの定義の仕方は、Zabbixマニュアルに詳細が記載されています。
- 計算アイテムの説明(いくつか例あり)
- 使用可能な関数の説明

乗数(Custom Multiplier)

Zabbixに登録したホスト(エージェントなど)から受信した値に対し、一律の倍率で乗算した値を使用する方法です。Zabbixマニュアルに詳細が記載されています。
該当のアイテムの保存前処理(Preprocessing)として指定するだけです。
画像は、取得した値を常に100倍する場合の設定例です。

Zabbix Custom multiplier
Zabbix Custom multiplier

  • Preprocessing stepsは、NameにCustom multiplierを選択し、Parametersにかけたい数(乗数)を指定します。10分の一にしたい場合は0.1です。
  • Type of informationは、乗算した後の値の種類を指定します。整数の場合は「Numeric (unsigned)」を指定します。浮動小数点数の場合は「Numeric(float)」を指定します。

JSONデータからの値の取り出し(Dependent item / JSONPath)

概要

Zabbixがホストから受信するデータがJSON形式である場合に、そのJSONデータから目的の値を取り出す方法です。
Dependent item(依存アイテム、従属アイテム)とJSONPathを使用します。Zabbixマニュアル(Dependent item、JSONPath)に詳細が記載されています。

ユースケースとしては、複数の値を含むJSONデータを１つのアイテム(キー)経由で受信し、その中に含まれる値を個々のアイテムとして扱う場合です。特に、1つのJSONデータに含まれる各値が「同時に取得された」ということが整合性の面から重要である場合、この方法が有効です。

以下に、JSONデータと定義するアイテムのイメージを記載します。

(ある時点で取得するJSONデータの例)
{
  "data1"   : "123",
  "data2"   : "456",
  "data3"   : "789"
}
定義するアイテム 説明
アイテム1 上記のJSONデータを取得するアイテム(HTTP エージェント、Zabbix トラッパー等)
アイテム2 アイテム１のJSONデータからdata1の値"123"を取り出すDependent item
アイテム3 アイテム１のJSONデータからdata2の値"456"を取り出すDependent item
アイテム4 アイテム１のJSONデータからdata3の値"789"を取り出すDependent item

設定例(アイテム１：JSONデータを取得)

JSONデータ取得用のアイテム(前述のアイテム１)の定義例です。HTTPエージェント以外の場合と、HTTPエージェントの場合で、設定項目が異なるため画像を2枚載せておきます。

Zabbix JSON取得用アイテム登録例1
Zabbix JSON取得用アイテム登録例1

上記は、HTTPエージェント以外の場合です。
- Typeは、Zabbixトラッパーや、Zabbixエージェント(アクティブ)が使用できます。Text形式でデータ取得できるものです。
- Type of informationは、「Text」を指定します。

Zabbix JSON取得用アイテム登録例2
Zabbix JSON取得用アイテム登録例2

上記は、HTTPエージェントの場合です。
- URLやQuery fieldsは、APIやアクセス先のWebサービスの仕様に沿って定義します。Query fieldsは、URLの後に"?"に続いて付与されるリクエスト文字列の一部です。

設定例(アイテム２，３，４：JSONデータから値を取り出し)

次に、JSONデータから値を取り出すためのアイテム(前述のアイテム２，３，４)の定義例です。

Zabbix JSONデータから値を取り出すアイテム登録例
Zabbix JSONデータから値を取り出すアイテム登録例

Itemタブ以外に、Preprocessingタブも設定します。

  • Typeは、「Dependent item」を選択します。
  • Master itemには、上記でJSON取得用に定義したアイテムを指定します。
  • Type of informationは、JSONから取り出す値の型を指定します。
  • Preprocessingタブでは、Preprocessing stepsに「JSONPath」を定義し、Parametersには「$.data1」のようにJSONデータの中から取り出したい値の名前を指定します。
  • Type of informationは、Itemタブにある同項目と同期されています。
  • JSONデータから取り出したい値の数だけ、同様にDependent itemを定義します。

定義したDependent itemは、Zabbixの監視対象項目として扱うことができます。

補足

以下、JSON形式のデータから値を取り出す際の補足事項です。

  • JSONデータを取得するアイテムのタイプはHTTPエージェントの場合もあれば、それ以外のタイプのアイテムからテキストデータとしてJSONデータを受信する場合もあります。環境に応じて定義できます。

  • JSONデータを取得するアイテムのタイプに関わらず、Dependent item(依存アイテム)を使用するという点は同じです。

    • ただし、JSONデータから取り出す値が1つだけである場合は、Dependent itemを定義する必要性はありません。JSONデータを取得するアイテム内で、Preprocessingタブの設定を行うだけで十分です。

  • Zabbixの構成上、同じキー名を定義したアイテムを複数登録することはできません。構成によっては、この制限に注意する必要性があるので、一応記載しておきます。

文字列型から数値型へのデータ変換

次に、本当は小数データなのに文字列型として受信してからZabbix内では数値データとして扱いたい場合の変換方法です。例えば、SNMP経由で小数データを取得する場合、監視対象機器のMIBによってはSNMPのデータタイプが文字列型(OCTET STRING)で定義されていることがあります。

これは特に個別の設定は不要で、Type of informationに変換後のデータタイプを指定するだけで、Zabbixが自動的に変換してくれるようです。

数値型データへの変換例
数値型データへの変換例

参考URL等

Zabbix Applianceの導入

運用管理 [IT]

概要

監視ソフトウェアとして広く使用されているZabbix。アプライアンス版は簡単に導入できるので検証用途等にも便利です。
本記事は、Zabbix Applianceの導入手順をまとめたものです。対象はZabbix 6系、仮想環境向けに配布されているアプライアンス版をHyper-V上に導入します。ESXiサーバでも同様のはずです。

本記事の目的

  • Zabbixのアプライアンス版等の配布形態を把握する。
  • Zabbix Applianceを導入する。


目次

基本

Zabbixの導入方法の種類

Zabbixマニュアルによると、以下の導入方法があります。

本記事では、仮想アプライアンス版について説明します。

Zabbixマニュアルの内容から、いくつか補足事項を要約します。

その他、コンテナ版について詳細は本記事では触れませんが、過去に混同しやすい名称でコンテナ版のアプライアンスがリリースされていたので、留意点として後述しておきます。

Zabbix Applianceの導入

仮想ディスクイメージのダウンロード

ダウンロードページから、使用している仮想環境に合った仮想ディスクイメージをダウンロードします。
本記事では、Zabbix 6.0 LTSのHyper-V 2012用のイメージを使用しました(.vhdx)。

ダウンロード後、仮想環境のホストから参照可能なパスに格納します。

仮想アプライアンス用の仮想マシン作成

Hyper-V上で仮想マシンを新規作成し、準備したvhdxファイルを指定します。

  • 具体的には、仮想マシンの新規作成ウィザードの「仮想ハードディスクの接続」画面で、「既存の仮想ハードディスクを使用する」を選択し、準備したvhdxファイルを指定します。
    なお、ここで指定したvhdxファイルは、格納パスは変更されずそのまま仮想ディスクとして使用されますが、仮想マシン作成後に仮想マシン自体の格納パスを移動できるので、いったん気にせず進めても問題ありません。

その他、補足です。

  • 「世代の指定」画面では、基本的に「第1世代」で問題ありません。
  • 必要なメモリは、Zabbixマニュアルに1.5 GBと記載があります。もちろん後で変更できます。
  • 「ネットワークの構成」で、DHCPが有効なDefault Swictchを指定します。
    DHCPが無くても導入できそうですが、マニュアル上は最初のセットアップ時にはDHCPを使ってIPアドレスを取得することになっています。仮想マシン作成後、コンソールから固定IPアドレスを設定可能です。

仮想アプライアンスの起動と初期セットアップ

仮想マシンの作成が完了したら、仮想マシンを起動します。

基本的な手順はZabbixマニュアルに書かれている通りですが、概要と注意点を記載します。

  • 仮想マシンを起動したら、コンソールを開きます。ログイン画面が表示されます。(ちなみにマニュアル記載のCentOSでなくAlmaLinuxでした)

    Zabbix Appliance
    Zabbix Appliance

  • Zabbix Applianceにログインする際のユーザ名とパスワードは、2 Zabbix configurationに記載があります。
    アプライアンス内のLinux OSは、ユーザ名 root、パスワード zabbix でログイン可能です。

  • Zabbix Applianceのコンソールにログインすると、説明メッセージが表示されます。その後は通常のLinuxのシェルを使用できます。

  • ip addr showコマンドで、Zabbix ApplianceがDHCP経由で取得したIPアドレスを確認します。

  • Hyper-Vホスト側でブラウザを起動し、http://確認したIPアドレスにアクセスすると、Zabbixのログイン画面が表示されます。ユーザ名 Admin、パスワード zabbix でログイン可能です。

    Zabbix Appliance
    Zabbix Appliance

  • 固定IPアドレスを設定する場合は、1.3 Using a static IP addressの手順に従います。
    注意点として、固定IPアドレス設定のために仮想マシンのコンソールで/etc/sysconfig/network-scripts/ifcfg-eth0を編集する際、キーボードが英語配列になっているようです(環境や設定によると思います)。日本語キーボードを使用する場合、"="は" ^ "のキー、":"はShift+";"のキーで入力できます。
    以下を修正し、systemctl restart networkで反映されます。ip addr showなどで反映結果を確認できます。

  • タイムゾーン設定のため、1.4 Changing time zoneの手順に従い修正します。
    日本なら、cp /usr/share/zoneinfo/Japan /etc/localtimeです。

  • 以上で初期セットアップ完了です。http://IPアドレスでZabbixの管理画面にアクセスし、Zabbixを使用できます。

詳細

その他の設定

  • 仮想アプライアンスはrootでsshログインできるようになっています。セキュリティ上問題がある場合は修正しておきましょう。

  • 必要に応じ、Webサーバ(nginx)の設定やファイアウォールの設定を変更しましょう。アクセス制限関連の設定です。

  • # dnf update zabbix*にてzabbixのアップデートが可能です。# dnf updateで全パッケージをアップデートしても大丈夫かと思いますが、マニュアルには記載はありません。

(廃止済みの形態)コンテナ版Zabbixにおけるアプライアンス

コンテナ版についての詳細は本記事では触れませんが、過去に混同しやすい名称でアプライアンスがリリースされていたので、留意点として記載します。

Docker Hubに、all-in-oneコンテナ版の「zabbix-appliance」というものがありますが、この導入形態は既に廃止されました。

all-in-oneなので、MySQL DBやNginx Web サーバが1つのイメージに同梱されていて便利そうですが、コンテナ版Zabbixは、各コンポーネントのDockerイメージを組み合わせて構成する必要性があるそうです。

Important information:_ Zabbix Docker Appliance image has been decommissioned and will not be available for 3.0.31, 4.0.19, 4.4.7, 5.0.0 and newer releases. Please use a separate Docker image for each component instead of the all-in-one solution.
https://hub.docker.com/r/zabbix/zabbix-appliance

参考URL等