完璧なモニタリングを求めて

この短い記事では、銀行DWHの作業を分析するために使用される監視ツールについてお話したいと思います。 この記事は、既存の既成の監視システムに満足していない人、および別のピースから自分でシステムを組み立てようと考えている人に興味があるだろう。 この記事ではGrafanaダッシュボードに多くの注意が払われていますが、これは私の意見では、Habréに不当に注意を奪われています。 監視システムのほとんどのコンポーネントについて、インストールプロセス（RedHatの下）について簡単に確認します。





暖かいランプのダッシュボード



問題の声明

一見したところ、このタスクは非常にシンプルで平凡です：最小限の時間で可能な限り少ない動きで、すべてのストレージシステムのステータスを完全に評価し、個々の関係者にイベントを通知できるようにする手段を備えています。 ただし、監視が必要なシステムの機能について簡単に説明する価値があります。

• MPP RDBMS Greenplum-それぞれに10〜18（宛先によって異なる）マシンの4つのクラスター。 クラスタ内のすべてのマシンのうち、2つのマシン（マスターとスタンバイマスター）のみが外部ネットワークにアクセスでき、残りは内部の隔離された相互接続ネットワークにのみあります。
• Dual-ETL（Duet）-このプロジェクトの詳細については、 次の記事を参照してください 。 モニタリングの観点から見ると、このプロジェクトは、bashスクリプト、SASコード、Oracleデータベース、Greenplumなど、さまざまな環境で必要なメトリックが生成されるという点で興味深いものです。
• Attunity CDC-詳細は、 次の記事にも記載されています 。 このシステムの重要な指標は待ち時間です。つまり、ソースデータベース（Oracle）のレコードの出現/変更と、レシーバー（Greenplum）の同様のイベントとの間の経過時間です。
• ETLプロセスとそれに使用されるハードウェア-データのロードと変換のプロセスを完全にカバーする必要があります。
• さまざまな目的のための18のWebサービス-最も簡単なタスク。 顧客は、サービスの応答時間とその可用性の時間を把握したいと考えていました。
• 他のいくつかの簡単なメトリック。

既存の選択

もちろん、私が最初に調べたのは、既存のシステムでした：Nagios、Zabbix（大部分）、Munin。 それぞれが独自の方法で優れており、それぞれに独自の応用分野があります。 Habréには、リストされている各システムに関する十分な情報があるため、完成したシステムを原則として拒否した理由のみをリストします。

• 監視したいメトリックはかなり「高度に専門化された」ものであり、完成したシステムの典型的な適用分野（鉄の負荷、ネットワーク帯域幅など）にはほとんど共通点がありません。 これは、いずれの場合でも、各システムについて、マスターシステムにデータを送信する独自​​のデーモンを作成する必要があることを意味します。これにより、既製の監視システムの概念全体が破壊されます。
• このようなシステムの主な目的は、問題を通知することです。私たちにとって、主なことはコンポーネントの動作を視覚化することであり、2番目のタスクは通知することです。
• 上記のシステムのファンを許してください、しかし、彼らは...いです。 2つのモニターでそれらを開いたり、異なる表示スタイルを選択したり、平均値を計算したり、微分を印刷したり、議論したり、拡大縮小やドラッグアンドドロップを行ったり、グラフィックを重ね合わせたり、隠された意味を探したりするのは嫌です

図 Zabbixの1つのチャート。 レビュー済みの既成システムのすべてで、チャートを使用する機会はほとんどありません。



また、メトリックの特定の関数（たとえば、導関数または指数）をプロットする場合、関数の値は、データを送信する自己記述デーモンの側で計算する必要があります。

さらに、ZabbixとNagiosは低レベルの監視（鉄の状態）のために銀行で使用されており、それらの使用にはある程度の経験がありました。 要するに、魂のすべての繊維は、これが私たちが必要とするものではないと感じました。



黒鉛

そのため、このような多様なメトリクスのセットを美しくわかりやすく視覚化できるシステムを見つける過程で、グラファイトが発見されました。 説明の第一印象は肯定的でしたが、テストインストールを展開する決定に大きく貢献したのは、 Yandexレクチャーであり、そこではかなり似た問題を解決しました。 グラファイトができました。





図 2グラファイトのグラフ



Graphiteは、オンラインチャート作成のためのシステムにすぎません。 単純化-ネットワーク上でメトリックを取得し、グラフに終止符を打ちます。これは後で何らかの方法で参照できます。 メトリックは「Folder1.Folder2.Metric_Name Metric_Value Temporary_Market」の形式で送信されます。 たとえば、フォルダディレクトリにあり、現在値が1であるbashからのテストメトリックの最も簡単な送信は、次のようになります。

echo "Folder.Test 1 $(date +%s)" |nc graphite_host 2003
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

シンプルでしょ？



アーキテクチャ上、Graphiteは3つのコンポーネントで構成されています。

• Graphite-Web、Django web-shellは、グラフレンダラーでもあり、mysqlを使用しています。
• Carbon、Whisperインバウンドメトリックを受信、キャッシュ、および書き込むためのデーモン。
• ウィスパー、履歴メトリックデータを保存するためのファイルデータベース。 したがって、メトリックはメトリックごとにファイルごとに別々のファイルに格納されます。これにより、これらのメトリックを簡単に管理できます（インストール間の転送、削除など）。

Graphiteが気に入った点：

• サーバーまたはサーバーグループ（hello Zabbix）の名前ではなく、ユーザーの裁量でフォルダーごとに並べ替えられたすべてのグラフ。
• 各メトリックのタイムスタンプは任意に設定されます。つまり、グラフのポイントは過去時制と未来時制の両方で設定できます。これはリポジトリの一部のコンポーネントで重要です。
• 関数をチャートデータに重ね合わせることができます。
• いくつかの素敵なグラフィックバン-充填、列の表示など;
• 少し便利なスケーリング。

失望したもの：

• ダッシュボードを作成する機会がわずかにあります。
• 多くのニュアンスでは、双方向性の欠如;
• 通知機能は原則的にはありません。
• 指標の表を表示する方法はありません

グラファナ

そのため、しばらくの間、グラファイトを使用していました。 テストと製品のインストールがあり、メトリック送信がDuetの制御コードに追加され、デーモンがGreenplumのステータスを監視するように記述され、アプリケーションがAttunityレイテンシをカウントしてGraphiteに送信するように記述されました。 たとえば、システムの動作を視覚的に表現したものがありました。たとえば、Duetの過去の勤務スケジュールによって大きな問題が特定されました。 アラートは、サードパーティのコード（bash、sas）によって実装されました。

しかし、完璧に制限はありません。しばらくしてからもっと欲しかったので、グラファナに行きました。





図 3 Grafanaのグラフと値の表



Grafanaは、Graphite、InfluxDB、またはOpenTSDBのデータに基づいたチャートおよびダッシュボードエディターで、特に情報の表示と分析に特化しています。 軽量で、比較的簡単にインストールでき、最も重要なことは、信じられないほど美しいです。 機内で：

• グラフ、トリガー、html挿入、その他の機能を備えた完全なダッシュボード。
• スクロール、ズーム、その他-ing;
• ソート可能な値テーブル（最小、最大、平均、現在、合計）;
• すべてのグラファイト機能のサポート。

機能的には、グラファンはユーザー定義の高さの線に分割されたユーザーダッシュボードのセットであり、ユーザーは機能要素（グラフ、html挿入、トリガープレート）を作成できます。 行は、あらゆる方法で移動、名前変更、および一般的にそれらをあざけることができます。

当然、ダッシュボードの主な機能要素はグラフィックです。 Grafanで新しいメトリックグラフを作成するには、特別な知識はまったく必要ありません。すべてが簡単かつ明確に行われます。



1. Graphiteのメトリックがチャートに追加されます-すべてはGUIで行われ、特定のフォルダーなどですべてのメトリックを指定できます。

2.必要に応じて、表示される前にメトリックに適用されるメトリックに関数が適用されます。 シンプルで頻繁に使用されるもの（スケール、平均、パーセンタイルなど）に加えて、もっと興味深いものがあります-たとえば、aliasByNode（）関数を使用すると、グラファン自身がグラフで呼び出すメトリックを正確に決定できます。 簡単な例として、2つのメトリックがあります。

Servers.ServerA.cpu

Servers.ServerB.cpu

デフォルトでは、メトリックは同じ名前（CPU）で呼び出されます。 上記の機能を使用すると、ServerAとServerBがチャートに表示されます。

3.軸（最も一般的な数量の自動スケーリング-時間、ファイルサイズ、速度があります）、グラフの名前を編集します。

4.表示スタイルを調整します（塗りつぶし、行/列、メトリックの合計、値を持つテーブルなど）。



スケジュールの準備ができました。 必要に応じて、HTMLコンテンツをダッシュ​​ボードと単純なトリガーサイコロに追加します（1つのメトリックにスナップし、メトリックが指定された境界を超えている場合はサイコロの色またはテキストを変更します）。

したがって、ほとんどすべての詳細で、任意のデータの表示をカスタマイズすることができます。



グラファンの利点：

• 柔軟性-すべてが構成されています。
• 使いやすさ-美しいだけでなく快適です。
• メトリックを表示する前に、数学/統計関数を適用できます。
• チャートの計算はクライアント側で行われます（ただし、これは状況によってはデメリットに起因する場合があります）。

短所：

• 承認なし-誰でもスケジュールとダッシュボードを変更できます。
• 通知なし。

ところで、grafana 2.0のバージョンでは、承認と通知の両方を追加する予定です。





ダイヤモンド

必要なシステムからメトリックを送信し、必要に応じてグラフに表示する方法を学びましたが、超一意のメトリックに加えて、CPU使用量などの値を、Zabbix / Nagiosの管理者とユーザーの近くで確認したい場合は、 iops、ネットワークの使用-このような各メトリックについては、bashで独自のデーモンを作成し、cronに詰め込む必要があります。 もちろんそうではありません。なぜなら、 ダイヤモンドがあるからです。

Diamondは、システム情報を収集してグラファイトや他のいくつかのシステムに送信するpythonデーモンです。 機能的には、コレクター-システムから情報を抽出する個々のパーサーデーモンで構成されます。 実際、コレクターは、cpuからmongoDBまで、監視対象のオブジェクト全体をカバーしています。

次に、各コレクターは、いくつかのメトリックを処理して受信側システム（この場合はグラファイト）に送信します。 たとえば、ネットワークコレクタの場合、ネットワークインターフェースごとに最大18個のメトリックが送信されます。 したがって、私の監視システムでは、ZabbixとNagiosの主な機能がカバーされているように見えます-1〜2回クリックするだけで新しいシステムメトリクスを追加します。 特に、Greenplumの小さいながらも鮮明な管理経験から、データベース操作の非常に重要なパラメーターは、セグメントサーバーのディスクサブシステムの負荷であることが示唆されました。 セグメントサーバーのRAIDコントローラーのiops、％負荷、待機、およびサービス時間のグラフ（uses / proc / diskstats）を使用して、個別のダッシュボードが作成されました。 短い観察から興味深い規則性が明らかになりました。コントローラーのディスクが解放し、RAIDコントローラーのステータスコントローラーがディスクの必要な交換を報告する前に、アレイ全体のパフォーマンスが大幅に低下しました。





図 4セグメントサーバーの1つのパフォーマンスが共通のヒープからノックアウトされる



ここで、各行は、データベースサーバーセグメントの1つに対するコントローラーの負荷の割合です。 IOPSが等しい（隣接するチャートに表示される）sdw10という名前のセグメントがはるかに多くロードされていることがわかります。 この機能を知ることにより、まず、交換の前準備をし、次に、パフォーマンスの低下に応じて、ディスクの早期交換の可能性についてベンダーと交渉することができました。





セイレン

したがって、主な問題-視覚化とデータ取得-は解決されます。 現在および過去の情報を含む美しく柔軟なダッシュボードがあり、さまざまなシステムからメトリックを送信し、新しいシステムインジケーターを簡単に追加できます。 残っていることが1つだけあります。イベントについて関係者に通知する方法を学習することです。 ここでセイレンが助けになります。メトリックの1つが新しい状態になったときに、 何らかの方法でユーザーに通知できる、小さくて非常にシンプルなダッシュボードです。 実際には、これは次のことを意味します。ユーザーは、グラファイトから特定のメトリックのチェックを作成し、その中に2つの制限を設定します-WARNおよびERRORレベル。 次に、サブスクライバーを追加し、通知する必要があるチャネルを示します（電子メール、Flowdock、HipChat、HTTP、Hubot、IRCcat、PagerDuty、Pushover、SLF4J、Slack、SNMP、Twilio）および通知スケジュール（たとえば、平日にのみ通知する）。





図 5セイレンのチェックイン



将来、メトリックが制限の1つに達すると、重大度を示すアラートが送信されます。 メトリックが以前の状態に戻ると、同じことが起こります。

はっきりしない点に注意する必要があります。SeyrenがGraphiteからメトリックを取得するには、チェックを作成するときに、大文字と小文字を区別して完全に名前を入力する必要があります。



ご覧のとおり、アラートは非常に単純で、メトリックの線形変化にのみ応答します。この場合、これで十分です。 Seyrenを使用すると、たとえば過去30分間の平均値の変化に対応するアラートを作成することはできません。 この種のチェックが必要な人には、 Cabotに注意を払うことをお勧めします。Cabotは、Syrenの完全な類似物で、Graphiteメトリックに関数を適用した結果のチェックを作成できます。 CabotはAWSまたはDigitalOceanのインスタンスとして配布され、CentOSでベアメタルインストールを実行する方法についても説明しています。



おわりに

全体として、出口には、多くの点で既存の「全体」ソリューションを上回る、ほぼ完成した監視システムがあります。 さらに、このようなシステムへの新しいサービスの統合ははるかに柔軟になり（何らかの方法で、より時間がかかる場合があります）、Graphiteで動作するソフトウェアの数を考慮した拡張性はほぼ無制限です。



参照資料

黒鉛

Graphite-100万個のグラフを作成する方法 -2013年の別のカンファレンスの投稿

グラファナ

ダイヤモンド

セイレン

キャボット

CentOSでのキャボットのインストール手順



Greenplumの災害復旧記事

Attunity CDCに関する記事