近年はSNSにおける誤情報の拡散やヘイトスピーチの増加、それに伴う政治や選挙への影響が懸念されており、研究者らはSNSでのコミュニケーションや言論に着目した研究を進めています。そんな中で欧州委員会(EC)が、TikTokとMetaがデジタルサービス法(DSA)に基づく「研究者に公的データへの適切なアクセスを許可する義務」に違反していると認定しました。
「SNSが誤情報を拡散して選挙に影響を与える仕組み」などを研究するためのデータアクセスをMetaとTikTokが妨害している - GIGAZINE
⇧ まぁ、「ソフトウェア」で適切な「データモデリング」が行われているのであれば、研究用のデータを提供できるとは思うのですが、ビジネスを優先して、
『とりあえず動くものを直ぐに開発せざるを得ない』
って状況だった場合、システムの状態がカオスになっていそうなので、開発チームがシステムの全体像を把握できていない可能性もありそうな気がしますな...
それにしても、欲しい情報を要求するだけで良いって、研究者の立場は「羨まけしからん」ですな...
「ソフトウェアエンジニア」は、「ファインダビリティ（Findability）」の欠片も無い膨大なドキュメントを読み込むという不毛な時間を経て漸く必要な情報を得られるかもしれないというのに...
格差社会というやつかね...
不条理過ぎるのよな...
システムの運用監視でZabbixの代替OSS（Open Source Software）が意外と存在しない問題
職場のチーム内で、「Zabbix」は「監視運用」を目的とした「ソフトウェア」として一般的なのかという疑問が挙げられて、確かに「監視運用」を目的とした「ソフトウェア」って「Zabbix」以外にも様々なものがあるイメージだったので、「ChatGPT」氏に質問してみたところ、以下のような回答が返ってきた。
🧭 OSS（Open Source Software）の監視ソフトウェア比較
| 分類 | ソフトウェア名 | 主な用途 | アーキテクチャ | 対応監視対象 | 可視化 | アラート機能 | スケーラビリティ | 主な特徴・長所 | ライセンス |
|---|---|---|---|---|---|---|---|---|---|
| 統合監視 | Zabbix | ホスト／サービス監視 | エージェント型＋SNMP＋API | OS, ネットワーク, DB, アプリ | 内蔵グラフ, Web UI | トリガー, 通知, 自動復旧 | 中～大規模 | 豊富なテンプレート、包括的監視 | GPLv2 |
| 統合監視 | Nagios Core | サービス監視 | エージェント型＋プラグイン | OS, ネットワーク, アプリ | Web UI（簡易） | メール, スクリプト連携 | 小～中規模 | 古参・プラグイン豊富 | GPLv2 |
| 統合監視 | Icinga 2 | ホスト／サービス監視 | Nagios互換＋API | OS, DB, ネットワーク | Web UI, Grafana連携 | 柔軟なルール設定 | 中～大規模 | API, モダンUI, 拡張性 | GPLv2 |
| 統合監視 | Checkmk Raw Edition | 自動検出＋監視 | Nagiosベース＋独自拡張 | OS, アプリ, DB | Web UI, グラフ | 内蔵通知＋外部連携 | 中規模 | 簡易セットアップ、高速 | GPLv2 |
| メトリクス監視 | Prometheus | メトリクス収集 | プル型, TSDB | アプリ, コンテナ, OS | Grafana連携 | Alertmanager連携 | 中～超大規模 | Kubernetes対応, 高性能 | Apache 2.0 |
| メトリクス監視 | Thanos / Cortex | Prometheus拡張（長期保存） | 分散型, オブジェクトストレージ | Prometheusメトリクス | Grafana連携 | Alertmanager併用 | 超大規模 | 長期保存・マルチクラスタ | Apache 2.0 |
| リアルタイム監視 | Netdata | 即時リソース監視 | エージェント型 | OS, プロセス, アプリ | 内蔵Web UI | 基本的な通知機能 | 小～中規模 | 導入即可視化・高分解能 | GPLv3 |
| ネットワーク監視 | LibreNMS | SNMP監視, 機器可視化 | SNMP＋自動検出 | ルータ, スイッチ, サーバ | Web UI, グラフ | 通知・閾値 | 中～大規模 | ネットワーク機器に特化 | GPLv3 |
| ネットワーク監視 | Observium (Community) | ネットワーク監視 | SNMP＋自動検出 | ルータ, スイッチ | Web UI, グラフ | 限定的 | 中規模 | 自動マッピング, 簡単導入 | QPL |
| イベント監視 | Sensu (Go) | イベント駆動監視 | エージェント＋メッセージバス | サーバ, アプリ | Web UI, API連携 | 柔軟なハンドラ | 中～大規模 | イベントベース, スクリプト自由度高 | Apache 2.0 |
| イベント監視 | Riemann | イベントストリーム監視 | ストリーミング型 | 任意（イベント） | カスタムUI, Grafana連携 | 高速通知 | 大規模 | 高スループット・相関アラート | EPL |
| ログ監視／分析 | Fluentd / Fluent Bit + (OpenSearch + Grafana) | ログ監視・集約 | エージェント＋集中収集 | OS, アプリ, コンテナ | Grafana / Kibana | アラートルール可 | 大規模 | ログ監視＋分析に強い | Apache 2.0 |
| 軽量監視 | Monit | プロセス監視・簡易復旧 | エージェント単体 | ローカルプロセス, サービス | Web UI（簡易） | メール通知 | 小規模 | 軽量、設定容易 | AGPLv3 |
なるほど、「総合監視」が実現できるような「OSS（Open Source Software）」が、そもそも候補としてほぼ存在しない説。
何だかんだ、消去法で「Zabbix」を利用せざるを得ないってことなのかもね...
ネットの情報を漁っていたところ、
⇧ 上記サイト様で、2016年度の「運用監視」系の「OSS（Open Source Software）」の比較しており、「ChatGPT」氏の回答では、「NTT データ」や「TIS」といった日本の企業が提供しているような「ソフトウェア」は取り上げられていなかった。
話を元に戻すと、勿論、「OSS（Open Source Software）」ではないのならば、「総合監視」を実現できる「ソフトウェア」で良いものがあるかもしれませんが、「OSS（Open Source Software）」で考えた場合、「Zabbix」の代替となり得そうな「総合監視」系の「ソフトウェア」が存在しないような気がするのよね...
まぁ、いずれにしろ、
- オンプレミス環境
- クラウド環境
のどちらでも利用できることは、最低条件になってくる気はしますな...
ちなみに、「運用監視」系の「OSS（Open Source Software）」について、変遷を知りたかったので、「ChatGPT」氏に質問してみたところ、以下のような回答が返ってきた。
🕰️ OSS（Open Source Software）監視ソフトウェア 登場年表
| 年 | ソフトウェア名 | 出典・背景・トピック |
|---|---|---|
| 1999年 | Nagios (当初は “NetSaint”) | 監視ソフトの元祖的存在。後に Nagios に改名（2002年）。プラグイン方式を確立。 |
| 2001年 | Monit | Unix系サーバの軽量プロセス監視ツールとして登場。自動再起動などシンプル運用に強み。 |
| 2004年 | Zabbix | ラトビア発。エージェント監視＋SNMP＋DB連携の総合監視ソフトとして登場。現在まで積極開発継続。 |
| 2006年 | OpenNMS（初版は2001頃、安定版リリースが2006） | 大規模ネットワーク監視プラットフォーム。商用版とOSS版を並行開発。 |
| 2007年 | Pandora FMS | スペイン発。Zabbix/Nagios影響下のフルスタック監視。Community版あり。 |
| 2009年 | Icinga（→後の Icinga 2 は2014年登場） | Nagiosからのフォーク。APIやWeb UIを強化したモダン監視へ。 |
| 2010年 | Sensu (Ruby版) | イベント駆動の次世代監視基盤として登場。2018年にGo版へ全面移行（Sensu Go）。 |
| 2011年 | Checkmk (v1.1.x) | Nagiosベースの高速化・自動検出監視を目指して登場。のちに独自監視エンジンへ発展。 |
| 2012年 | Riemann | ストリーミング処理ベースのイベント監視。リアルタイム性と柔軟なルール定義が特徴。 |
| 2012年 | Fluentd | Treasure Data により公開。ログ収集／監視パイプラインの基盤として普及。軽量版 Fluent Bit は2015年登場。 |
| 2012年 | Observium | ネットワーク機器のSNMP監視ツールとして登場。のちにLibreNMSのベースとなる。 |
| 2013年 | Prometheus | SoundCloud 社が開発。Pull型メトリクス監視の新潮流を作る。2016年にCNCFプロジェクトへ。 |
| 2014年 | LibreNMS | Observium のフォークとして誕生。コミュニティ志向で活発な開発を継続。 |
| 2016年 | Netdata | 高分解能リアルタイム監視ツールとして登場。導入即時に詳細なメトリクスを可視化。 |
| 2017年 | Thanos | Prometheus のスケールアウト／長期保存を実現するOSSとして発表。 |
| 2018年 | Cortex | Prometheus の分散ストレージ実装としてCNCF傘下で公開。 |
| 2019年 | Sensu Go | Sensu の Go 実装版（再設計版）として登場。クラウド／コンテナ向け強化。 |
| 2021年 | OpenSearch | Elasticsearch からのフォーク。OSSライセンス維持のため AWS により公開。 |
📈 補足：OSS（Open Source Software）監視史のざっくり流れ
| 時代 | 主なトレンド | 代表的ツール |
|---|---|---|
| 1990年代後半〜2000年代前半 | システム／サービス監視の誕生期（Ping, SNMP, スクリプト中心） | Nagios, Monit |
| 2000年代中盤〜2010年前後 | フルスタック監視・テンプレート化 | Zabbix, Pandora FMS, Icinga |
| 2010年代前半 | API化・自動検出・イベント駆動の進化 | Checkmk, Sensu, Riemann |
| 2010年代中盤 | クラウド／メトリクス中心監視へシフト | Prometheus, Grafana |
| 2015年以降 | コンテナ／分散アーキテクチャ・リアルタイム可視化 | Thanos, Netdata, Cortex |
| 2020年代〜 | OSS＋商用SaaS混在・AI運用（AIOps）へ移行 | Zabbix, Prometheus, OpenSearch系 |
なるほど、役割分担というか、棲み分けの傾向が進んでいるということなのか、「Zabbix」のような幅広く対応するという「ソフトウェア」が登場しなくなったということなのかしらね...
対応している「プロトコル」についても、「ChatGPT」氏に質問してみたところ、以下のような回答が返ってきた。
🛰️ OSS（Open Source Software）監視ソフトウェア 対応プロトコル・収集方式一覧
| ソフトウェア名 | 主な収集方式・プロトコル | 通信方向 | 対応監視対象 | 備考・特徴 |
|---|---|---|---|---|
| Zabbix | Zabbix Agent（TCP 10050/10051）, SNMP (v1/v2c/v3), IPMI, JMX, SSH, Telnet, HTTP(S) チェック, ICMP, VMware API, Cloud API(AWS/Azure/GCP) | プル / プッシュ両対応 | OS, NW機器, 仮想環境, クラウド | 非常に多彩。Zabbix Sender/Proxy で分散収集も可能。 |
| Nagios Core | NRPE (TCP 5666), NSClient++, SNMP, SSH, ICMP, HTTP(S) チェック, custom plugin | プル（基本） | OS, サービス, NW機器 | プラグインで任意プロトコルを拡張可能。 |
| Icinga 2 | NRPE互換, Icinga 2 API (HTTPS, REST), SNMP, SSH, HTTP(S), ICMP | プル / プッシュ（API） | OS, DB, アプリ, NW機器 | Nagiosプラグイン互換。REST API強化。 |
| Checkmk (Raw) | Checkmk Agent (TCP 6556), SNMP, Piggyback, Active Checks (HTTP, TCP, etc.) | プル | OS, DB, アプリ, NW機器 | 自動検出によるSNMP/Agent混在対応。 |
| Prometheus | HTTP (REST / /metrics), Node Exporter, cAdvisor, SNMP Exporter, Blackbox Exporter, Pushgateway（プッシュ時） | プル（基本） / プッシュ（例外） | アプリ, コンテナ, OS, NW機器 | Exporter経由で多様なソース対応。K8s Service Discoveryに強い。 |
| Thanos / Cortex | HTTP (gRPC / HTTP API), Object Storage (S3, GCS, etc.) | 双方向 / Pull+Push混在 | Prometheus データ | PrometheusのTSDBを拡張。監視プロトコルはPrometheus準拠。 |
| Netdata | Netdata Agent (HTTP API, Streaming), eBPF, SNMP, StatsD, Prometheus Exporter互換 | プル / プッシュ両方 | OS, アプリ, DB | 自前エージェント＋プラグインでメトリクス収集。 |
| LibreNMS | SNMP (v1/v2c/v3), ICMP, HTTP(S), Syslog, Agent (optional) | プル | NW機器, サーバ | ネットワーク監視に特化。自動検出が強力。 |
| Observium | SNMP (v1/v2c/v3), ICMP, Syslog | プル | NW機器 | LibreNMSのベース。Community版はSNMP中心。 |
| Sensu Go | API (HTTP/REST), TCP/UDP（エージェント通信）, スクリプト実行, StatsD | プッシュ（イベント駆動） | サーバ, アプリ | チェック結果をイベントとして送信。ハンドラで処理。 |
| Riemann | TCP/UDP (default 5555), HTTP, Graphite互換, StatsD | プッシュ | 任意（イベント） | 高速ストリーム処理。イベント集約に最適。 |
| Fluentd / Fluent Bit | TCP/UDP, HTTP, Syslog, Unix Socket, Kafka, MQTT, Cloud API, Elasticsearch API | プッシュ | ログ, メトリクス, IoTデータ | ログ監視の基盤として多様な入力プラグインあり。 |
| Monit | 内部エージェント, ICMP, TCP, HTTP(S), SMTP | ローカル / プル | ローカルプロセス, サービス | ローカル監視に特化。軽量。 |
| OpenNMS | SNMP, ICMP, HTTP, JMX, WMI, Syslog, Trap, API | プル / プッシュ | ネットワーク, サーバ, アプリ | 大規模ネットワーク監視用。 |
| Pandora FMS (Community) | Pandora Agent, SNMP, ICMP, WMI, SSH, TCP, HTTP | プル / プッシュ | サーバ, NW機器, OS, DB | エージェント＋SNMPのハイブリッド。 |
まぁ、「多機能」だと「学習コスト」も上がりますし、使いこなすのも大変ですからな...
とりあえず、「運用監視」のための「ソフトウェア」を導入して、「運用」の負担が軽減されなかったとしたら、本末転倒な気もしますしな...
後は、可能な限り「カスタマイズ」しなくても必要とする「機能」が実現できるのがベストではありますかね。
「カスタマイズ」の弊害については、
総合商社の丸紅が進める大規模なSAP S/4HANA Cloud移行プロジェクトが注目を集めている。従来のオールインワンシステムから脱却し、3つのシステムに分割する戦略的刷新を推進。海外26拠点への段階的展開では、当初計画で直面した「業務移行の壁」を乗り越えるため、プロジェクト手法を大幅に見直した。今回は「Fit to Standard戦略」「ユーザーエンゲージメント戦略」「展開手法の確立」の3つの工夫を通じて、アドオンを3,500本から200本へと大幅削減しながら、クリーンコアを実現した同社の取り組みを解説する。
SAP移行で一度は失敗した丸紅、プロジェクト中断からの『展開パッケージ』戦略でV字回復を遂げた舞台裏 (1/3)|EnterpriseZine（エンタープライズジン）
⇧「SAP」の移行の事例が有名ですかね。
「互換性」を担保してくれていれば良いのですが、「破壊的変更（Breaking Change）」になっていることがほとんどなので、可能な限り、余計なことはしないに限るのだが、「カスタマイズ」することでしか実現できない場合があるので悩ましいところだとは思うのだが、まぁ、「カスタマイズ」したが最後、雁字搦めで改修困難な状態になってしまうのよね...
所謂、「変更容易性」が著しく低下することは勿論のこと、「バージョンアップ」など「マイグレーション」の際に苦しむこと必至なのよね...
つまり、「カスタマイズ」で対応すると、結局のところ、「保守・運用」を担当する人の負担が増加することになるという話なのよね...
当然のことながら、
- 後のことは知らないが、兎にも角にも、ビジネスを優先して、直ぐに動くソフトウェアを作る
- 時間がかかるのは止むを得ないとして、運用・保守を見据えたソフトウェアを作る
の「トレードオフ」な気はするのだが、利益を上げなければならないのでビジネスを優先せざるを得ないのは分かるのだが、問題を先送りにされると、後進が苦しむことになるわけなのよね...
要するに「技術的負債」を先送りしていくしかない悪循環に陥って、最終的には、二進も三進もいかない状況になるので、手に負えなくなる前に「リファクタリング」していくことが重要なのだが、「リファクタリング」も後回しにされることが多いのが実情なのよね...
とは言え、
KISSの原則 (キスのげんそく、英: KISS principle) とは、「Keep it simple stupid.」（シンプルで愚鈍にする）、もしくは「Keep it simple, stupid.」（シンプルにしておけ！この間抜け）、もしくは「Keep it short and simple.」（簡潔に単純にしておけ）という内容の、1960年代の米国海軍において言われた、経験的な原理・原則の略語。その意味するところは、設計の単純性（簡潔性）は成功への鍵だということと、不必要な複雑性は避けるべきだ、ということである。
ソフトウェア開発
KISSの原則に反して、仕様が徐々に複雑化していくことは、ソフトウェア開発の世界でよくみられる。これは、「なし崩しの機能追加主義」として知られる。ソフトウェアが複雑になるにつれて、使い方を習得する時間が増えたり、操作に手間取ったり、どれが重要な機能なのか分からなくなったりする。さらには、ハードウェアへの要求スペックが高くなったり製品価格が高くなったりもする。しかし、大多数のユーザーが実際に使用する機能は、そのごく一部であったりする。ユーザへの負担や開発コストを考えると、単純なソフトウェアの方がユーザフレンドリかつ生産性が高い可能性がある。
⇧ 上記にあるように「シンプル」を保つことが「ソフトウェア開発」では非常に困難であると...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
