分散システムでの可観測性

投稿日: 2022-10-28 2022-10-28
タグ: Architecture, DevOps

1. 序章

このチュートリアルでは、可観測性と、それが分散システムで重要な役割を果たす理由について説明します。可観測性を構成するデータの種類について説明します。これは、分散システムからテレメトリデータを収集、保存、分析する際の課題を理解するのに役立ちます。

最後に、可観測性の分野で業界標準と人気のあるツールのいくつかについて説明します。

2. 可観測性とは何ですか？

追いかけっこをして、最初に正式な定義を出しましょう！可観測性とは、外部出力によってのみシステムの内部状態を測定する機能です。

マイクロサービスのような分散システムの場合、これらの外部出力は基本的にテレメトリデータとして知られています。これには、マシンのリソース消費、マシンで実行されているアプリケーションによって生成されたログなどの情報が含まれます。

2.1. テレメトリデータの種類

テレメトリデータは、可観測性の3つの柱、ログ、メトリック、およびトレースと呼ばれる3つのカテゴリに分類できます。それらをより詳細に理解しましょう。

ログは、コードの実行中にアプリケーションが個別のポイントで生成するテキスト行です。通常、これらは構造化されており、多くの場合、さまざまなレベルの重大度で生成されます。これらは非常に簡単に生成できますが、多くの場合、パフォーマンスコストがかかります。さらに、ログを効率的に収集、保存、分析するために、Logstashなどの追加のツールが必要になる場合があります。

簡単に言うと、メトリックは、一定期間にわたってを計算または集計するカウントまたはメジャーとして表される値です。これらの値は、仮想マシンなどのシステムに関するデータを表します。たとえば、1秒ごとの仮想マシンのメモリ消費量です。これらは、ホスト、アプリケーション、クラウドプラットフォームなどのさまざまなソースから取得できます。

トレースは、単一の要求が複数のアプリケーションを通過できる分散システムにとって重要です。 トレースは、要求が分散システムを流れるときの分散イベントの表現です。これらは、分散システムのボトルネック、欠陥、またはその他の問題を特定するのに非常に役立ちます。

2.2. 可観測性の利点

まず、システムで可観測性が必要な理由を理解する必要があります。私たちのほとんどは、実稼働システムでの理解しにくい動作のトラブルシューティングという課題に直面している可能性があります。本番環境を混乱させるオプションが限られていることを理解するのは難しいことではありません。これにより、システムが生成するデータを分析する必要がほとんどあります。

可観測性は、システムが意図した状態から逸脱し始める状況を調査するために非常に貴重です。これらの状況を完全に防ぐことも非常に便利です。システムによって生成された監視可能なデータに基づいてアラートを注意深く設定すると、システムが完全に故障する前に是正措置を講じることができます。さらに、このようなデータは、より良いエクスペリエンスのためにシステムを調整するための重要な分析的洞察を提供します。

可観測性の必要性は、どのシステムにとっても重要ですが、分散システムにとっては非常に重要です。さらに、当社のシステムは、パブリッククラウドとプライベートクラウド、およびオンプレミス環境にまたがることができます。さらに、時間の経過とともに規模と複雑さが変化し続けます。これにより、これまで予期されていなかった問題が発生することがよくあります。非常に観察しやすいシステムは、このような状況に対処するのに非常に役立ちます。

3. 可観測性vs。モニタリング

DevOps の実践では、可観測性に関連するモニタリングについてよく耳にします。では、これらの用語の違いは何ですか？どちらも同様の機能を備えており、システムの信頼性を維持することができます。しかし、それらには微妙な違いがあり、実際、それらの間には関係があります。システムが観察可能である場合にのみ、システムを効果的に監視できます。

監視とは、基本的に事前定義された一連のメトリックとログを通じてシステムの状態を監視する方法を指します。これは本質的に、既知の一連の障害を監視していることを意味します。ただし、分散システムでは、多くの動的な変更が発生し続けます。これは、私たちが決して探していなかった問題を引き起こします。したがって、私たちの監視システムはそれらを見逃す可能性があります。

一方、可観測性は、システムの内部状態を理解するのに役立ちます。これにより、システムの動作について任意の質問をすることができます。たとえば、問題が発生した場合に各サービスがリクエストをどのように処理したかなど、複雑な質問をすることができます。時間の経過とともに、システムの動的な動作に関する知識を構築するのに役立ちます。

これがなぜそうなのかを理解するには、カーディナリティの概念を理解する必要があります。 カーディナリティとは、セット内の一意のアイテムの数を指します。たとえば、ユーザーの社会保障番号のセットは、性別よりもカーディナリティが高くなります。システムの動作に関する恣意的な質問に答えるには、高いカーディナリティデータが必要です。ただし、監視は通常、カーディナリティの低いデータのみを処理します。

4. 分散システムでの可観測性

前に見たように、可観測性は複雑な分散システムで特に役立ちます。しかし、分散システムを正確に複雑にするものは何ですか？また、そのようなシステムでの可観測性の課題は何ですか？この質問を理解して、過去数年間にこの主題を中心に成長したツールとプラットフォームのエコシステムを理解することが重要です。

分散システムでは、システムランドスケープを動的に変更する多くの移動コンポーネントがあります。さらに、動的なスケーラビリティとは、ある時点でサービスに対して実行されているインスタンスの数が不確実であることを意味します。これにより、ログやメトリックなどのシステム出力を収集、キュレート、および保存する作業が困難になります。

さらに、システムのアプリケーション内で何が起こっているのかを理解するだけでは十分ではありません。たとえば、問題はネットワーク層またはロードバランサーにある可能性があります。次に、データベース、メッセージングプラットフォームがあり、リストは続きます。 これらすべてのコンポーネントが常に監視可能であることが重要です。システムのすべての部分から意味のあるデータを収集して一元化できる必要があります。

さらに、複数のコンポーネントが同期的または非同期的に連携して動作しているため、異常の原因を特定するのは簡単ではありません。たとえば、システム内のどのサービスがパフォーマンスの低下としてボトルネックの拡大を引き起こしているのかを判断するのは困難です。以前に見たように、トレースはそのような問題を調査するのに非常に役立ちます。

5. 可観測性の進化

可観測性は、制御理論にルーツがあります。これは、応用数学の一分野であり、フィードバックを使用してシステムの動作に影響を与え、目的の目標を達成します。この原理は、産業プラントから航空機の運用まで、いくつかの産業に適用できます。ソフトウェアシステムの場合、 Twitterなどの一部のソーシャルネットワーキングサイトが大規模に機能し始めて以来、これは人気があります。

近年まで、ほとんどのソフトウェアシステムはモノリシックであり、インシデントの発生時にそれらについて推論するのはかなり簡単でした。監視は、典型的な障害シナリオを示すのに非常に効果的でした。さらに、問題を特定するためにコードをデバッグするのは直感的でした。しかし、マイクロサービスアーキテクチャとクラウドコンピューティングの出現により、これはすぐに困難な作業になりました。

この進化が続くにつれ、ソフトウェアシステムはもはや静的ではなくなり、動的にシフトする多数のコンポーネントがありました。その結果、これまで予期していなかった問題が発生しました。このは、AppDynamicsやDynatraceなど、Application Performance Management（APM）の傘下にある多くのツールを生み出しました。これらのツールは、アプリケーションコードとシステムの動作を理解するためのより良い方法を約束しました。

これらのツールは進化の過程で長い道のりを歩んできましたが、当時はかなりメトリックベースでした。これにより、システムの状態について必要な種類の視点を提供できなくなりました。しかし、それらは大きな前進でした。今日、私たちは可観測性の3つの柱に対処するためのツールの組み合わせを手に入れました。もちろん、基礎となるコンポーネントも観察可能である必要があります。

6. 可観測性の実践

可観測性について十分な理論をカバーしたので、これをどのように実践できるか見てみましょう。シンプルなマイクロサービスベースの分散システムを使用し、JavaのSpring Bootを使用して個々のサービスを開発します。これらのサービスは、RESTAPIを使用して同期的に相互に通信します。

私たちのシステムサービスを見てみましょう：

これは、math-serviceがaddition-service、multiplication-serviceなどによって提供されるAPIを使用する非常に単純な分散システムです。さらに、 math-service は、さまざまな数式を計算するためのAPIを公開しています。これらのマイクロサービスの作成の詳細は非常に簡単なので、スキップします。

この演習の重点は、可観測性のコンテキストで今日利用可能な最も一般的な標準と人気のあるツールを認識することです。可観測性を備えたこのシステムのターゲットアーキテクチャは、次の図のようになります。

これらの多くは、コンテナ技術の進歩を促進する組織である Cloud Native Computing Foundation（CNCF）でもさまざまな認識段階にあります。分散システムでこれらのいくつかを使用する方法を見ていきます。

7. OpenTracingを使用したトレース

トレースが、単一のリクエストが分散システムを介してどのように伝播するかを理解するための貴重な洞察をどのように提供できるかを見てきました。 OpenTracing は、CNCFの下でのインキュベーションプロジェクトです。 ベンダーに依存しないAPIと、分散トレース用のインストルメンテーションを提供します。これは、どのベンダーにも固有ではないインストルメンテーションをコードに追加するのに役立ちます。

OpenTracingに準拠する利用可能なトレーサーのリストは急速に増えています。最も人気のあるトレーサーの1つはJaegerで、これもCNCFの段階的プロジェクトです。

アプリケーションでOpenTracingでJaegerを使用する方法を見てみましょう。

詳細については後で説明します。ちなみに、 LightStep 、 Instana 、 SkyWalking 、Datadogなどの他のオプションがいくつかあります。コードにインストルメンテーションを追加する方法を変更することなく、これらのトレーサーを簡単に切り替えることができます。

7.1. 概念と用語

OpenTracingのトレースは、スパンで構成されています。 スパンは、分散システムで実行される個々の作業単位です。基本的に、トレースはスパンの有向非巡回グラフ（DAG）と見なすことができます。スパン間のエッジを参照と呼びます。分散システムのすべてのコンポーネントは、トレースにスパンを追加します。スパンには他のスパンへの参照が含まれており、これはトレースがリクエストの存続期間を再現するのに役立ちます。

時間軸またはグラフを使用して、トレース内のスパン間の因果関係を視覚化できます。

ここでは、 OpenTracingが定義する2種類の参照、「ChildOf」と「FollowsFrom」を確認できます。これらは、子と親のスパン間の関係を確立します。

OpenTracing仕様は、スパンがキャプチャする状態を定義します。

操作名
開始タイムスタンプと終了タイムスタンプ
キー値スパンタグのセット
キー値スパンログのセット
SpanContext

タグを使用すると、ユーザー定義の注釈を、トレースデータのクエリとフィルタリングに使用するスパンの一部にすることができます。スパンタグはスパン全体に適用されます。同様に、ログを使用すると、スパンでログメッセージやその他のデバッグまたはアプリケーションからの情報出力をキャプチャできます。スパンログは、スパン内の特定の瞬間またはイベントに適用できます。

最後に、 SpanContextは、スパンを結び付けるものです。プロセスの境界を越えてデータを伝送します。典型的なSpanContextを簡単に見てみましょう。

ご覧のとおり、主に次のもので構成されています。

spanIdやtraceIdのような実装に依存する状態
プロセスの境界を越えるキーと値のペアである手荷物アイテム

7.2. セットアップと計装

使用するOpenTracing互換トレーサーであるJaegerのインストールから始めます。いくつかのコンポーネントがありますが、単純なDockerコマンドですべてをインストールできます。

docker run -d -p 5775:5775/udp -p 16686:16686 jaegertracing/all-in-one:latest

次に、必要な依存関係をアプリケーションにインポートする必要があります。 Mavenベースのアプリケーションの場合、これは依存関係の追加と同じくらい簡単です。

<dependency>
    <groupId>io.opentracing.contrib</groupId>
    <artifactId>opentracing-spring-jaeger-web-starter</artifactId>
    <version>3.3.1</version>
</dependency>

Spring Bootベースのアプリケーションの場合、サードパーティによって提供されたこのライブラリを活用できます。これには、必要なすべての依存関係が含まれ、Web要求/応答を計測してJaegerにトレースを送信するために必要なデフォルト構成を提供します。

アプリケーション側では、Tracerを作成する必要があります。

@Bean
public Tracer getTracer() {
    Configuration.SamplerConfiguration samplerConfig = Configuration
      .SamplerConfiguration.fromEnv()
      .withType("const").withParam(1);
    Configuration.ReporterConfiguration reporterConfig = Configuration
      .ReporterConfiguration.fromEnv()
      .withLogSpans(true);
    Configuration config = new Configuration("math-service")
      .withSampler(samplerConfig)
      .withReporter(reporterConfig);
    return config.getTracer();
}

これは、リクエストが通過するサービスのスパンを生成するのに十分です。必要に応じて、サービス内で子スパンを生成することもできます。

Span span = tracer.buildSpan("my-span").start();
// Some code for which which the span needs to be reported
span.finish();

これは非常にシンプルで直感的ですが、複雑な分散システムについて分析すると非常に強力です。

7.3. トレース分析

Jaegerには、デフォルトでポート16686からアクセスできるユーザーインターフェイスが付属しています。トレースデータを視覚化してクエリ、フィルタリング、分析する簡単な方法を提供します。分散システムのサンプルトレースを見てみましょう。

ご覧のとおり、これは traceIdによって識別される特定のトレースの視覚化です。このトレース内のすべてのスパンが、どのサービスに属しているか、完了までにかかった時間などの詳細とともに明確に示されます。これは、非定型の動作の場合に問題が発生する可能性がある場所を理解するのに役立ちます。

8. OpenCensusを使用したメトリック

OpenCensus は、さまざまな言語のライブラリを提供し、アプリケーションからメトリックと分散トレースを収集できるようにします。それはGoogleで始まりましたが、それ以来、成長するコミュニティによってオープンソースプロジェクトとして開発されてきました。 OpenCensusの利点は、分析のためにデータを任意のバックエンドに送信できることです。これにより、特定のバックエンドに結合するのではなく、インストルメンテーションコードを抽象化できます。

OpenCensusはトレースとメトリックの両方をサポートできますが、サンプルアプリケーションのメトリックにのみ使用します。 使用できるバックエンドがいくつかあります。最も人気のあるメトリクスツールの1つは、 Prometheus です。これは、CNCFの段階的プロジェクトでもあるオープンソースの監視ソリューションです。 OpenCensusを備えたJaegerがアプリケーションとどのように統合されるかを見てみましょう。

Prometheusにはユーザーインターフェイスが付属していますが、Prometheusとうまく統合できるGrafanaのような視覚化ツールを使用できます。

8.1. 概念と用語

OpenCensusでは、メジャーは記録されるメトリックタイプを表します。たとえば、要求ペイロードのサイズは、収集する1つのメジャーにすることができます。 測定は、測定によって数量を記録した後に生成されるデータポイントです。たとえば、80 kbは、要求ペイロードサイズ測定の測定値になります。すべてのメジャーは、名前、説明、および単位で識別されます。

統計を分析するには、データをビューで集計する必要があります。 ビューは、基本的に、メジャーと、オプションでタグに適用される集計の結合です。 OpenCensusは、カウント、分布、合計、最後の値などの集計方法をサポートしています。ビューは、名前、説明、メジャー、タグキー、および集計で構成されます。複数のビューで、異なる集計で同じメジャーを使用できます。

タグは、記録された測定値に関連付けられたデータのキーと値のペアであり、コンテキスト情報を提供し、分析中にメトリックを区別してグループ化します。測定値を集計してメトリックを作成する場合、タグをラベルとして使用してメトリックを分類できます。タグは、分散システムで要求ヘッダーとして伝播することもできます。

最後に、エクスポーターは、メトリックを消費できる任意のバックエンドにメトリックを送信できます。エクスポータは、クライアントコードに影響を与えることなく、バックエンドに応じて変更できます。これにより、OpenCensusはメトリック収集に関してベンダーに中立になります。 Prometheusのような人気のあるバックエンドのほとんどで、複数の言語で利用できるエクスポーターがかなりあります。

8.2. セットアップと計装

バックエンドとしてPrometheusを使用するので、最初にインストールする必要があります。これは、公式のDockerイメージを使用してすばやく簡単に行えます。 Prometheusは、監視対象のターゲットのメトリックエンドポイントをスクレイピングすることにより、これらのターゲットからメトリックを収集します。したがって、Prometheus構成YAMLファイルprometheus.ymlで詳細を提供する必要があります。

scrape_configs:
  - job_name: 'spring_opencensus'
    scrape_interval: 10s
    static_configs:
      - targets: ['localhost:8887', 'localhost:8888', 'localhost:8889']

これは、メトリックをスクレイプするターゲットをPrometheusに指示する基本的な構成です。これで、簡単なコマンドでPrometheusを起動できます。

docker run -d -p 9090:9090 -v \
  ./prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus

カスタムメトリックを定義するには、メジャーの定義から始めます。

MeasureDouble M_LATENCY_MS = MeasureDouble
  .create("math-service/latency", "The latency in milliseconds", "ms");

次に、定義したメジャーの測定値を記録する必要があります。

StatsRecorder STATS_RECORDER = Stats.getStatsRecorder();
STATS_RECORDER.newMeasureMap()
  .put(M_LATENCY_MS, 17.0)
  .record();

次に、集計を定義し、これをメトリックとしてエクスポートできるようにするメジャーのビューを表示する必要があります。

Aggregation latencyDistribution = Distribution.create(BucketBoundaries.create(
  Arrays.asList(0.0, 25.0, 100.0, 200.0, 400.0, 800.0, 10000.0)));
View view = View.create(
  Name.create("math-service/latency"),
  "The distribution of the latencies",
  M_LATENCY_MS,
  latencyDistribution,
  Collections.singletonList(KEY_METHOD)),
};
ViewManager manager = Stats.getViewManager();
manager.registerView(view);

最後に、ビューをPrometheusにエクスポートするには、コレクターを作成して登録し、HTTPサーバーをデーモンとして実行する必要があります。

PrometheusStatsCollector.createAndRegister();
HTTPServer server = new HTTPServer("localhost", 8887, true);

これは、アプリケーションからの測定値としてレイテンシーを記録し、それをストレージと分析のためにPrometheusにエクスポートする方法を示す簡単な例です。

8.3. 指標分析

OpenCensusは、zPages と呼ばれるインプロセスWebページを提供します。このページには、接続されているプロセスから収集されたデータが表示されます。さらに、Prometheusには、任意の式を入力してその結果を確認できる式ブラウザーが用意されています。ただし、 Grafana のようなツールは、よりエレガントで効率的な視覚化を提供します。

公式のDockerイメージを使用してGrafanaをインストールするのは非常に簡単です。

docker run -d --name=grafana -p 3000:3000 grafana/grafana

GrafanaはPrometheusのクエリをサポートしています—GrafanaのデータソースとしてPrometheusを追加するだけです。次に、メトリックの通常のPrometheusクエリ式を使用してグラフを作成できます。

グラフを調整するために使用できるグラフ設定がいくつかあります。さらに、Prometheusで利用できるビルド済みのGrafanaダッシュボードがいくつかあります。

9. ElasticStackを使用したログ

ログは、アプリケーションがイベントにどのように反応したかについての貴重な洞察を提供できます。残念ながら、分散システムでは、これは複数のコンポーネントに分割されます。したがって、効果的な分析のために、すべてのコンポーネントからログを収集し、それらを1つの場所に保存することが重要になります。さらに、ログを効率的にクエリ、フィルタリング、参照するには、直感的なユーザーインターフェイスが必要です。

Elastic Stack は基本的にログ管理プラットフォームであり、最近まで、Elasticsearch、Logstash、Kibana（ELK）の3つの製品のコレクションでした。

ただし、それ以降、効率的なデータ収集のためにBeatsがこのスタックに追加されました。

これらの製品をアプリケーションでどのように使用できるかを見てみましょう。

ご覧のとおり、Javaでは、SLF4Jのような単純な抽象化とLogbackのようなロガーを使用してログを生成できます。ここではこれらの詳細をスキップします。

Elastic Stack製品はオープンソースであり、Elasticによって保守されています。これらが一緒になって、分散システムでのログ分析のための魅力的なプラットフォームを提供します。

9.1. 概念と用語

これまで見てきたように、ElasticStackは複数の製品のコレクションです。これらの製品の初期のものはElasticseachでした。これは、分散型のRESTfulなJSONベースの検索エンジンです。柔軟性と拡張性のために非常に人気があります。これがElasticの基礎となった製品です。これは基本的にApacheLucene検索エンジンに基づいています。

Elasticsearch は、ストレージの基本単位であるドキュメントとしてインデックスを保存します。これらは単純なJSONオブジェクトです。タイプを使用して、ドキュメント内の同様のタイプのデータを細分化できます。インデックスは、ドキュメントの論理パーティションです。通常、スケーラビリティのために、インデックスを水平方向にシャードに分割できます。さらに、フォールトトレランスのためにシャードを複製することもできます。

Logstash は、さまざまな入力ソースからデータを収集するログアグリゲーターですまた、さまざまな変換と拡張を実行し、出力先に送信します。 Logstashの方がフットプリントが大きいため、 Beats を使用します。これは、サーバーにエージェントとしてインストールできる軽量のデータシッパーです。最後に、 Kibana は、Elasticsearchの上で機能する視覚化レイヤーです。

これらの製品を組み合わせることで、ログデータの集計、処理、保存、分析を実行するための完全なスイートが提供されます。

これらの製品を使用して、ログデータの本番環境グレードのデータパイプラインを作成できます。ただし、このアーキテクチャを拡張して大量のログデータを処理することは非常に可能であり、場合によっては必要です。 Logstashの前にKafkaのようなバッファーを配置して、ダウンストリームコンポーネントがそれを圧倒するのを防ぐことができます。 Elastic Stackは、その点で非常に柔軟性があります。

9.2. セットアップと計装

先に見たように、ElasticStackはいくつかの製品で構成されています。もちろん、個別にインストールすることもできます。ただし、これには時間がかかります。幸い、Elasticはこれを簡単にするために公式のDockerイメージを提供しています。

シングルノードのElasticsearchクラスターの起動は、Dockerコマンドを実行するのと同じくらい簡単です。

docker run -p 9200:9200 -p 9300:9300 \
  -e "discovery.type=single-node" \
  docker.elastic.co/elasticsearch/elasticsearch:7.13.0

同様に、KibanaをインストールしてElasticsearchクラスターに接続するのは非常に簡単です。

docker run -p 5601:5601 \
  -e "ELASTICSEARCH_HOSTS=http://localhost:9200" \
  docker.elastic.co/kibana/kibana:7.13.0

Logstashのインストールと構成は、データ処理に必要な設定とパイプラインを提供する必要があるため、もう少し複雑です。これを実現するためのより簡単な方法の1つは、公式画像の上にカスタム画像を作成することです。

FROM docker.elastic.co/logstash/logstash:7.13.0
RUN rm -f /usr/share/logstash/pipeline/logstash.conf
ADD pipeline/ /usr/share/logstash/pipeline/
ADD config/ /usr/share/logstash/config/

ElasticsearchおよびBeatsと統合するLogstashのサンプル構成ファイルを見てみましょう。

input {
  tcp {
  port => 4560
  codec => json_lines
  }
  beats {
    host => "127.0.0.1"
    port => "5044"
  }
}
output{
  elasticsearch {
  hosts => ["localhost:9200"]
  index => "app-%{+YYYY.MM.dd}"
  document_type => "%{[@metadata][type]}"
  }
  stdout { codec => rubydebug }
}

データソースに応じて、いくつかのタイプのビートを使用できます。この例では、Filebeatを使用します。 Beatsのインストールと構成は、カスタムイメージを使用して行うのが最適です。

FROM docker.elastic.co/beats/filebeat:7.13.0
COPY filebeat.yml /usr/share/filebeat/filebeat.yml
USER root
RUN chown root:filebeat /usr/share/filebeat/filebeat.yml
USER filebeat

Spring Bootアプリケーションのサンプルfilebeat.ymlを見てみましょう。

filebeat.inputs:
- type: log
enabled: true
paths:
  - /tmp/math-service.log
output.logstash:
hosts: ["localhost:5044"]

これは非常に大雑把ですが、ElasticStackのインストールと構成の完全な説明です。すべての詳細に入るのは、このチュートリアルの範囲を超えています。

9.3. ログ分析

Kibanaは、ログ用の非常に直感的で強力な視覚化ツールを提供します。 Kibanaインターフェースには、デフォルトのURL http：// localhost：5601でアクセスできます。ビジュアライゼーションを選択して、アプリケーションのダッシュボードを作成できます。

サンプルダッシュボードを見てみましょう。

Kibanaは、ログデータをクエリおよびフィルタリングするための非常に広範な機能を提供します。これらは、このチュートリアルの範囲を超えています。

10. 可観測性の未来

これで、可観測性が分散システムの重要な関心事である理由がわかりました。また、可観測性を実現できるさまざまなタイプのテレメトリデータを処理するための一般的なオプションのいくつかについても説明しました。ただし、事実は変わりません。すべての部品を組み立てるのは依然として非常に複雑で時間がかかります。私たちは多くの異なる製品を扱わなければなりません。

この分野での重要な進歩の1つは、CNCFのサンドボックスプロジェクトであるOpenTelemetryです。基本的に、 OpenTelemetryは、OpenTracingプロジェクトとOpenCensusプロジェクトの慎重な合併によって形成されました。明らかに、これは、トレースとメトリックの両方に対して単一の抽象化を処理するだけでよいため、理にかなっています。

さらに、OpenTelemetry は、ログをサポートし、分散システム用の完全な可観測性フレームワークにする計画を持っています。さらに、OpenTelemetryはいくつかの言語をサポートしており、一般的なフレームワークやライブラリとうまく統合されています。また、OpenTelemetryは、ソフトウェアブリッジを介してOpenTracingおよびOpenCensusと下位互換性があります。

OpenTelemetryはまだ進行中であり、今後数日で成熟することが期待できます。一方、私たちの苦痛を和らげるために、いくつかの可観測性プラットフォームは、シームレスなエクスペリエンスを提供するために前述の製品の多くを組み合わせています。たとえば、 Logz.io は、ELK、Prometheus、およびJaegerの機能を組み合わせて、サービスとしてスケーラブルなプラットフォームを提供します。

可観測性の領域は急速に成熟しており、革新的なソリューションを備えた新製品が市場に登場しています。たとえば、 Micrometer は、いくつかの監視システムの計装クライアント上にベンダー中立のファサードを提供します。最近、 OpenMetrics は、クラウドネイティブメトリックを大規模に送信するためのデファクトスタンダードを作成するための仕様をリリースしました。

11. 結論

このチュートリアルでは、可観測性の基本と分散システムでのその意味について説明しました。また、単純な分散システムで可観測性を実現するために、今日人気のあるオプションのいくつかを実装しました。

これにより、OpenTracing、OpenCensus、およびELKが監視可能なソフトウェアシステムの構築にどのように役立つかを理解することができました。最後に、この分野でのいくつかの新しい開発と、将来的に可観測性が成長し成熟することをどのように期待できるかについて説明しました。

getdocs

13036