New Relic だけではない: Datadog と Atatus の概要

SRE/DevOps エンジニアの環境では、ある日クライアント (または監視システム) が現れて、「すべてが失われた」と報告しても、誰も驚かないでしょう。サイトは機能せず、支払いは完了せず、生活は衰退しています。 ...そのような状況でどれだけ助けたいと思っていても、シンプルでわかりやすいツールがなければ、これを行うのは非常に困難です。 多くの場合、問題はアプリケーション コード自体に隠されているため、必要なのはそれをローカライズすることだけです。

そして悲しみの中にも喜びの中にも…

偶然にも、私たちは長い間深く New Relic に夢中になっていました。 これは、アプリケーションのパフォーマンスを監視するための優れたツールであり、また、(エージェントを使用して) マイクロサービス アーキテクチャなどを計測することもできます。 そして、サービスの価格設定ポリシーの変更がなければ、すべてがうまくいったはずです。 コスト 2013年で 3倍以上に成長した。 さらに、昨年からトライアルアカウントを取得するには個人マネージャーとのコミュニケーションが必要となり、潜在的な顧客に製品を紹介することが難しくなりました。

通常の状況: New Relic は「永続的に」必要ではなく、問題が発生した瞬間にのみ New Relic を覚えています。 ただし、定期的に料金を支払う必要があり (サーバーあたり月額 140 米ドル)、自動的に拡張されるクラウド インフラストラクチャでは、その金額はかなり高額になります。 従量課金制のオプションもありますが、New Relic を有効にするにはアプリケーションを再起動する必要があり、これによりアプリケーションがすべて開始された問題の状況が失われる可能性があります。 少し前に、New Relic は新しい料金プランを導入しました - Essentials, - 一見すると、Professional の合理的な代替品のように見えます...しかし、詳しく調べてみると、いくつかの重要な機能が欠けていることがわかりました (特に、 主要なトランザクション, クロスアプリケーショントレース, 分散トレース).

その結果、より安価な代替サービスを探すことを検討し始め、Datadog と Atatus の XNUMX つのサービスを選択することになりました。 なぜ彼らに？

競合他社について

市場には他のソリューションがあることをすぐに言っておきます。 オープンソースのオプションも検討しましたが、すべてのクライアントがセルフホスト型ソリューションをホストするための空き容量を持っているわけではありません...さらに、追加のメンテナンスが必要になります。 私たちが選んだカップルは最も近いことが判明しました 私たちのニーズ:

• PHP アプリケーションの組み込みおよび開発されたサポート (当社のクライアントのスタックは非常に多様ですが、これは New Relic の代替を探すという状況において明確なリーダーです)。
• 手頃なコスト (ホストあたり月額 100 米ドル未満)。
• 自動計測器。
• Kubernetes との統合。
• New Relic インターフェースとの類似性は、顕著な利点です (当社のエンジニアはそれに慣れているため)。

したがって、最初の選択段階で、他のいくつかの一般的なソリューション、特に次のソリューションを除外しました。

• Tideways、AppDynamics、Dynatrace - コスト。
• Stackify はロシア連邦でブロックされており、表示されるデータが少なすぎます。

記事の残りの部分は、最初に問題のソリューションを簡単に紹介し、その後、New Relic との典型的なやり取りと、他のサービスで同様の操作を実行したときの経験/印象について説明するように構成されています。

選ばれた選手のプレゼンテーション

オン 新しいレリック、おそらく誰もが聞いたことがあるでしょうか？ このサービスは10年以上前の2008年に開発が始まりました。 私たちは 2012 年からこれを積極的に使用しており、PHP、Ruby、Python で非常に多くのアプリケーションを問題なく統合できました。また、C# や Go との統合の経験もあります。 このサービスの作成者は、アプリケーション、インフラストラクチャの監視、マイクロサービス インフラストラクチャのトレース、ユーザー デバイス用に作成された便利なアプリケーションなどのためのソリューションを提供しています。

ただし、New Relic エージェントは独自のプロトコルで実行され、OpenTracing をサポートしません。 高度なインスツルメンテーションには、New Relic 専用の編集が必要です。 最後に、Kubernetes のサポートはまだ実験段階です。

2010年に開発を開始 データドッグ Kubernetes 環境での使用という点では、New Relic よりも明らかに興味深いように見えます。 特に、NGINX Ingress、ログ収集、statsd、および OpenTracing プロトコルとの統合をサポートしています。これにより、接続の瞬間から完了までユーザー リクエストを追跡したり、このリクエストのログを検索したりできます (両方とも Web サーバー側で)。そして消費者にも）。

Datadog を使用すると、マイクロサービス マップが正しく構築されない場合があり、いくつかの技術的な欠点があることがわかりました。 たとえば、サービスの種類を誤って認識し (Django をキャッシュ サービスと間違えて)、人気のある Predis ライブラリを使用する PHP アプリケーションで 500 エラーを引き起こしました。

アタトゥス — 最年少の楽器。 サービスは2014年に開始されました。 同社のマーケティング予算はリストされている競合他社よりも明らかに劣っており、言及されることはほとんどありません。 ただし、ツール自体は、機能 (APM、ブラウザ監視など) だけでなく、外観も New Relic に非常に似ています。

重大な欠点は、Node.js と PHP のみをサポートしていることです。 一方で、Datadog よりも著しく優れた実装が施されています。 後者とは異なり、Atatus ではアプリケーションがコードに変更を加えたりラベルを追加したりする必要はありません。

New Relic との連携方法

ここで、New Relic を一般的にどのように使用するかを考えてみましょう。 解決策が必要な問題があるとします。

グラフで見るとわかりやすいですね スプラッシュ - 分析してみましょう。 New Relic では、Web トランザクションは Web アプリケーションに対して即座に選択され、すべてのコンポーネントがパフォーマンス グラフに示され、エラー率、リクエスト率のパネルがあります...最も重要なことは、これらのパネルから直接、異なるパネル間を移動できることです。アプリケーションの一部 (たとえば、MySQL をクリックするとデータベース セクションに移動します)。

検討中の例ではアクティビティの急増が見られるため、 PHP、このチャートをクリックすると、自動的に次の場所に移動します。 取引:

本質的に MVC モデルのコントローラーであるトランザクションのリストは、すでに次の順序で並べ替えられています。 最も時間がかかるこれは非常に便利です。アプリケーションが何をしているのかがすぐにわかります。 New Relic によって自動的に収集される長いクエリの例を次に示します。 並べ替えを切り替えると、次のものが簡単に見つかります。

• 最も負荷の高いアプリケーション コントローラー。
• 最も頻繁にリクエストされるコントローラー。
• コントローラーの中で最も遅い。

さらに、各トランザクションを展開して、コードの実行時にアプリケーションが何を行っていたかを確認できます。

最後に、アプリケーションは長いリクエスト (2 秒以上かかるもの) のトレースの例を保存します。 長いトランザクションのパネルは次のとおりです。

XNUMX つのメソッドに多くの時間がかかることがわかり、リクエストが実行された時刻と同時に、その URI とドメインも表示されます。 多くの場合、これはログ内のリクエストを見つけるのに役立ちます。 に行く トレースの詳細で、これらのメソッドがどこから呼び出されているかを確認できます。

とで データベースクエリ — アプリケーションの実行中に実行されたデータベースへのクエリを評価します。

この知識があれば、アプリケーションの速度が低下する理由を評価し、開発者と協力して問題を解決する戦略を立てることができます。 実際には、New Relic は常に明確な全体像を提供するとは限りませんが、調査のベクトルを選択するのに役立ちます。

• 長い PDO::Construct pgpoll の奇妙な機能に私たちは導かれました。
• 時間の経過とともに不安定になる Memcache::Get 仮想マシンが正しく構成されていないことを示唆しました。
• テンプレート処理にかかる時間が疑わしいほど増加したため、オブジェクト ストレージ内の 500 個のアバターの存在をチェックするネストされたループが発生しました。
• 以下のように...

また、コードを実行する代わりに、外部データ ストレージに関連するものがメイン画面に表示されることもあります。Redis や PostgreSQL など、それらはすべてタブ内に表示されます。 データベース.

トランザクションで行う方法と同様に、リサーチ用の特定のベースを選択し、クエリを並べ替えることができます。 [リクエスト] タブに移動すると、各アプリケーション コントローラーでこのリクエストが何回発生したかを確認し、呼び出される頻度を推定することもできます。 とても快適です:

タブには同様のデータが含まれています 外部サービス、オブジェクト ストレージへのアクセス、セントリへのイベントの送信など、外部 HTTP サービスへのリクエストを非表示にします。 このタブの内容はデータベースと完全に似ています。

競合他社: 機会と印象

ここで最も興味深いのは、New Relic の機能を競合他社が提供する機能と比較することです。 残念ながら、実稼働環境で実行されている XNUMX つのアプリケーションの XNUMX つのバージョンで XNUMX つのツールすべてをテストすることはできませんでした。 ただし、可能な限り同一の状況/構成を比較するように努めました。

1.Datadog

Datadog は、サービスの壁を備えたパネルで私たちを迎えてくれます。

アプリケーションをコンポーネント/マイクロサービスに分割しようとするため、サンプル Django アプリケーションでは PostgreSQL への 2 つの接続が表示されます (defaultdb и postgres）、セロリ、レディスと同様に。 Datadog を使用するには、MVC の原則に関する最低限の知識が必要です。つまり、ユーザーのリクエストが一般的にどこから来るのかを理解する必要があります。 これは通常役に立ちます サービスマップ:

ちなみに、New Relicにも似たようなものがあります。

...そして私の意見では、そのマップはよりシンプルかつ明確になっています。XNUMX つのアプリケーションのコンポーネント (Datadog の場合のように過度に詳細になる) は表示されず、特定のサービスまたはマイクロサービスのみが表示されます。

Datadog に戻りましょう。サービス マップから、ユーザー リクエストが Django に送信されていることがわかります。 Django サービスにアクセスして、最終的に予想した結果を確認してみましょう。

残念ながら、デフォルトではここにグラフはありません Webトランザクション時間、メインの New Relic パネルに表示されるものと同様です。 ただし、スケジュールの代わりに設定することもできます。 費やした時間の割合。 に切り替えるだけで十分です タイプごとのリクエストあたりの平均時間...そして今、見慣れたグラフが私たちに注目しています。

なぜ Datadog が別のチャートを選択したのかは私たちにとって謎です。 もう XNUMX つのイライラする点は、(競合他社とは異なり) システムがユーザーの選択を記憶しないため、唯一の解決策はカスタム パネルを作成することです。

しかし、これらのグラフから関連サーバーのメトリクスに切り替え、ログを読み取り、Web サーバー ハンドラー (Gunicorn) の負荷を評価できる Datadog の機能には満足していました。 すべてが New Relic とほぼ同じです...さらには (ログが) もう少し多くなります。

グラフの下には、New Relic と完全に類似したトランザクションが表示されます。

Datadog では、トランザクションは次のように呼ばれます。 資源。 リクエストの数、平均応答時間、および選択した期間に費やされた最大時間によってコントローラーを並べ替えることができます。

リソースを展開すると、New Relic ですでに観察されたすべての内容を確認できます。

リソースに関する統計、内部呼び出しの一般化されたリスト、応答コード別にソートできるリクエストの例があります... ちなみに、当社のエンジニアはこのソートを非常に気に入っていました。

Datadog 内の任意のサンプル リソースを開いて調べることができます。

リクエスト パラメーター、各コンポーネントに費やされた時間の概要グラフ、および呼び出しのシーケンスを示すウォーターフォール グラフが表示されます。 ウォーターフォール チャートのツリー ビューに切り替えることもできます。

そして最も興味深いのは、リクエストが実行されたホストの負荷を表示し、リクエスト ログを表示することです。

素晴らしい統合です！

タブがどこにあるのか疑問に思うかもしれません データベース и 外部サービス、New Relicのように。 ここには何もありません。Datadog はアプリケーションをコンポーネントに分解するため、PostgreSQL が考慮されます。 別のサービス外部サービスの代わりに探す価値があります aws.storage (アプリケーションがアクセスできる他のすべての外部サービスでも同様です)。

以下にその例を示します postgres:

基本的に、私たちが望んでいたものはすべてあります。

リクエストがどの「サービス」から来たのかを確認できます。

Datadog は NGINX Ingress と完全に統合されており、リクエストがクラスターに到着した瞬間からエンドツーエンドのトレースを実行できるほか、statsd メトリクスの受信、ログの収集、メトリクスのホストも可能であることを思い出していただくのは間違いありません。 。

Datadog の大きな利点は、その価格です。 整形です インフラストラクチャ監視、APM、ログ管理、合成テストなど。 柔軟にプランをお選びいただけます。

2.アタトゥス

Atatus チームは、自社のサービスは「New Relic と同じですが、それより優れている」と主張しています。 これが本当にそうなのか見てみましょう。

メイン パネルは似ていますが、アプリケーションで使用されている Redis と memcached を特定することはできませんでした。

APM はデフォルトですべてのトランザクションを選択しますが、通常は Web トランザクションのみが必要です。 Datadog と同様に、メイン パネルから目的のサービスに移動する方法はありません。 さらに、トランザクションはエラーの後にリストされますが、これは APM にとってあまり論理的ではないようです。

Atatus のトランザクションでは、すべてが New Relic と可能な限り類似しています。 欠点は、各コントローラーのダイナミクスがすぐに表示されないことです。 コントローラーテーブルでソートしてそれを探す必要があります。 最も多くの時間を費やした:

コントローラの通常のリストはタブで利用できます。 詳細:

ある意味、このテーブルは Datadog を彷彿とさせますが、私は New Relic の同様のテーブルよりも気に入っています。

各トランザクションを展開すると、アプリケーションが何を行っていたかを確認できます。

このパネルは Datadog をより彷彿とさせます。多数のリクエストとコールの全体像が表示されます。 上部パネルにはエラータブが表示されます HTTP の失敗 遅いクエリの例 セッショントレース:

トランザクションに移動すると、トレースの例が表示され、データベースへのリクエストのリストを取得して、リクエスト ヘッダーを確認できます。 すべてが New Relic に似ています。

一般に、Atatus は詳細なトレースに満足しています。New Relic の典型的なリマインダー ブロックへの呼び出しの貼り付けは不要です。

ただし、(New Relic のように) 超高速リクエスト (5 ミリ秒未満) を遮断するフィルターがありません。 一方、最終的なトランザクション応答 (成功またはエラー) の表示は気に入りました。

パネル データベース アプリケーションが行う外部データベースへのリクエストを調べるのに役立ちます。 Redis と memcached もプロジェクトに関与していますが、Atatus は PostgreSQL と MySQL のみを発見したことを思い出してください。

リクエストは、応答頻度、平均応答時間などの通常の基準に従って並べ替えられます。 クエリが最も遅いタブについても触れておきたいと思います。これは非常に便利です。 さらに、PostgreSQL のこのタブのデータは、拡張機能からのデータと一致しました。 pg_stat_statements - 素晴らしい結果です！

タブ 外部からのリクエスト データベースとまったく同じです。

所見

提示された両方のツールは、APM の役割において優れたパフォーマンスを発揮しました。 どれも必要最小限のものを提供できます。 私たちの印象を簡単にまとめると次のようになります。

データドッグ

長所：

• 便利な料金体系 (APM はホストごとに 31 米ドルかかります)。
• Python ではうまく動作しました。
• OpenTracing との統合の可能性
• Kubernetes との統合。
• NGINX Ingress との統合。

短所：

• モジュール エラー (predis) によりアプリケーションが使用できなくなる原因となった唯一の APM。
• 弱い PHP 自動インスツルメンテーション。
• サービスとその目的の部分的に奇妙な定義。

アタトゥス

長所：

• 深い PHP インストルメンテーション。
• New Relic に似たユーザー インターフェイス。

短所：

• 古いオペレーティング システム (Ubuntu 12.05、CentOS 5) では動作しません。
• 弱い自動計測。
• XNUMX つの言語 (Node.js と PHP) のみをサポートします。
• インターフェイスが遅い。

Atatus のサーバーあたり月額 69 米ドルという価格を考慮すると、私たちのニーズ (K8s の Web アプリケーション) によく統合され、多くの便利な機能を備えた Datadog を使用することを選択します。

PS

私たちのブログもお読みください:

• «Kubernetes 上で実行されるアプリケーションの開発者向けのツール";
• «Kubernetes ポッドでデバッグするための kubectl-debug プラグイン";
• «マイクロサービス: Kubernetes を使用している場合でも、サイズは重要です'。

出所： habr.com