1 分でハイライトを簡単に概要説明
現段階では、可観測性を構築するための統一された実行パスはありません。各企業は、独自のビジネス ニーズ、運用モデル、規模に基づいて独自の一連の実践を形成します。ビジネス規模の拡大や要件の変化に対応するために、オブザーバブルチームはアーキテクチャの最適化とアップグレードを継続的に行い、オブザーバブルシステム自体の高可用性を常に確保する必要があります。
この記事では、単一アプリケーション段階でのリソースのボトルネック、運用保守コストの上昇、分散サービスでの通信の問題など、2017 年から現在までに滴滴出行が 4 つの異なる段階で遭遇した技術的課題について詳しく説明します。Didi は、適切な技術ソリューションを見つけて適用することで、これらの技術的問題を徐々に克服し、その観察可能なアーキテクチャが常にビジネスを強力にサポートできるようにしました。
著者について
Didi Chuxing の観察可能な建築のリーダー — Qian Wei
Taroks 安定性コミュニティの専門家チームのメンバーであり、滴滴出行の観察可能なアーキテクチャの責任者です。彼は長年にわたり、アーキテクチャの設計と最適化に焦点を当て、観察可能な分野に深く関わってきました。チームを率いて、Didi の第 2 世代から第 4 世代のアーキテクチャの反復を完了しました。複数の観察可能なオープンソース プロジェクトの貢献者。現在の焦点は、Didi 可観測性の安定性構築と、Didi シナリオにおける可観測性の実現と実装にあります。
注意: この記事は約 7,500 文字で、読むのに約 12 分かかります。
「TakinTalks Stability Community」パブリック アカウント バックエンドは、リーダー コミュニケーション グループに入るには「Communication」と応答し、コースウェア情報を取得するには「1026」と応答します。
背景
まずはストーリーを見てみましょう——
「20世紀初頭、フォードは急速な発展の時期にありました。ある日、モーターが故障し、関連する生産作業が停止せざるを得なくなりました。多くの労働者や専門家が問題を発見できませんでした。スタインメンツという男が招待されるまでは、機械を検査した後、シュタインメンツ氏はモーターのケーシングにチョークで線を描き、モーターのスイッチを入れてマークのコイルを 16 回転減らすように指示しました。修理工がそうした後、障害は解消され、生産はすぐに再開されました。」
私たちが仕事をしているとき、または開発プロセス中に、このようなシナリオに遭遇することがよくあります。つまり、混乱してどこから始めればよいかわからない問題ですが、問題を一目で理解できる 1 人か 2 人の「専門家」が常に存在します。それで、私たちはそれについて考える必要があります、これは良いことですか、それとも悪いことですか？
Didi のビジネスは旅行プラットフォームとして、特急列車、自家用車、配車、シェア自転車などの分野をカバーしています。毎日何千万ものユーザーとドライバーがプラットフォームをやり取りして使用し、サービス間に複雑な依存関係を形成します。このような大規模な分散システムでは、トラブルシューティングとパフォーマンスの最適化は間違いなく複雑なタスクです。
毎回個々の専門家の経験に依存することは明らかに制御不能であり、結果は保証できません。したがって、私たちは、観察可能なアーキテクチャを継続的に進化させることによって、迅速なビジネスの反復と革新をサポートしたいと考えています。
1. 観察可能なアーキテクチャの進化はどのような問題を解決しますか?
1.1 Didi 監視システムの一般的なアーキテクチャ
Didi の観察可能なシステムの一般的なアーキテクチャは、次の図に示すように、主にいくつかの部分で構成されています。
ターゲット ホストまたはその他の関連インジケーターを収集します。伝送リンクを通過した後、一部のインジケーターはコンピューティング モジュールによって処理され、システムに書き戻される場合があります。このデータは保存されます。これらの保存されたデータに基づいて、クエリ機能は、ダッシュボード、データ ダッシュボード、アラームやイベントなどの上位層アプリケーションにデータ表示を提供できます。
各モジュールは異なるタスクを完了するか、異なる機能を実装する必要があることに注意してください。たとえば、クエリ モジュールは、データのルーティング、集約、および通常クエリ層で実装される DSL 機能の実装を担当する場合があります。
InfluxDB、RRDtool、Prometheus、Druid、ClickHouse など、データ ストレージを実装する方法は数多くあります。これらはすべて、監視可能なシステムのストレージ ソリューションとして使用できます。
送信モジュールはシステム内の接続の役割を果たしており、このモジュールで共通メッセージキューが使用されます。メッセージ キューについて話すとき、最初に思い浮かぶのは Kafka かもしれませんが、もちろん、NSQ など、よりニッチな選択肢もあります。
計算モジュールのタスクは、多数の指標を必要な形式に変換することであり、場合によっては計算のためにいくつかの次元を削除します。このモジュールでは、Flink や Spark などのツールが一般的に選択されます。
データ収集には、Telegraf、ノード エクスポーター、最近リリースされた Grafana Agent など、豊富なツールから選択できます。
1.2 観察可能なアーキテクチャ進化の 4 段階
1.2.1 フェーズ 1: 2017 年以前
ビジネス要件が変化すると、通常、ストレージ モジュールのパフォーマンスの問題が最初に明らかになります。2017 年以前、Didi はストレージの選択肢として主に InfluxDB を使用していました。ビジネス サービスの規模に応じて InfluxDB インスタンスを分割しましたが、この設計によりいくつかの問題が発生しました。
まず、スタンドアロン版のパフォーマンスにボトルネックがあります。例えば、クエリスパンが長い、クエリデータが大きいなど、クエリ量が多い状況では、メモリ不足（OOM）の問題が発生しやすくなります。これはコミュニティでも頻繁に議論される問題です。
さらに、採用しているシャーディング方法にも問題があります。サービスごとに分割しているため、たとえば、現在 50 のサービスがある場合、必要なインスタンスは 50 以下になる可能性があります。しかし、明日サービス数が 500 に増加すると、運用保守コストが大幅に増加します。特にマイクロサービスアーキテクチャが広く採用されている現状では、この種の運用保守コストは非常に高額になります。
1.2.2 フェーズ 2: 2017 ～ 2018 年
上記の問題を解決するために、私たちは 2017 年に RRDTool を導入しました。この期間中、RRDTool が InfluxDB に取って代わり、Didi Observable のメイン ストレージ ツールになりました。
RRDTool の設計では、一貫したハッシュ アルゴリズムを使用して、読み取りリンクと書き込みリンクで複数の RRDTool インスタンスのシャーディングを実行します。このハッシュ アルゴリズムのプロセスでは、最初にすべてのタグをレベル分けし、次にそれらを並べ替え、最後にそれらをハッシュして各インスタンスに配布します。
これに加えて「インデックス」というサービスも導入しました。このサービスの主なタスクは、製品のニーズを満たすことです。たとえば、サービス リストを提供する必要がある場合、ユーザーは自分のサービスを選択した後、サービスの下にどのようなインジケーターがあるか、各インジケーターの下にどのようなタグがあるかを知る必要があります。この要件には、効率的なインデックス作成サービスが完了する必要があります。
RRDTool に基づくアーキテクチャの改善により、2 つの大きな成果がもたらされました。まず、InfluxDB のホット スポットを解決します。当初はサービスに応じてインスタンスを分割していましたが、現在はこれらの曲線を各インスタンスに広げています。第 2 に、比較的自動化されたシャーディング手法を採用しているため、InfluxDB の運用とメンテナンスのコストも削減されます。
1.2.3 フェーズ 3: 2018 ～ 2020 年
2018 年以降、私たちは新たな課題に直面しました。RRDTool の設計原則は曲線ごとに 1 つのファイルであるため、データ規模が増加すると、IO の需要も増加します。IOPS が 30,000 を超えたため、この問題を解決するには、高い IO パフォーマンスを備えたマシンなどのデバイスを追加する必要があります。しかし、これによりコストが徐々に増加し、問題が悪化します。同時に、可観測性における読み取りと書き込みは直交しており、読み取りと書き込みの最適化で競合が発生します。通常、書き込みはすべての曲線の最新部分を書き込みますが、読み取りでは通常、複数の曲線または特定の曲線からデータを長時間読み取ります。 。
(縦方向は書き込み、横方向は読み取り)
では、この問題をどのように解決すればよいでしょうか? 分析の結果、クエリの 80% が過去 2 時間に集中していることが判明したため、ホットおよびコールド階層化戦略を設計しました。この戦略の中核は、圧縮されたデータをメモリに保存することです。圧縮は主に 2 つの側面を対象としています。1 つはタイムスタンプ、もう 1 つは値です。タイムスタンプ生成間の時間間隔は通常比較的固定されており、値の変化は比較的緩やかな傾向があるため、これが圧縮戦略の基礎となります。
この原則に基づいて、主に過去 2 時間のデータを提供し、フルメモリ設計を採用する「Cacheserver」と呼ばれるサービスを社内で作成しました。この設計により、ユーザー クエリの遅延が 10 秒から 1 秒未満に短縮され、各データ ポイントのストレージが元の 16 バイトから 1.64 バイトに削減されます。
上の図を見ると全体のデザインが理解できます。1 つ目はホットとコールドの階層化で、RRDTool と Cacheserver が共同してストレージ タスク全体を完了します。図の右半分を例にとると、元のタイムスタンプは 350、360、370、および 381 であり、これらのデータを保存するには 256 ビットが必要です。ただし、圧縮後は 88 ビットだけで十分です。これはタイムスタンプが 4 つの場合のみであり、タイムスタンプの数が増えると、圧縮効果はさらに大きくなります。
1.2.4 フェーズ 4: 2020 年～現在
ユーザーがアクセスするコンポーネントの数が増加し続けるにつれて、ユーザーのクエリのニーズはますます複雑になっています。この使用シナリオでは、RRDTool がダウンスケーリングを実行すると、元のデータを表示できなくなります。
このような状況に直面して、私たちはユーザーの現在および将来のニーズを満たすことができるシステムをどのように設計するかを考え始めました。私たちは問題解決戦略を変更し、特定の状況ごとに個別のソリューションを設計することはなくなりました。たとえば、過去に新しいクエリ フォームがあった場合は、新しい関数をコーディングして起動する必要がありました。現在、私たちは業界のエコシステムを直接利用することを選択しています。
当時、プロメテウスは非常に人気がありました。私たちは目標をエコシステムの導入から Prometheus エコシステムの導入に変更しました。Prometheus を選択した理由は、K8 の人気により、Prometheus が監視システムの事実上の標準になったためです。多くの大手業界プレーヤーや人気ベンダーが、コードとアーキテクチャを Prometheus に提供し続けています。
ただし、Prometheus エコシステムを導入することを選択した場合、RRDTool は Prometheus エコシステムと互換性がないため、使い続けることができなくなります。そのためには、新しいストレージ ソリューションを見つける必要があります。
問題 1: 新しいストレージ ソリューションを選択するにはどうすればよいですか?
新しいストレージ ソリューションの選択に直面したとき、私たちは主に Cortex、Thanos、VictoriaMetrics (略して VM) を検討しました。これらのソリューションは、Prometheus 自体の欠点の一部を補うように設計されています。Prometheus は最初からスタンドアロン ストレージとして位置付けられており、長期ストレージをサポートしておらず、高可用性も備えていないためです。その結果、Cortex と Thanos が当時の業界で主流のソリューションとなりました。
（業界におけるPrometheus関連ソリューションの調査）
これらのソリューションを比較すると、Cortex と Thanos の両方が Prometheus 本来の欠点を効果的に解決できることがわかりました。コストの観点から見ると、Thanos と Cortex はどちらもオブジェクト ストレージを使用しているため、コストは比較的低くなります。ただし、これら 2 つのソリューションは多数のサードパーティ サービスを使用しているため、企業にオブジェクト ストレージやクラウド サービスがない場合は、これらのコンポーネントのメンテナンスを可観測性チームが完了する必要がある場合があります。
(RRDTool ソリューションと VictoriaMetrics ソリューションの比較)
対照的に、VM は RRDTool と比較して Prometheus と完全な互換性があります。また、先ほど削減戦略について触れましたが、RRDTool のデータは 2 時間以上経過すると削減されますが、抽出が削減されると元のデータを表示できなくなります。VM 自体はマイニングを削減しないため、より多くの可能性がもたらされます。ストレージ コストの削減という点では、VM のパフォーマンスが優れており、当社の環境テストでは、ストレージ コストは RRDTool の約 1/20 にすぎません。データ レポート フォームに関しては、Prometheus はプル フォームですが、RRDTool はプッシュ フォームのみをサポートし、プライベート プロトコルのみをサポートします。ただし、VM はプルとプッシュの両方をサポートしており、一般的なデータ レポート プロトコルも適切にサポートしています。
難しさ 2: Prometheus エコシステムを導入するにはどうすればよいですか?
では、単純にストレージ ソリューションを VM に置き換えることはできるのでしょうか? 実際、答えはノーです。新しいエコシステムを導入する場合、まず既存の企業ソリューションを検討する必要があります。新しいエコシステムの導入は、既存の製品アーキテクチャを完全に破壊することを意味するものではなく、単に置き換えることはできません。
新しい生態系を導入するために、Didi はいくつかの変更を加えました。図に示すように、緑色の部分は Prometheus ネイティブ ソリューションを使用するために必要な作業です。監視対象のオブジェクトが「/metrics」などのインターフェイスをサポートしている限り、Prometheus はデータをプルできます。Didi の場合、私たちのオリジナルのアーキテクチャは、収集、送信、ストレージのプッシュ モデルに基づいていました。そこで、コレクション部分にPrometheusと互換性のあるAdapterを追加しました。もともと、Prometheus のプルをサポートする新しいサービスについては、独自の収集方法を使用してデータをプルすることもできます。
エコロジー導入の成果としては、Prometheus のデータ収集をサポートし、PromQL のチャート表示とアラームの 2 つの一般的なシナリオをサポートできます。さらに、TopK/BottomK やその他のチャート ディメンションの外れ値機能の追加など、チャート表示ディメンションにいくつかの新しい機能も追加しました。このようにして、サービスに多数のインスタンスがある場合、TopK/BottomK などの関数を使用して外れ値を見つけることができます。
コミュニティへの還元という点では、コミュニティ全体に貢献するために、VM 関係者と Prometheus コミュニティにいくつかの PR を提出しました。
2. 観測可能なシステム自体の安定性をどのように確保するか?
周知のとおり、監視可能なシステムの目的はビジネスの安定性を確保することです。では、観測可能なシステム自体の安定性をどのように確保するのでしょうか? まず、この観測可能なシステムを監視する方法を検討する必要があります。自分のシステムにいくつかのポリシーを設定することは可能ですか? それともダッシュボードを構築しますか? それとも他のアプローチを取るのでしょうか？これに関して、私たちの実験と考察のいくつかを共有したいと思います。
2.1 観測可能なシステムを観測するにはどうすればよいですか?
観測可能なシステム自体を観測させることはできません。たとえば、ストレージ システムに障害が発生し、データをクエリする方法がそのストレージ システム自体のストレージからクエリする場合、循環依存関係が形成されます。したがって、最初の原則は、観測可能なシステムはそれ自体を観測することはできないということです。2 番目の原則は、1 番目の原則に関連していますが、観測を行うには別のデータ収集および警報サービスのセットが必要であるということです。
私たちの実践では、主に 2 つの方法が使用されます。
最初の方法はトラフィックの監視に使用され、データの収集、送信、保存に適しています。このアプローチでは、主に Exporter、Prometheus、および Alertmanager を使用して自己監視を実行します。たとえば、ストレージの書き込みトラフィックが突然変化した場合、このシステムを使用して自己監視できます。
もう 1 つのアプローチは、監視機能です。アラームを例にとると、最も簡単な方法は、常にしきい値をトリガーするアラームを設定することですが、リアルタイム メッセージや SMS 通知は送信しない場合があります。アラーム イベントが中断されると、アラーム システム自体に問題があるか、アラーム システムが依存するストレージ クエリに問題があることが考えられます。この場合、検出器を設置し、エンドツーエンドの検査を行うことで問題を解決できます。
2.2 監視可能なアーキテクチャが常に安定していることを保証するにはどうすればよいですか?
これは 2 つの側面から検討できます。1 つはアーキテクチャの最適化によるもの、もう 1 つは一般的な保護方法の使用です。
2.2.1 アーキテクチャの最適化
ポイント1：卵をひとつのカゴに入れない
アーキテクチャを最適化するための単純な原則は、すべての卵を 1 つのかごに入れないことです。これは、次の設計を通じて実現できます。
(VictoriaMetrics ストレージ マルチクラスター設計)
Didi は主に配車事業を行っており、オンライン配車事業と非オンライン配車事業の観測データは異なるストレージ クラスタに保存されており、これが VM マルチクラスタ設計です。たとえば、配車サービス以外のビジネス インスタンスで問題が発生した場合、それが配車ビジネスに影響を及ぼさないことを望みますし、その逆も同様です。そこで、マルチクラスターストレージシステムを設計しました。
(トランスポートマルチクラスタ設計)
データ送信に関しては、設計思想は似ていますが、1 つの違いは、送信とストレージでは負荷特性が異なるため、異なるシャーディング戦略が使用されることです。例えば、ある企業の送信量は非常に多いのですが、ストレージへのクエリ量は非常に少ない場合、送信側でデータを分割し、ストレージにデータが書き込まれることだけを確認すれば済みます。側。同じストレージ クラスタを共有できます。
ポイント2：悪い卵はすぐに捨てる
「悪い卵は期限内に捨てる」という原則もあります。送信モジュールには、ストレージへの書き込みに加えて、ストリーミング アラームなどの他のダウンストリーム モジュールがあります。
したがって、特定のサブシステムが何らかの理由で速度を低下させ、それが伝送モジュール全体に影響を与える場合、それを見たくないのです。私たちは、サブシステムの速度が低下したり、問題が発生したりしたときに、適切なタイミングでシステムからサブシステムを削除できること、つまりサーキット ブレーカー戦略を期待しています。場合によっては、サーキット ブレークを自動的に実行し、このサブシステムの継続的な復元を試みることができます。正常に回復した場合は、システムを再接続します。
2.2.2 その他の一般的な保護方法
サーキットブレーカー、ダウングレード、多次元電流制限:
サーキットブレーカーやダウングレードに加えて、多次元電流制限などの他の保護手段も備えています。多次元電流制限では、柔軟な戦略を使用してリクエストを制限します。たとえば、数か月または数年にわたるデータ クエリなど、長期間にわたる継続的で高頻度のクエリには、多次元電流制限手法を適用します。
小切手管理が遅い:
もう 1 つの安全策は、多数の曲線のクエリを含む低速チェックの管理です。たとえば、クエリに何百万もの曲線が含まれる場合、それらを検出して管理するには、低速検索を実行する必要があります。一部のキー保護期間中はこれらの戦略を有効にし、異常が特定されたら、多次元の電流制限を使用し、その特性に基づいて制限または直接無効にします。
もっと生きる:
内部で観察可能な複数の活動については、それをユニット化するという方法が採用されています。たとえば、コンピュータ室 A とコンピュータ室 B の間の専用回線が遮断された場合、ユーザーが対応するコンピュータ室のデータに独立してアクセスできるようにする必要があります。
能力評価制度：
能力評価制度もございます。観察可能なアーキテクチャとビジネス トラフィックまたは注文量の増加は直接比例しない可能性があるため、独自のキャパシティ評価システムのセットが必要です。企業ごとにビジネスモデルが異なる場合があるため、保護手段としてこの制度を確立する必要があります。
計画と訓練:
また、これらの手法が効果的であることを確認するための計画を策定し、訓練を実施します。
3. Didi では可観測性がどのように実現されていますか?
3.1 戦略の選択
可観測性のテーマは、2021 年または 2022 年に非常にホットなトピックです。可観測性について話さないと、かなり後進的であると感じる人もいるかもしれません。まずは主要メーカーによる可観測性の定義を見てみましょう。
可観測性は、チームがシステムを効果的にデバッグするのに役立つツールまたは技術ソリューションです。可観測性は、事前に定義されていないプロパティとパターンの探索に基づいています。——出典 Google
可観測性とは、出力、ログ、パフォーマンス メトリクスを調べることによって、システムまたはアプリケーションの状態を監視、測定、理解する能力です。——出典 RedHat
可観測性とは、外部出力についての知識のみに基づいて、複雑なシステムの内部状態または条件をどの程度理解しているかということです。——出典 IBM
ここで Google、RedHat、IBM の可観測性の定義をそれぞれ引用しますが、これらには 2 つのコンセンサスがあります。1 つ目は、可観測性とはシステムの内部状態を外部から理解できる能力であり、これらの状態を知る必要はないということです。2 番目のコンセンサスは、ログ、インジケーター、イベントなどを含む可観測性の手段が多数あるということです。
では、可観測性を実現するにはどうすればよいでしょうか? 大手メーカーごとに独自の実装方法があります。Google はクラウド プラットフォーム GCP を推奨し、RedHat は OpenShift Observability を推奨し、IBM は独自製品 Instana Observability を推奨し、Grafana は LGTM (Loki、Tempo、Mimir) を推奨しています。
まとめると、可観測性を実現するには大まかに 3 つの方法があります。1 つ目は SaaS ベンダーのサービスを購入すること、2 つ目はできるだけ詳細な観測可能なデータを収集して保存すること、3 つ目は複数の観測データを関連付けることです。
3.2 スキームの比較
Didi の場合、最初の実装方法は適切ではないため、最初に除外します。
2つ目の実装方法ですが、「できるだけ詳細に」ということで、観測データを次元とカーディナリティの2つの次元に分割します。ディメンション性は、タイムスタンプ、バージョン、顧客 ID などのタグに似た概念です。カーディナリティは顧客 ID を例としており、10,01 ～ 19,999 のデータが含まれる場合があります。このソリューションの利点は、大量のデータを収集できることですが、欠点は、実装コストが高いこと、リソース消費量が大きいこと、データ使用率が低いことです。
3 番目の実装方法は、複数の観測データを関連付ける方法であり、一般的な観測データには、Metric、Trace、Log が含まれます。メトリック データは、エラーの数を伝えることができる高レベルの抽象概念ですが、特定のエラー情報を提供することはできません。トレース データは主に、リクエストがどのサービスを経験したかなど、サービス間の相関関係に使用されます。ログ データは開発者が優先する情報であり、人間が判読できる最も詳細なデータを提供します。ただし、複数の観測データを相関させるこの方法の欠点は、アーキテクチャの実装が比較的複雑であることです。
3.3 アーキテクチャ設計
Didi では、上記の 2 つの方法を借用し、データを低カーディナリティと高カーディナリティの 2 つのカテゴリに分類しました。低いカーディナリティはメトリック データを指し、高いカーディナリティはログ データを指します。これら 2 種類のデータを異なるデータベースに保存し、それらの相関関係を確立します。
たとえば、一定期間内に 2 つのエラー ログを収集した場合、エラー番号「2」が時系列データベースに報告されます。同時に、エラー ログの 1 つをサンプリングし、Exemplar DB に保存します。次に、時系列データベースと Exemplar DB をタグで関連付けます。
3.4 実践結果
Didi の可観測性実践の成果は非常に重要です。可観測性を確立する前に、トラブルシューティング時にマシンにログインしてログを取得する必要があります。幸運にも問題のあるマシンを見つけることができた場合は、幸運だったと考えてください。ただし、問題がこのマシンにあるわけではない場合、またはこのサービスに問題がある場合でも、上記の操作を繰り返す必要があります。また、このような操作を行っても、問題が発見されるかどうかは不明です。
ただし、可観測性を確立した後は、アラーム メッセージを受信したときに、アラームに関連付けられた元のログ テキストを直接表示できます。ログの原文を確認し、大きな問題がないと思われる場合は、一時的に放置しても問題ありません。緊急の場合は緊急対応を開始いたします。
また、チャートを見ているときに指標が急上昇していることに気づき、その原因を知りたい場合には、ドリルダウン機能を利用することができます。この機能を使用すると、ログの元のテキストを表示できるだけでなく、ログにトレース情報が含まれている場合はそのトレース情報を抽出することもできます。トレース情報は、さらに処理するために特殊なトレース製品にドリルダウンできます。
4. まとめと展望 Didi の可観測性アーキテクチャの開発は、実際にはさまざまなニーズ、シナリオ、時代背景に基づいて行われ、最も適切なソリューションが選択されます。
私たちは業界の成熟したエコシステムと接続し、これらのエコシステムをシステムに統合しました。これにより、多くの作業を完了し、作業効率を向上させることができました。同時に、観測プラットフォームを構築する過程で、観測システム自体の安定性を確保するためのいくつかの戦略も採用しました。
可観測性を実装するための統一された方法はなく、企業ごとに独自の特徴があることに注意してください。そのため、各企業は自社の特性に合わせて特化したソリューションをカスタマイズし、実態に応じて最適なソリューションを選択、調整し続ける必要があります。（全文終わり）
Q&A
1. Didi には、監視可能なアーキテクチャを維持するための専任の技術チームがいますか? Prometheus の水平スケーラビリティ機能は比較的限られています。InfluxDB の具体的な問題は何ですか?
2. アーキテクチャの可観測性を測定するにはどうすればよいですか? 助言がありますか？
3. メトリクスの適時性は第 2 レベルである必要がありますか?
4. インターフェイスが時折タイムアウトになります。呼び出しチェーンでは、タイムアウト インターフェイスの名前のみが表示されますが、内部メソッドは表示されません。根本原因が特定できず、再現が困難です。どうすればよいですか?
上記の質問に対する回答については、[全文を読む]をクリックして回答の完全版をご覧ください。
声明: この記事はもともとパブリック アカウント「TakinTalks Stability Community」とコミュニティの専門家によって書かれたものです。転載する必要がある場合は、バックグラウンドで「転載」と返信して許可を取得してください。
IntelliJ IDEA 2023.3 と JetBrains Family Bucket の年次メジャー バージョン アップデート 新しいコンセプト「防御型プログラミング」: 安定した仕事に就く GitHub.com では 1,200 を超える MySQL ホストが稼働していますが、8.0 にシームレスにアップグレードするにはどうすればよいですか? Stephen Chow の Web3 チームは来月、独立したアプリをリリースする予定ですが、 Firefox は廃止されるのでしょうか? Visual Studio Code 1.85 リリース、フローティング ウィンドウ Yu Chengdong: ファーウェイは来年破壊的な製品を発売し、業界の歴史を書き換えるだろう 米国 CISA はメモリ セキュリティの脆弱性を排除するために C/C++ の廃止を勧告 TIOBE 12 月: C# がプログラミングになると予想30年前に 雷軍が書いた論文「コンピュータウイルス判定エキスパートシステムの原理と設計」この記事は、複数の記事を公開するブログOpenWriteによって公開されています。