GitHubは5月21日（現地時間）、Eclipse向けAIコーディング支援プラグイン「GitHub Copilot for Eclipse」をMITライセンスのもとオープンソースで公開したと発表した。
これにより、利用者はGitHubリポジトリ（https://github.com/microsoft/copilot-for-eclipse）でソースコードを閲覧・学習できるほか、バグ報告や機能提案、プルリクエストによる改良にも参加できる。
⇧ 業務で「Eclipse」を最後に利用したのは、2022年頃になるのかな...
最近は、「VS Code（Visual Studio Code）」を利用することが多くなってしまったのだが、
Of 155 responses, 77 were posted on Bluesky, 62 on X and 16 on Threads
https://blog.pragmaticengineer.com/ide-that-software-engineers-love/
This data is likely to be biased towards early tech adopters and non-enterprise users, as I posted on social media, and self-selecting software engineers active on those sites who are likely to be up-to-date on new tools, and willing to adopt them. There were more replies from developers at smaller companies like startups or smaller scaleups, and very few respondents from larger companies.
https://blog.pragmaticengineer.com/ide-that-software-engineers-love/
⇧ 上記の「SNS」に対する「アンケート」の結果によると、
IDE that devs name as their favorites
https://blog.pragmaticengineer.com/ide-that-software-engineers-love/
⇧「Eclipse」は「Other」に含まれる模様...
一方で、
⇧ 上記のサイトによると、「Java」に限った開発では、「Eclipse」の利用者は「VS Code（Visual Studio Code）」と同じくらいの割合となっている模様...
まぁ、統計のデータが不明瞭なので、信頼できる統計とは言い難いのだが...
- コスト
- 実現できる機能
- 使い易さ
が重要になって来るとは思われますが、「フロントエンド」側の「開発」とかも考慮せざるを得ない「開発プロジェクト」だと、「VS Code（Visual Studio Code）」一択といった感じになって来てしまうのかな...
pmacctの処理の流れの全体像とかRDBMSのテーブルのカスタマイズとか
前回、
⇧ 上記の記事で、「pmacct」という「C言語」製の「ネットワークモニタリングツール」についての話に触れたのだが、
⇧ 上記サイト様にありますように、公式の「ドキュメント」が結構、不親切という...
とりあえず、「ChatGPT」氏に「処理の流れの全体像」について整理して欲しいと、お願いしたところ、以下のような回答が返ってきた。
※「アウトプット」先が「RDBMS（Relational DataBase Management System）」の場合を想定してます。
📌 処理の流れの全体像
※ 何回、壁打ちしても「ChatGPT」氏の「幻覚（ハルシネーション）」が改善されないので、「Google Gemini」にお願いした。
処理の流れの全体像
[ BGP Peer / Router ] [ Network / Interface / Device ]
| (BGP / BMP) |
v |
+----------------------------------------------------------------|----------------+
| pmacct framework | |
+----------------------------------------------------------------|----------------+
| [ BGP Collector ] v |
| +--------------------+ +--------------------------------+ |
| | pmbgpd | | [ Core Capture Daemons ] | |
| | (BGP/BMP Collector)| | (環境に応じて並列/個別起動) | |
| +---------+----------+ +--------------------------------+ |
| | | | | | |
| | (Internal BGP Table) v v v v |
| | +-------+-------+-------+-------+ |
| | |pmacctd|nfacctd|sfacctd|uacctd | |
| | |-------|-------|-------|-------| |
| | |pcap |NetFlow|sFlow |NFLOG | |
| | |packet |IPFIX |sample |input | |
| | +---+---+---+---+---+---+---+---+ |
| | | | | | |
| +-- (経路情報をルックアップ) --------+-------+-------+-------+ |
| | |
| v |
| +----------------------------------+ |
| | Aggregation Engine | |
| |----------------------------------| |
| | - Primitive Mapping | |
| | - Flow Normalization & Counters | |
| | - Cache / Hash Tables | |
| +-----------------+----------------+ |
| | |
| +---------------------+---------------------+ |
| v v |
| +-----------------------+ +-----------------------+ |
| | Classification | | Enrichment (Internal)| |
| |-----------------------| |-----------------------| |
| | - nDPI (L7 App Class) | | - BGP (AS, AS-Path) | |
| | - VLAN IDs | | - GeoIP Lookup | |
| | - Custom Primitives | | - BGP Communities | |
| +-----------+-----------+ +-----------+-----------+ |
| \ / |
| \ / |
| +--------------------+------------------+ |
| | |
| v |
| +----------------------------------+ |
| | Plugin Dispatcher | |
| +------------------+---------------+ |
| | |
| +-----------------+-----------------+-----------------+ |
| v v v v |
| +------------+ +------------+ +------------+ +------------+ |
| | SQL Plugin | |Kafka Plugin| |Print Plugin| |Memory/AMQP | |
| |------------| |------------| |------------| |------------| |
| | PostgreSQL | | JSON/Avro | | file/json | | RAM cache | |
| | MySQL | | streaming | | stdout | | RabbitMQ | |
| +------+-----+ +------------+ +------------+ +------------+ |
| | |
| v |
| +----------------------------+ |
| | SQL Query Builder | |
| |----------------------------| |
| | - INSERT/UPDATE generation | |
| | - sql_optimize_clauses | |
| +----------------------------+ |
+---------------------------------------------------------|-----------------------+
v (Network / Local socket)
+----------------------------+
| External RDBMS Backend |
|----------------------------|
| - PostgreSQL / MySQL |
| - acct tables |
| - Table Partitioning |
+----------------------------+
⇧ とりあえず、「幻覚（ハルシネーション）」を引き起こしていそうではあるのだが、「C言語」は門外漢なので、上記のような流れであると信じることにする...
「インプット（packet、flow、telemetory、など）」を「デーモン（pmacctd、nfacctd、sfacctd、uacctd など）」が受け取り、諸々の処理を経て、最終的に「プラグイン」の処理によって「アウトプット」先に出力する感じになるようですと。
📌 ソースコードの対応
※ 何回、壁打ちしても「ChatGPT」氏の「幻覚（ハルシネーション）」が改善されないので、「Google Gemini」にお願いした。
| レイヤー | コンポーネント群 | 役割（アーキテクチャ図対応） | 正確なソースコード位置（pmacct/src/） | データ形態 |
|---|---|---|---|---|
| ① Input / Collector Layer | pmacctd / nfacctd / sfacctd / uacctd | パケット / フロー / カーネルイベントを取得するデーモン群 | src/pmacctd.c src/nfacctd.c src/sfacctd.c src/uacctd.c（※ディレクトリではなく、src直下のソースファイル） |
raw packet / NetFlow / IPFIX / sFlow / NFLOG |
| pmbgpd / pmbmpd | BGP / BMP テレメトリ収集（ルーティング情報） | src/bgp/bgp.c src/bmp/bmp.c などの各ディレクトリ内 |
routing updates / telemetry | |
| ② Decode / Normalize Layer（core入口） | flow decoders | 各プロトコルを共通フォーマットへパース・変換 | src/pkt_handlers.c src/net_aggr.c src/ip_flow.c src/pretag_handlers.c（※src/netflowやsrc/sflowという独立フォルダは存在しない） |
normalized flow |
| ③ Core Processing Layer | aggregation engine | フロー集約（キー単位の統合） | src/net_aggr.c src/ip_flow.c src/pmacct-data.h |
aggregated flow records |
| cache / hash tables | 状態管理・高速ルックアップ（内部テーブル管理） | src/hash.c src/purging.c |
in-memory state | |
| flow normalization | 異種入力の統一形式化（コアデータ構造体） | src/pmacct-data.h （基本データ構造 struct __data 等） |
unified flow struct | |
| ④ Enrichment / Classification Layer | BGP enrichment | AS_PATH / prefixなどのルーティング情報をデータ面に付与 | src/bgp/ src/bmp/ と連携するコア処理（src/net_aggr.c 内のルックアップ） |
enriched flow |
| GeoIP enrichment | 地理情報（MaxMind GeoIP等）の付与 | src/geoip.c src/geoip2.c |
geo-tagged flow | |
| nDPI / L7 classification | ディープパケットインスペクションによるアプリ識別 | src/ndpi.c（※src/classifierというフォルダはない） |
classified flow | |
| VLAN / L2 tagging | L2情報（MAC/VLAN等）のタグ付け | src/pkt_handlers.c src/pretag_handlers.c |
tagged flow | |
| ⑤ Plugin Dispatch Layer | plugin dispatcher | 各プラグイン（出力プロセス）への共有メモリ/パイプ等を通じたルーティング | src/plugin_hooks.c src/plugin_common.c |
plugin API event |
| plugin API | 共通プラグインインタフェース（基底構造） | src/pmacct-plugin.h src/plugin_common.c |
plugin calls | |
| ⑥ Output Plugin Layer | SQL plugin (MySQL, PostgreSQL, SQLite) | リレーショナルデータベースへの出力 | src/mysql_plugin.c src/pgsql_plugin.c src/sqlite3_plugin.c（※これらはすべてsrc/直下にフラットに存在。plugins/sql/という階層はない） |
SQL rows |
| Kafka plugin | ストリーミング・メッセージキュー出力 | src/kafka_plugin.c |
JSON / Apache Avro | |
| Print plugin | 標準出力 / ファイルへのテキスト・JSON出力 | src/print_plugin.c |
text / json | |
| Memory plugin | RAM上のメモリテーブル保持（外部からpmacctクライアントツールで読込） | src/memory_plugin.c |
in-memory tables | |
| AMQP plugin | RabbitMQ等へのメッセージキュー出力 | src/amqp_plugin.c |
message queue | |
| Forwarding plugin (補足) | 他のコレクタへの再転送・エクスポート（オプション） | src/nfprobe/ (NetFlow/IPFIXエクスポート)src/sfprobe/ (sFlowエクスポート) |
NetFlow / sFlow packet | |
| ⑦ SQL Processing Layer（plugin内部） | SQL query builder & mapping | 動的なSQL文（INSERT/UPDATE）の生成、内部スキーマのマッピング | src/sql_common.c src/mysql_plugin.c などの各SQLファイル内（※独立したsql/ディレクトリはない。テーブル初期化用SQLスキーマ自体はリポジトリのルートにある sql/ フォルダに格納されているが、ソースコードは src/ 直下） |
SQL statements / relational schema |
| ⑧ Storage Layer | PostgreSQL / MySQL / SQLite / Kafka 等 | 永続化・分析（ pmacct の外に構築されるエコシステム） | 外部ミドルウェア（pmacct外） | historical flow DB / Stream |
📌 処理のまとまり毎にレイヤー分けした情報との対応
※ 何回、壁打ちしても「ChatGPT」氏の「幻覚（ハルシネーション）」が改善されないので、「Google Gemini」にお願いした。
┌──────────────────────────────────────────────────────────────┐
│ INPUT / COLLECTOR LAYER │
│ (プロトコル別の入口：各デーモンのメインロジック) │
├───────────────┬───────────────┬───────────────┬─────────────┤
│ pmacctd │ nfacctd │ sfacctd │ uacctd │
│ libpcap │ NetFlow/IPFIX │ sFlow │ NFLOG │
│ packet-based │ flow-based │ sampled flow │ kernel flow │
├───────────────┴───────────────┴───────────────┴─────────────┤
│ src/pmacctd.c src/nfacctd.c src/sfacctd.c src/uacctd.c │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ OPTIONAL TELEMETRY EXTENSIONS │
├───────────────┬──────────────────────────────────────────────┤
│ pmbgpd │ BGP route collector (AS/path enrichment) │
│ pmbmpd │ BMP telemetry collector │
├───────────────┴──────────────────────────────────────────────┤
│ src/bgp/bgp.c src/bmp/bmp.c │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ CORE PROCESSING LAYER (pmacct core) │
│ │
│ 1. normalization & decode (pkt_handlers.c, ip_flow.c) │
│ 2. aggregation engine (net_aggr.c, ip_flow.c) │
│ 3. cache / hash tables (hash.c, purging.c) │
├──────────────────────────────────────────────────────────────┤
│ src/net_aggr.c src/ip_flow.c src/hash.c src/pmacct-data.h │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ ENRICHMENT & CLASSIFICATION LAYER │
│ │
│ - BGP enrichment (src/bgp/ と連携した内部ルックアップ処理) │
│ - GeoIP enrichment (src/geoip.c, src/geoip2.c) │
│ - nDPI L7 classification (src/ndpi.c) │
│ - VLAN / L2 / pre-tagging (pkt_handlers.c, pretag_handlers.c)│
├──────────────────────────────────────────────────────────────┤
│ src/geoip.c src/ndpi.c src/pretag_handlers.c │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ PLUGIN DISPATCH LAYER │
│ │
│ → plugin dispatcher & common API (plugin_hooks.c / _common.c)│
├───────────────┬───────────────┬───────────────┬─────────────┤
│ SQL plugin │ Kafka plugin │ Print plugin │ Memory │
│ AMQP plugin │ nfprobe │ sfprobe │ etc... │
├───────────────┴───────────────┴───────────────┴─────────────┤
│ src/mysql_plugin.c src/kafka_plugin.c src/print_plugin.c │
│ src/pgsql_plugin.c src/amqp_plugin.c src/memory_plugin.c│
│ (※すべて src/ 直下にフラットに配置。エクスポート用のみ一部フォルダ化)│
│ src/nfprobe/ src/sfprobe/ │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ OUTPUT / STORAGE LAYER │
├───────────────┬───────────────┬───────────────┬─────────────┤
│ PostgreSQL │ MySQL │ Kafka stream │ Files/JSON │
│ (acct tables) │ │ │ │
├───────────────┴───────────────┴───────────────┴─────────────┤
│ 外部ミドルウェア（pmacctのスコープ外、sql/ フォルダに初期化用スキーマ有）│
└──────────────────────────────────────────────────────────────┘
⇧ と言った感じの分類になるそうな。
ちなみに、「Google Gemini」に追加で質問してみた。
結論から言うと、「テーブル（データベース側）にはすべての器（カラム）が用意されているけれど、デフォルトで全部にデータが入るわけではない」というのが正確な仕様です。
リンクしていただいた pmacct-create-table_v9.pgsql の中身を見ると、確かに ip_src, ip_dst, port_src, port_dst, as_src など、ほぼすべての項目がテーブル定義（CREATE TABLE）に含まれていますよね。
これが「すべて有効に見える」理由ですが、pmacctがデータを書き込む際は、aggregate で明示的に指定した項目以外はすべて「0」や「空文字（デフォルト値）」として保存される挙動になります。
⚠️ 注意：不要なカラムをそのままにすると負荷になる
この「すべての器を用意しておく」方式（sql_table_type: typed）は手軽ですが、集計にインデックスを貼る際や、ディスク容量の面で無駄が発生しやすくなります。
もし本番環境などで「送信元/宛先IPとポートだけでいい。他は完全に削りたい」という場合は、以下のようなアプローチをとるのが一般的です。
- SQLファイルを自分でカスタムする
不要なカラム（as_srcやmac_srcなど）をごっそり削除したマイテーブルを手動で作成する。 - pmacct側に「カスタムテーブルだよ」と教える
設定ファイルにsql_dont_blame_less_fields: trueというオプションを書き加えます。これを書くと、pmacctは「テーブルに足りないカラムがあってもエラーを出さずに、aggregateで指定された項目だけをスマートに書き込む」ようになります。
公式の「GitHub」の「Wiki」の「RDBMS: Customising the SQL database schema」のページによると、
⇧ とあり、
- 設定ファイルに設定を追加
- DDL（CREATE TABLE文など）に反映
を用意して、テーブルを作成しておいた後で、「pmacct」の「デーモン」を起動しておく必要がありますと。
ちなみに、「アウトプット」先が「pmacct」が稼働しているマシンとは別のマシンの「PostgreSQL」になっている場合、設定ファイルの「データベース」の「接続情報」の「ホスト」で「IPアドレス」の指定が必要になりそうよね...
ついでに、「フィルター」などの「機能」が用意されているのか、「Google Gemini」に質問してみたところ、以下のような回答が返ってきた。
はい、不要なデータをPostgreSQLに INSERT（または UPDATE）させないための強力なフィルター機能が、pmacctには複数用意されています。
ネットワーク上のすべてのパケットを律儀にデータベースに入れていると、すぐにディスクがパンクしてしまいます。そのため、実運用ではフィルターを使って「特定のトラフィックだけをデータベースに保存する」のが一般的です。
用途に合わせて3つのレイヤー（階層）でフィルターをかけることができます。
📌 レイヤー1：グローバルフィルター（一番手前で一括カット）
デーモンがパケットをキャプチャした瞬間に、「そもそも集計対象にすらしないデータ」を秒速で間引くフィルターです。Linuxでおなじみの tcpdump (libpcap) と全く同じ構文 が使えます。
設定キー: pcap_filter （※pmacctd などのパケットキャプチャ版で有効）
# 例: 192.168.1.0/24 セグメントの通信だけを収集し、それ以外はすべて無視（INSERTもしない） pcap_filter: net 192.168.1.0/24 # 例: DNS通信(Port 53)やSSH(Port 22)はノイズになるのでデータベースに保存したくない pcap_filter: not port 53 and not port 22
📌 レイヤー2：プラグイン個別フィルター（プラグインごとに仕分ける）
pmacctは「PostgreSQLへ保存するプラグイン」と「ログファイルに書き出すプラグイン」などを同時に動かせます。「PostgreSQLにだけは、特定のデータを入れたくない（あるいは入れたい）」という場合にこれを使います。こちらも tcpdump 構文です。
設定キー: aggregate_filter[<プラグイン名>]
# プラグイン定義 plugins: pgsql[my_postgres_db] # ★my_postgres_dbプラグインに渡すデータだけを制限する # 例: Webトラフィック（HTTP/HTTPS）のデータだけをPostgreSQLにINSERTする aggregate_filter[my_postgres_db]: port 80 or port 443
📌 レイヤー3：プレタギング・マップ（複雑な条件で選別・除外する）
「IPアドレス」「ポート番号」「AS番号」「受信インターフェース」などを複雑に組み合わせたルールを作って、合致したものだけを保存（または除外）する高度な機能です。
外部に pretag.map のようなテキストファイルを作成し、それを読み込ませて制御します。
設定キー: pre_tag_map
設定ファイル（pmacctd.conf）側：
plugins: pgsql aggregate: src_host, dst_host, tag pre_tag_map: /etc/pmacct/pretag.map
マップファイル（/etc/pmacct/pretag.map）側：
# ファイアウォールのように「上から順に」評価されます # 例①: 特定の危険なIP(10.0.0.5)からの通信は、タグ「999」をつけて通過させる set_tag=999 src_host=10.0.0.5 # 例②: それ以外の通信は、すべて「フィルタ（除外）」してデータベースに入れない # （何もsetせず、filter=true にするとそのパケットは破棄される） filter=true ip=0.0.0.0/0
💡 まとめ：どれを使うべき？
- 「そもそもDBに保存する必要のないプロトコルやセグメントがはっきりしている」
👉 pcap_filter を使うのが最もCPU負荷が低く、おすすめです。 - 「PostgreSQLには特定の社内サーバーの通信だけを記録したい」
👉 aggregate_filter で対象のIPを指定するのが最も手軽です。
⇧ う～む...
設定ファイルの内容次第ということなんだろうか...
兎にも角にも、「pmacct」を利用した「アプリケーション」の開発において、独自のカスタマイズをするのは構わないのだが、どこまで手を加えているのか「ドキュメント」に「仕様」を残しておいて欲しいお気持ち...
とりあえず、
⇧ 上記サイト様のような過激派もおられるのだが、「pmacct」とかも「C言語」以外の「プログラミング言語」に「リファクタリング」できないものなのかしら...
「低レイヤー」の処理だと、「C言語」を利用せざるを得ないということなのかね...
「Linux」の「カーネル」も一部に「Rust」が導入され始めたぐらいの状況っぽいので、脱「C言語」は現実的には厳しいのかもしれない...
とは言え、
⇧ 一般的な「Web」系の「ソフトウェア開発」においては、脱「C言語」の方向性を目指していそうな感じではあるのよね...
まぁ、
⇧ 大学や専門学校などの「情報学科」で履修できる時間のある方は良いのだが、文系出身の社会人の状態で、学習時間を捻出するのが困難というのはありますな...
何となく、「Web」系の「ソフトウェア開発」において、「C言語」が必要となるケースが希少という気がするので、「C言語」を学習する「費用対効果」として「メリット」が薄いというのもあり、「モチベーション」は上がらないわな...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
