Prometheus、Clickhouse、ELK でモニタリングを構築した方法

私の名前はアントン・バデリンです。 私はハイテクノロジーセンターでシステム管理をしています。 XNUMX か月前、私たちの企業カンファレンスが終了し、蓄積された経験を市の IT コミュニティと共有しました。 Web アプリケーションの監視について話しました。 この教材は、このプロセスをゼロから構築しないジュニアまたは中級レベルを対象としています。

あらゆる監視システムの基礎となるのは、ビジネス上の問題を解決することです。 監視のための監視は誰にとっても興味がありません。 ビジネスは何を望んでいるのか？ すべてがエラーなく迅速に機能するようにします。 企業は、私たち自身がサービスの問題を特定し、できるだけ早く解決できるよう、積極的に行動したいと考えています。 実際、これらは、私が昨年、ある顧客のプロジェクトで解決した問題です。

プロジェクトについて

このプロジェクトは、国内最大のロイヤルティ プログラムの 14 つです。 ボーナスカードなどのさまざまなマーケティングツールを通じて、小売チェーンの販売頻度の向上を支援します。 合計で、このプロジェクトには XNUMX 台のサーバーで実行される XNUMX 個のアプリケーションが含まれています。

インタビューの過程で、管理者が Web アプリケーションの監視に常に正しく取り組んでいるわけではないことに繰り返し気づきました。管理者の多くは依然としてオペレーティング システムのメトリクスに焦点を当てており、サービスを監視することもあります。

私の場合、顧客の監視システムは以前は Icinga に基づいていました。 上記の問題はまったく解決されませんでした。 多くの場合、クライアント自身が問題について私たちに知らせてきましたが、多くの場合、理由を突き止めるのに十分なデータがなかっただけです。

さらに、これ以上の開発が無駄であることも明確に理解されていました。 アイシンガに詳しい方なら分かると思います。 そこで、私たちはこのプロジェクトのために Web アプリケーション監視システムを完全に再設計することにしました。

プロメテウス

私たちは XNUMX つの主要な指標に基づいて Prometheus を選択しました。

1. 膨大な数の利用可能なメトリクス。 私たちの場合、それらは60万個あります。 もちろん、それらの大部分 (おそらく約 95%) は使用されていないことに注意してください。 その一方で、どれも比較的安価です。 私たちにとって、これは以前に使用されていた Icinga とは対極です。 その中で、メトリクスの追加は特に面倒でした。既存のメトリクスは高価でした (プラグインのソース コードを見てください)。 どのプラグインも Bash または Python のスクリプトであり、その起動には消費されるリソースの点でコストがかかります。
2. このシステムは比較的少量のリソースを消費します。 すべてのメトリクスには、600 MB の RAM、15 コアの XNUMX%、数十の IOPS で十分です。 もちろん、メトリクス エクスポーターを実行する必要がありますが、それらはすべて Go で書かれており、それほど電力を消費しません。 現代の現実において、これが問題になるとは思いません。
3. Kubernetes に移行する機能を提供します。 顧客の計画を考慮すると、選択は明らかです。

ELK

以前は、ログを収集または処理していませんでした。 欠点は誰の目にも明らかです。 ELK を選択したのは、このシステムの使用経験がすでにあったからです。 そこにはアプリケーション ログのみが保存されます。 主な選択基準は、全文検索とその速度でした。

クリックハウス

当初、選択肢は InfluxDB にありました。 Nginx ログ、pg_stat_statements からの統計を収集し、Prometheus の履歴データを保存する必要があることに気づきました。 Influx は定期的に大量のメモリを消費し始めてクラッシュするため、私たちは気に入りませんでした。 また、クエリをremote_addrでグループ化したいのですが、このDBMSではタグのみでグループ化しています。 タグは高価 (メモリ) であり、その数は条件付きで制限されます。

私たちは再び捜索を始めました。 必要なのは、リソース消費を最小限に抑え、できればディスク上のデータ圧縮を備えた分析データベースでした。

Clickhouse はこれらの基準をすべて満たしており、私たちはその選択を後悔したことはありません。 異常な量のデータは書き込まれません (挿入数は XNUMX 分あたりわずか約 XNUMX 回です)。

NewRelic

NewRelic は、お客様の選択であったため、歴史的に当社と協力してきました。 APMとして使用しています。

ザビックス

当社では、さまざまな API のブラック ボックスを監視するためにのみ Zabbix を使用しています。

モニタリングアプローチの定義

私たちはタスクを分解し、それによってモニタリングへのアプローチを体系化したいと考えました。

これを行うために、システムを次のレベルに分割しました。

• ハードウェアと VMS。
• オペレーティング・システム;
• システムサービス、ソフトウェアスタック。
• 応用;
• ビジネスの論理。

このアプローチが便利な理由:

• 各レベルの作業の責任者が誰であるかがわかっているので、これに基づいてアラートを送信できます。
• アラートを抑制するときにこの構造を使用できます。仮想マシン全体が利用できないときにデータベースが利用できないことに関するアラートを送信するのは奇妙です。

私たちのタスクはシステムの運用における違反を特定することであるため、アラート ルールを作成する際に注意を払う価値のある特定のメトリクス セットを各レベルで強調する必要があります。 次に、「VMS」、「オペレーティング システム」、および「システム サービス、ソフトウェア スタック」のレベルを見てみましょう。

仮想マシン

ホスティングにより、プロセッサ、ディスク、メモリ、ネットワークが割り当てられます。 最初の XNUMX つは問題がありました。 したがって、メトリクスは次のとおりです。

CPU の盗難時間 - Amazon で仮想マシン (t2.micro など) を購入する場合、プロセッサ コア全体が割り当てられるのではなく、その時間の割り当てだけが割り当てられることを理解する必要があります。 そしてそれを使い果たすと、プロセッサーはあなたから奪われます。

この指標を使用すると、そのような瞬間を追跡し、意思決定を行うことができます。 たとえば、料金をもっと高くしたり、バックグラウンド タスクと API リクエストの処理を別のサーバーに分散したりする必要がありますか?

IOPS + CPU iowait 時間 - 何らかの理由で、多くのクラウド ホスティングは十分な IOPS を提供しないという罪を犯します。 さらに、IOPS が低いスケジュールは彼らにとって議論になりません。 したがって、CPU iowait を収集する価値があります。 この XNUMX つのグラフ (IOPS が低く、I/O 待機が大きい) を使用すると、ホスティングと対話して問題を解決できます。

オペレーティングシステム

オペレーティング システムのメトリクス:

• 使用可能なメモリの量 (%)。
• スワップ使用アクティビティ: vmstat swapin、swapout;
• ファイルシステム上の利用可能な i ノードの数と空き領域 (%)
• 平均負荷。
• tw 状態の接続の数。
• conntrack テーブルの満杯。
• ネットワークの品質は、ss ユーティリティである iproute2 パッケージを使用して監視できます。その出力から RTT 接続のインジケーターを取得し、宛先ポートごとにグループ化します。

オペレーティング システム レベルにも、プロセスなどのエンティティがあります。 システム内で、その運用において重要な役割を果たす一連のプロセスを特定することが重要です。 たとえば、複数の pgpool がある場合は、それぞれの pgpool の情報を収集する必要があります。

一連のメトリクスは次のとおりです。

• CPU;
• メモリは主に常駐します。
• IO - できれば IOPS で。
• FileFd - 開いて制限します。
• 重大なページ障害 - これにより、どのプロセスがスワップされているかを理解できます。

すべての監視を Docker でデプロイし、Advisor を使用してメトリクス データを収集します。 他のマシンでは、プロセス エクスポーターを使用します。

システムサービス、ソフトウェアスタック

各アプリケーションには独自の特性があり、特定の指標セットを選び出すのは困難です。

ユニバーサルセットは次のとおりです。

• リクエストレート。
• 間違いの数;
• 待ち時間。
• 飽和。

このレベルでの監視の最も顕著な例は、Nginx と PostgreSQL です。

私たちのシステムで最も負荷の高いサービスはデータベースです。 以前は、データベースが何をしているのかを理解するのに苦労することがよくありました。

ディスクに高い負荷がかかっていることがわかりましたが、遅いログには実際には何も示されていませんでした。 この問題は、クエリ統計を収集するビューである pg_stat_statements を使用して解決しました。

管理者に必要なのはこれだけです。

読み取りおよび書き込みリクエストのアクティビティのグラフを作成します。

すべてがシンプルかつ明確で、それぞれのリクエストには独自の色があります。

同様に印象的な例は、Nginx ログです。 これらを解析したり、必需品のリストに挙げたりする人がほとんどいないのも不思議ではありません。 標準形式はあまり有益ではないため、拡張する必要があります。

個人的に、request_time、upstream_response_time、body_bytes_sent、request_length、request_id を追加し、応答時間とエラー数をプロットします。

応答時間とエラー数のグラフを作成します。 覚えて？ ビジネスタスクについて話しましたか？ エラーなく迅速に行うには? これらの問題については、XNUMX つのグラフですでに説明しました。 また、それらを使用して勤務中の管理者に電話をかけることもできます。

しかし、事件の原因を迅速に排除するという、もう一つの問題が残っています。

インシデントの解決

問題の特定から解決までのプロセス全体は、いくつかのステップに分けることができます。

• 問題を特定する。
• 職務管理者への通知。
• インシデントへの対応。
• 原因の除去。

これをできるだけ早く行うことが重要です。 そして、問題を特定して通知を送信する段階であまり時間が取れない場合、いずれにせよ XNUMX 分はそれらの作業に費やされることになり、その後の作業は単に改善のために耕されていない畑にすぎません。

当直警察官の電話が鳴ったと想像してみましょう。 彼は何をするでしょうか？ 何が壊れたのか、どこで壊れたのか、どう対処すればよいのかなど、質問に対する答えを探してください。 これらの質問に対する答えは次のとおりです。

これらすべての情報を通知のテキストに含め、この問題への対応方法、解決方法、エスカレーション方法を説明した Wiki ページへのリンクを通知に渡すだけです。

アプリケーション層とビジネスロジックについてはまだ何も語っていません。 残念ながら、私たちのアプリケーションはまだメトリクス収集を実装していません。 これらのレベルの情報の唯一のソースはログです。

いくつかの点。

まず、構造化されたログを書き込みます。 メッセージのテキストにコンテキストを含める必要はありません。 そのため、グループ化や分析が困難になります。 Logstash がこれらすべてを正規化するには長い時間がかかります。

次に、重大度レベルを正しく使用します。 各言語には独自の標準があります。 個人的には、次の XNUMX つのレベルを区別します。

1. エラーはありません。
2. クライアント側のエラー。
3. 間違いは私たちの側にあり、私たちはお金を失うことはなく、リスクを負いません。
4. 間違いは私たちの側にあり、私たちはお金を失います。

要約してみましょう。 ビジネス ロジックに基づいて監視を構築する必要があります。 アプリケーション自体を監視し、販売数、新規ユーザー登録数、現在アクティブなユーザー数などの指標を使用して運用してみてください。

ビジネス全体がブラウザーの XNUMX つのボタンである場合、ボタンがクリックされて適切に機能するかどうかを監視する必要があります。 残りはすべて問題ありません。

これを持っていない場合は、私たちが行ったように、アプリケーション ログや Nginx ログなどで情報を取得してみることができます。 できる限りアプリケーションの近くにいる必要があります。

オペレーティング システムの指標はもちろん重要ですが、企業はそれらに興味を持っておらず、私たちはそれらに対してお金を払っているわけではありません。

出所： habr.com