可観測性プラットフォームを実装するための技術的なポイントは何ですか? 【書籍寄贈イベント｜『可観測性工学』第9号】

可観測性の概念が人々の心に深く根付いているため、可観測性プラットフォームは実装段階に入り始めており、その進歩は疑いの余地がありませんが、統合されたものとして企業にどのように根付かせるかというもう一つの課題があります。統合プラットフォームは？

可観測性は単なる流行語ではなく、キーワードの誇大宣伝でもありません。私たちが知っている運用および保守管理の進化を再検討し、運用および保守管理におけるプロセスと人材に関する煩雑な手続きを脇に置いたほうがよいでしょう。インフラストラクチャとアプリケーション アーキテクチャの変化、およびこれらの無限の技術ツールの側面だけに焦点を当てましょう。

グローバルセマフォに対応

テレメトリ手法の観点から見ると、どのようなタイプの信号にも、それぞれ独自の目的と理由があります。それらの 1 つを可観測性の同義語として恣意的に選択するのは、比較的極端な考えです。本番環境のデバッグに向かう途中では、私たちにとってそれは困難です。単一の信号に依存する方法。さまざまなアプリケーション システムの特性とサービス タイプに基づいて合理的な SLI の組み合わせを選択し、適切なセマフォを使用して対象のアプリケーション システムをカバーする必要があり、その目標は、アプリケーション システム自体の「可観測性属性」を作成することです。このように、信号タイプを賢明に選択、追加、変更し、ニーズに応じて治療を調整できる必要があります。ここで、監視データ ソースが多ければ多いほど良いというわけではなく、盲目的に包括的にカバーすることは、半分の労力で 2 倍の結果を達成するアプローチでもあり、高次元でカーディナリティの高い運用および保守のビッグ データを扱うシナリオでは、ストレージ コストが高騰し、無効なノイズ データが依然として存在する状況が容易に発生し、貴重な情報ポイントが大幅に希薄化する可能性があります。

いわゆるグローバル セマフォとは何ですか?

ログ: システムとアプリケーションのアクティビティ、イベント、エラーをテキストで記録し、詳細なコンテキストを提供します。

メトリクス: システムステータスの監視に役立つ、CPU 使用率やリクエストレートなどの定量的なパフォーマンス測定。

分散トレース トレース: 分散システム内のリクエストのパスとパフォーマンスのボトルネックを追跡します。

ストリーミング データ: リアルタイムの監視と分析のために、ユーザーの行動などのリアルタイムで生成されるデータ。

ユーザー エクスペリエンス データ RUM: アプリケーションでのユーザーの対話、操作、反応を記録し、エクスペリエンスの品質を評価します。

eBPF: Berkeley Packet Filter を拡張して、分析と監視のためにカーネルレベルのデータを収集します。

ネットワーク パフォーマンス管理 NPM: ネットワーク帯域幅、遅延、接続ステータスを監視し、ネットワーク パフォーマンスを最適化します。

プロファイリング: アプリケーションの最適化に役立つように、実行中のコードのパフォーマンス特性を分析します。

クラウド サービス クラウド: クラウド プロバイダーから取得したデータを監視して、リソースの使用状況とパフォーマンスを追跡します。

ダイヤル テスト データ 稼働時間/合成: システムの外部テストを定期的に実施して、さまざまな場所や条件におけるシステムの可用性とパフォーマンスを監視します。

将来の新技術: 未知の種類のデータ。

「可観測性管理プラットフォーム」は、最初の設計目標として包括的かつ包括的なセマフォを使用して設計される必要があります。これは、観測データの収集、アップロード、保存、表示、相関分析の全プロセスにおいて、タイプ間のデータ相関をより合理的かつ効果的に実行できるように、あらゆる種類のデータが正しく処理される必要があることを意味します。 -down, プロセス中に、さまざまなタイムライン間を自由にジャンプして探索できます。
もちろん、既知の「未知のもの」を監視することは基本的な管理要件であり、これを達成するにはある種のセマフォを使用できる必要があります。可観測性とは、「未知の」状態間の変更の管理について議論することです。これには、マルチレベル、高依存性、マルチクラウド環境、および分散システムの高度な「複雑さ」を処理できる「可観測性プラットフォーム」が必要です。多くの場合、セマフォへのオンデマンド アクセスは必要条件にすぎません。
市場には、「可観測性」管理プラットフォームと称する運用保守管理プラットフォームがすでに数多く存在します。しかし、それらのほとんどは特定の監視タイプから始まり、徐々に他の信号タイプをカバーするように拡張されます。一般に、3 種類以上の信号タイプをカバーできるプラットフォームのみが優れた実用的な効果をもたらす可能性が高く、すでに 3 ～ 5 年前の「可観測性」製品の場合、短期間で素晴らしい結果を達成する可能性は低いです。裏を返せば、製品を最初から再構築することはできません。

統合された収集およびアップロード ツール

物理マシンが普及している時代では、ホスト (仮想マシンまたは物理マシン) が複数の役割を果たす可能性があります。さらに、さまざまなチームの管理ニーズに応じて、オペレーティング システムのインジケーター、ログ、データベース、ミドルウェア、セキュリティ検査などのさまざまな管理監視エージェントがオペレーティング システムにインストールされます。この積み重ねられた形式は、単にサービスを提供するだけではありません。システムリソースを所有するオペレーターは深刻な消費をもたらし、さらにはサーバー管理に多くの些細な問題をもたらします (たとえば、データベース監視エージェントも専用のユーザーアカウントを作成する必要があるなど)。この問題を解決するために、多くの企業は、単一の収集エージェントの使用をできるだけ少なくしたいと考えています。例: BMC の巡回監視製品には、さまざまな収集モジュール KM (データベース、ミドルウェア、Web サーバーなど) があり、ユーザーは次のことを行うことができます。複数の収集エージェントを展開する必要がなく、必要に応じて構成できます。ただし、BMC は徐々に多くの新製品を取得し、その後の製品には動的パフォーマンス ベースライン管理、自動構成管理などが含まれます。工具メーカーの観点から見ると、迅速な製品統合を行うことができず、単一の回収代理店を維持することは困難です。
甲社の企業環境では、各部門がそれぞれのニーズに応じて異なる管理ツールを購入することになり、部門間の差異によりツールの構築やデータの収集が繰り返され、部門間のデータ共有が容易ではありません。これにより、収集ツールを同一ホスト上に重ねて配置するだけでなく、重複データを抱えた多数の離島運用保守データデータベースを独立運用することにもつながります。この状況はさらに別の問題を引き起こしており、たとえば、同じホスト上の同じ障害により、さまざまなツールで複数のアラーム イベントがトリガーされ、イベント ストームが発生します。この混沌とし​​た状況により、AIOps ツールには生き残る余地が与えられていますが、イベントの収束と圧縮においてある程度の利点が得られるとしても、「症状は治療するが根本原因は治療しない」という明らかな間違いがあります。

時は仮想化＆クラウドネイティブの時代に移りましたが、上記の状況は根本的に変わっておりません。むしろ、入れ子人形のような深い依存というジレンマをもたらします。Web、ミドルウェア、データベース、メッセージキューなどの機能をPOD内で実行するのではなく、水平展開可能なサブサービス(コンテナサービス)として独立して配置した上で、管理オブジェクトの数が増加します。指数関数的な急増。コンテナ時代には、Prometheus、Grafana、FluntD、Graphite、cAdvisor、Loki、EFK などの新しい監視ツールが導入されました。新しいツールによって、複数の収集機能エージェントの共存および重ね合わせの状況が完全に変わるわけではないことがわかります。複数の同様のエージェント プログラムをデプロイするという問題を認識した後、Elastic は近年、以前のさまざまな Beats プログラム (複数回取得されたプロジェクト) を迅速に統合エージェント Elastic Agent に統合しましたが、このプログラムは現時点では多目的エージェントにすぎません。 Beats プログラム用の (パッケージ化シェル) プログラム。

複数の収集ツールセットにより、エンドポイントでの展開と構成の多くの作業が発生するだけでなく、バ​​ックエンドも独自の独立したデータベース展開に対応します。異なるデータベースの同じ管理オブジェクトのフィールド記述は基本的に異なります。これにより、ツールセットのユーザーがさまざまなデータベースで相関分析を実装することが困難になります。人間の脳はデバッグ コンテキストを伝達し、多数のコンソールでデバッグを実行します。タスクは非常に労働集約的であり、タイムラインを調整したりオブジェクトを監視したりすると、すぐに認知の上限を使い果たしてしまいます。

CMDB は解決策になるかもしれませんが、CMDB の設計と構築は監視システム プロジェクト自体を構築するのと同じくらい難しく、この問題を解決するために CMDB を使用することは困難であり、実装にはコストがかかります。データ ガバナンスも一般的な手法となり、これらの運用および保守データベース コレクション間で ELT とデータ ガバナンスを実行し、最終的に異種の運用および保守情報の正規化を実現するソリューションは、単なる無力なステップにすぎません。スタッフはプロジェクト中に状況を利用して苦い思いをすることは間違いありません。

Elastic によって最初に導入された Unified Data Model (ECS) は、データを標準化された定義に移行する実現可能な方法であるようです。私たちもそれを目にしました。OpenTelemetry プロジェクトはすぐに Elastic ECS を採用しました。CNCFはその後、同様の観測データ定義モデルを立ち上げました。CNCF は、テクノロジーの青写真における可観測性と分析のカテゴリーにおいて、同様のツールが急速に繁栄しているのを目にしたに違いないと思います。これらの標準は私たちの渇きを潤すだけです。なぜなら、ほとんどのメーカーや多数のオープンソースプロジェクトが互換性の実装と実装にすぐに従うのをまだ見ていないからです。

Observation Cloud の DataKit は、上記の問題を解決するために設計された多機能の収集エージェントであり、すでに幅広いテクノロジー エコシステムと互換性があり、接続されています。収集エージェントがターゲット データを収集または接続した後、実際には一連の詳細を処理する必要があります。そうしないと、依然として「ソース ガバナンス」を達成できず、「ゴミが入ったゴミが出る」というジレンマを回避できません。まず、DataKit がデータを整理してカプセル化するとき、すべてのフィールドの定義は観測クラウド (Elastic ECS に相当) によって定義されたデータ ディクショナリに従います。次に、報告されたデータ パッケージがパッケージ化される前に、データ パイプライン処理を実行することもできます。データの現場廃棄、品質管理、ガバナンス、非感作などの問題を実現します。最後に、DataKit のコレクションは、DataDog の APM プローブ データの受信、OpenTelemetry データへの接続など、オープン ソースおよびクローズド ソースのエコシステムに接続することもできます。インターネット上やネットワーク間での観測データの転送も実現できます。

統合ストレージ バックエンド

可観測性プラットフォームを構築するプロセスでは、各タイプのセマフォが最適な場所に配置されるに値します。

Elasticsearch: Elastic の ECS のおかげで、これは非常に適切な 1 つのインベントリ、すべてのソリューションのように見えますが、その前提として、費用対効果を維持できる必要があります。

時系列データベース: 個別にリストされていないため、インジケーターの時系列データに適しています。

カラムデータベース：ClickHouseに代表されるリアルタイムデータ解析用のカラムデータベースで、様々なシグナルに対応しています。

リレーショナル データベース: なぜそうではないのか。

データ ストレージの観点から見ると、セマフォごとに最適なデータベース タイプを構成することは、誰にとっても幸せな状況のように思えます。これは、さまざまなオープンソースデータベースが開花している現状を裏切るものではありません。
すでに前述したデータサイロとガバナンスの問題はスキップしてください。クエリの観点から見ると、ユーザーは複数のクエリ言語を学習する必要があり、その前に n 種類の SQL 構文を学習する必要があり、そうでない場合は 1 対多のクエリ インターフェイスを開発して維持する必要があります。ここでは、可観測性データのデータベース間のデータ相関分析をどのように実装するかについては説明しません。
質問: 複数のタイプのセマフォ データを統合データ ウェアハウスに統合するマルチモーダル統合データベースはありますか?
実際、現在の可観測性 SaaS プロバイダーは、少なくとも可観測性データの使用のクエリと探索の観点から、そのような統合および統合されたデータ バックエンドをユーザーに提供しています。Observation Cloud は、上記の統合、統合、ポリモーフィックな共存管理のニーズを解決するために、そのようなデータベースも立ち上げています。Observation Cloud ユーザーは間もなく、このテクノロジーを SaaS サービスやプライベートで導入された製品で使用できるようになります。

データを自由に探索および合成できる

観測できるデータの価値はその活用に反映され、さまざまなデータを自由に探索し、総合的に活用することで初めてデータの価値を高めることができます。可観測性データの使用シナリオを検討する際、編集者は、経験に頼ることを避け、新しい可観測性技術がすべての古い技術を置き換えることができるという仮定を排除するために、「第一原則」を使用して考えることを強く推奨します。可観測性テクノロジーの概念的な原点に戻ります。

要約する

この記事では、一定の深さと期間を持つ 4 つのレベルから可観測性プラットフォームを実装する技術的なポイントについて説明します。希望: あなたの作業環境に、統合および統合された可観測性プラットフォームがすぐに実装できるようになります。2つのブーツを履くことで、裸足で戦闘に参加し、裸足で消火活動をするという以前のジレンマから逃れることができます。私たちは、可観測性プラットフォームがソフトウェア配信パイプラインの全員を支援し、可観測性を使用して運用を補完し、SRE の力を高め、開発を勇気づけることができることを願っています。

推奨読書「可観測性エンジニアリング」

推奨理由: Google SRE のコア専門家と可観測性コミュニティのリーダーが執筆し、可観測性分野の国内ユニコーン企業の観測クラウド チームが愛情を込めて翻訳しました。クラウド ネイティブ時代のソフトウェア システムの難しい運用と保守の問題点を効果的に解決する可観測性テクノロジの実装ガイド。ITシステムを推進し、効率的な配信、統一的な運用保守、永続的な最適化を実現します。

購入リンク https://u.jd.com/nb2cA1B

ライブブロードキャストプレビュー

ライブ ブロードキャストのテーマ:
現代ソフトウェア エンジニアリングの新潮流に関するフォーラムと新刊『オブザーバビリティ エンジニアリング』の発売

生放送時間
9月20日（水）
19:00～20:30

『Observability Engineering』は2021年に出版され、海外でも高く評価されており、可観測性技術を理解したいすべてのエンジニア必読の書です。2023年9月20日の夜19:00、機械産業出版局華庄支局は、本書の中国語翻訳者である「観察雲チーム」と協力して、オンライン新書発売カンファレンスを開催し、ゲストを交えた可観測性技術の開発、新たなトレンドと新たな未来。

ライブ配信を予約する

動画番号：CSDN 生放送予約リマインダー：「講義」～現代ソフトウェア工学の新潮流; CSDN公式サイト生放送室でも同時中継します！

抽選方法

• フォロー+いいね+記事を集める

• コメント欄にメッセージを残してください: あらゆる知識を学び、勝者を見つけてください (フォローしてメッセージを残すことで賞金プールに参加できます。各人が最大 3 つのメッセージを残すことができます)

• 日曜午後8時に抽選

• 今回は 2 ～ 5 冊プレゼントします 【読めば読むほどプレゼント量が増えます】
  500-1000 2 冊無料
  1000-1500 3 冊無料
  1500-2000 4 冊無料
  2000+ 5 冊無料