こんにちは！私の名前はアレクサンダーアフェノフです。ラモダで働いています。この記事は、HighLoad 2019からの私の話に基づいています。その記録はここにあります。



以前はチームリーダーで、いくつかの重要なサービスを担当していました。そして、何か問題が発生した場合、実際のビジネスプロセスが停止しました。たとえば、注文は倉庫内のアセンブリに行くのをやめました。



私は最近ディレクションリードになり、現在では1チームではなく3チームを担当しています。それぞれがITシステムを実行しています。各システムで何が起こっているのか、何が壊れるのかを理解したい。



この記事で私は話します

• 私たちが監視するもの
• 監視方法
• そして最も重要なのは、これらの観察結果をどのように処理するかです。

ラモダには多くのシステムがあります。それらはすべて解放され、何かが彼らの中で変化し、何かがテクノロジーで起こっています。そして、少なくとも故障を簡単に突き止めることができるという幻想が欲しいです。私は理解しようとする警告に常にさらされています。抽象化を避けて詳細に進むために、最初の例を紹介します。

時々何かが爆発する：火のクロニクル

暖かい夏の朝、宣戦布告なしで、いつものように、私たちの監視は機能しました。警告として、Icingaを使用します。 Alertによると、DBMSサーバーには50 GBのハードディスクが残っています。ほとんどの場合、50ギガバイトは海の落下であり、すぐに終了します。残りの空き容量を正確に確認することにしました。これらは仮想マシンではなくアイアンサーバーであり、データベースの負荷が高いことを理解する必要があります。 1.5テラバイトのSSDがあります。すぐにこの記憶は終わりを迎えます。それは20〜30日間続きます。これは非常に小さいので、問題をすばやく解決する必要があります。



次に、1〜2日で実際に消費されたメモリ量をさらに確認しました。 50ギガバイトは約5〜7日続くことがわかりました。その後、このベースで動作するサービスは予測どおりに終了します。結果について考え始めます。緊急にアーカイブするもの、削除するデータ。データ分析部門にはすべてのバックアップがあるため、2015年より古いものはすべて安全に削除できます。



私たちはそれを削除しようとしますが、MySQLはハーフキックではこのように機能しないことを覚えています。削除されたデータは素晴らしいですが、テーブルとDBに割り当てられたファイルのサイズは変わりません。 MySQLはこのスペースを使用します。つまり、問題は解決されず、スペースがなくなりました。



別のアプローチを試す：ラベルを、期限切れの早いSSDから遅いSSDに移行します。これを行うには、重量は大きいが負荷が小さいタブレットを選択し、Perconaモニタリングを使用します。テーブルを移動しましたが、サーバー自体の移動もすでに検討しています。 2番目の移動後、サーバーは1.5ではなく4テラバイトのSSDを使用します。



私たちはこの火を消しました：移動を計画し、そしてもちろん、固定監視をしました。これで、警告は50ギガバイトではなく、半テラバイトでトリガーされ、重要な監視値は50ギガバイトになります。しかし、実際には、これは後部を覆う単なる毛布です。しばらく続きます。しかし、ベースをパーツに分割せずにシャーディングを考えずに、状況の繰り返しを許可すると、すべてが異常終了します。



サーバーをさらに変更したとします。ある段階で、マスターを再起動する必要がありました。おそらく、この場合はエラーになります。私たちの場合、ダウンタイムは約30秒でした。しかし、リクエストが来て、どこにも書くことができず、エラーが降り、監視は機能しました。私たちはPrometheus監視システムを使用しています-そして、注文を作成するときの500エラーのメトリックまたはエラーの数が急増していることがわかります。しかし、詳細はわかりません。作成されなかった注文の種類などです。



さらに、そのような状況にならないようにするために、監視をどのように処理するかを説明します。

モニタリングのレビューとカスタマーサポートの明確な説明

観察しているいくつかの領域と指標があります。オフィスのいたるところにテレビがあり、そこにはさまざまな技術ラベルやビジネスラベルがあり、開発者に加えて、サポートサービスによって監視されています。



この記事では、私たちがどのようにそれを持っているかについて話し、私たちが行きたいものを追加します。これはレビューの監視にも適用されます。 「プロパティ」のインベントリを定期的に実施した場合、古いものすべてを更新して修正し、fakapの繰り返しを回避できます。これを行うには、明確なリストが必要です。



私たちのリポジトリには、現在4678行あるアラート付きの設定があります。このリストから、各特定の監視が何について話しているかを理解することは困難です。メトリックがdb_disc_space_leftであるとしましょう。サポートサービスは、これが何であるかをすぐには理解しません。フリースペースについての何か、素晴らしい。



もっと深く掘り下げたい。この監視の構成を見て、それがどこから来たかを理解します。

pm_host: "{{ prometheus_server }}" 
pm_query: ”mysql_ssd_space_left" 
pm_warning: 50 
pm_critical: 10 pm_nanok: 1 

このメトリックには名前があり、独自の制限があります。警告監視を有効にするタイミングと、重要な状況を報告するアラートです。メトリックの命名規則を使用します。各メトリックの先頭には、システム名があります。これのおかげで、責任の領域が明らかになります。システムの担当者がメトリックを開始すると、誰に行くべきかすぐにわかります。



アラートは電報またはスラックに注がれます。サポートサービスは、24時間年中無休で対応する最初のサービスです。これが正常な状況である場合、彼らは正確に何が爆発したかを見ます。彼らは指示があります：

• 交換するために与えられたもの、
• 継続的に合流して修正される指示。展開された監視の名前によって、それが何を意味するかを見つけることができます。最も重要なのは、何が壊れているか、どのような結果が生じるか、誰を上げる必要があるかについて説明されています。

また、主要なシステムを担当するチームにシフトシフトがあります。各チームには、常に対応できる人がいます。何かが起こったら、彼らは彼を迎えに行きます。



アラートがトリガーされると、サポートチームはすべての重要な情報をすばやく見つける必要があります。エラーメッセージに添付されている監視の説明へのリンクを用意しておくと便利です。たとえば、そのような情報があるように：

1. この監視の説明は、理解しやすく、比較的単純です。
2. 所在地の住所。
3. このメトリックの説明;
4. 結果：間違いを訂正しない場合、どのように終了するか。
5. , , . , , . -, .

また、Prometheusインターフェースでトラフィックダイナミクスをすぐに確認できると便利です。



モニタリングごとにそのような記述をしたいと思います。彼らはあなたのレビューを構築し、調整を行うのに役立ちます。私たちはこのプラクティスを実装しています。アイシング構成には、この情報との合流へのリンクがすでに含まれています。私はほぼ4年間1つのシステムに取り組んできましたが、基本的にそのような説明はありません。だから今私は一緒に知識を集めています。説明は、チームの意識の​​欠如も解決します。



特定のビジネスへの影響につながるものを示しているほとんどのアラートの指示があります。このため、状況を迅速に整理する必要があります。起こり得るインシデントの重要度は、ビジネスとともにサポートサービスによって決定されます。



例を挙げましょう。注文処理サービスのRabbitMQサーバーでのメモリ消費の監視がトリガーされた場合、これはキューサービスが数時間または数分でクラッシュする可能性があることを意味します。これにより、多くのビジネスプロセスが停止します。その結果、顧客は注文、SMS /プッシュ通知、ステータス変更などを待たずに失敗します。



ビジネスとの監視についての議論は、重大な事件の後にしばしば起こります。何かが壊れている場合、私たちは、私たちの釈放または事件に引っかかった指示の代表者と共に委員会を集めます。会議では、インシデントの原因、二度と起こらないようにする方法、被害を受けた被害、損失額、および損失額を分析します。



顧客のために作成された問題を解決するには、ビジネスを接続する必要がある場合があります。そこでは、予防的なアクションについて説明します。これが再び発生しないように、どのような監視を開始するかです。



サポートサービスは、電報ボットを使用してメトリックの値を監視します。新しい監視が行われると、サポートワーカーは、内訳がどこにあり、それに対して何をすべきかを見つけるための簡単なツールを必要とします。アラートの説明へのリンクはこの問題を解決します。

私はファカップを現実のように見ています：報告のためのセントリーの使用

エラーを見つけるだけでは不十分で、詳細を確認したい場合。標準的な使用例は次のとおりです。リリースをロールアウトし、K8Sスタックからアラートを受け取りました。監視のおかげで、ポッドのステータスを確認します。ロールアウトされたアプリケーションのバージョン、展開がどのように終了したかなど、すべて良好です。



次に、RMMを確認します。これは、ベースとそれに負荷がかかっているものです。 Grafanaとボードでは、ウサギへの接続数を調べます。彼はクールですが、メモリが不足したときにリークする方法を知っています。私たちはこれらを監視し、次にセントリーをチェックします。次の大失敗がどのように詳細に展開されるかをオンラインで見ることができます。この場合、リリース後の監視は何がどのように壊れているかを報告します。



PHPプロジェクトでは、レイヴンクライアントを使用し、さらにそれをデータで強化します。セントリーはそれをすべてうまくまとめています。そして、各fakapのダイナミクス、それが発生する頻度を確認します。また、リクエストが失敗した、アウトされたリクエストの例も確認します。





これはおおよその外観です。次のリリースでは、通常よりも多くのエラーがあることがわかります。具体的に何が壊れたかをチェックします。そして、必要に応じて、状況に応じて失敗した注文を取得し、修正します。



Jiraへのバインド-クールなものがあります。これはチケットトラッカーです。ボタンを押すと、JiraがSentryへのリンクとこのエラーのスタックトレースを含むエラータスクを作成しました。タスクには特定のラベルが付いています。



開発者の一人が賢明なイニシアチブをもたらしました-"Clean Project、Clean Sentry"。計画では、Sentryから作成された少なくとも1〜2個のタスクをスプリントに投入するたびに。システムで何かが常に壊れている場合、Sentryには何百万もの小さな愚かなバグが殺到しています。本当に深刻なものを見落とさないように、私たちは定期的にそれらを掃除します。

何らかの理由でブレイズ：監視が不要になり、誰もがそれに見舞われます

• 間違いに慣れる

何かが常に点滅して壊れているように見える場合、それは誤った基準の感覚を与えます。サービスデスクは、状況が適切であると誤解することがあります。そして、深刻な何かが壊れたとき、彼らはそれを無視します。「狼、狼！」と叫ぶ少年の寓話のように。



典型的なケースは、注文処理を担当する私たちのプロジェクトです。倉庫自動化システムと連携して、そこにデータを転送します。このシステムは通常午前7時にリリースされ、その後監視を開始します。誰もがそれに慣れ、詰まるので、あまり良くありません。これらのコントロールを調整することは賢明でしょう。たとえば、特定のシステムのリリースと一部のアラートをPrometheusでリンクするには、余分なアラームを切り取らないでください。

• モニタリングではビジネス指標は考慮されません

注文処理システムはデータを倉庫に転送します。このシステムに監視機能を追加しました。誰も解雇せず、すべてが順調に進んでいるようです。カウンターは、データが残っていることを示しています。このケースは石鹸を使用しています。実際には、カウンターは次のようになります。緑の部分は着信交換、黄色の部分は発信です。







データが本当に満足する場合がありましたが、曲線です。注文は支払われませんでしたが、支払済みとマークされました。つまり、購入者は無料でそれらを受け取ることができます。怖いみたいです。しかし、その逆の方がより楽しいです。人が支払われた注文を受け取るために来て、システムのエラーのために彼は再び支払うように求められます。



この状況を回避するために、テクノロジーだけでなくビジネス指標も監視しています。受領時に支払いが必要な注文の数を監視する特定の監視があります。このメトリックの大きな飛躍は、何か問題が発生したかどうかを示します。



ビジネスインジケーターの監視は当たり前のことですが、私たちを含め、新しいサービスがリリースされると、忘れられがちです。誰もが、ディスクに関連する純粋に技術的なメトリック、パーセントなど、新しいサービスを塗りつぶします。オンラインストアとして、私たちは重要なものを持っています-作成された注文の数。マーケティングプロモーションに合わせて調整された、通常の購入額を把握しています。したがって、リリース中にこのインジケータを監視します。



もう1つの重要なこと：クライアントが同じ住所への配達を繰り返し注文する場合、コールセンターとの通信によってクライアントを苦しめることはありませんが、自動的に注文を確認します。システムクラッシュは、カスタマーエクスペリエンスに大きな影響を与えます。異なるシステムからのリリースが大きな影響を与える可能性があるため、この測定基準にも従います。

現実の世界を観察する：健康的なスプリントとパフォーマンスを管理する

企業がさまざまな指標を追跡できるように、小さなリアルタイムダッシュボードシステムを書き留めました。もともと別の目的のために作られました。このビジネスには、来月の特定の日に販売したい注文数の計画があります。このシステムは、計画の遵守を示し、実際に作成されました。スケジュールについては、彼女は生産拠点からデータを取得し、その場でその場で読み取ります。



レプリカが壊れたら。モニタリングがなかったので、それを知る時間はありませんでした。しかし、ビジネスは、私たちが従来の10注文の計画を満たしていないことを知り、コメントを出しました。私たちはその理由を理解し始めました。壊れたレプリカから無関係なデータが読み取られていることがわかりました。これは、企業が興味深い指標を観察するケースであり、問​​題が発生したときに私たちは互いに助け合います。



長い間開発が続けられており、各チームによって常に調整されている、実世界の別の監視についてお話します。Jira Viewerがあります。開発プロセスを監視できます。システムは非常にシンプルです。PHPフレームワークSymfonyは、Jira Apiにアクセスし、入力として指定された内容に応じて、タスクやスプリントなどに関するデータをそこから取得します。Jira Viewerは、チームとそのプロジェクトに関連するメトリックを定期的にPrometeusに書き込みます。そこで監視され、警告され、そこからGrafanaに表示されます。このシステムのおかげで、私たちは進行中の作業を追跡します。

• 進行中の瞬間から本番環境にロールアウトするまでのタスクの継続時間を監視します。数が多すぎる場合、理論的には、これはプロセス、チーム、タスクの説明などに問題があることを示しています。タスクの寿命は重要なメトリックですが、それだけでは十分ではありません。
• . , , . , .
• – ready for release, . - - , « ».
• : , . .
• . 400 150. , , .
• 勤務時間外の開発者からのプルリクエストの数をチームで監視しました。特に、午後8時以降。そして、メトリックが急上昇したとき、これは憂慮すべき兆候です：人は何かのための時間がないか、あまりにも多くの努力を費やし、遅かれ早かれ燃え尽きます。

スクリーンショットは、Jira Viewerがデータを表示する方法を示しています。これは、スプリントからのタスクのステータスの概要、各タスクの重量などが記載されているページです。そのようなものも集まり、プロメテウスに飛びます。

技術的な測定基準だけでなく、すでに監視しているもの、監視できるもの、なぜこれがすべて必要なのか

まとめると、プロセス、開発、ビジネスに関連するテクノロジーとメトリックの両方を一緒に監視することをお勧めします。技術的な指標だけでは十分ではありません。

• , -, Grafana-. . , , .
• : , . , , crontab supervisor. . , , .
• – , , .
• : , - , . , .
• , . – Sentry . - , . - , . Sentry , , .
• . , , .
• , . , - , - . .