Googleは、AIを用いることでファイルの種類を高速かつ正確に判別できるオープンソースのツール「Magika 1.0」を公開したと発表しました。
Google、AIでファイルの種類を高速正確に判別するオープンソース「Magika 1.0」公開。Rustで再構築し、より高速かつ対象を200種類に拡大へ － Publickey
Magikaは、あるファイルの中味が何なのか、記述されたプログラミング言語の種類、動画や画像、音声などのフォーマットの種類、ExcelやWord、PDFなどのオフィス系ソフトウェアの種類、OSの実行形式バイナリなどの種類を瞬時に判別してくれます。
Google、AIでファイルの種類を高速正確に判別するオープンソース「Magika 1.0」公開。Rustで再構築し、より高速かつ対象を200種類に拡大へ － Publickey
⇧ ファイルが破損しているかどうかについてはチェックしてくれないのかな...
動画ファイルとかのようなバイナリファイルって、破損していないのかもチェックしたいこと、あるあるの気がしますからな。
何やら、
今回のバージョン1.0では、Rustによって内部の判別エンジンが完全に書き直されてより高速化され、また判別できるファイルの種類も以前の100種類から200種類へと倍増。テキストで書かれたコードや構成ファイルの種類と言った判別が難しいものに対する正確性も向上しています。
Google、AIでファイルの種類を高速正確に判別するオープンソース「Magika 1.0」公開。Rustで再構築し、より高速かつ対象を200種類に拡大へ － Publickey
⇧「Rust」で「リファクタリング」されているらしい。
⇧ なるほど、「Rust」の割合が、25.9%ということで、4分の1を占めると。
「インストール」の方法のページを確認した感じでは、
⇧ サポートしているプログラミング言語としては、
あたりになるのかね？
「Docker」はというと、
⇧「Dockerfile」を見た限りでは、「Python」を利用して「インストール」している模様。
まぁ、
- サーバサイド側
- フロントエンド側
って使い分けになるのかな？
構成管理データベース（CMDB：Configuration Management Database）
Wikipediaによると、
構成管理データベース（Configuration Management Database、CMDB）とは、情報システムの全コンポーネントに関する情報の統合された保管・管理（構成管理）を行うデータベース。
CMDB は構成要素（configuration item、CI）とその重要な属性の詳細を記録し、CI同士の関係を記録する。CIは一般に3つの構成可能な属性で記述される:
- 技術的属性
- 所有者属性
- 関係属性
CMDB実装で鍵となるのは、CIに関する情報を自動的に発見する能力（自動検出）と変更に自動的に対応できる能力である。 自動的に対応するためには、インベントリ収集や監視システム、サービスデスク、チケットシステムとのAPI連携が必要となる。
⇧ とあり、「構成要素（configuration item、CI）」在りきといった感じ。
そりゃそうだ、「データベース」なんだから管理する対象の「情報」が無ければ始まらないものな。
なのだが、「構成要素（configuration item、CI）」の説明が抽象的過ぎて、具体的なイメージが全く浮かびませんと。
ちなみに、「構成管理」はというと、
構成管理（こうせいかんり、configuration management、CM）とは、システムのライフサイクルにわたる範囲、性能、機能的および物理的要件、設計、操作に関する情報などを確立し維持する作業またはプロセスである。
形態管理、コンフィギュレーションマネジメントとも。CMプロセスは、武器システム、車両、情報システムなどの複雑なシステムを管理するため、軍事工学組織で広く使われている。 軍事以外では、ITILやISO/IEC 20000で定義されるようなITサービス管理、土木工学や生産技術の分野でのドメインモデルでも使われており、例えば道路・橋・運河・ダム・建築物の建設や保守管理がある。
⇧ 利用されている領域が様々であるが、「構成管理データベース（CMDB：Configuration Management Database）」は、「ITサービス管理」の領域で「構成管理」を実施する場合のものになるっぽい。
ZabbixとCMDBを連携するソリューションって意外に無いっぽい
で、「Zabbix」はというと、
Zabbix はアレクセイ・ウラジシェフ(Alexei Vladishev)によって作られた、ネットワーク管理ソフトウェアである。様々なネットワークサービス、サーバ 、その他のネットワークハードウェアのステータスを監視・追跡できる。現在はウラジシェフが設立したZabbix社によって開発が継続されている。
⇧ とありますと。
ちなみに、「Zabbix」は「要件」として「RDBMS（Relational DataBase Management System）」の利用が必須、つまり、「データベース」を利用している。
となって来ると、
- Zabbixの利用しているデータベース
- 構成管理データベース（CMDB：Configuration Management Database）
って連携できた方が都合が良さそうですと。
なのだが、ネット上の情報で、それらしきソリューションがほとんど見当たらない...
とりあえず、
⇧ 公式の「Zabbix」のブログで「NetBox」を「構成管理データベース（CMDB：Configuration Management Database）」とした場合の記事が公開されておりますが。
ちなみに、「NetBox」へのデータの登録については、
⇧ 上記サイト様によりますと、「CSVファイル」で一括登録できるらしいので、「Zabbix」の公式ブログにあるように、1件ずつ登録する必要は無いっぽい。
話が脱線しましたが、「NetBox」以外を、「構成管理データベース（CMDB：Configuration Management Database）」とした場合に、「Zabbix」が対応してるかが分からないのよね...
対応していない場合は、
- Zabbixの利用しているデータベース
- 構成管理データベース（CMDB：Configuration Management Database）
の2つのデータベースのハブとなる中間データベースを用意する感じになるとは思うのだが...
「ChatGPT」氏に「ServiceNow」の「CMDB」と「Zabbix」の連携について質問してみたところ、以下のような回答が返ってきた。
■ServiceNowのCMDBとZabbixの連携
+--------------------+ +---------------------------+ | ServiceNow CMDB | | Zabbix Server (オンプレ) | | cmdb_ci_server | | | | ↑ REST API | | ↓ REST API | | |<---------------->| Pythonスクリプト等 | | | | (ServiceNow→Zabbix連携) | +--------------------+ +---------------------------+
⇧ いずれにしろ、「API」を実行することで「情報」を共有する感じにはなりそう。
まぁ、普通に考えたら、
- 構成管理データベース（CMDB：Configuration Management Database）に構成要素（configuration item、CI）となる機器情報が登録される
- Zabbixの監視するホスト（機器情報）は、1.で登録された機器情報になるので、CMDBに対して機器情報を取得するAPIのリクエストを送信する
- Zabbixで監視するホスト（機器情報）に割り当てる監視用のテンプレートをZabbix APIで登録する
- Zabbixで監視対象のホスト（機器情報）を登録する際に監視用のテンプレートをZabbix APIで紐付ける
といったような流れになると思うので、「Zabbix」がインストールされているマシンの側から「ServiceNow」の「CMDB」に向かって「API」のリクエストを送信する形になる気はしますかね。
あとは、「API」のトリガーとなる「クライアント」側をどうするかですかね...
「Web画面」を用意するとなった場合、「画面」の「要件」を決める必要が出てくるのよな...
となって来ると、
⇧ 上記の問題に行き着くわけなのよね...
10000件とかのデータに対する更新系の処理とかを、1件ずつ「Web画面」でポチポチ選択して処理していくわけにいかないものな...
それに、「Web画面」から「CSVファイル」などをインポートする方式を導入した場合、
- Zabbixの利用しているデータベース
- 構成管理データベース（CMDB：Configuration Management Database）
のどちらの「データベース」も、「Web画面」からのインプット情報を保存できる作りになっていないので、新たな「データベース」が必要になって来るということですな。
「Web画面」からのインプット情報を切り捨てるのであれば、新たな「データベース」が無くても良いかもしれませんが...
新たな「データベース」を用意しておけば、「ServiceNow」の「CMDB」の情報は定期的なバッチ処理などで同期するようにしておけば、毎回、「ServiceNow」の「CMDB」に対して「API」のリクエストを送信しなくても良くなるとは思いますが。
まぁ、どのぐらいの頻度で「API」が実行されるのかに依りけりといった感じですかね。
1か月に10回ぐらいの頻度であれば、新たに「データベース」の用意をしなくても良いと思いますし、1か月に10000回とかの頻度になるならば、新たな「データベース」を用意した方が良い気はしますが...
ただ、「データベース」を追加するとなると、どのぐらいの期間まで保持するのか、などの「運用面」の問題も出て来ますからな...
ちなみに、
Source: https://git.zabbix.com/projects/ZBX/repos/zabbix/browse/templates/media/servicenow?at=release/7.4
ServiceNow webhook
This guide describes how to integrate Zabbix 7.4 installation with ServiceNow using the Zabbix webhook feature. This guide provides instructions on setting up a media type, a user and an action in Zabbix.
Please note that recovery and update operations and ServiceNow's custom fields are supported only for trigger-based events.
⇧「ServiceNow」向けの「Zabbix」の「テンプレート」があるらしいのだが、「Zabbix」側の監視の結果などを「ServiceNow」の「CMDB」側に連携するような機能っぽい気がする。
ちなみに、
⇧ 上記のブログ記事によると、
- NetBox
- ServiceNow
間の連携はできるっぽい書きっぷり。
う～む...、「ServiceNow」はブラックボックスな部分が多いのよな...
まぁ、結局のところ、「ファインダビリティ（Findability）」の問題になってしまうのだが、必要な情報に辿り着き辛いのですな...
凝ったことをしないのであれば、
エクスポート/インポートできるもの
エクスポート/インポートできるオブジェクトは次の通りです。
https://www.zabbix.com/documentation/current/jp/manual/xml_export_import
インポートに関する詳細
- インポートは、最初のエラーで停止します。
- 画像のインポート時に、既存の画像を更新する場合、"imagetype "フィールドは無視されます。つまり、インポートを介してイメージタイプを変更することはできません。
- ホスト/テンプレートを "存在しない場合に削除"オプションでインポートする場合、インポートファイルに存在しないホスト／テンプレートマクロも削除されます。
- アイテム、トリガー、グラフ、ディスカバリールール、アイテムプロトタイプ、 トリガープロトタイプ、グラフプロトタイプの空タグは意味がありません。つまり、存在しないのと同じです。
- インポートは、YAML、XML、JSONをサポートしています。 YAMLは.yamlと.yml、XMLは.xml、JSONは.jsonと、正しいファイル拡張子が必要です。サポートされているXMLのバージョンに関しては、バージョン間の互換性を参照してください。
- インポートは、UTF-8 エンコーディング (BOM 付き/なし) の設定ファイルのみをサポートしています。他のエンコーディング (UTF16LE、UTF16BE、UTF32LE、UTF32BE等) ではインポートの変換エラーになります。
https://www.zabbix.com/documentation/current/jp/manual/xml_export_import
⇧ 上記の説明を見る限り「Zabbix」の「Web画面」からのインポートについては、
に対応しているらしい。まさかの「CSVファイル」には対応していないというオチ...
しかも、
⇧「インポート」用のファイルのフォーマットが紹介されていないのよな...
「AI」とかに任せて「インポート」用のファイルの生成を良しなにしてくれるかというと、厳しそうな気もするのよな...
そもそも、
『インポートは、最初のエラーで停止します。』
とあるにもかかわらず、「インポート」用のファイルの正解が把握し辛いのは、有無を言わさずに利用のハードルを上げていることに何故に気付かないのか...
「ユーザーエクスペリエンス（UX：User eXperience）」が蔑ろにされているんではなかろうか...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
