MEGAZONEブログ
![コンテナでのモニタリングのためのコーディング](https://www.hyperbilling.jp/wp-content/uploads/2023/12/pasted-image-0-18.png)
コンテナでのモニタリングのためのコーディング
Coding for container observability
Pulisher : Managed & Support Center キム・ソンド
Description : 様々な環境でモニタリングを行うためにOpen Telemetry SDKとAWS Distro for Open Telemetry(ADOT) Collectorの使用について紹介するショーン氏。
はじめに
様々な環境でモニタリングをするためにOpen Telemetry SDKとAWS Distro for Open Telemetry(ADOT) Collectorを使う例について確認することができるセッションです。
大規模コンテナベースでの安定的なADOT活用事例とパイプライン構築に関する内容を聞きたいと思い、セッションを申し込みました。
![](https://www.hyperbilling.jp/wp-content/uploads/2024/01/pasted-image-0-21-1024x768.png)
コンテナでのモニタリング方法を確認するセッションです。
![](https://www.hyperbilling.jp/wp-content/uploads/2024/01/pasted-image-0-1-12-1024x768.png)
モニタリングは、データを使用してユーザーが知りたい内容を確認し、重要な答えを見つけるプロセスです。
モニタリングはCPU Utilization、ネットワークチェックなどがありますが、インフラコストなどエンジニアのための内容ではないかもしれません。
![](https://www.hyperbilling.jp/wp-content/uploads/2024/01/pasted-image-0-2-11-1024x768.png)
モニタリングの3つの軸はMetrics、Logs、Tracesと言えます。
時系列であるMetrics、システムエラーとコンテキストを確認するためのLogs、ネットワークとセキュリティまで網羅できるTracesで定義することができます。
![](https://www.hyperbilling.jp/wp-content/uploads/2024/01/pasted-image-0-4-12-1024x768.png)
Metrics、Logs、Tracesが必要な内容を一つ一つ定義するのは難しいかもしれません。
そこで人々は頭を合わせてMetrics, Logs, Tracesの標準を作り、OpenTelemetryというオープンソースプロジェクトが作られることになりました。
![](https://www.hyperbilling.jp/wp-content/uploads/2024/01/pasted-image-0-5-12-1024x768.png)
OpenTelemetryを使うためには、既存のコードにメトリック収集のためのいくつかのコードを追加して修正する必要があります。
追加するだけで、色んな対象にデータを送信することができるようになります。
![](https://www.hyperbilling.jp/wp-content/uploads/2024/01/pasted-image-0-6-10-1024x768.png)
パイプラインはReceivers, Processors, Exporters, Extensionsに分けられます。
![](https://www.hyperbilling.jp/wp-content/uploads/2024/01/pasted-image-0-7-8-1024x768.png)
パイプラインを作る時、上の章表にある特定のコンポーネントを自動でインストールすると、ユーザーの立場でとても良い楽しみができます。
今からパイプラインを作りながら実際のコードでどのように動くかデモをデモします。
![](https://www.hyperbilling.jp/wp-content/uploads/2024/01/pasted-image-0-8-6-1024x768.png)
上の章表は基本的なデモ環境です。
このデモはHTTPリクエストで提供されたFlask Pythonアプリケーションを実行しています。
CloudwatchでLogをロードして、Prometheusにアプリケーションを管理するためのMetric、Tracesをロードします。
![](https://www.hyperbilling.jp/wp-content/uploads/2024/01/pasted-image-0-10-3-1024x768.png)
![](https://www.hyperbilling.jp/wp-content/uploads/2024/01/pasted-image-0-11-3-1024x768.png)
![](https://www.hyperbilling.jp/wp-content/uploads/2024/01/pasted-image-0-12-3-1024x768.png)
![](https://www.hyperbilling.jp/wp-content/uploads/2024/01/pasted-image-0-13-1-1024x768.png)
まず、手動計測をしてみます。
写真のようにライブラリだけ持って来れば、コードですぐ使うことができます。
TracerとMeterというグローバル変数を作ってアプリケーションでMetricとTracesを収集します。
そしてrollという関数を作りました。簡単に1から6までの整数を返すコードです。
Curlを使ってKeyとValueでデータを送信したら受信する簡単なアプリケーションでした。
![](https://www.hyperbilling.jp/wp-content/uploads/2024/01/pasted-image-0-14-1-1024x768.png)
上の写真はAWS Distro for OpenTelemetryを使った構成図です。
上のデモで見たように既存のOpenTelemetryは既存のコードを少し修正する必要があります。
しかし、ADOTの場合Collectorを利用してMetrics、Traces、Logsを構成することができます。
![](https://www.hyperbilling.jp/wp-content/uploads/2024/01/pasted-image-0-15-1-1024x768.png)
パイプラインを生成する時、上の写真のようにそれぞれのReceiverを生成してそれに合うProcessorにExportersだけ追加すれば終わりです。
一番下のfilterが見えますが、これはcreditcardのような個人情報が入ってるデータは外部に流出されないようにするため、データを収集しないため追加しました。
また、batchが一番最後にあるのが見えますが、これはバッチ処理をするのは一番最後に処理するためです。
![](https://www.hyperbilling.jp/wp-content/uploads/2024/01/pasted-image-0-16-1-1024x768.png)
![](https://www.hyperbilling.jp/wp-content/uploads/2024/01/pasted-image-0-17-1-1024x768.png)
最後にURLを共有して自分が一番好きな週を選択する簡単なアプリケーションを生成して実際にどのようにLogが保存され、TraceされるかをGrafanaを使って確認しました。
上のデモは下記のGithubリンクで確認することができます。
https://github.com/lewinkedrs/cop-401-instrumentation
セッションを終えて
発表者の方がセッションを進行しながらCodeWhisperを活用して素早くコードを生成する姿まで見せてくれました。
どのようなコードが欲しいか説明するだけで、コードをすぐに生成できるのが驚きで、Open Telemetryも良いですが、EKSを使う顧客ならAWS Distro for OpenTelemetryを利用して、アプリケーションを使用しながら生成されるデータを簡単に収集、加工、処理することができると思いました。
Coding for container observability