私たちはスポーツマスターを監視します - どのように、何を使って

プロダクトチームを編成する段階で監視体制の構築を考えました。 私たちのビジネス、つまり搾取はこれらのチームに当てはまらないことが明らかになりました。 何故ですか？

実際のところ、私たちのチームはすべて、個々の情報システム、マイクロサービス、フロントを中心に構築されているため、システム全体の全体的な健全性をチームが把握しているわけではありません。 たとえば、ディープ バックエンドの小さな部分がフロントエンドにどのような影響を与えるかを知らない可能性があります。 彼らの関心の範囲は、システムが統合されているシステムに限定されています。 チームとそのサービス A がサービス B とほとんど関係がない場合、そのようなサービスはチームにはほとんど見えません。

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

したがって、私たちの部門はどのチームにも属しておらず、少し横に位置していることがわかりました。 この全体のストーリーにおいて、私たちの任務は、情報システムがどのように動作するか、その機能、統合、ソフトウェア、ネットワーク、ハードウェア、そしてこれらすべてがどのように相互に接続されているかを包括的に理解することです。

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

• フロント
• ミドルオフィス
• バックオフィス

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

理想的には、プラットフォーム全体の健全性モニタリングを自動化する必要があります。 そして私たちは、このプロセスの必然的な部分としてモニタリングを行うようになりました。 当初、このシステムは最前線部分のみを対象として構築されていましたが、ネットワーク スペシャリスト、ソフトウェアおよびハードウェア管理者は独自のレイヤーごとの監視システムを使用していましたし、現在も使用しています。 これらの人々は全員、自分のレベルでのみモニタリングに従っており、包括的な理解を持っている人もいませんでした。

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

最終的に、このような異なるストーリーは、フロントエンド全体、ユーザー、そして当社の中核となるビジネス機能であるオンライン販売に影響を及ぼします。 私たちはチームの一員ではなく、オンライン ストアの一部としてすべての e コマース アプリケーションの運用に携わっているため、e コマース プラットフォームの包括的な監視システムを作成するというタスクを引き受けました。

システム構造とスタック

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

アプリケーションの立ち上げの初期段階で包括的な監視が欠如していたために (ほとんどのシステムが実稼働状態にあったときに構築を開始したため)、プラットフォーム全体の監視を設定するために多大な技術的負債を抱えていたという事実につながりました。 残りのシステムはしばらく監視されないままになるため、XNUMX つの IS の監視を設定し、その監視を詳細に検討することに集中する余裕はありませんでした。 この問題を解決するために、私たちは情報システムの状態を層ごとに評価するために最も必要な指標のリストを特定し、その実装を開始しました。

そこで彼らはゾウを部分的に食べることにしました。

私たちのシステムは次のもので構成されています。

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

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

さて、スタックについて。

私たちはオープンソースソフトウェアを使用しています。 中心には Zabbix があり、主に警告システムとして使用しています。 これがインフラストラクチャの監視に最適であることは誰もが知っています。 これはどういう意味ですか？ サーバーの温度、メモリの状態、RAID、ネットワーク デバイスのメトリクスなど、独自のデータ センターを維持するすべての企業 (Sportmaster も独自のデータ センターを持っています) が持つ、まさにこれらの低レベルのメトリクスです。

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

ほかに何か。 Zabbix に加えて、動的環境アプリケーションでメトリクスを監視できる Prometheus を使用します。 つまり、HTTP エンドポイント経由でアプリケーション メトリクスを受信でき、どのメトリクスをロードするか、どのメトリクスをロードしないかを気にする必要がありません。 このデータに基づいて、分析クエリを開発できます。

他のレイヤー (ビジネス指標など) のデータ ソースは XNUMX つのコンポーネントに分割されます。

まず、これらは外部ビジネス システムである Google Analytics であり、ログから指標を収集します。 そこから、アクティブ ユーザー、コンバージョン、その他ビジネスに関連するすべてのデータを取得します。 XNUMX 番目に、これは UI 監視システムです。 もっと詳しく説明する必要がある。

かつて、私たちは手動テストから始まり、機能と統合の自動テストに成長しました。 これを基に、主要な機能のみを残してモニタリングを作成し、可能な限り安定しており、時間の経過とともに頻繁に変更されないマーカーに依存しました。

新しいチーム構造は、すべてのアプリケーション活動が製品チームに限定されることを意味するため、純粋なテストを行うのをやめました。 代わりに、Java、Selenium、Jenkins (レポートの起動と生成のためのシステムとして使用) で書かれたテストから UI モニタリングを作成しました。

たくさんのテストをしましたが、最終的にはメインロードであるトップレベルの指標に進むことにしました。 また、特定のテストが多数ある場合は、データを最新の状態に保つことが困難になります。 その後のリリースごとにシステム全体が大幅に破壊されるため、私たちが行うのはそれを修正することだけです。 したがって、私たちはめったに変更されない非常に基本的なものに焦点を当て、それらを監視するだけでした。

最後に、XNUMX 番目に、データ ソースは集中ログ システムです。 ログには Elastic Stack を使用し、このデータを監視システムに取り込んでビジネス指標を得ることができます。 これらすべてに加えて、Python で書かれた独自のモニタリング API サービスがあり、API 経由でサービスにクエリを実行し、そこからデータを Zabbix に収集します。

監視に欠かせないもう XNUMX つの特性は視覚化です。 私たちのものはGrafanaに基づいています。 ダッシュボード上でさまざまなデータ ソースからのメトリクスを視覚化できるという点で、他の視覚化システムの中でも際立っています。 オンライン ストアのトップレベルのメトリクス、たとえば DBMS から過去 XNUMX 時間に行われた注文数、Zabbix からこのオンライン ストアが実行されている OS のパフォーマンス メトリクス、このアプリケーションのインスタンスのメトリクスを収集できます。プロメテウスより。 これらすべてが XNUMX つのダッシュボード上に表示されます。 明確でアクセスしやすい。

セキュリティについて言及しておきます。現在、システムを最終調整中ですが、後でグローバル監視システムと統合する予定です。 私の意見では、情報セキュリティの分野で電子商取引が直面する主な問題は、ボット、パーサー、ブルート フォースに関連しています。 これらすべてがアプリケーションの動作とビジネスの観点からの評判の両方に重大な影響を与える可能性があるため、私たちはこれに注意を払う必要があります。 そして、選択したスタックを使用して、これらのタスクを正常にカバーします。

もう XNUMX つの重要な点は、アプリケーション層が Prometheus によって組み立てられることです。 彼自身も Zabbix に統合されています。 また、ページの読み込み速度、ボトルネック、ページのレンダリング、スクリプトの読み込みなどのパラメーターを表示できるサービスである sitespeed もあり、API も統合されています。 したがって、メトリクスは Zabbix で収集され、それに応じてそこからアラートも生成されます。 現在、すべてのアラートは主要な送信方法で送信されています (現時点では電子メールと電報ですが、最近では MS Teams も接続されました)。 スマートボットがサービスとして機能し、関心のあるすべての製品チームに監視情報を提供するような状態にアラートをアップグレードする計画があります。

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

当社の監視システムの利点は、すべてのシステムの健全性状態を確認し、相互および共有リソースへの影響を評価できることです。 そして最終的には、それによって私たちはリソース計画に取り組むことができるようになり、それが私たちの責任でもあります。 当社は、サーバー リソース (電子商取引内のプール) を管理し、新しい機器の運用と廃止、追加の新しい機器の購入、リソース使用率の監査の実施などを行います。 毎年、チームは新しいプロジェクトを計画し、システムを開発します。私たちは彼らにリソースを提供することが重要です。

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

見込み

システム全体の核となる部分は完成しましたが、まだまだ取り組むべき点がたくさんあります。 これは少なくとも情報セキュリティ層ですが、ネットワークに到達し、警告を発し、相関関係の問題を解決することも重要です。 多くのレイヤーとシステムがあり、各レイヤーにはさらに多くのメトリクスがあります。 マトリョーシカの程度のマトリョーシカであることがわかります。

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

この状況では、アラートからスパムを受信することになり、これは適切な監視システムの形式に適合しなくなります。 相関関係の問題が生じます。 したがって、理想的には、監視システムは、XNUMX 件のアラートを猛烈に浴びせるのではなく、XNUMX 件のアラートで「皆さん、あなたの物理マシンが故障しました。それに伴い、このアプリケーションとこれらのメトリクスも故障しました」と伝えるべきです。 重要なこと、つまり原因を報告する必要があり、局所化による問題を迅速に解決するのに役立ちます。

当社の通知システムとアラート処理は、XNUMX 時間のホットライン サービスを中心に構築されています。 必須と考えられ、チェックリストに含まれているすべてのアラートがそこに送信されます。 各アラートには、何が起こったのか、実際に何を意味するのか、何に影響するのかなどの説明が必要です。 また、ダッシュボードへのリンクと、この場合に行うべき手順についての説明も含まれています。

これはアラートを作成するための要件に関するすべてです。 その場合、状況は XNUMX つの方向に発展する可能性があります。問題があり解決する必要があるか、監視システムに障害が発生したかのいずれかです。 しかし、いずれにせよ、行ってそれを理解する必要があります。

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

当社が運用しているシステムを監視し、当社側で重要と考えられる指標を収集するだけでなく、監視システムにより製品チームのデータを収集することもできます。 これらは、監視している情報システム内の指標の構成に影響を与える可能性があります。

私たちの同僚が来て、私たちとチームの両方にとって役立つ指標を追加するように依頼するかもしれません。 あるいは、たとえば、チームは私たちが持っている基本的な指標を十分に持っていない可能性があるため、いくつかの特定の指標を追跡する必要があります。 Grafana では、チームごとにスペースを作成し、管理者権限を付与します。 また、チームがダッシュボードを必要としているが、チーム自身がダッシュボードを作成できない、またはその方法を知らない場合は、私たちがサポートします。

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

このようにして、新しいリリースと新たな問題との相関関係を確認できます。 主なアイデアは、システムがすべての層でどのように動作するかを理解し、問題の箇所を迅速に特定し、同様に迅速に修正することです。 結局のところ、問題の解決ではなく、原因の究明に最も時間がかかることがよくあります。

今後もこの分野に積極的に注力していきたいと考えています。 理想的には、迫りくる問題について事後ではなく事前に知り、解決するのではなく予防できるようにしたいと考えています。 人的ミスとアプリケーションの変更の両方により、監視システムの誤った警報が発生することがあります。そして、私たちはこれに取り組み、デバッグし、監視システムを操作する前に、それについて使用しているユーザーに警告するよう努めています。 、またはこれらのアクティビティを技術ウィンドウで実行します。

それで、システムは立ち上げられ、春の初めからうまく機能しており、非常に実際の利益を示しています。 もちろん、これが最終バージョンではなく、さらに多くの便利な機能を導入する予定です。 しかし現在、非常に多くの統合とアプリケーションが存在するため、監視の自動化は避けられません。

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

出所： habr.com