【Graphiteの監視の基本】アーキテクチャとその概念

Graphiteは、主要なオープンソースの時系列メトリック監視システムです。 Graphiteは最初に2008年にリリースされ、SNMPなどの苦痛なプロトコルを必要とせずに、外部システムからのメトリックデータを取り込んで処理する独自のネットワークベースのアプローチを導入することにより、組織が時系列データを監視する方法を近代化しました。 MetricFireではHosted Graphiteというサービスを提供しております。今すぐ無料トライアルを試して、Graphiteインストールのセットアップと管理をスキップできます。 この記事は2部構成のシリーズのパート1です。 このシリーズを見て、Hosted Graphiteが舞台裏で何が起こっているのかを確認してください。 ここで、Graphiteのインストールとセットアップに関する記事をご覧になりたい方はこちらを確認してください。

基本概念

このセクションでは、Graphiteの仕組みを説明し、重要な概念を強調します。

アーキテクチャ

以下で説明する最初のアーキテクチャは、中小規模の環境のニーズに対応することを目的とした単一のサーバーインスタンスで構成されています。 2つ目は、いくつかのGraphiteインスタンスで構成され、大規模な環境や分散環境のニーズに対応します。

単一インスタンスのアーキテクチャと制約

Graphite監視環境の基本的なアーキテクチャは次の図のようになります。クライアントがネットワークを介してデータをフィードするハンドラー（つまり、カーボンキャッシュ）を提供する中央サーバーがあります。 Graphiteは、データ収集のプッシュアプ​​ローチを使用しているため、各クライアントがデータをサーバーにプッシュするタイミングを決定できます。これは、プルプロポーザル（たとえば、Prometheusで使用される）とは対照的に、クライアントからデータを収集するタイミングを決定するのはサーバーということになります。このプッシュアプ​​ローチには、すでにここで説明したように、利点と欠点があります。詳しい説明はしませんが、Graphiteに関して次の点を考慮する必要があります。

• 各クライアントは、サーバーがサーバーに送信されたデータを受信および取り込めない場合を認識し、処理できる必要があるのでご注意ください。
• Graphiteでサポートされているプロトコルとデータ形式を使用してネットワーク経由でサーバーにデータを送信できる限り、Graphiteクライアントは、選択した言語に関係なく、どのようなソフトウェアでもかまいません。これらのプロトコルとデータ形式については、このセクションの後半で説明します。
• 各クライアントがいつデータをサーバーにプッシュするかを決定することは、特にサーバーが一度に多くのクライアントからの高頻度のデータを取り込むことができることを意味します（特に大規模環境で）。そうでない場合、監視はスケーリングしません。この側面を考慮して、Graphiteはさまざまな機能と展開戦略を活用して、小規模、中規模、および大規模の監視環境をカバーできます。次に、これらの機能のいくつかについて説明します。可能な場合は、読者が議論されない概念にさらに進むために役立つリンクを追加します。

サーバーと3つのクライアントを備えた基本的なGraphiteアーキテクチャです。サーバーにより、カーボンキャッシュハンドラーは、これらのクライアントによってプッシュされたメトリックデータを収集して取り込むことができます。

マルチインスタンスアーキテクチャ

Graphiteは、ストレージの前にメトリックのメモリ内キャッシュを使用するなど、効率的な取り込み機能を提供します。ただし、クライアントの数が多い環境や、データを頻繁に取り込む必要がある環境では、単一のサーバーインスタンスでは、負荷をサポートするのに十分ではない場合があります。Graphiteには、これらの状況に対処するための高度な導入機能があります。

次の図に、従来の分散型展開シナリオを示します。このようなシナリオでは、他の一連のGraphiteインスタンスの負荷分散フロントエンドとして機能する特別なGraphiteインスタンスがありま、このフロントエンドインスタンスは、カーボンリレーと呼ばれる特別なハンドラーを有効にします。その役割は、クライアントからデータを収集し、追加の処理なしでそれらを他のインスタンスにディスパッチすることです。したがって、構成で事前定義されたルールに従って、着信データを他のインスタンスに転送するロードバランサーとして機能します。各バックエンドインスタンスにより、カーボンキャッシュハンドラーは、受け取ったメトリックを収集、取り込み、保存できます。カーボンリレーハンドラーはカーボンキャッシュと比較して複雑な処理を行わないため、このアーキテクチャーを使用すると、データフィードの頻度が高い場合でも、Graphite環境を簡単にスケーリングして多数のクライアントをサポートできます。

負荷分散を備えたGraphiteアーキテクチャ-カーボンリレーハンドラーを有効にするフロントエンドグラファイトサーバーがあり、メトリックを収集して、それらのメトリックの収集、取り込み、保存を有効にしたカーボンキャッシュデーモンを備えた他のGraphiteサーバーにディスパッチします。

メトリックの集計

Graphiteは、時間サンプリングの最も詳細な解像度が1秒であるメトリックを処理します。つまり、同じタイムスタンプ（秒単位）でメトリックの複数のサンプルが収集された場合、それらのサンプルをGraphiteに個別に保存することはできません。このような状況に対処するために、Graphiteは、構成された期間内に受信したすべてのサンプルを収集するように構成できる特別なハンドラー（つまり、カーボンアグリゲーター）を提供します。合計や平均などの関数を使用してそれらを集約し、格納可能な単一のメトリックを生成します。これらのケースでは、StatsDをGraphiteの前に配置して、1秒未満の解像度でデータを集計することも一般的です。

Graphiteのアグリゲーターの機能は、以下のような他のさまざまなユースケースにも対応しています。

1. メトリックに必要な精度が、サンプルを受信する頻度よりも低い場合。たとえば、メトリックが数秒ごとに受信されるシナリオを想像してください。しかし、5分ごとに平均メトリックを提供するだけの分析が必要です。
2. 次に、ストレージ容量を最小限に抑えるために、集約を有効にすることができます。
3. ユーザーが特定の間隔で受信したサンプルの合計を取得するだけの場合。例として、特定のサービスによって毎秒受信されるリクエスト数をプッシュするメトリックコレクターを考えますが、5分ごとに受信されるメトリックの量を示す分析が必要です。

TCP / UDPデータフィード

Graphiteネットワークハンドラーは、TCPまたはUDPモードで有効にできます。 TCPモードで有効にすると、各クライアントとサーバー間のデータ交換はTCPプロトコルの信頼性を活用し、データの損失がないことを保証します。 ただし、これは、TCPプロトコルの信頼性を確保するために必要な同期が原因で、各データ交換により遅延オーバーヘッドが発生することを意味します。 このような信頼性は特定のユースケースで必要になる場合がありますが、一部のユースケースでは、データの損失がわずかに許容される場合があります。 たとえば、数秒ごとに大量のデータが生成され、分析に必要な解像度が低いメトリックス監視環境を想像してみてください。 このような場合、Graphiteを使用すると、UDPモードでネットワークリスナーを設定できます。 これにより、データの供給が速くなるため、大規模な環境で非常に役立ちます。

メトリック管理

メトリック形式

Graphiteサーバーにプッシュされた各メトリックサンプルには、次のエントリが含まれます。

• メトリック名は、メトリックを識別する無料のASCII文字列である必要があります。
• 値は、メトリックサンプルの値に対応する整数または浮動小数点数です。
• エポックからの秒数で表されるタイムスタンプ。

メトリックパス

メトリック名には1つ以上のドット（例：server1.application1.request_count）が含まれる場合があり、それらは一般にメトリックパスと呼ばれます。 このドットベースのメトリック名は、メトリックのアクセスと取得を最適化する方法でデータストレージを編成するために、Graphiteによって内部的に使用されます。 さらに、次の図に示すように、ツリーベースのデータ探索とメトリックの視覚化のヒントとしても使用できます。

Graphiteメトリックツリーの図
メトリックパスには、最初のレベルのホストグループ、2番目のレベルのホスト名、3番目と最後のレベルの実際のメトリック名が含まれます。

サーバーへのメトリックのプッシュ

Graphiteでメトリックをフィードするには、単一のプレーンテキストメトリックとして、またはpickleプロトコルを使用したメトリックのバイナリセットとして、2つの方法があります。 この後者のアプローチは、コンパクトなバイナリデータのシリアル化を使用して、ネットワークを通過するデータのサイズを制限しながら、データを一括でプッシュする利点を引き出します。 これらのアプローチのそれぞれについて、Graphiteサーバーは、カーボンキャッシュまたはカーボンリレー上の適切なリスナーがこれらのデータを処理できるようにする必要があります。 たとえば、Graphiteのデフォルトのインストールでは、単一のメトリックの場合はポート2003で、ピクルスデータの場合はポート2004でカーボンキャッシュリスニングを有効にします。

各リスナーを介して受信したメトリックは、次のセクションで説明するように処理および保存されます。

データストレージ

内部的に、Graphiteはファイルベースのデータベースにメトリックを保存します（デフォルトではウィスパー）。このデータベースには、いくつかの重要な特性があります。

メトリックが格納されるベースディレクトリがあり、それぞれ別のファイルに格納されています。メトリック名が上記のようにパスとして表現されている場合、つまり1つ以上のドットが含まれている場合、それらのドットはベースロケーションからのサブディレクトリとして処理されます。例えば。 server1.application1.request_countという名前のメトリックは、ベースメトリックディレクトリのserver1 / application1 / request count.wspにあるファイルに格納されます。
メトリックファイルのサイズは固定されているため、無制限に大きくなることはありません。それを保証するために、メトリックは2つの重要なプロパティで定義されます。保持期間と長期にわたるデータ解決です。例として、メトリックが1年間保存されるように設定できます（保持）。過去2週間は1秒、過去2か月は5分、残りの時間は1時間の精度で表示されます。
保存期間と解像度により、各ファイルのサイズを決定できます。

可視化

メトリックが取り込まれると、それらを視覚化するさまざまな方法があります。 1つ目は、Graphiteプロジェクトが提供するネイティブの視覚化ツールであるGraphite-Webを使用することです。 ただし、運用の可視化には十分な柔軟性がない場合があります。 これが、ユーザーがGrafanaの使用という２つ目の選択肢を選択する理由です。これは、より多くのGraphiteインスタンスを同時に処理できるという事実と組み合わせて、より優れた視覚化機能を提供します。 最後に、まれなケースとして、ユーザーは、Graphite WebまたはGraphite APIを介してGraphiteのメトリックを取得するカスタムメイドの視覚化システムを選択することもできます。

Graphiteについてさらに興味がある方は、このシリーズの2番目の記事である、Graphiteのインストールと設定をご覧ください。 Graphiteの使用に興味はあるが、Graphiteインストールのセットアップと管理が多すぎる場合は、 MetricFireのHosted Graphiteの無料トライアルをお試しください。 また、デモを予約して、インフラストラクチャの監視について直接お問い合わせください。

それでは、またの記事で！