要約: TiDB は、優れたオープンソースの分散データベース ソフトウェアとして、ユーザーからの注目とアプリケーションがますます増えていますが、運用と保守の保証の過程で、運用と保守の島、境界と位置付けの難しさ、および問題にも直面しています。この記事では、TiDB ユーザーが DeepFlow に基づいてフルスタックの可観測性を構築するためのベスト プラクティスを要約します。これには、DeepFlow の高性能、ゼロ侵入可観測性テクノロジを使用してフルリンク追跡の盲点を排除する方法が含まれます。 TiDB 側、および DeepFlow の高性能ゼロ侵入可観測性テクノロジーを使用して TiDB 側の死角を排除する方法について説明します。
01: 分散データベースの運用と保守の課題
分散データベースの DBA は、日常の運用とメンテナンスにおいて、通常、次の 3 つの課題に直面します。
- 観測データのリアルタイム パフォーマンス: 従来の計測方法では明らかなパフォーマンスの低下が生じるため、DBA はビジネス例外が発生した後にのみ TiDB の組み込み分散トレース機能を有効にし、障害処理は事後分析と反復によってのみ実行できます。 、およびパッシブポジショニング。
- 観測データの網羅性：従来のデータベースの運用・保守は主にデータベース自身のデータに依存しており、クライアントアプリケーションからのリアルタイムデータ、システムリソース、データベースファイルの読み書き、サーバーネットワークのパフォーマンスなどの要素が不足しており、周囲の環境も厳しい状況にあります。診断の盲点。
- 観察と診断の継続性: 従来の監視ツールではデータが互いに分離されており、分析プロセスでは複数の監視ツール間の切り替えが必要になることがよくあります。
上記の問題により、データベースの運用と保守と他の運用と保守が分断され、運用と保守の孤立が形成され、ビジネス運用リスクの検出が難しく、障害の境界設定が難しく、復旧サイクルが長く、コミュニケーションとコラボレーションが多数発生します。 、運用と保守の競合が多数あります。
DeepFlow は、ゼロ侵入、高パフォーマンスの観測データ収集、オープンな観測データ アクセス、統合された観測データ相関分析などの複数のコア機能を通じて、フルスタック、フルリンク、実稼働対応の観測機能を TiDB に提供し、DBA による完全な構築を支援します。 - リンク監視、迅速な障害特定、根本原因分析、および分散データベースの運用と保守の効率を効果的に向上させ、上記の運用と保守の問題点を解決するその他の機能。
02: TiDB 可観測性導入ソリューション
TiDB可観測性実践計画では、ビジネスクラスタとTiDB分散データベースクラスタのノードにDeepFlow Agentを自動導入し、多次元の観測データを収集し、構造化された観測データをネットワーク経由で送信し、均一に処理します。 、統合された関連データ、および統合された分析データ）は、運用および保守シナリオに厳密に従った機能設計を通じて、DeepFlow サーバーに一元的に保存され、これらのデータは、マクロからミクロまでの柔軟な多次元のフルスタックの観察および分析機能を提供します。 。
DeepFlow Agent は、次のような豊富な観察データを収集します。
- eBPF ゼロ侵入データ: コール チェーン トラッキング、SQL パフォーマンス インジケーター、SQL コール ログ、ネットワーク パフォーマンス インジケーター、ネットワーク フロー ログ、ファイル読み取りおよび書き込みイベント、CPU パフォーマンスおよびその他の観察データ
- OpenTelemetry インストルメンテーション データ: TiDB の各コンポーネント内のコール チェーン トラッキング データ
- Prometheus Exporter データ: K8s システム指標、TiDB パフォーマンス指標
03: コールチェーン追跡
DeepFlow の TiDB のフルスタック観察の実践では、従来の APM テクノロジーと比較して、フロントエンド アプリケーション、中間ネットワーク、TiDB-Proxy、TiDB を含むフルリンク コール チェーン追跡機能を実現しました。 DeepFlow Tracking によって実装された には、次のような有利な機能があります。
- 死角なし: TiDB、ゲートウェイミドルウェア、中間ネットワークにおける追跡の死角を排除します。
- 高性能: eBPF テクノロジーによって実現される高性能のゼロ侵入追跡により、本番環境に対応したTiDB の非サンプリング追跡および観察機能が構築されます。
- ホットリロード: eBPF テクノロジーのコードホットスワップ機能により、アプリケーションや TiDB クラスターでいつでもオンライン追跡機能を利用でき、小さなパフォーマンスのジッターでも詳細なレベルで継続的に観察できるため、システムのリスクを迅速に発見して排除できます。
- クロステクノロジースタック：フルスタック追跡機能により、 DBA、データベース開発、システム運用保守、アプリケーション運用保守などの複数の運用保守技術スタックの統合追跡と統合連携を実現し、障害境界と障害境界を迅速に特定し、技術コラボレーションの効率を向上させます。
1) 死角のないコールチェーン追跡
シンプルな概略図を通じてこの質問に答えることができます。従来の計測ソリューションと比較して、DeepFlow eBPF ゼロ侵入コレクションが死角なしでコール チェーン トラッキングを真に実現できるのはなぜでしょうか?
アプリケーションの計測
従来の APM テクノロジは、アプリケーション コード インストルメンテーションを通じてアプリケーション コール チェーンを追跡します。監視範囲は、ビジネス アクセスの応答が遅い場合、TiDB 側で監視の盲点を形成します。 TiDB が問題の原因であるかどうかをすぐに判断することは不可能です。
アプリケーション インストルメンテーション + TiDB インストルメンテーション
アプリケーション コール チェーンの追跡機能を TiDB に拡張するために、コード修復のために TiDB コミュニティにPRを提出し、TiDB 側に追跡機能を実装しました。しかし、その後、TiDB のインストルメンテーションにはまだ 3 つの問題があることがわかりました。
- TiDB オペレーティング環境のネットワークは追跡の盲点にあり、SQL パフォーマンスに対するネットワークの影響を診断できません。
- TiDB の前にある TiDB-Proxy は追跡の盲点にあり、SQL パフォーマンスに対する TiDB-Proxy の影響を診断できません。
- TiDB インストルメンテーション後の応答パフォーマンスは大幅に低下し (具体的なデータについては以下を参照)、本番システムで継続的に使用することはできません。
DeepFlow eBPF ゼロ侵入収集
DeepFlow の eBPF テクノロジーによって構築されたゼロ侵入コール チェーン追跡機能は、TiDB の追跡の盲点を排除し、あらゆるアプリケーション コール プロセスの次の場所に対する完全な追跡機能を備えています。1) フロントエンド アプリケーション、2) TiDB-Proxy。 4) K8s ネットワーク。
この時点で、DeepFlow コール チェーン トレース フレーム グラフで特定の遅い応答を追跡し、応答遅延に対する各位置の寄与率を直感的に観察できるため、特定の遅い応答の発生源の場所を迅速に特定できます。
たとえば、次の図では、DeepFlow 呼び出しチェーン トレースのフレーム グラフの一部で、COM_QUERY COMMIT特定のビジネス プロセスの MySQL 呼び出しによって tidb-proxy プロセスの処理に 480 ミリ秒の遅延が生じていることが明確にわかります。
2) 高性能コールチェーン追跡
TiDB の可観測性を実際の運用システムに導入する際の最も重要な問題は、観測データ収集のパフォーマンスです。
アプリケーション内インストルメンテーションや Java エージェントのバイトコード拡張などのテクノロジを使用してコール チェーン収集を実装すると、定義が難しい追加のリソース消費が発生し、重大なビジネス パフォーマンスの損失が発生する可能性があることがわかりました。技術的なソリューションは、高い同時実行性、高いパフォーマンス、および高い信頼性の要件を備えたシステムには実装できません。多くの企業は、このような追跡機能をテスト システムまたは重要ではない運用システムでのみ有効にすることができますが、より重要な運用システムでは、ビジネスへの悪影響を軽減するために、特に財務部門のコア運用システムでのみ高比率のサンプリングと追跡を使用できます。業界は業績に影響を与えないように追跡機能を完全に放棄することになりますが、これは運用サポート機能の弱体化と制御不能な運用および保守のリスクにつながります。
DeepFlow は、eBPF テクノロジーを使用して、これらの問題を非常にうまく解決するゼロ侵入 (ゼロコード) オブザーバビリティを実現し、通常、ビジネス遅延 (応答時間) の影響はミリ秒未満のレベルにとどまり、エージェントのリソース消費の制限は予測可能であり、設定可能です。ジャストインタイム (JIT) テクノロジーのおかげで、DeepFlow Agent の eBPF コードの実行効率はカーネルのネイティブ コードのパフォーマンスに匹敵し、収集プロセス中のアプリケーションの処理プロセスに影響を与えないため、アプリケーションはゼロ侵入の処理プロセスを呼び出します。
DeepFlow の TiDB のフルスタック観察の実践では、Jaeger インストルメンテーションを使用した場合と、可観測性の実践のために DeepFlow の eBPF ゼロ侵入テクノロジを使用した場合の、TiDB クラスターのビジネス パフォーマンスの異なるパフォーマンスをテストおよび検証しました。
Jaeger インストルメンテーション収集中の TiDB SQL 応答遅延: TiDB の OpenTracing機能をオンにして、tiproxy にアクセスするアプリケーション インスタンスの場所 (svc-order) の応答パフォーマンスを観察したところ、平均 SQL 応答遅延は300 ～ 400 ミリ秒で安定していることがわかります。場合によっては、平均最大遅延が1.5 秒を超えます。
DeepFlow eBPF 収集中の TiDB SQL 応答遅延: DeepFlow エージェントを使用して、TiDB 分散クラスター上の非サンプリング観察データを収集し、tiproxy にアクセスする際のアプリケーション インスタンスの場所 (svc-order) の応答パフォーマンスを観察します。平均遅延は3 ～ 5msに減少し、最大遅延は38msを超えません。
上記のパフォーマンス比較データから、eBPF テクノロジーを通じて DeepFlow によって達成されるゼロ侵入オブザーバビリティにより、インストルメンテーション ソリューションによって引き起こされるビジネス パフォーマンスの問題が解決され、本番環境に対応した、手間のかからない分散型 TiDB ソリューションを構築できることがわかりました。コア IT 生産システムのデータベースのサンプリングおよび追跡観察機能。
3) いつでもホットロードによるコールチェーン追跡
アプリケーション内インストルメンテーションや Java エージェントのバイトコード拡張などの技術的手段によってビジネス パフォーマンスが低下するため、重要なコア実稼働システムでは基本的に日常の運用ではトレース機能がオフになります。ただし、障害や例外が発生した場合には、きめ細かいトレースが必要になります。 、しかし、インストルメンテーションと Java エージェントの起動プロセスでは、コア実稼働システムのアプリケーション インスタンスと TiDB コンポーネント インスタンスを再起動する必要があることがわかりました。この時点で、追跡機能を有効にするかどうかは難しくて難しい決断となり、最終的にはこれにつながります。運用保守の現状：
- 軽微な障害は気付かれず、システムは隠れた危険を抱えた状態で稼働します。
- 中間障害には多額の投資が行われ、テスト環境は繰り返しテストされ、根本原因は運によって特定されます。
- 重大な障害を解消するためにあらゆる努力が払われ、チーム全体がコストに関係なく、ビジネスが復旧するまで年中無休で働きました。
ヘインの法則によれば、重大な事故の背後には 29 の軽微な事故と 300 の潜在的な危険が潜んでいます。これと同じパターンが IT システムの運用と保守にも存在します。インスツルメンテーションと Java エージェントの起動には再起動アクションが必要であるため、実稼働環境における多数の潜在的な隠れた危険や軽微な障害の診断と特定は困難であり、中間障害の再配置には多大な労力がかかります。重大な障害が発生し続けます。
DeepFlow のゼロ侵入可観測性は、この問題を完全に解決します。アプリケーション システムまたは TiDB のコール チェーン トラッキング機能を有効にする必要がある場合は、いつでもワンクリックで DeepFlow Agent をデプロイして追跡データ収集を開始できます。エージェントのデプロイ時にアプリケーション POD や TiDB に侵入する必要はありません。コンポーネント POD を使用するだけでなく、アプリケーション、TiDB、またはオペレーティング システムを再起動する必要もありません。エージェントは、追跡データ収集コードをオペレーティング システムのカーネルに即座にホット ロードし、eBPF テクノロジーのみを介して各場所で追跡データ収集を開始できます。 Linux オペレーティング システム。負荷が非常に高いビジネス システムであっても、追跡機能をアンインストールしたい場合は、エージェントの eBPF 収集スイッチをオンラインでオフにするか、エージェントをアンインストールすることで、追跡データ収集コードをオペレーティング システム カーネルから即座にアンインストールできます。このプロセス全体の間、上位層のアプリケーションと TiDB コンポーネント プログラムは認識しません。
DeepFlow Agent のコール チェーン追跡機能は、オペレーティング システム カーネルでいつでもホットロードできるため、アプリケーションへの障害を心配することなく、アプリケーション システムおよび TiDB クラスターでいつでもオンラインおよびオフラインで機能を追跡および観察できます。いつでも軽度の障害と中間の障害を検出し、システムの危険性を迅速に発見して排除し、重大な障害を回避します。
4) コール チェーン トラッキングによるテクノロジー スタック間の統合コラボレーション
従来のインスツルメンテーション テクノロジの APM 追跡は、アプリケーション開発者や TiDB 開発者に適しています。コール チェーンは、開発経験がなければ理解するのが難しい、プロセス内の関数呼び出し関係をより詳細に反映します。操作は必須です。次元の役割は実際にはほとんど役に立ちません。 DeepFlow 可観測性プラットフォームは、アプリケーションからオペレーティング システムおよび基盤となるネットワークに至るあらゆるアプリケーション呼び出しのフルスタック トレース機能を実現するため、TiDB の運用と保守、TiDB 開発、アプリケーション開発、K8s の運用と保守、およびミドルウェアの運用を構築できます。各テクノロジー スタックのフル スタックの運用およびメンテナンスのコラボレーション機能により、アプリケーション呼び出しのプロセス全体における各処理リンクのパフォーマンスを明確に把握し、障害の境界を迅速に判断できます。
DeepFlow 観測可能プラットフォームにおける上の図を例に挙げます。
- ビジネス アプリケーションの開発と運用と保守: ビジネス アプリケーションのマイクロサービスの呼び出し遅延を通じて、ビジネス アプリケーションに隠れた危険性や障害を迅速に診断して発見します。
- K8s の運用とメンテナンス: 各マイクロサービス インスタンス間のネットワーク カードの呼び出し遅延を通じて、K8s プラットフォームの隠れた危険性や障害を迅速に診断します。
- ミドルウェアの運用と保守: TiDB-Proxy ロケーションの呼び出し遅延を通じて、ミドルウェアの隠れた危険性や障害を迅速に診断して発見します。
- DBA : eBPF によって収集された TiDB 呼び出し遅延を使用して、TiDB 側の隠れた危険や障害を迅速に診断します。
- データベース開発: TiDB の OpenTelemetry インストルメンテーション データをオンデマンドで有効にすると、データベース開発者は、TiDB の主要な内部機能の隠れた危険性や障害を迅速に診断できます。
04：全方位観察
コール チェーンの追跡に加えて、TiDB の日常的な運用とメンテナンス中に、ビジネス パノラマ、ネットワーク パフォーマンス、システム リソース パフォーマンス、オペレーティング システム ファイルの読み取りおよび書き込みパフォーマンス、およびアプリケーション機能のパフォーマンスのすべての側面を包括的に観察し、分析する必要があります。根本的な原因は、可観測性の実践では、複数の種類の観測データのサイロを解放し、観測データ間の接続を確立し、フルスタックの運用および保守担当者が効率的に作業できるように、スムーズな観測操作フローを設計する必要があることです。観察の運用と保守プロセスをスムーズに実行し、全方位のデータを観察し、データから結論を迅速かつ簡単に見つけます。
TiDB 可観測性の実践では、DeepFlow プラットフォームで複数種類のデータの統合収集と分析を実装しており、スムーズな運用フローを通じて、さまざまな種類のデータに効率的にアクセスし、次のようなあらゆる種類の観察機能を実現できます。
- ビジネス全景観察
- ネットワークパフォーマンスの観察
- SQL ステートメントのトレースバック
- システムリソースのパフォーマンスの監視
- ファイルの読み取りおよび書き込みパフォーマンスの観察
- 機能性能観測（CPUプロファイリング）
１）ビジネス全景視察
DeepFlow は、クラウド ネイティブ API インターフェイスとのリアルタイム ドッキングを通じてリソース タグとビジネス タグを動的に取得し、リアルタイムで収集されたアプリケーションのデータ タグを呼び出します。これにより、自動化され、ビジネスに合わせて動的に更新されるビジネス パノラマを構築する機能を実現します。 。
DeepFlow に基づく TiDB 可観測性の実践では、クラウド ネイティブ アプリケーション クラスターから TiDB 分散データベース クラスターまでのエンドツーエンドのビジネス パノラマを構築しました (以下を参照)。
クラウドネイティブアプリケーションクラスタとTiDBデータベースクラスタのビジネスパノラマトポロジを構築することで、ITビジネスシステムの全体像をマクロな視点で観察することができ、ビジネスパノラマの中で局所的な業績の異常が見つかった場合に、ミクロな視点から段階的に探索することができます。未知の未知をすぐに見つけます。
2) ネットワークパフォーマンスの観察
TiDB データベース クラスターの障害診断プロセスでは、ネットワーク パケット損失とネットワーク遅延が問題として疑われることがよくあります。DeepFlow は、ネットワーク パフォーマンスの観察を通じて、特定の分散データベース ビジネスの障害がネットワーク障害によって引き起こされているかどうかを迅速に判断できます。
ネットワーク パフォーマンスの観察では、以下の 6 つの指標を通じて、TiDB クラスターへの外部アクセスおよび TiDB クラスターの内部コンポーネントの相互アクセスのネットワーク インタラクション パフォーマンスを観察し、さまざまな種類のネットワーク伝送の問題を診断および特定できます。
- バイト (スループット レート) - ネットワークのスループット圧力を観察します。
- TCP 再送信率 - ネットワーク パケット損失を観察する
- TCP ゼロ ウィンドウ率 - TCP 輻輳の観察
- 接続確立と失敗の比率 - TCP 接続確立の異常を観察する
- 平均 TCP 接続確立遅延 - 観測されたネットワーク RTT
- TCP/ICMP システムの平均遅延 - オペレーティング システムの応答速度を観察します。
例 1: TiDB ポータルにアクセスするクライアントのネットワーク インタラクション パフォーマンスを素早く観察する
例 2: TiDB 内部コンポーネント間のネットワーク相互作用パフォーマンスを迅速に観察する
3) SQL ステートメントのトレースバック
不合理な SQL ステートメントは大量の CPU およびメモリ リソースを占有し、TiDB の応答遅延を増加させ、TiDB の全体的なパフォーマンスを低下させます。そのため、非効率な SQL ステートメントを迅速にバックトラックすることは、データベースの運用とメンテナンスの重要な部分です。インデックスを使用しないクエリ、テーブル全体のスキャン、過度に複雑なクエリ、不適切な関数やデータ型の使用はすべて、バックトラックして SQL ステートメントに焦点を当てる必要があるタイプの「悪い SQL」です。
TiDB 可観測性の実践では、DeepFlow はゼロ侵入バイパス収集機能を使用して、SQL ステートメント、応答遅延、発生時間、ソース ノードなどを含む各 SQL ステートメントの詳細を完全に記録します。これらの情報は、通話ログの検索および検索中に取得できます。不正なSQLの発生頻度をリアルタイムに追跡し、SQLの発生源を特定します。
4) システムリソースパフォーマンスの観察
オペレーティング システムの過剰な CPU およびメモリ使用率、またはネットワーク インターフェイスのスループットの輻輳が同じ期間に発生すると、SQL の遅延が発生する可能性があります。そのため、SQL の遅延の問題の根本原因をより迅速かつ正確に見つけるには、TiDB を迅速に分析します。インスタンスの CPU、メモリ、およびネットワーク インターフェイスのインジケーターは、分散データベースの監視機能、運用および保守機能、トラブルシューティングの効率を向上させるための重要な部分です。
TiDB 可観測性の実践では、Grafana Agent を通じてシステム インジケーターを収集し、データを DeepFlow 可観測性プラットフォームに均一にインポートして、TiDB コンポーネントの POD インジケーター データを観察できるようにします。コール チェーン トレースで遅い SQL のソース POD を検出すると、ワンクリックで POD の CPU 使用率変化曲線、メモリ使用量変化曲線、ネットワーク スループット変化曲線を表示でき、インジケーター値を通じて遅い SQL イベントを簡単に判断できます。問題が発生している期間中のシステム CPU、メモリ、ネットワーク インターフェイス リソースのパフォーマンスとの相関関係。
5) ファイルの読み取りおよび書き込みパフォーマンスの観察
ファイルの読み取りおよび書き込みのパフォーマンスは、TiDB の SQL 応答パフォーマンスに大きな影響を与えます。高性能のストレージ リソースを使用すると、ファイルの読み取りおよび書き込みが遅くなる可能性を可能な限り回避できますが、依然として 2 つの質問に頻繁に答える必要があります。 TiDB の運用と保守:
- SQL が散発的に遅い場合、ファイルの読み取りと書き込みが散発的に遅いことが問題の根本原因であるかどうかを判断するにはどうすればよいでしょうか?
- システム内で未知の大きなファイルの読み書きや頻繁なファイルの読み書きが発生した場合、ファイルの読み書き元のプロセスをどのように見つければよいでしょうか?
DeepFlow は、Linux カーネルの eBPF 機能を通じて、オペレーティング システム ファイルの読み取りおよび書き込みイベントの完全な収集と監視を実現し、完全収集や部分収集などの複数の収集モードをサポートします。
アプリケーションの応答が遅い場合、DeepFlow は、問題が発生している期間中のクライアントとサーバー上のすべてのファイル読み取りおよび書き込みイベントをワンクリックで取得し、リスト内のファイル操作イベントとソース プロセスを迅速にロックします。遅い SQL 応答が発生した場合、DBA は関連する遅い IO イベントがあるかどうかを数秒以内に判断できます。不明なファイルの読み取りおよび書き込み動作がある場合、システムの運用とメンテナンスは数秒以内にファイル IO ソースをロックできます。
6) 機能性能観測(CPUプロファイリング)
遅い SQL のトラブルシューティング プロセス中に、CPU がビジネス パフォーマンスのボトルネックになっていることが判明した場合、次に行うべきことは、TiDB コンポーネント POD の CPU スケジューリング状況を分析し、TiDB コンポーネント内のホットな機能を見つけることです。プログラムを選択し、最適化のエントリ ポイントであるプログラムを見つけます。 DeepFlow は、Linux カーネルの eBPF テクノロジを通じてアプリケーション プロセスの CPU パフォーマンス データ収集および監視機能を実装し、TiDB コンポーネント アプリケーション プロセスの CPU パフォーマンスを分析することで、開発者はカーネル関数、ライブラリ関数、およびアプリケーション関数を簡単にロックできます。各 TiDB コンポーネント プログラムの CPU ホット スポット。
TiDB 可観測性の実践では、DeepFlow を使用して TiDB、PD、および TiKV コンポーネントの CPU パフォーマンスを分析しました。その中で、次の TiDB プロセスの CPU パフォーマンス分析フレーム グラフでは、Jaeger インストルメンテーションが TiDB プロセスに重大な CPU リソース オーバーヘッドをもたらしていることがはっきりと観察できます。
05: 値の概要
TiDB 分散データベースの安定した運用には、優れた運用および保守サポート機能が必須です。この可観測性の実践において、DeepFlow は、最先端の高性能 eBPF ゼロ侵入データ収集テクノロジー、ゼロインストルメンテーション コール チェーン トラッキング テクノロジー、およびマルチソース サーバーを使用します。データの統合観察テクノロジーは、TiDB のフルスタック、フルリンク、いつでもホットロード、および実稼働実装のための可観測性ソリューションを構築します。これにより、TiDB の総合的な運用および保守機能が大幅に向上し、TiDB データベースの安定した運用を効率的に支援します。ユーザーがより信頼性が高く安定したデータベース サービスを作成するのに役立ちます。
06: DeepFlowとは
DeepFlow は、複雑なクラウド インフラストラクチャとクラウド ネイティブ アプリケーションに深い可観測性を提供することを目的として、Yunshan Network によって開発された可観測性製品です。 DeepFlowは、eBPFをベースに、アプリケーション性能指標、分散トレーシング、継続的性能解析などの観測信号のゼロイントルージョン（Zero Code）収集を実現し、スマートラベル（SmartEncoding）技術と組み合わせることで、フルスタック相関とすべての観測信号の効率的なアクセス。 DeepFlow を使用すると、クラウド ネイティブ アプリケーションは自動的に深い可観測性を実現できるため、開発者に対する継続的なインスツルメンテーションの大きな負担が軽減され、DevOps/SRE チームにコードからインフラストラクチャに至るまでの監視および診断機能が提供されます。
GitHub アドレス: https://github.com/deepflowio/deepflow
DeepFlow デモにアクセスして、ゼロ インストルメンテーション、完全なカバレッジ、および完全に関連する可観測性を体験してください。
私はオープンソースの産業用ソフトウェアを諦めることにしました - OGG 1.0 がリリースされ、Huawei がすべてのソース コードを提供しました。Google Python Foundation チームは「コード クソ マウンテン」によって解雇されました 。 Fedora Linux 40が正式リリース。有名ゲーム会社がリリース 新規定：従業員の結婚祝儀は10万元を超えてはならない。チャイナユニコム、世界初のオープンソースモデルLlama3 8B中国語版をリリース。Pinduoduoに賠償判決国内のクラウド入力方式に500万元の罰金- クラウドデータアップロードのセキュリティ問題がないのはファーウェイだけ