Manzanの発表：IBM iイベント 監視の将来像

2025年4月25日　ジェシー・ゴルジンスキー、サンジュラ・ガネポラ

今日のIT環境では、インフラストラクチャーの日々の運用を全体的に監視することが、これまで以上に重要になっています。新しいテクノロジーとともに、パフォーマンス、セキュリティー、信頼性に関する新たな考慮事項が生まれています。つまり、管理者が「監視」するべき指標やイベントの数はますます増えているということです。そして、時間の経過に伴い、「監視」は非常に複雑な作業になっていく可能性があります。この課題に対処するため、IBM iのインフラストラクチャー監視およびイベント管理のための新しいソリューション、Manzanのテクノロジープレビューを、IBMは公式に発表します。

Manzanは、IBM iのシステム・イベントをユーザー・アプリケーション、外部資源、オープンソース技術などのさまざまなエンドポイントに通知するプロセスを簡素化するために設計されたオープンソース・プロジェクトです。システム・メッセージの監視、アラートの発報、コンプライアンスおよびレポート作成のためのログ統合のどれが必要であっても、ManzanがIBM iをIT環境の他の機能と容易に統合できるようにします。

Manzanが必要な理由とは？

長年にわたり、お客様はIBM iのシステム監視用に独自のソリューションを作成したり、サードパーティー製ソフトウェアを利用したりしてきました。一方、IBMはAPIやSQLサービスなど、システムのさまざまな側面の調査を支援する仕組みを数多く提供してきました。それでもなお、STRWCH/ENDWCH CLコマンドによるシステムの「監視」機能のように、十分に活用されていない機能がいくつかあります。さらに、IBM iのイベントはさまざまな場所に存在している可能性があります。ジョブ・ログに記録されるものもあれば、メッセージ待ち行列のどこかにあるもの、ストリーム・ファイル中に隠れているものもあります。これらのイベントすべてを単一のツールで可視化できたら、どれほど便利でしょう。

もしそのようなツールがあれば、いくつかの非常に合理的な要望を満たすだろうと想像できます。たとえば、主要な会計プログラムが機能停止したときに、テキストメッセージを送るのはどうでしょう？履歴ログ・イベントに基づいたメールはどうでしょう？Node.jsプログラムがログ・ファイルに警告を書き込んだときにSlackチャンネルにメッセージを投稿するのも便利かもしれません。SentryやGrafana Lokiのようなツールにダッシュボードを配備するのはどうでしょうか？そこでManzanの出番です。Manzanを使えば、これらのタスクはどれもわずか数分で設定できるのです。

Manzanの中核をなす機能は2つあります。1つ目は、多数のイベントタイプを「単一の画面枠」に集約することです。これにより、各イベントタイプ用に異なるツール（あるいは異なる手書きプログラム）を用意する必要がなくなります。2つ目は、これらのイベントをオープンソースの監視ツールや人工知能（AI）など、数多くの技術と統合できることです。

それでは、Manzanがどのように機能するのか、そして、なぜ、わずか数分で「監視」を開始できるのかを詳しく見ていきましょう。

アーキテクチャーを理解する

▲図1. Manazanのアーキテクチャー

まず、「入力」と「送り先」という 2つのコア・コンポーネントを詳しく調べることで、Manzan のアーキテクチャーが最もよく理解できます。

1. 入力はデータの発信元です。その最も単純な形は、監視したいストリーム・ファイルかもしれません。しかし、入力にはシステムの監視機能も使えます。IBM iに組み込まれた監視機能は強力ながらも十分に活用されていないツールです。ManzanはSTRWCHコマンドを使用してイベント監視機能を開始します。イベント監視機能は、指定されたイベントが発生したときに、指定されたプログラムを呼び出します。つまり、入力には下記のものが使用できるのです。
   ・メッセージ・キュー
   ・ストリーム・ファイル
   ・ライセンス内部コード（LIC：License Internal Code）ログ項目
   ・製品アクティビティ・ログ（PAL：Product Activity Log）項目
2. 送り先は、データを送り届けたい場所です。独自に作成したILEコードを使用してデータを取得することもできますが、ほとんどの場合、使用場面に応じて、サポート対象になっている下記の多様な送り先のいずれかを使用することになります。
   ・HTTP/HTTPS endpoints （REST, etc）
   ・Email （SMTP/SMTPS）
   ・SMS (via Twilio）
   ・Slack
   ・FluentD
   ・Kafka
   ・Sentry
   ・Grafana Loki
   ・Google Pub/Sub
   ・ActiveMQ
   

Manzanは、入力と送り先をつなぐ通路であり、ハンドラーとディストリビューターという2つのコア・コンポーネントで構成されています。

1. ハンドラーは、システム監視または出口点イベントを入力として受け取り、処理します。まず、すべてのシステム監視を開始し、次にデータを使用可能な形式に変換し、最後にイベントが検出された時にこれをテーブルまたはデータ待ち行列に書き込みます。では、ハンドラーはどのように入力の内容を認識するのでしょうか？その答えは、この入力に関する情報を記した設定ファイル（data.ini）を定義することです。
2. ディストリビューターは、統合の万能ツールと称されるApache Camelを使い、データを最終的な送り先に送信します。Apache Camelは、テーブルまたはデータ待ち行列からデータを取得し、選択された送り先に送信します。ハンドラーと同様に、これらの送り先に関する情報を記した設定ファイル（dests.ini）を定義します。

入力と送り先を設定する

前述の通り、Manzanの設定は/QOpenSys/etc/manzan/にあるいくつかの設定ファイルを使って簡単に行えます。これらの設定ファイルは、それぞれiniファイル形式に従っていて、入力と送り先のどちらも数分で簡単に追加・削除できるようになっています。統合したい新しいツールごとに異なるプロトコルを覚える必要はなく、これらの標準ファイルを更新するだけで済みます。

1. app.ini： app.iniは、Manzanが機能を果たすのに必要なILEコンポーネントが格納されているライブラリーを指定する情報を含んでいます。ほとんどの場合、app.iniは変更せず、そのままにしておけます。
2. data.ini： data.iniには、単純な形式で入力の概要を記述します。入力は、それぞれ固有のIDと、ストリーム・ファイル、メッセージ・キューなどを監視するかどうかに基づいて割り当てられる型をもちます。入力情報を送り先に対応させる作業もここで行います。
3. dests.ini： dests.iniには、送り先とその固有のIDの概要を記述します。データの送り先に基づいて、認証情報などいくつかの必須プロパティーを指定する必要があります。

これらの設定ファイルのセットアップがいかに簡単かを理解するには、次の2つの実例を詳しく見ていただくのが一番です。

Slackにメッセージを送信する

Slackは、チームに継続的に最新情報を提供するための優れた協業ツールです。Manzanを使えば、IBM iで稼働しているアプリケーションの状況について、チームメンバーに最新の情報を継続的に提供できます。最初の例では、IBM iのアプリケーションがストリーム・ファイルにエラーログを書き出す際に、Slackにそのアプリケーションに関する最新情報を提供する方法を見てみましょう。

Slackチャンネルにメッセージを送信できるようにするために、以下の手順に従ってSlackアプリを作成する必要があります。

1. Slackアプリのウェブサイトにアクセス
2. ［アプリを作成］をクリックし、［最初から］を選択
3. アプリに名前を付け、ワークスペースを選択して、［アプリを作成(Create App)］をクリック

▲図2. Slackアプリを作る

次に、新しく作成したSlackアプリがチャンネルにメッセージを送信するための受信Webhookを作成する必要があります。

1. ［機能］という見出しの下にある［受信Webhook］セクションにアクセス
2. 受信Webhookを有効にするために、この機能をオンにし、［ワークスペースに新規のWebhookを追加］をクリック
3. 最新情報を受け取りたいSlackチャンネルを選択し、「許可（Allow）」をクリック
4. 生成されたWebhookのURLをコピーして保管
   URLは https://hooks.slack.com/services/… のようになります

▲図3. Slack Webhookを作る

この例の場合、Manzanという名前のSlackアプリを作成し、IBM iテスト・ワークスペースへのアクセスを許可し、my-app-statusという名前のチャンネルへアクセスを許可しました。

Slackアプリが動作するようになったので、後はManzanの設定ファイルを更新してメッセージの送信を開始するだけです。まずは、data.iniファイルに新しい入力を追加することから始めましょう。

[file_my_app]
type=file=
file=/tmp/my-app-log.txt
destinations=slack_out
filter=ERROR:
format=$FILE_DATA$

ここで、具体的にそれぞれの行が何をしているのかを確認してみましょう。

• [file_my_app]： この入力の固有のIDとしてfile_my_appを割り当て
• type： ストリーム・ファイルを監視したいので、この入力をファイル型として指定
• file： 監視したいファイルへのパスを指定。この場合は、アプリケーションのログ・ファイル
• destinations： このデータの送り先としてslack_outを指定。このID（slack_out）は後述するdests.iniにも定義
• filter： 特定のログ・メッセージに対してだけSlackを更新したい場合、監視対象を絞り込むためのフィルターを指定。この例ではERROR：を含む行だけを監視するよう指定
• format： データの送信形式を定義。指定しない場合、すべての情報を送信。この例では、ログ・メッセージそのものだけに関心があるので、特別なキー$FILE_DATA$を使用してファイルの内容だけを取得。使用可能なすべてのキーのリストは、こちらのページを参照

最後のステップは、dests.iniファイルに新しい送り先を追加することです。

[slack_out]
type=slack
channel=my-app-status
webhook=https://hooks.slack.com/services/...

もう一度、これらの行をそれぞれ確認してみましょう。

• [slack_out]： この送り先に固有のIDとしてslack_outを割り当て。これは、上述のdests.iniのdestinationsフィールドで使用したIDと同じ。
• type： この送り先タイプをSlack（Slackの定義済みタイプ）に指定。使用可能なすべてのタイプのリストは、こちらのページを参照。
• channel： Slackアプリの投稿先として割り当てたチャンネルを指定
• webhook： 前に生成したWebhookのURLを指定

ここまで完了したら、Service Commanderを使ってManzanを起動できます。Manzanが稼働しているので、アプリケーションのログ・ファイルにメッセージが追加されるたびに、Slackチャンネルにもメッセージが投稿されているのが分かります（図4参照）。

▲図4. Manzanを使いSlackにメッセージを送信する

この例の場合、RESTサーバーの起動に失敗してアプリケーションがエラーを記録したときに、SlackアプリのManzanがチャンネルmy-app-statusにメッセージを投稿します。

Grafana Lokiにログを取り込む

基本的な例を見たので、次はGrafana Lokiを使った、さらに複雑な例を見てみましょう。Grafana Lokiの設定はSlackより複雑ですが、同じ設定ファイルを使ってManzan自体を設定する手順は同一であることに留意してください。

Grafana Lokiはログの取り込みとクエリー処理に使用されるログ集約システムです。Grafanaは、アプリケーションやITインフラストラクチャーのログをクエリーし、カスタム設計されたダッシュボードにそのログを表示できます。IBM i上のQHST履歴ログのメッセージ待ち行列に次々と追加されるメッセージを監視し、そのデータをGrafana Lokiに取り込む方法を見てみましょう。

以下の手順では、Grafana Lokiインスタンスがすでに作成されており、その資格情報（URL、ユーザー名、パスワード）が手元にあると仮定します。

前の例と同様に、最初のステップは、data.iniファイルに新しい入力を追加することです。

[watch_hstlog]
type=watch
id=sanjula
destinations=loki_out
strwch=WCHMSG((*ALL)) WCHMSGQ((*HSTLOG))
format=$MESSAGE_ID$ (severity $SEVERITY$): $MESSAGE$

ここで何が起きたのか、もう一度復習しましょう。

• [watch_hstlog]： この入力の固有のIDとしてwatch_hstlogを割り当て
• type： メッセージ・キューを監視するため、この入力をwatch型として指定
• id： この監視のセッションID (SSNID)としてsanjulaを割り当て。このIDは、IBM i上のすべてのアクティブな監視間で唯一の存在でなくてはいけません。
• destinations： このデータの送り先としてloki_outを指定。この同じIDをdests.iniの中に定義
• strwch： Manzanの起動時に監視をどのように開始するかを記述するために、STRWCH CLコマンドの追加パラメーターを指定。この例の場合、履歴ログのメッセージ・キューに追加されるすべてのメッセージを監視
• format： データ送信の形式を定義。前の例と違い、ここでは詳細情報を含めるために複数のキーを使用

入力を定義したので、次にdests.iniファイルに新しい送り先を追加する必要があります。

[loki_out]
type=loki
url=<loki_url>
username=<loki_username>
password=<loki_password>

もう一度、これらの行をそれぞれ確認してみましょう。

• [loki_out]： この送り先の固有のIDとしてloki_outを割り当て。これは、上述のdests.iniのdestinationsフィールドで使用したIDと同じ
• type： この送り先の型として、Grafana Lokiの定義済み型のlokiを指定
• url：Grafana Lokiサーバー・インスタンスのURLを指定
• username：Grafana Lokiインスタンスの認証情報（ユーザー名）を指定
• password： Grafana Lokiインスタンスの認証情報（パスワード）を指定

これで、以前と同じようにManzanを起動できますが、今回は履歴ログのメッセージ待ち行列にメッセージが追加されるたびに、Grafana Lokiにもメッセージが取り込まれることが分かります（図5参照）。

▲図5. Manzanを使ってGrafana Lokiにログを取り込む

これらの集約されたログがすべて揃ったら、この情報を視覚化するための独自のダッシュボードを設計、構築できます。図6はダッシュボードの例で、システム管理者がメッセージの頻度を監視し、重要なログを迅速に切り分けるために使用できます。

▲図6. Grafanaダッシュボードへのログの表示例

Manazanの始め方

2025年3月現在、Manzanはテクノロジープレビューとして利用可能です。インストール方法やそのほかの例については、こちらのページをご覧ください。

Manzanのロードマップには、さらに多くの機能の搭載が予定されています。より多くのイベント送り先のサポートや、監査ジャーナルおよびネットワーク出口点のサポートのようなセキュリティー機能の強化など、Manzanのロードマップにはさらに多くの機能が含まれています。さらに、 Prometheus用IBM iエクスポーターとの相乗効果についても検討していく予定です。Manzanはオープンソース・プロジェクトですので、サポートするべき新しい送り先やその他のアイデアについてご意見がありましたら、GitHub Issueを開いて共有してください。あるいは、気軽にこのプロジェクトに貢献してください。