ヘンリーで SRE をやっている id:nabeop です。最近の仕事のテーマはサービスの可観測性の向上と信頼性の計測です。 最近では可観測性の文脈では OpenTelemetry が話題に上がると思いますが、ヘンリーでも OpenTelemetry を導入してテレメトリデータを収集して、各種バックエンドに転送しています。分散トレース周りの話題については、以下のエントリがあります。 ヘンリーではマイクロサービスからのテレメトリデータは Cloud Run で構築した OpenTelemetry Collector で集約し、otelcol のパイプライン中で必要な処理を実施し、バックエンドに転送するアプローチを採用しています。 OpenTelemetry Collector でテレメトリデータを収集している様子 現在は監視基盤の移行期なので、メトリクスが Google Cloud と Da

最近たまたまなのか聞かれることが多くあったので半分メモです。 バックエンドにテレメトリーデータを送る際には、通常OpenTelemetry Collector（以下、Otel Collector）を使用します。[1] Otel Collectorは以下のような多段構成を取れます。 Otel CollectorのGateway化の何が嬉しいでしょうか。考えられるパターンとしては： セキュリティの理由などで送信元を絞りたいとき Processor/Exporterを一ヶ所で管理したいとき 何らかの理由でOtel Collector Agent側で諸々隠蔽したいとき とりあえず覚えておいて損はない技かと思います。 参考：https://opentelemetry.io/docs/collector/deployment/gateway/ Gatewayとは 別に特別なOtel Collector

この記事はMackerel Advent Calendar 2023 12月19日分の記事です。 Mackerelと連携する外形監視エージェント、maprobeというOSSを5年ほど前に作って、ずっと使っています。今回は maprobe v0.7.0で Otel (OpenTelemetry) metrics を送信する機能を追加したというお話です。 github.com maprobeについては以下の記事もどうぞ。 sfujiwara.hatenablog.com 3行でまとめ maprobeはMackerelに登録されているホスト情報を取得して、そのホストに対してping, TCP, HTTPによる外形監視とmackerel-pluginの実行によるメトリック取得を定期的に実行するエージェントです maprobe v0.7.0 では外形監視の結果とpluginの実行結果を、Macker

OpenTelemetry Collector の Connector を使ってログをメトリックに変換する 2023.09.09 OpenTelemetry には、メトリック、トレース、ログの 3 つの形式があります。これらの形式はそれぞれ別のパイプラインで処理されます。ある形式のデータを別の形式に変換し、あたかも 1 つのパイプライン上でデータを処理したい場合に Connector を使用します。例えば、あるパイプラインはログのパイプラインのエクスポーターとメトリックのパイプラインのレシーバーとして動作します。このような場合、Connector はログをメトリックに変換する役割を担います。 OpenTelemetry Collector における Connector は異なるパイプラインを接続する役割を担います。Connector はパイプラインのレシーバーとエクスポーターとして動作しま

Cloud Native Days Tokyo 2023 の登壇スライドです https://event.cloudnativedays.jp/cndt2023/talks/2058

The Qiita Advent Calendar 2023 is supported by the following companies, organizations, and services.

sumirenです。 SREやSDETや技術顧問やフルスタックエンジニアをしています。 この記事は OpenTelemetry Advent Calendar 2023 3日目の記事です。 2日目の記事は @k6s4i53rx さんの OpenTelemetryとOpenObserveを使ってKubernetes監視をかじる でした。 背景 OpenTelemetryを使うと、分散システムの各サブシステムでどのように処理が進んだのか可視化することができます。 経験を積んだエンジニアの方であれば、各サブシステムとオブザーバビリティバックエンドが一体どのようなコラボレーションをしているのか気になることかと思います。実際、SDKやOpenTelemetry Collectorを使って手軽に分散トレーシングを実現できても、仕組みを理解できていないと、いざトラブルが発生したときに問題解決が難しいでし

OpenTelemetry を使用して Node.js アプリケーションを計装する 2023.08.26 OpenTelemetry は Observability のフレームワークであり、トレース・メトリクス・ログなどのテレメトリーデータを作成、管理するためのツールキットです。OpenTelemetry はベンダーに依存しない形で標準化されたプロトコルとツールを提供していることが特徴です。この記事では Node.js アプリケーションを計装して Prometheus にデータを送信する方法を紹介します。

概要 OpenTelemetryはObservabilityの三本柱であるLogs、Metrics、Tracesをベンダーに依存せず実装するための仕様＆実装です。 今回はそのうちのTracesをGoで試してみます。 環境 Go v1.20.2 go.opentelemetry.io/otel/trace v1.14.0 前提知識 登場人物 OpenTelemetryでは以下の要素があります。 登場人物 役割 Tracer Provider Tracerを提供する。またトレース情報のExport先を管理したり、トレースに共通で付けたい属性データを管理する Tracer Spanを生成する Span 各操作におけるトレース情報 Trace Exporter トレース情報の出力先。標準出力だったり、Jaegerのような分散トレース可視化ツールなど Trace Context Spanの関連付け（

OpenTelemetry Meetup 2023-10 https://opentelemetry.connpass.com/event/296353/

OpenTelemetry Meetup の登壇スライドです。 https://opentelemetry.connpass.com/event/296353/

はじめに こんにちは、Google Cloudでオブザーバビリティの担当をしているものです。このエントリーはOpenTelemetry Advent Calendar 2022の2日目の記事です。1日目は @katzchang の「OpenTelemetry Collectorでログファイルの更新を取り込む」でした。 さて、みなさんは分散トレースを活用しているでしょうか。分散トレースはマイクロサービスアーキテクチャのみならず、モノリスなシステムにおいてもレイテンシーのボトルネックを発見する上で有用なテレメトリーです。まだ活用されていないという方はぜひ活用していきましょう！ 分散トレースのサンプリング 活用されているみなさまにおかれましては、分散トレースの取得において、トレースのサンプリング方法について頭を悩ませていることと思います。テスト環境などではサンプリングレートを100%にして、あら

https://opentelemetry.connpass.com/event/296353/

システムの状態を監視するためのツールは多数存在していますが、その中でもSigNozはメトリクス・トレース・ログというシステム観測の3本柱に対応しており、さらに「OpenTelemetry」を利用してさまざまなアプリのデータを取得できるツールとのことなので、実際に使って試してみました。 Open source APM | SigNoz https://signoz.io/ SigNozはmacOSのほか、Linuxの下記のディストリビューションで動作するとのこと。 ・Ubuntu ・Debian ・OpenSuse ・CentOS ・SUSE Linux Enterprise Server (SLES) その他のディストリビューションにおいてもDocker経由で起動することが可能とされていますが、今回はDebianを利用して進めていきます。まずは下記のコードで各パッケージを更新しておきます。

これはOpenTelemetry Advent Calendarの14日目です。 qiita.com どんな話がいいかなと考えていたのですが、ここでは「アプリケーションとOpenTelemetry Collectorがどのように関わってメトリックを(Prometheusなどの)バックエンドサービスに送信するのか」を見ていこうと思いました。今からOpenTelemetryを触るならOpenTelemetry Collectorは実質必須なコンポーネントだと思うで、関係を把握しておくと嬉しいことがあるかもしれません。 OpenTelemetry Collectorとは何か 記憶によると、2020年頃はOpenTelemetry Collectorが存在していなかったので、過去に書いたOpenTelemetryでメトリックを記録するではアプリケーションにExporter*1を組み込んでいました。

はじめに OpenTelemetryを使ってgRPCのトレースを楽に取ろうと思うと otelgrpc を使ってよしなにリクエストのトレースを取っていることと思います。 たとえばサーバー側であれば interceptorOpt := otelgrpc.WithTracerProvider(otel.GetTracerProvider()) srv := grpc.NewServer( grpc.UnaryInterceptor(otelgrpc.UnaryServerInterceptor(interceptorOpt)), grpc.StreamInterceptor(otelgrpc.StreamServerInterceptor(interceptorOpt)), ) クライアント側であれば interceptorOpt := otelgrpc.WithTracerProvider(o

こんにちは！Google Cloudでオブザーバビリティを担当しているものです！Cloud Runでマルチコンテナーサポートがパブリックプレビューになりましたね！これはCloud Runでサイドカーを走らせられるということです！というわけで今日は1ユースケースとしてOpenTelemetry CollectorをCloud Runのサイドカーとして走らせてみようと思います。 TL;DR Cloud Runのマルチコンテナーサポートを使うと、アプリケーション側はOTLP送信の実装だけして、OpenTelemetry Collectorをサイドカーとして走らせて、テレメトリーをCloud Opsや外部のオブザーバビリティツールに送ることが可能になります。 構成 Kubernetesで使っているようなポッド内のサイドカーの構成をCloud Runでもできますよ、というだけなので、それをわかってる

こんにちは。SRE/データストアチーム の飯塚です。 私たちのチームではデータベースを代理で操作したり情報を取得したりするサービスをいくつか作り、それをプロダクトチームが利用できるように gRPC 経由で提供しています。ところで、ある日突然「分散トレーシングを活用していくことになったので、あなたのチームのサービスも対応させてください」とお願いされたらどうすればよいでしょうか？私はこれまでにいろいろなカンファレンスで分散トレーシングや OpenTelemetry についての講演を聞いていたので、理念は理解した、便利そうだ、導入してみたい、と思ったことは何度かありました。しかし実際に導入しようとして SDK のドキュメントを開いてみると、理解しなければいけない（ように見える）概念や、使い方をマスターしないといけない（ように見える）API の数に圧倒されてしまい、後回しにしてしまっていました。

OCHaCafe Season7 の LT 資料です。 https://ochacafe.connpass.com/event/282817/