Sportmasterを監視します-どのようにそして何で

製品チーム編成の段階でモニタリングシステムの構築を考えました。私たちのビジネス（搾取）がこれらのチームに分類されないことが明らかになりました。何故ですか？



実際、すべてのチームは個別の情報システム、マイクロサービス、およびフロントを中心に構築されているため、チームはシステム全体の全体的な状態を確認できません。たとえば、深いバックエンドの小さな部分がフロントエンドにどのように影響するかを知らない場合があります。彼らの関心の範囲は、彼らのシステムが統合されているシステムに限定されています。チームとそのサービスAがサービスBとほとんど関係がない場合、そのようなサービスはチームにはほとんど見えません。







私たちのチームは、互いに非常に強力に統合されたシステムを使用しています。システム間には多くの接続があり、これは非常に大規模なインフラストラクチャです。そして、オンラインストアの仕事はこれらすべてのシステムに依存しています（ちなみに、私たちは膨大な数を持っています）。



したがって、私たちの部門はどのチームにも属していませんが、少し離れていることがわかりました。このストーリー全体を通して、私たちのタスクは、情報システムがどのように機能するか、それらの機能、統合、ソフトウェア、ネットワーク、ハードウェア、およびこれらすべてがどのように相互接続されているかを複雑な方法で理解することです。



オンラインストアが運営されているプラ​​ットフォームは次のようになります。

• 前面
• ミドルオフィス
• バックオフィス

好きなだけですが、すべてのシステムがスムーズかつ完璧に動作するということはありません。ここでも重要なのは、システムと統合の数です。これまでのように、テストの品質にもかかわらず、いくつかのインシデントは避けられません。さらに、別のシステム内とそれらの統合の両方の観点から。また、プラットフォームの個別の部分ではなく、プラットフォーム全体の状態を包括的に監視する必要があります。



理想的には、プラットフォーム全体の状態の監視を自動化する必要があります。そして、私たちはこのプロセスの必然的な一部として監視するようになりました。当初はフロント部分のみを対象に構築されていましたが、ネットワーク担当者、ソフトウェア、ハードウェアの管理者は、レイヤーごとに独自の監視システムを持っていました。これらの人々はすべて、自分のレベルでのみ監視を行っていました。誰も包括的な理解を持っていませんでした。



たとえば、仮想マシンがクラッシュした場合、ほとんどの場合、ハードウェアと仮想マシンを担当する管理者だけがそれを知っています。このような場合、フロントチームはアプリケーションのクラッシュの事実を確認しましたが、仮想マシンのクラッシュに関するデータはありませんでした。また、管理者は、顧客が誰であるかを知ることができ、これが何らかの大規模なプロジェクトである場合、現在この仮想マシンで何が実行されているかを大まかに想像できます。彼はおそらく小さなものについて知らないでしょう。いずれの場合も、管理者は所有者のところに行き、このマシンに何があったか、何を復元する必要があるか、何を変更するかを尋ねる必要があります。そして、非常に深刻な問題が発生した場合、システム全体を誰も見なかったため、彼らは輪になって走り回り始めました。



最終的に、これらの異なるストーリーは、フロントエンド全体、ユーザー、および当社のコアビジネス機能であるオンライン販売に影響を与えます。私たちはチームの一員ではありませんが、オンラインストアの一部としてすべてのeコマースアプリケーションの運用に従事しているため、eコマースプラットフォームの包括的な監視システムを作成する作業を引き受けました。

システム構造とスタック

まず、システムの監視のいくつかのレイヤーを特定することから始めました。そのコンテキストで、メトリックを収集する必要があります。そして、これらすべてを組み合わせる必要がありました。これは最初の段階で行いました。現在、この段階で、相関関係を構築し、システムが相互にどのように影響するかを理解するために、すべてのレイヤーの最高品質のメトリックのコレクションを完成させています。



アプリケーションの起動の初期段階での包括的な監視の欠如（ほとんどのシステムが稼働しているときにアプリケーションの構築を開始したため）により、プラットフォーム全体の監視を設定するための多大な技術的負債が発生しました。残りのシステムはしばらくの間監視せずに残っ​​ていたため、単一のISの監視を設定し、その監視を詳細に行うことに集中する余裕はありませんでした。この問題を解決するために、レイヤーごとに情報システムの状態を評価するために最も必要なメトリックのリストを特定し、それを実装し始めました。



そのため、象を少しずつ食べることにしました。



私たちのシステムは以下で構成されています：

• ハードウェア;
• オペレーティング・システム;
• ソフトウェア;
• 監視アプリケーションのUIパーツ。
• ビジネス指標;
• 統合アプリケーション;
• 情報セキュリティー;
• ネットワーク;
• トラフィックバランサー。

このシステムの中心はそれ自体を監視しています。システム全体の状態を一般的に理解するには、これらすべてのレイヤーのアプリケーションで、アプリケーションのセット全体のコンテキストで何が起こっているのかを知る必要があります。



だから、スタックについて。







オープンソースのソフトウェアを使用しています。センターには、主にアラートシステムとして使用するZabbixがあります。インフラストラクチャの監視に理想的であることは誰もが知っています。ここではどういう意味ですか？これらは、サーバーの温度、メモリステータス、レイド、ネットワークデバイスのメトリックなど、すべての企業が独自のデータセンターを持っている（およびSportmasterが独自のデータセンターを持っている）低レベルのメトリックです。



Zabbixは、チームで積極的に使用されているTelegramメッセンジャーおよびMicrosoftTeamsと統合されています。 Zabbixは、実際のネットワーク、ハードウェア、および部分的にソフトウェアのレイヤーをカバーしていますが、万能薬ではありません。他のいくつかのサービスからこのデータを充実させます。たとえば、ハードウェアレベルに関しては、APIを介して仮想化システムに直接接続し、データを収集します。



ほかに何か。 Zabbixに加えて、動的環境アプリケーションでメトリックを監視できるPrometheusを使用しています。つまり、HTTPエンドポイントを介してアプリケーションメトリックを受信でき、ロードするメトリックとロードしないメトリックについて心配する必要はありません。このデータに基づいて、分析クエリを実行できます。



他のレイヤーのデータソース（ビジネスメトリックなど）は、3つのコンポーネントに分けられます。



まず、これらは外部のビジネスシステムであるGoogle Analyticsであり、ログから指標を収集します。それらから、アクティブユーザー、コンバージョン、およびビジネスに関連するその他すべてのデータを取得します。第二に、それはUI監視システムです。それはより詳細に議論されるべきです。



昔々、私たちは手動テストから始めました、そしてそれは機能と統合の自動テストに進化しました。私たちはそれを監視し、主要な機能のみを残し、可能な限り安定していて、時間の経過とともに頻繁に変化しないマーカーに関連付けました。



新しいチーム構造は、すべてのアプリケーションアクティビティが製品チームにロックされていることを意味するため、純粋なテストの実行を停止しました。代わりに、Java、Selenium、およびJenkins（レポートを起動および生成するためのシステムとして使用）で記述されたテストからUIモニタリングを作成しました。



たくさんのテストを行いましたが、最終的にはトップレベルの指標である主要道路に行くことにしました。また、特定のテストが多数ある場合、データを最新の状態に保つことは困難です。以降の各リリースでは、システム全体が大幅に破損するため、修正するだけです。したがって、私たちはめったに変更されない非常に基本的なものに結び付け、それらを監視するだけです。



最後に、第3に、データソースは一元化されたロギングシステムです。ログにはElasticStackを使用し、このデータをビジネスメトリックの監視システムにドラッグできます。これらすべてに加えて、Pythonで記述された独自のMonitoring APIサービスが機能し、APIを介してすべてのサービスにクエリを実行し、それらからデータをZabbixに取得します。



監視のもう1つのかけがえのない属性は、視覚化です。グラファナをベースに構築しています。他の視覚化システムの中でも、ダッシュボード上のさまざまなデータソースからのメトリックを視覚化できるという点で際立っています。オンラインストアのトップレベルの指標を収集できます。たとえば、DBMSから過去1時間に行われた注文数、Zabbixからこのオンラインストアを実行しているOSのパフォーマンス指標、Prometheusからこのアプリケーションのインスタンスの指標を収集できます。そして、これらすべてが1つのダッシュボードに表示されます。視覚的でアクセスしやすい。



セキュリティについて注意しておきます。現在、システムを完成させており、その後、グローバル監視システムと統合します。私の意見では、情報セキュリティの分野でeコマースが直面する主な問題は、ボット、パーサー、ブルートフォースに関連しています。これらはすべて、アプリケーションのパフォーマンスとビジネスの観点からの評判の両方に重大な影響を与える可能性があるため、これを監視する必要があります。そして、選択したスタックでこれらのタスクをうまくカバーします。



もう1つの重要な点は、アプリケーションレイヤーがPrometheusによって収集されることです。彼自身もZabbixと統合されています。また、sitespeedもあります。これは、ページの読み込み速度、ボトルネック、ページレンダリング、スクリプトの読み込みなどのパラメーターを適宜確認できるサービスであり、APIを介して統合されています。したがって、メトリックはそれぞれZabbixで収集され、そこからもアラートが送信されます。これまでのすべてのアラートは、送信の主な方法に送られます（今のところ、これらは電子メールと電報であり、最近MSチームに接続しました）。計画では、スマートボットがサービスとして機能し、関心のあるすべての製品チームに監視情報を提供するような状態にアラートを送ります。



私たちにとって、個々の情報システムのメトリックだけでなく、アプリケーションが使用するインフラストラクチャ全体にわたる一般的なメトリック（仮想マシンを実行する物理サーバーのクラスター、トラフィックバランサー、ネットワークロードバランサー、ネットワーク自体、通信チャネルの使用率）も重要です。さらに、独自のデータセンターのメトリック（いくつかあり、インフラストラクチャは非常に重要です）。







監視システムの利点は、すべてのシステムの状態を確認できるため、相互の影響や共通のリソースへの影響を評価できることです。そして最終的に、それは私たちの責任でもある資源計画を可能にします。サーバーリソース（eコマースのフレームワーク内のプール）の管理、新しい機器の導入と廃止、新しい機器の購入、リソース使用率の監査の実施などを行います。チームは毎年新しいプロジェクトを計画し、システムを開発しており、私たちがチームにリソースを提供することが重要です。



また、メトリックの助けを借りて、情報システムによるリソース消費の傾向を確認できます。そしてすでに彼らに基づいて私たちは何かを計画することができます。仮想化レベルでは、データを収集し、データセンターのコンテキストで利用可能なリソースの量に関する情報を確認します。そして、すでにデータセンター内で、リソースの使用率、実際の分散、消費を確認できます。さらに、スタンドアロンサーバーと仮想マシン、およびこれらすべての仮想マシンが活発に回転している物理サーバーのクラスターの両方を使用します。

展望

これで、システム全体のコアの準備が整いましたが、作業するのに十分な時間が残っています。少なくともこれは情報セキュリティの層ですが、ネットワークにアクセスし、アラートを作成し、相関関係を使用して問題を解決することも重要です。多くのレイヤーとシステムがあり、各レイヤーにはさらに多くのメトリックがあります。それはmatryoshkaの程度にmatryoshkaになります。



私たちの仕事は、最終的には適切なアラートを作成することです。たとえば、ハードウェアに問題があり、仮想マシンに問題があり、重要なアプリケーションがあり、サービスがまったくバックアップされていない場合です。仮想マシンが停止したことがわかりました。次に、ビジネス指標を警告します。ユーザーがどこかで姿を消した、変換がない、インターフェイスのUIが利用できない、ソフトウェアとサービスも停止した。



この状況では、アラートからスパムを受信しますが、これは正しい監視システムの形式に適合しなくなります。相関の問題が発生します。したがって、理想的には、監視システムは、何百ものアラートで猛烈に攻撃するのではなく、1つのアラートの助けを借りて、「みんな、あなたの物理的なマシンが死んだ、そしてそれに伴ってこのアプリケーションとそのようなメトリック」と言うべきです。彼女は主なことを報告しなければなりません-理由は、そのローカリゼーションによる問題の除去の迅速さに貢献します。



当社のアラートおよびアラート処理システムは、24時間年中無休のホットラインサービスを中心に構築されています。私たちにとってなくてはならないものと見なされ、チェックリストに含まれているすべてのアラートがそこに送信されます。各アラートには、何が起こったか、実際に何を意味するか、何に影響するかなどの説明が必要です。また、ダッシュボードへのリンクと、この場合の対処方法についても説明します。



アラートを作成するための要件は以上です。さらに、状況は2つの方向に発展する可能性があります。問題があり、解決する必要があるか、監視システムに障害が発生したかのいずれかです。しかし、いずれにせよ、あなたはそれを理解する必要があります。



現在、平均して1日あたり約100のアラートが発生しています。これは、アラートの相関関係がまだ適切に構成されていないという事実を考慮に入れています。そして、技術的な作業を行う必要があり、何かを強制的にオフにすると、その数は大幅に増加します。



私たちが運用しているシステムを監視し、私たちの側で重要と見なされるメトリックを収集することに加えて、監視システムを使用すると、製品チームのデータを収集できます。これらは、ここで監視される情報システム内のメトリックの構成に影響を与える可能性があります。



私たちの同僚が来て、私たちとチームに役立ついくつかのメトリックを追加するように依頼することができます。または、たとえば、チームは私たちが持っている基本的なメトリックを十分に持っていない可能性があり、特定のメトリックを追跡する必要があります。 Grafanaでは、チームごとにスペースを作成し、管理者権限を発行します。また、チームがダッシュボードを必要としているが、チーム自身がそれを行う方法を理解できない/わからない場合、私たちは彼らを支援します。



私たちはチームの価値創造、リリース、計画の流れの外にいるため、すべてのシステムのリリースはシームレスであり、私たちと調整しなくても毎日展開できるという結論に徐々に達します。また、これらのリリースを追跡することは重要です。これらのリリースは、アプリケーションの動作に影響を与えて何かを壊す可能性があるためです。これは非常に重要です。リリースを管理するために、Bambooを使用します。ここから、APIを介してデータを取得し、どのリリースでどの情報システムがリリースされたか、およびそれらのステータスを確認できます。そして、最も重要なことはいつですか。主要な重要な指標にリリースマーカーを配置します。これは、問題が発生した場合に視覚的に非常にわかりやすくなります。



このようにして、新しいリリースと新たな問題との相関関係を確認できます。主なアイデアは、システムがすべてのレイヤーでどのように機能するかを理解し、問題をすばやく特定して、同じようにすばやく修正することです。実際、問題を解決するのではなく、原因を見つけるためにほとんどの時間が費やされることがよくあります。



そして、将来的にはこの方向で、積極性に焦点を当てたいと思います。理想的には、解決策ではなく予防に対処するために、事後ではなく、差し迫った問題について事前に知りたいと思います。人為的ミスとアプリケーションの変更の両方が原因で、監視システムの誤検知が発生することがあります。私たちはこれに取り組んでおり、監視システムを操作する前に、これについてユーザーに警告するように取り組んでいます。 、またはテクニカルウィンドウでこれらのイベントを実行します。



そのため、このシステムは開始され、春の初めから正常に機能しています...そして非常に実質的な利益を示しています。もちろん、これは最終バージョンではありません。さらに多くの便利な機能を紹介します。しかし、現在、非常に多くの統合とアプリケーションがあるため、監視の自動化は本当に不可欠です。



多数の統合を伴う大規模なプロジェクトも監視している場合は、このために見つけた特効薬をコメントに書き込んでください。