# Graphite 2006 年開始のオープンソース監視プラットフォーム。whisper ストレージライブラリ・carbon 書き込みデーモン・graphite-web 読み込み UI の 3 コンポーネントで構成される。[[Mackerel]] が 2018 年以前に使用していた時系列データベース基盤。 ## アーキテクチャ ``` クライアント → carbon-cache → whisper ファイル ← graphite-web ↑ ↑ メモリバッファ CARBON_LINK でマージ ``` | コンポーネント | 役割 | 実装の特徴 | |---|---|---| | **whisper** | RRD ストレージ | 固定サイズ・ローリング・Rollup Aggregation | | **carbon-cache** | 書き込みデーモン | Twisted 非同期 I/O、2 スレッド上限 | | **carbon-relay** | 書き込みプロキシ | シャーディング・レプリケーション | | **graphite-web** | 読み込み UI | Django、CARBON_LINK でメモリデータをマージ | ## whisper のラウンドロビン設計 whisper は RRDtool の後継として設計された時刻束縛型ストレージ。ファイルサイズを作成時点で固定し、複数 archive（精度×保持期間の組）を定義することで古いデータを Rollup Aggregation で粗精度に変換する。 - **利点**: ディスク使用量が一定（予測可能な容量計画） - **制約**: 過去データの上書き・精度劣化は避けられない。古いデータを高精度で保持したい場合は archive 設定の変更とディスク増強が必要 この設計は [[HeteroTSDB]] の「追記型 + TTL tiering」や [[Gorilla]] の「圧縮インメモリ + HBase」とは異なるアプローチで、2006–2015 年の監視 TSDB における代表的設計だ。 ## carbon-cache の CPU 限界 Twisted フレームワークベースにより実質 2 スレッド上限。マルチコアスケールには carbon-relay を前置して consistent-hashing で複数プロセスに分散する必要がある。この制約が [[Mackerel]] の多段 carbon-relay 構成を生んだ。 ## レプリケーションと一貫性 carbon-relay のレプリケーションはバイナリログなし・一貫性保証なし。ノード復旧は rsync による同期が標準（DRBD は全方位書き込みでネットワーク帯域が限界に達するため不採用）。監視 TSDB における「CP より AP」の典型的選択。([[@2015__yuuk.io__High-Performance-Graphite]]) ## Mackerel での運用と廃止 [[Mackerel]] は 2015 年頃まで Graphite を採用し、1 分あたり 100,000 件以上のメトリクスを処理していた。2018 年に [[HeteroTSDB]] へ移行し Graphite の運用を終えた。移行動機はマルチコアスケール限界・ページキャッシュ圧迫・一貫性なしレプリケーションなどの構造的制約。([[@2015__yuuk.io__High-Performance-Graphite]]) ## 開発状況（2015 年時点） stable バージョン 0.9.12。テストコードが少なくプルリクエスト承認率が低い状態だった。次世代実装として Megacarbon と Ceres が開発中だったが、Mackerel は独自の HeteroTSDB へ移行する道を選んだ。 ## 関連 - 本ソース: [[@2015__yuuk.io__High-Performance-Graphite]] - 採用サービス: [[Mackerel]] - 後継（Mackerel): [[HeteroTSDB]] - 著者（記事): [[Yuuki Tsubouchi]] - 関連概念: [[時系列データベース]] / [[ラウンドロビンデータベース]] - 先行技術: RRDtool