翻訳元: https://collectd.org/
collectd Wiki: https://collectd.org/wiki/index.php/Main_Page
個人的趣向が入った編集となっている点にご注意ください。
Start page
collectdはシステムのパフォーマンス情報を周期的に収集し、多様な形式（たとえばRRD）で保存するデーモン。
What does collectd do?
collectdは、collectdが動作しているシステム上のパフォーマンス統計値を収集、保存する。この統計値はパフォーマンスに関するボトルネックの発見（パフォーマンス解析）や将来のシステム負荷予測（キャパシティプランニング）に利用される。また、ユーザが保有するサーバ上でグラフ化することもできる。（翻訳元では、例としてCPU使用率のグラフを表示している）
Why collectd?
collectdと同様の機能をもつオープンソースツールは存在し、そのいくつかはここのSimilar projectsの項にまとめた。ここではcollectdをなぜ使うべきかについて述べる。
collectdは他のツールに比べ、いくつかの優位点がある。例えば、__C言語で記述__されているためパフォーマンスや軽量さの点で優れている。特に、スクリプト言語やクーロンデーモンを要しない組み込み系システムにも活用でき、同時に数百規模のデータセットを扱うことができる。また、__90を超えるプラグイン__が存在するため、高い拡張性を有すると共に用途に特化した使用方法もできる。さらに、積極的な開発が今も続けられ、ドキュメントも整っている。他にも多くの特長があるので、こちらを参照されたい。
Limitations
- collectdそのものはグラフ化機能を提供しておらず、あくまでRRD等のデータベースにデータを保存するだけである。kcollectdやdrrawといった他のツールと組み合わせて、グラフ表示させることはできる。
- モニタリング機能はversion 4.3から導入されたものの、シンプルな閾値チェック機能しかサポートしていない。Nagios等と組み合わせることはできる。
Features
Modularity/Portablity
collectdの機能はコンフィグパーサを除き、プラグインによって提供される。つまり、メインのcollectdデーモンは外部依存性を持たず、POSIX(Portable Operating System Interface)と呼ばれるような共通のAPIを提供するのみである。デーモンはLinux、Solaric、Mac OS X、AIX、FreeBSD、NetBSD、OpenBSDで動作確認されている。(SSC ServではWindowsをサポートしている)
Reasonable defaults
collectdのコンフィグは簡易さの維持に努めており、デフォルトでは特にコンフィグ変更を加えなくても動作するようになっている。ユーザの用途に応じて、コンフィグ変更ももちろんできる。
High-resolution statistics
他のツールと異なり、collectdはC言語で記述されているのでパフォーマンスや軽量さに利点がある。デーモンはメモリ上に常駐するため、値を取得するための起動に都度重い割り込み処理が走ることはない。デフォルトでは10秒間隔で収集する。10分間隔で収集し、グラフ表示させた場合において、小さな組み込みソフトウェアルータであるOpenWrtで動作させてもCPUにほとんど影響を与えなかった。
Sophisticated network code
collectdはデータプッシュ型モデルを利用している。つまり、収集されたデータはサーバやマルチキャストグループに送信（プッシュ）される。そのため、クエリ（データ収集リクエスト）は必要ない。
収集データの送信はIPv4のユニキャストだけでなく、IPv6やマルチキャストに対応している。データの送信と受信に関するコンフィグは別々に設定することができ、以下のネットワークモードに対応している。
- No networking: network-pluginを動作させなければ、送信されない。
- Multicast: マルチキャストグループとしてデータの送受信をする。ローカルネットワーク上で多くのクライアントを少数のサーバで管理する場合に有効である。
- Unicast: 特定のホストにデータを送信する。
- Proxy operation: データをフォワードする。
ネットワークプロトコルは軽量なので、ネットワークの帯域は圧迫しない。プロトコルはオープンなので、既存機能を維持しつつ、将来的に新機能を追加することも容易である。
Custom extensions
collectdの機能拡張の手段はいくつかある。
- C-plugins: collectdデーモンから直接ロードされる。開発サイクルは長期間に及ぶものの、パフォーマンスは最も良い。
- Perl-plugins: Perl-interpreterをデーモンに埋め込み、C言語とPerlモジュールの互換性を提供する。拡張機能をPerlを用いて実装することができるようになる。
- Java-plugins: Java Virtual Machine(JVM)をデーモンに埋め込み、Javaのプラグインを実行する。拡張機能をJavaを用いて実装することができるようになる。
- Python-plugins: Python-interpreterをデーモンに埋め込み、C言語とPythonモジュールの互換性を提供する。拡張機能をPythonを用いて実装することができるようになる。
- UNIX domain socket: UNIXソケットを活用することで、収集データのソケット通信を実現できる。
- Execute binaries or scripts: バイナリやスクリプト実行環境を提供する。
- Java MBean support: jcollectdを用いたネットワークプロトコルのpure-java実装を提供。
Built to scale
collectdは数千規模に及ぶ複数のホストを操作でき、効率的にリソースを活用できる。例えば、複数のrrd-updatesを一度のオペレーションで実行、各collectdで収集された統計値の最大値をネットワークに送信などなど。IOに問題がなければマルチスレッドで収集を実行することも可能である。
SNMP support
SNMP pluginはNet-SNMPライブラリを活用して、パフォーマンスの収集、送信を実施することができる。CPUの貧弱なシステムに対してSNMPクエリを実施する場合はホストに応じて適切なインターバルを設定する必要がある。
Integration with monitoring solutions
version 4.3以降では、notificationsとthresholds機能を提供している。しかし、collectdはモニタリングツールではない点に留意してもらいたい。collectdとNagiosを組み合わせる手段もある。
FAQs
Q. 上手く動作しない場合の診断方法は？
A. log plugin、主としてLogFileやSysLog pluginをロードする。log pluginをロードしない場合、標準エラー出力として表示されるが、バックグラウンド実行された場合は出力を確認することはできない。
Q. ping-pluginを導入したが、ping_host_add failed.メッセージが出力される。何が問題なのか？
A. ICMPパケットを送信するためには、いわゆる'RAW socket'をオープンする必要がある。多くのUNIXシステムはこのソケットを開くにはルート権限が必要である。
Q. マルチキャストを受信するのは誰か？
A. ネットワーク構成に依存する。デフォルトでは、collectdはローカルアドレスを使うので、ASは超えられない。
Q. コンパイル時のライブラリ関連付け方法は？
A. 一般的ではないライブラリパスを用いてライブラリをインストールするには、configure実行時に明記する必要がある。そうでなければ、ライブラリと関連付けられない。例えば、 /opt/rrdtool-x.y.zに対しては、
$ ./configure --with-librrd=/opt/rrdtool-x.y.z
Q. バージョン数の意味は？
A. バージョンはmajor、minor、patchlevelの3つから成る。majorバージョンが違えば、基本的には互換性はなく、rrdファイルやコンフィグの定義方法も異なる。minorバージョンが違いについては、過去のminorバージョンに対しては互換性があり、これは機能追加はあっても機能削除はないことを意味する。patchlevelはバグフィックスの違いはあるものの、機能の追加削除はなく、互換性は維持される。
Q. --enable-fooを用いて、foo-pluginをオンにしようと試みたが失敗する。なぜ？
A. その結果は正常であり、コンパイル時に依存性の解決ができていないため、プラグインがオンにできない。一般的には、依存性を解決した後、コンパイルし直すことが望ましい。
Q. collectdのDebianパッケージをインストールしたが、“lt_dlopen (foo.so) failed: file not found”のエラーが出る。
A. collectdのDebianとUbuntuパッケージはすべてのプラグインが含まれている。しかしそれらすべてのプラグインに必要とされるライブラリの依存関係を含んではいない。そのため、ライブラリが足りていないか、/usr/share/doc/collect-core/README.Debian.pluginsを確認してほしい。
Q. ビルドにおいて"relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC"
A. 多くのディストリビューションは'static libraries'内のライブラリを活用するため、ライブラリのコンパイルは不要であるが、一部のディストリビューション（特にi386系）ではコンパイルに失敗するため、ライブラリに対し、'--fPIC'オプションをつけてコンパイルする必要がある。
Q. 多くのプラグインが、例えばCPU pluginもそうだが、収集メトリックが別々のファイルで管理されているのはなぜか？
A. 後方互換性を維持するため。
Q. collection.cgiは正しくグラフ表示できないのはなぜか？
A. このスクリプトはユーザの開発のスタートポイントとしての役割であり、ウェブフロントエンドに適用できるようなものではない。
Q. なぜCPU状態の和の上限が100%ではないのか？
A. デフォルトではCPU pluginはCPU使用率をパーセンテージではなく、'giffies'（ticks単位）で収集している。パーセント表示がいいなら ValuesPercentageオプションをtrueにすればいい。jiffyのタイムユニットはOSのスケジューラに依存する。Linuxでは100jiffies/secであるため、多くのユーザが%表記であると誤解しがちである。
Q. ネットワークトラフィックは暗号化されているのか？
A. version 4.7.0からHMACに対応。
Documentation
collectdのドキュメントはmanページで確認することもできる。ソースに関する一般的な項目はREADMEファイルにも記述されている。
Manual pages
manによるヘルプをhtml化したもので、少し古い場合もある点に注意。
collectd(1) ※重要
collectdmon(1)
collectd.conf(5) ※重要
collectd-email(5)
collectd-exec(5)
collectd-nagios(1)
collectd-perl(5)
collectd-python(5)
collectd-java(5)
collectd-snmp(5)
collectd-tg(1)
collectd-unixsock(5)
types.db(5) ※重要
collectd Wiki
ドキュメント整理の容易化のため、いくつかのドキュメントをWikiに移行している。
collect Wiki
Special documentation
以下のドキュメントはデーモンに関する特別なユースケースについて記述している。
First steps with collectd
Networking introduction
Inside the RRDtool plugin
Notifications and thresholds
Introduction to chains, collectd's filtering mechanism
collectd v3 to v4 migration guide
General development information and documentation
How to Report Bugs Effectively
Reference documentation
各プロジェクト（プラグイン）に関する技術的なドキュメントは各々で整理されている。上記のmanual pagesで参照できるが、以下に特定のページを取り上げる。
Plugins: 全プラグインのリスト。機能の簡易説明あり。
Libraries / Dependencies: 各プラグインが使用するライブラリとその依存関係のリスト。
Configuration options: コンフィグの記述方法。
Contributors: コントリビュータ一覧。
Development Information
Git repository
現開発物についてはGitリポジトリ(Github)に保存されている。最新の開発バージョンのcollectdを入手するためには以下のコマンドによりgitリポジトリをクローンする。クローンしたら、'automake'と'autoconf'ファイルを生成し、'build.sh'で実行。
# Canonical repository
$ git clone git://git.verplant.org/collectd.git
# Github mirror
$ git clone git://github.com/collectd/collectd.git
Bugtracking system
GitHub issuesによりバグ管理を実施している。
Development articles
collectd's plugin architecture: プラグインの技術的な概要
collectd's build system: autotools-based build-system(automake、autoconf)の説明
Submitting patches: パッチ投稿方法
A few words on coding style: コーディング規約
Roadmap: 実装予定の機能