モニタリングは死んだのか？ — 長期監視

2008 年以来、当社は主にインフラストラクチャ管理と Web プロジェクトの 400 時間体制の技術サポートに従事してきました。当社には 15 以上のクライアントがあり、これはロシアの電子商取引の約 15% に相当します。 したがって、非常に多様なアーキテクチャがサポートされています。 何かが落ちた場合は、XNUMX 分以内に修理する義務があります。 しかし、事故が発生したことを理解するには、プロジェクトを監視し、インシデントに対応する必要があります。 これを行う方法？

適切な監視体制を整えることに問題があると思います。 問題がなければ、私のスピーチは「Prometheus + Grafana とプラグイン 1、2、3 をインストールしてください」という 2008 つのテーマで構成されていたはずです。 残念ながら、もうそのようには機能しません。 そして主な問題は、ソフトウェア コンポーネントに関して、XNUMX 年に存在したものを誰もが信じ続けていることです。

監視システムの組織に関して、あえて言えば…適切な監視を備えたプロジェクトは存在しない。 そして、状況は非常に悪いため、何かが落ちた場合、それが気づかれない危険があります。結局のところ、誰もが「すべてが監視されている」と確信しています。
おそらくすべてが監視されているのでしょう。 しかし、どうやって？

私たちは皆、次のような話に遭遇したことがあります。特定の Devops で、特定の管理者が作業していると、開発チームが彼らのところにやって来て、「私たちは解放されました。今は監視します」と言います。 何を監視しますか？ 使い方？

わかりました。 私たちは昔ながらの方法で監視しています。 そしてそれはすでに変化しており、あなたが監視していたサービス A が、サービス C と対話するサービス B になり、サービス C と対話することがわかりました。しかし、開発チームはあなたにこう言います。「ソフトウェアをインストールしてください。ソフトウェアはすべてを監視するはずです!」

それで何が変わったのでしょうか？ - すべてが変わった！

2008年すべて順調

数人の開発者、XNUMX つのサーバー、XNUMX つのデータベース サーバーがあります。 すべてはここから始まります。 いくつかの情報があるので、zabbix、Nagios、cacti をインストールします。 そして、CPU、ディスク操作、ディスク容量に関する明確なアラートを設定しました。 また、サイトが応答し、注文がデータベースに入力されていることを確認するために、いくつかの手動チェックも行います。 それだけです。私たちは多かれ少なかれ守られています。

当時、管理者が監視を提供するために行った作業量を比較すると、その作業の 98% は自動でした。監視を行う人は、Zabbix のインストール方法、Zabbix の構成方法、およびアラートの構成方法を理解する必要があります。 そして 2% - 外部チェック: サイトが応答してデータベースにリクエストを行うこと、新しい注文が到着したこと。

2010年負荷が増大している

私たちは検索エンジンを追加して、ウェブの規模を拡大し始めています。 製品カタログにすべての製品が含まれていることを確認したいと考えています。 そして、その製品検索は機能します。 データベースが機能していること、注文が行われていること、サイトが外部から応答し、XNUMX つのサーバーから応答していること、別のサーバーにリバランスされている間にユーザーがサイトから追い出されないこと、などです。 さらに多くのエンティティがあります。

さらに、インフラに関連するエンティティは依然として経営者の頭の中で最大のものです。 私の頭の中には、監視を行っている人が zabbix をインストールして設定できる人であるという考えがまだあります。

しかし同時に、外部チェックの実施、一連の検索インデクサー クエリ スクリプト、インデックス作成プロセス中に検索が変更されたことをチェックする一連のスクリプト、商品が組織に転送されたことをチェックする一連のスクリプトを作成する作業も行われています。配送サービスなど等々。

注: 「一連のスクリプト」を 3 回書きました。 つまり、監視の責任者は、単に zabbix をインストールするだけの人ではなくなります。 これからコーディングを始める人です。 しかし、チームの心の中ではまだ何も変わっていません。

しかし世界は変化しており、ますます複雑になっています。 仮想化レイヤーといくつかの新しいシステムが追加されます。 彼らは互いに交流し始めます。 「マイクロサービスの匂いがする」なんて誰が言ったのでしょう？ ただし、各サービスは依然として個別の Web サイトのように見えます。 私たちはそれに頼ることができ、それが必要な情報を提供し、それ自体が機能することを理解できます。 そして、あなたが 5 ～ 7 ～ 10 年間開発されてきたプロジェクトに常に関与している管理者であれば、この知識が蓄積されます。新しいレベルが現れて、気づいた、別のレベルが現れ、気づいた...

しかし、プロジェクトに 10 年間も同行する人はほとんどいません。

監視員の履歴書

あなたが、すぐに 20 人の開発者を雇用し、15 のマイクロサービスを作成した新しいスタートアップ企業に来て、「CI/CD を構築せよ」と言われた管理者であるとします。 お願いします。" CI/CD を構築した後、突然次のような声が聞こえてきます。「アプリケーションがその中でどのように動作するかを理解せずに、「キューブ」内で運用環境を操作するのは困難です。 同じ「立方体」の中にサンドボックスを作ってください。
このキューブ内にサンドボックスを作成します。 彼らはすぐにこう言います。「データベース上で動作することを理解しながら、同時に本番データベースを損なわないように、本番環境から毎日更新されるステージ データベースが必要です。」

あなたはこれらすべての中で生きています。 リリースまであと 2 週間あります。「さあ、これをすべて監視しましょう...」と言われます。 クラスターインフラストラクチャの監視、マイクロサービスアーキテクチャの監視、外部サービスとの動作の監視...

そして私の同僚たちは、いつもの計画を頭から外してこう言います。 これらすべてを監視するプログラムをインストールしてください。」 はい、はい: Prometheus + Grafana + プラグイン。
さらに、「XNUMX週間の猶予があるので、すべてが安全であることを確認してください。」と付け加えました。

私たちが目にする多くのプロジェクトでは、モニタリングのために 2 人が割り当てられています。 XNUMX 週間のモニタリングを行う人を雇いたいと考え、その人の履歴書を書くと想像してください。 これまで述べてきたことを考慮すると、この人にはどのようなスキルが必要でしょうか?

• 彼は、鉄のインフラストラクチャの監視と運用の詳細を理解する必要があります。
• 彼は、Kubernetes 自体とそのインフラストラクチャの監視の詳細を理解する必要があり (そして誰もが「キューブ」に行きたがります。すべてを抽象化し、非表示にすることができます。残りは管理者が処理するためです)、それ自体とそのインフラストラクチャ、およびアプリケーションの監視方法を理解する必要があります。内部。
• 彼は、サービスが特別な方法で相互に通信することを理解し、サービスが相互にどのように相互作用するかの詳細を知らなければなりません。 他に方法がないため、いくつかのサービスが同期的に通信するプロジェクトが発生する可能性があります。 たとえば、バックエンドは REST 経由、gRPC 経由でカタログ サービスにアクセスし、製品のリストを受信して​​返します。 ここで待つことはできません。 また、他のサービスでは非同期で動作します。 注文品を宅配サービスに転送したり、手紙を送ったりします。
  おそらくもう泳ぎ終えたでしょうか？ そして、これを監視する必要がある管理者はさらに混乱しました。
• 仕事がますます増えていくにつれて、彼は正しく計画を立てて計画を立てることができなければなりません。
• したがって、サービスを具体的に監視する方法を理解するために、作成されたサービスから戦略を作成する必要があります。 彼は、プロジェクトのアーキテクチャとその開発の理解と、開発で使用されるテクノロジーの理解が必要です。

ごく普通のケースを思い出してください。PHP で作られたサービス、Go で作られたサービス、JS で作られたサービスがあります。 彼らはどういうわけかお互いに協力します。 これが「マイクロサービス」という用語の由来です。個別のシステムが非常に多く、開発者がプロ​​ジェクト全体を理解できないのです。 チームの一部は、それ自体で動作するサービスを JS で作成しますが、システムの残りの部分がどのように動作するかは知りません。 他の部分は Python でサービスを作成し、他のサービスの動作に干渉せず、独自の領域に分離されます。 XNUMX つ目は、PHP などでサービスを作成することです。
これら 20 人全員が 15 のサービスに分割されており、これらすべてを理解しなければならない管理者は 15 人だけです。 停止！ 20 人ではシステム全体を理解できないため、システムを XNUMX のマイクロサービスに分割しただけです。

しかし、何らかの方法で監視する必要があります...

結果はどうなりましたか? その結果、開発者チーム全体が理解できないことすべてを考え出す人物が XNUMX 人存在します。同時に、その人は、ハードウェア インフラストラクチャ、Kubernetes インフラストラクチャなど、上で示した内容についても理解し、実行できなければなりません。

何と言えばいいでしょうか...ヒューストン、我々には問題があります。

最新のソフトウェア プロジェクトの監視は、それ自体がソフトウェア プロジェクトです

監視はソフトウェアであるという誤った信念から、私たちは奇跡を信じるようになります。 しかし、悲しいかな、奇跡は起こりません。 zabbix をインストールしても、すべてが動作することを期待することはできません。 Grafana をインストールしても、すべてがうまくいくことを期待するのは意味がありません。 ほとんどの時間は、サービスの動作と相互作用のチェックを整理し、外部システムがどのように機能するかをチェックすることに費やされます。 実際、時間の 90% はスクリプトの作成ではなく、ソフトウェアの開発に費やされます。 そして、それはプロジェクトの作業を理解しているチームによって処理される必要があります。
この状況で XNUMX 人が監視に放り込まれると、大惨事が発生します。 それはどこでも起こっていることです。

たとえば、Kafka を介して相互に通信するサービスがいくつかあります。 注文品が到着したので、注文に関するメッセージを Kafka に送信しました。 注文内容を聞いて商品を発送するサービスがあります。 注文に関する情報を聞いてユーザーに手紙を送信するサービスがあります。 そしてさらにたくさんのサービスが登場し、私たちは混乱し始めます。

そして、これをリリースまで残りわずかの段階で管理者や開発者にも伝えると、その人はこのプロトコル全体を理解する必要があります。 それらの。 この規模のプロジェクトにはかなりの時間がかかるため、システム開発にはそれを考慮する必要があります。
しかし、特に新興企業では、監視が後回しにされることが非常によく見られます。 「これから私たちは概念実証を作成し、それを使って立ち上げ、失敗に任せます。私たちは犠牲を払う準備ができています。 そして、私たちはすべてを監視します。」 プロジェクトが収益を上げ始めると (または収益が得られ始めた場合)、企業はさらに多くの機能を追加したいと考えます。それは、すでに機能し始めているため、さらに展開する必要があるからです。 そして、まずこれまでのすべてを監視する必要がある段階にいますが、これには 1% ではなく、それ以上の時間がかかります。 ちなみに、開発者はモニタリングのために必要になるため、開発者に新しい機能を開発してもらう方が簡単です。 その結果、新しい機能が作成され、すべてが台無しになり、終わりのない行き詰まりに陥ります。

では、プロジェクトを最初から監視する方法と、監視する必要があるプロジェクトを取得したが、どこから始めればよいかわからない場合はどうすればよいでしょうか?

まず、計画を立てる必要があります。

余談ですが、多くの場合、インフラストラクチャの監視から始まります。 たとえば、Kubernetes があります。 まずは Grafana を使用して Prometheus をインストールし、「キューブ」を監視するためのプラグインをインストールしましょう。 開発者だけでなく管理者も、「このプラグインをインストールするつもりですが、プラグインはおそらくその方法を知っているでしょう」という残念な習慣を持っています。 人々は重要なアクションよりも、単純で単純なことから始めることを好みます。 また、インフラストラクチャの監視も簡単です。

まず、何をどのように監視するかを決めてから、ツールを選択します。他の人があなたの代わりに考えることはできないからです。 そしてそうすべきでしょうか？ このプラグインが書かれたときに、ユニバーサル システムについて考えたり、まったく考えなかった人もいます。 そして、このプラグインに 5 人のユーザーがいるからといって、それが何の役にも立たないというわけではありません。 おそらく、以前にすでに 5001 人がいたという理由だけで、あなたが 5000 人目になるでしょう。

インフラストラクチャの監視を開始し、アプリケーションのバックエンドが応答を停止した場合、すべてのユーザーはモバイル アプリケーションとの接続を失います。 エラーが表示されます。 彼らはあなたのところに来て、「アプリケーションが動作していません。ここで何をしているのですか？」と言うでしょう。 - 「私たちは監視しています。」 — 「アプリケーションが動作していないことが分からない場合、どうやって監視すればよいでしょうか?!」

1. ユーザーのエントリーポイントから正確に監視を開始する必要があると思います。 アプリケーションが動作していることがユーザーに見えなければ、それは失敗です。 そして、監視システムは最初にこれについて警告する必要があります。
2. そうして初めてインフラストラクチャを監視できるようになります。 あるいは並行して行います。 インフラストラクチャを使用すると簡単になります。ここで、最終的に zabbix をインストールするだけです。
3. 次に、アプリケーションのルートにアクセスして、どこが機能していないのかを理解する必要があります。

私の主な考えは、モニタリングは開発プロセスと並行して行うべきだということです。 監視チームの注意を他のタスク (CI/CD の作成、サンドボックス化、インフラストラクチャの再編成) に集中させると、監視に遅れが生じ始め、開発に追いつかなくなる可能性があります (または、遅かれ早かれ開発を停止しなければならなくなるでしょう)。

レベル別のすべて

私は監視体制の整備をこのように考えています。

1) アプリケーションレベル:

• アプリケーションのビジネスロジックを監視する。
• サービスの健全性メトリクスを監視する。
• 統合モニタリング。

2) インフラストラクチャレベル:

• オーケストレーションレベルのモニタリング。
• システムソフトウェアの監視。
• 鉄レベルのモニタリング。

3) 再びアプリケーションレベルですが、エンジニアリング製品として:

• アプリケーションログの収集と監視。
• APM;
• 追跡中。

4) 警告:

• 警報システムの組織化。
• 職務制度の組織化。
• インシデント処理のための「知識ベース」とワークフローの組織化。

それが重要だ: アラートは後ではなく、すぐに通知されます。 監視を開始して、誰がアラートを受信するかを「後で何らかの方法で」把握する必要はありません。 結局のところ、監視の仕事とは何でしょうか。システムのどこで問題が発生しているのかを理解し、それを適切な担当者に知らせることです。 これを最後まで放置しておくと、適切な担当者は「何もうまくいっていない」と言うだけで、何か問題が起こっていることを知ることになります。

アプリケーション層 - ビジネスロジックの監視

ここでは、アプリケーションがユーザーに対して動作するかどうかを確認することについて話します。

このレベルは開発段階で実行する必要があります。 たとえば、条件付き Prometheus があります。Prometheus はチェックを行うサーバーに移動し、エンドポイントをプルし、エンドポイントが API をチェックします。

サイトが動作していることを確認するためにホームページを監視するように求められることがよくあるとき、プログラマーは、API が動作していることを確認する必要があるたびに取得できるハンドルを提供します。 そしてプログラマは現時点でも /api/test/helloworld を取得して書き込みます
すべてが機能していることを確認する唯一の方法はありますか? - いいえ！

• このようなチェックの作成は、基本的に開発者の仕事です。 単体テストは、コードを作成するプログラマーによって作成される必要があります。 なぜなら、それを管理者に漏らすと、「おい、これが 25 個の関数すべての API プロトコルのリストだ。すべてを監視してください!」となるからです。 -何もうまくいきません。
• 「hello world」と出力した場合、その API が機能するはずであり、実際に機能することは誰も知りません。 API を変更するたびに、チェックも変更される必要があります。
• すでにそのような問題が発生している場合は、機能を停止し、これらのチェックを作成する開発者を割り当てるか、損失を受け入れ、何もチェックされずに失敗することを受け入れます。

技術的なヒント:

• チェックを整理するために必ず外部サーバーを構築してください。プロジェクトが外部からアクセスできることを確認する必要があります。
• 個々のエンドポイントだけでなく、API プロトコル全体にわたるチェックを整理します。
• テスト結果を使用して prometheus エンドポイントを作成します。

アプリケーション層 - ヘルスメトリクスの監視

ここで、サービスの外部健全性メトリクスについて話します。

私たちは、外部監視システムから呼び出す外部チェックを使用して、アプリケーションのすべての「ハンドル」を監視することにしました。 しかし、これらはユーザーが「見る」「ハンドル」です。 私たちはサービス自体が機能することを確認したいと考えています。 ここにはもっと良い話があります。K8s にはヘルスチェックがあり、少なくとも「キューブ」自体はサービスが機能していることを確信できます。 しかし、私が見た小切手の半分は同じ「hello world」のプリントでした。 それらの。 そこで彼は、展開後に一度プルすると、すべて問題ないと答えました。それだけです。 また、サービスが独自の API を提供する場合、同じ API に対して膨大な数のエントリ ポイントがあり、それが機能するかどうかを確認する必要があるため、これも監視する必要があります。 そして私たちはすでに内部でそれを監視しています。

これを技術的に正しく実装する方法: 各サービスは現在のパフォーマンスに関するエンドポイントを公開し、Grafana (またはその他のアプリケーション) のグラフですべてのサービスのステータスを確認します。

• API を変更するたびに、チェックも変更される必要があります。
• ヘルスメトリクスを使用して新しいサービスをすぐに作成します。
• 管理者は開発者のところに来て、「すべてを理解し、これに関する情報を監視システムに追加できるように、いくつかの機能を追加してください」と頼むことができます。 しかし、開発者は通常、「リリースの XNUMX 週間前には何も追加しません」と答えます。
  このような損失が発生することを開発マネージャーに知らせ、開発マネージャーの管理者にも知らせてください。 なぜなら、すべてがダウンしても、誰かが電話をかけてきて、「常にダウンしているサービス」を監視するように要求するからです (c)
• ちなみに、Grafana 用のプラグインを作成する開発者を割り当てます。これは管理者にとって良い助けになります。

アプリケーション層 - 統合監視

統合監視は、ビジネスクリティカルなシステム間の通信の監視に重点を置いています。

たとえば、相互に通信するサービスが 15 個あります。 これらはもはや別々のサイトではありません。 それらの。 サービスを独自にプルしたり、/helloworld を取得したり、サービスが実行されていることを理解したりすることはできません。 注文 Web サービスは注文に関する情報をバスからバスに送信する必要があるため、倉庫サービスはこのメッセージを受信して​​さらに処理する必要があります。 そして、電子メール配信サービスはこれを何らかの方法でさらに処理する必要があります。

したがって、個々のサービスを個別に調べても、すべてが機能するかどうかを理解することはできません。 それは、あらゆるものが通信し相互作用する特定のバスがあるからです。
したがって、この段階は、他のサービスとの相互作用についてサービスをテストする段階である必要があります。 メッセージブローカーを監視することによって通信監視を組織化することは不可能です。 データを発行するサービスとそれを受け取るサービスがある場合、ブローカーを監視すると、左右に飛び交うデータしか表示されません。 たとえ、このデータの相互作用を内部的に監視することができたとしても、つまり、特定のプロデューサーがデータを投稿し、誰かがそれを読み取り、このフローが Kafka に進み続けたとしても、XNUMX つのサービスが XNUMX つのバージョンでメッセージを送信した場合には情報は得られません。 、しかし、他のサービスはこのバージョンを予期していなかったので、スキップしました。 サービスはすべてが機能していることを通知してくれるため、これについてはわかりません。

私が推奨すること:

• 同期通信の場合: エンドポイントは関連サービスにリクエストを行います。 それらの。 このエンドポイントを取得し、サービス内でスクリプトをプルします。スクリプトはすべてのポイントに行き、「あそこにプルできる、あそこにプルできる、あそこにプルできる...」と指示します。
• 非同期通信の場合: 受信メッセージ - エンドポイントはバスにテスト メッセージがないか確認し、処理ステータスを表示します。
• 非同期通信の場合: 送信メッセージ - エンドポイントはテスト メッセージをバスに送信します。

よくあることですが、データをバスにスローするサービスがあります。 私たちはこのサービスに来て、その統合の健全性について教えてほしいとお願いしました。 そして、サービスがさらに別の場所 (WebApp) でメッセージを生成する必要がある場合は、このテスト メッセージを生成します。 そして、OrderProcessing 側でサービスを実行すると、まず独立して投稿できるものを投稿し、依存するものがあれば、バスから一連のテスト メッセージを読み取り、それらを処理できることを理解し、レポートし、 、必要に応じて、さらに投稿してください、そしてこれについて彼は言います-すべて大丈夫、私は生きています。

「戦闘データでこれをどのようにテストできますか?」という質問をよく聞きます。 たとえば、同じ注文サービスについて話しています。 命令は、商品が償却される倉庫にメッセージを送信します。「私の商品は償却されます!」という理由で、戦闘データでこれをテストすることはできません。 解決策: 最初にこのテスト全体を計画します。 モックを作成する単体テストもあります。 したがって、ビジネスの運営に悪影響を及ぼさないコミュニケーションチャネルがある、より深いレベルでそれを実行してください。

インフラストラクチャ層

インフラストラクチャの監視は、監視そのものであると長い間考えられてきました。

• インフラストラクチャの監視は別のプロセスとして開始できますし、開始する必要があります。
• たとえ本当にそうしたいと思っていたとしても、実行中のプロジェクトのインフラストラクチャ監視から始めるべきではありません。 これはすべての DevOps にとって苦痛です。 「まずクラスターを監視します。次にインフラストラクチャを監視します」 – つまり、 まず、下にあるものを監視しますが、アプリケーションには入りません。 なぜなら、アプリケーションはDevOpsにとって理解できないものだからです。 それは彼にリークされましたが、彼はそれがどのように機能するかを理解していません。 しかし、彼はインフラストラクチャを理解しており、そこから始めます。 しかし、そうではありません。常に最初にアプリケーションを監視する必要があります。
• アラートの数を増やしすぎないでください。 現代のシステムの複雑さを考えると、アラートは常に飛び交っており、この大量のアラートに何とか対処しなければなりません。 そして、オンコール担当者は、次の XNUMX 件のアラートを見て、「それについては考えたくない」と判断するでしょう。 アラートは重要なことについてのみ通知する必要があります。

ビジネスユニットとしてのアプリケーションレベル

キーポイント：

• エルク。 これは業界標準です。 何らかの理由でログを集約していない場合は、直ちに集約を開始してください。
• APM。 アプリケーション監視を素早く終了する方法としての外部 APM (NewRelic、BlackFire、Datadog)。 これを一時的にインストールして、少なくとも自分に何が起こっているのかを理解することができます。
• トレース。 数十のマイクロサービスでは、リクエストが単独で存在しなくなるため、すべてを追跡する必要があります。 後から追加するのは非常に難しいため、開発中にすぐにトレースをスケジュールすることをお勧めします。これは開発者の作業であり、ユーティリティです。 まだ実装していない方はぜひ実装してください！ イェーガー/ジプキンを参照

警告中

• 通知システムの構成: 多数のものを監視する状況では、通知を送信するための統一システムが必要です。 グラファナではできます。 西洋では誰もが PagerDuty を使用しています。 アラートは明確である必要があります (例: アラートの出所など)。 そして、通知がまったく受信されないように制御することをお勧めします。
• 職務システムの組織化: アラートは全員に送信されるべきではありません (群衆の中で全員が反応するか、誰も反応しないかのどちらかです)。 開発者もオンコールである必要があります。必ず責任範囲を定義し、明確な指示を作成し、月曜と水曜に誰に電話するのか、火曜と金曜に誰に電話をかけるのかを正確に書き込んでください（そうしないと、たとえ平日であっても誰にも電話をかけなくなります）。大きな問題が発生した場合 - 彼らはあなたを起こしたり邪魔したりすることを恐れます。人々は一般に、特に夜間に電話をかけたり他の人を起こしたりすることを好みません）。 そして、助けを求めることは無能の表れではないことを説明し（「私が助けを求めているということは、私はダメな労働者だということです」）、助けを求めることを奨励します。
• 「知識ベース」の組織化とインシデント処理のワークフロー: 重大なインシデントごとに事後調査を計画し、一時的な措置としてインシデントを解決するためのアクションを記録する必要があります。 そして、警告を繰り返すのは罪であることを習慣にしてください。 コードまたはインフラストラクチャ作業で修正する必要があります。

技術スタック

スタックが次のようになっていると想像してみましょう。

• データ収集 - プロメテウス + グラファナ;
• ログ分析 - ELK;
• APM またはトレース用 - Yetager (Zipkin)。

オプションの選択は重要ではありません。 なぜなら、最初にシステムを監視する方法を理解し、計画を書き留めていれば、要件に合ったツールを選択し始めるからです。 問題は、最初に何を監視することを選択したかです。 おそらく、最初に選択したツールが要件をまったく満たしていない可能性があるからです。

最近あちこちで見かける技術的なポイントをいくつか挙げます。

Prometheus が Kubernetes 内に押し込まれています - 誰がこれを思いついたのでしょうか?! クラスターがクラッシュした場合、どうしますか? 内部に複雑なクラスターがある場合は、クラスターの内部と外部に、クラスターの内部からデータを収集する何らかの監視システムが必要です。

クラスター内では、ログとその他すべてのものを収集します。 ただし、監視システムは外部にある必要があります。 Promtheus が内部にインストールされているクラスターには、サイトの動作を外部からチェックするシステムも存在することがよくあります。 外部との接続が切断され、アプリケーションが動作しなくなったらどうなるでしょうか? 内部的にはすべて問題がないことがわかりましたが、ユーザーにとってはそれほど簡単ではありません。

所見

• 開発の監視はユーティリティのインストールではなく、ソフトウェア製品の開発です。 今日のモニタリングの 98% はコーディングです。 サービス内のコーディング、外部チェックのコーディング、外部サービスのチェック、それだけです。
• 開発者の時間を監視に無駄にしないでください。開発者の作業の最大 30% がかかる可能性がありますが、それだけの価値はあります。
• Devops の皆さん、何かを監視できないことを心配しないでください。いくつかのことはまったく異なる考え方だからです。 あなたはプログラマーではありませんでした。監視作業はまさにプログラマーの仕事です。
• プロジェクトがすでに実行中で監視されていない場合 (およびあなたがマネージャーである場合)、監視用のリソースを割り当てます。
• 製品がすでに実稼働中で、あなたが「監視を設定する」ように言われた DevOps である場合は、私がこれまでに書いた内容を管理者に説明してみてください。

これは、Saint Highload++ カンファレンスでのレポートの拡張版です。

それに関する私のアイデアや考え、および関連トピックに興味がある場合は、こちらをご覧ください。 チャンネルを読む 🙂

出所： habr.com