FIXER cloud.config Tech Blog
OpenTelemetryを楽に導入する「Automatic Instrumentation」
2023年08月31日 10時00分更新
本記事はFIXERが提供する「cloud.config Tech Blog」に掲載された「OpenTelemetryを楽に導入するAutomatic Instrumentation」を再編集したものです。
マイクロサービスというソフトウェア開発のアーキテクチャがあります。大規模なアプリケーションを小さな独立した機能単位に分割し、それぞれを個別のサービスとして実装する方法です。分離性、独立性など多くの利点がありますが複雑さを増してしまうという大きな欠点があります。
1分でわかる可観測性
複雑さを増していくソフトウェアに必要になるのがオブザーバビリティ（可観測性）です。これを高めることでサービスを可視化し、パフォーマンスを正確に把握することができます。
可観測性は軸となる三つの柱があります。
メトリクス
システムやアプリケーションのパフォーマンスやリソース使用状況に関する数値データ
トレース
システムやアプリケーション内でのリクエストやトランザクションのフローを追跡するためのデータ
ログ
システムやアプリケーションの動作に関する時系列データ
What's OpenTelemetry
OpenTelemetryとは上記の観測データを作成、管理するフレームワークです。OpenTelemetryの大きな利点として、ベンダーに依存しない点とJaegerやPrometheusのような様々なバックエンドをサポートしている点です。
主なコンポーネント
OpenTelemetry Collector
観測データを受信、処理、エクスポートします。OpenTelemetryプロトコルだけでなく、Jaeger、Zipkin、Prometheusなどの他のトレーシングやメトリクスデータソースもサポートしています。
・Receiver・・・観測データを受信する
・Processor・・・観測データを処理する
・Exporter・・・観測データをエクスポートする
OpenTelemetry Operator
Opentelemetry CollectorをKubernetesクラスターにデプロイする際に、簡単に設定を変更するためのカスタムリソースです。また、今回のタイトルでもあるAuto Instrumentationを管理します。Helm Chartを使ってインストールできます。
Auto Instrumentationを実装する
Insturumentationとは計測を行うためのプロセスです。従来のトレーシングでは観測データを出力する処理をコードに記述する必要がありました。しかしOpentelemetryはコードに記述することなくInstrumentationを行うことができます。これがベンダーに依存しないといわれる所以です。今回はその方法を紹介します。
Opentelemetry Operatorをインストールする
operator.yml
本来であればあらかじめcert-managerというリソースを作成しておく必要がありますが上記の設定を追記することでその手間を省くことができます。あとはデフォルトの設定で問題ないです。
Opentelemetry Collectorを作成する
collector.yml
上記の設定はあくまで一例でreceiver、exporterを追加することで様々なツールと連携することができます。
Instrumentationを作成する
Instrumentation.yml
バックエンドのコードに記述する代わりにkubernetesリソースを作成します。
PodにAnnotationを追加する
最後に、バックエンドのコードにInstrumentationを注入するアノテーションを追加します。
dotnetの場合:
ほかの言語の記述はこちらからどうぞ。
まとめ
以上がOpentelemetryを楽に導入する工程でした。可観測性を高めることで多くのメリットを得ることができます。
Automatic Instrumentationではないですが、簡単に動かせる公式のOpenTelemetryデモがあるので試しに触ってみてください！（ローカルで動かすとCPUめちゃ使う）
最後まで読んでいただきありがとうございました。
秋山 直輝／FIXER
（あきやま なおき）
HAL東京を卒業し、2023年度入社しました。朝食は元気の源
