ログ設計ガイドライン
免責事項 有志で作成したドキュメントである。フューチャーには多様なプロジェクトが存在し、それぞれの状況に合わせて工夫された開発プロセスや高度な開発支援環境が存在する。本ガイドラインはフューチャーの全ての部署／プロジェクトで適用されているわけではなく、有志が観点を持ち寄って新たに整理したものである相容れない部分があればその領域を書き換えて利用することを想定している。プロジェクト固有の背景や要件への配慮は、ガイドライン利用者が最終的に判断すること。本ガイドラインに必ず従うことは求めておらず、設計案の提示と、それらの評価観点を利用者に提供することを主目的としている掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとする。掲載している情報は予告なく変更する場合がある 対象スコープアプリケーションが出力するログ（アプリログ）が対象AWS
はじめにTechnology Innovation Groupの八木です。 フューチャー社内の有志メンバーでログ設計ガイドラインを作成し公開しました！ ログは、システムの稼働状況を可視化し、トラブルが発生した際に迅速に原因特定するための生命線になります。しかし、その重要性の一方で、プロジェクトごとに設計がバラバラになりがちだったり、とりあえず標準出力しているだけになっていたりと、十分に活用しきれていないケースも多く見受けられます。 本記事では、今回公開したログ設計ガイドラインの背景や、現場で役立つ設計のポイントを抜粋してご紹介します。 ガイドライン作成のモチベーションこれまで、ログ設計は個々のエンジニアの経験則や、プロジェクトごとの慣習に委ねられることが多くありました。しかし、システムが複雑化し、マイクロサービスやクラウドネイティブな構成が当たり前になった現代において、ログの役割は「単なる
5年後には標準になっている可観測性のこと - Learning Opentelemetry の読書感想文 - じゃあ、おうちで学べる
はじめに 本稿は、オープンソースの可観測性(Observability)プロジェクトである OpenTelemetry を取り上げた書籍「Learning Opentelemetry」の読書感想文です。従来の可観測性の課題であったデータの分断を解消し、トレース、メトリクス、ログなどの様々なテレメトリデータを統合的に扱うことができる OpenTelemetry は、可観測性の分野における革命的な存在と言えます。 過去10年間で、可観測性はニッチな分野から、クラウドネイティブの世界のあらゆる部分に影響を与える数十億ドル規模の産業へと発展しました。しかし、効果的な可観測性の鍵は、高品質のテレメトリデータにあります。OpenTelemetryは、このデータを提供し、次世代の可観測性ツールと実践を開始することを目的としたプロジェクトです。 learning.oreilly.com 本書の想定読者は、
オブザーバビリティ入門: OpenTelemetryについて知っておくべきこと - joker1007’s diary
自分が在籍している会社でKafkaを利用したマイクロサービスが増えてきているので、昔からオブザーバビリティの向上というものにちゃんと着手したかったのだが、最近になってやっと手を動かせる所まで優先度を上げられた。 という訳で、ここしばらくは社内にあるマイクロサービス群にOpenTelemetryによる計装を入れまくっている訳だが、大分可視化が進んできたので、これを社内のメンバーに周知しなければならない。 とは言え、説明したい内容が余りに一般的な知識なので、社内向けのクローズドなドキュメントとして書くのは勿体無いので、オープンなブログの方にまとめることにする。 (会社のテックブログに書いた方がいいのではという話はあるが、仕事っぽくなると面倒臭い……) 基本的にはOpenTelemetryの公式ドキュメントを自分なりに解釈して要点を絞る、という形で解説していくつもりなので、公式ドキュメントは一通
AI を導入したら、逆に「何が起きてるか分からない」が増えた Claude Code を使い始めて数週間。生産性は確かに上がった。でも、こんな場面が増えた。 「なんか遅いな……」→ 何が遅いのか分からない Bash を 10 回連続で叩いてる → なぜそんなに必要なのか追えない サブエージェントが勝手に動いてる → いつ終わるのか読めない エラーで止まった → どの段階で詰まったのか分からない Web サービスなら、こういう「見えない」は OpenTelemetry（OTel） で解決する。リクエストのトレース、レイテンシの分布、エラー率——全部可視化できる。 じゃあ、AI エージェントにも同じことをやってみよう。 この記事では、Claude Code の実セッションログ（1 日・130 回のツール呼び出し）を OTel トレースに変換し、Jaeger で可視化した全記録を公開する。 準備
監視 やばい
yabaibuki.dev #5の登壇資料です https://livesense.connpass.com/event/349898/
社員に何もさせずにClaude Code利用ログを集める ── 数百名規模のOpenTelemetry収集基盤の構築 - ZOZO TECH BLOG
こんにちは、技術戦略部CTOブロックの塩崎です。 当社ZOZOには1人あたり月額200ドルの基準のもと、Claude CodeやGemini CLIをはじめとした各種AI開発ツールを利用可能にする制度を2025年7月にスタートさせました。 corp.zozo.com 現在ではこの制度を用いて数百名という非常に多くの社員がClaude Codeを利用しています。このような中で組織全体のAI活用を推進するためには、それぞれの社員や部署のClaude Codeの利用状況をモニタリングすることが重要です。そのためにClaude CodeのOpenTelemetry機能を利用して、全社員のClaude Code利用状況を収集したので、本記事ではその手法を紹介します。 ccusageを使った利用情報の収集の課題 Claude CodeのOTel機能の紹介 作ったものの全体像紹介 利用情報を送信する部分
CLIを書いてるなら、まずOTLPでtracesとeventsを吐けるようにするのがオススメ - Kengo's blog
とりあえず他の人に説明するのに良さそうなので、ChatGPTに書かせた記事です。 Agentic CodingでCLIを実装していると、機能要件がどんどん進められる反面、非機能要件がないがしろになりがちです。自分は最近静的解析CLIを育てているのですが、OpenTelemetryでtracesとeventsをexportできるようにしました。結果として「どこで遅いか」「どの実装が遅いか」を事実として掴めるようになり、最適化を迷わず打てるようになりました。さらにJargerを使えばスクリーンショットやJSONとして結果を取得できるため、人間はもちろんCoding Agentにとっても計測と改善のループを回しやすくなります。 traces（Span）とは CLIの処理を「区間」に分けて、spanとして刻みます。例えば： 引数解析 入力列挙（ファイル探索など） 入力の読み込み 処理実行（処理ごと
GitHub Actionsを可視化するGitHub Actions OpenTelemetryの紹介 - ともにかける
GitHub Actionsはワークフロー全体の実行時間や各ステップの詳細な可視化、変更による効果測定を行うには工夫が必要となります。この記事では、OpenTelemetryを活用してGitHub Actionsの実行結果をトレースとメトリクスの形で収集するGitHub Actions OpenTelemetryを紹介します。どのステップに時間がかかっているのか、改善施策の効果がどの程度あったのかを把握しやすくなるため、ワークフローの継続的な改善を目指す方に役立ちます。 Trace Sample (Jaeger) 1. GitHub Actionsにおける課題 1-1. ワークフローの詳細を可視化する方法が提供されていない 1-2. ワークフローの変更による影響を分析しづらい 2. GitHub Actions OpenTelemetryとは 2-1. 概要と主な機能 2-2. OpenT
この記事は2024年3月に書かれたものです。この警告を記載している2025年3月現在、筆者のオブザーバビリティバックエンドの評価軸はかなり変わりました。 筆者が暇なら書き直したいのですが、あいにくその時間的コストは払えないためそのまま残しています。 依然として筆者にとってHoneycombがほかとは一線を画する最強であることには2025年現在も変わりがありませんし、お読みいただくことに一定価値があるとは思いますが、評価の一部が現在の筆者にとって無意味となっていることだけ明記しておきます。 背景 2024年現在、OpenTelemetryが盛り上がっており、ベンダへの依存度を下げてテレメトリを収集・送信することがトレンドになってきているように思います。多くの企業様で、OpenTelemetry対応のオブザーバビリティバックエンドを選定されているのではないでしょうか。 一方で、E2E自動テスト
作ってわかるOpenTelemetryのゼロコード計装 Go言語eBPF編 - Mackerel ブログ #mackerelio
OpenTelemetryではeBPFという技術を用いることで、Go言語でできたアプリケーションのコードを変更せずに観測可能にすることができます。本記事では、その手法と仕組みについて実際にコードを書きながら解説します。 こんにちは。Mackerelチームでアルバイトをしているエンジニアの id:appare45 です。本記事ではOpenTelemetryのゼロコード計装を、Go言語でできたアプリケーションに対してeBPFを用いて実現する方法について、実際に実装しながら解説していきます。 ゼロコード計装とは eBPFとは Go言語でeBPFプログラムを書く 関数の実行開始と終了を記録する uretprobeを使わずに関数の終了を知る Goroutineを追う Mackerelへトレースを投稿する 引数の値を取得する eBPFを用いたGo言語のゼロコード計装のまとめ Appendix: 環境構
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
はじめに OpenTelemetryは、計装を通じてオブザーバビリティを向上させるためのツールです。 OpenTelemetryで計装を行うと、収集したデータはOpenTelemetry Collectorやバックエンド（MackerelやJaeger）に送信されます。 送信されるメトリックやトレースなどのデータは、まとめてシグナルと呼ばれます。 OpenTelemetryの計装は簡単ですが、シグナルを深く理解することで、OpenTelemetryをより効果的に活用できるようになります。 この記事では、Mackerelチームでアプリケーションエンジニアをしている id:mrasu が、OpenTelemetryのシグナルについてProtocol Buffersの定義と計装を深堀りしていきます。 はじめに シグナルの送信 Protocol Buffersでの定義 Protocol Buffe
ISUCON 14: ClickHouse と OpenTelemetry で ISUCON の計測環境を作ったら快適だった - Unyablog.
ISUCON 14 に id:utgwkk, id:wass80 と「ミレニアムサイエンススクール」というチーム名で参加した。 結果は 28875 点で 22 位！去年は fail して最下位だったので反省を活かすことができたのでは？ 一昨年に Kibana / Elasticsearch / Filebeat で解析環境を組んでサクセスしていたが、今年は OpenTelemetry (Otel) をベースにモニタリング環境を作り直し、バックエンドは ClickHouse、フロントは Grafana の構成でやってみた。これがなかなか良かったので紹介。 コンテスト当日のアプリ改善周りは utgwkk の記事を見てください。 blog.utgw.net 序: ISUCON で必要な計測 ISUCON ではパフォーマンスを継続的に確認してボトルネックを探しながら改善していくのが王道ルート。 イ
こんにちは・こんばんは・おはようございます、エンジニアのid:aerealです。 この記事では筆者が開発に参加しているサービスの監視フレームワークをOpenTelemetryへ移行した際の体験を紹介します。 OpenTelemetryとは OpenTelemetry is an Observability framework and toolkit designed to create and manage telemetry data such as traces, metrics, and logs. What is OpenTelemetry? サイトの説明にある通り分散トレースやメトリクス、ログなどの指標を扱う監視フレームワークです。 OpenTracingやOpenCensusなどを継承・統合したプロジェクトと言うと合点がいく方も多いのではないでしょうか。 OpenTelemet
Claude Codeには OpenTelemetry (OTel) のサポートがある。 これを使ってログやメトリクスを収集し、さくらのクラウドの「モニタリングスイート」に送信する試みをした。 Claude CodeのOpenTelemetry設定 otel-collectorで受ける otel-collectorからモニタリングスイートへ送る メトリクスの設定 ログの設定 さらにHooksも メトリクス可視化 まとめ Claude CodeのOpenTelemetry設定 ほぼすべてのことがここに書いてある。 docs.anthropic.com 最も簡単には、以下の設定を .claude/settings.local.json などに書けば確認できる。 { "env": { "CLAUDE_CODE_ENABLE_TELEMETRY": "1", "OTEL_LOGS_EXPORTER
OpenTelemetry Meetup #3 2024-06 登壇資料 https://opentelemetry.connpass.com/event/317170/
Jagu'e'r オブザーバビリティ分科会 Meetup #3 https://jaguer-o11y-sre.connpass.com/event/359593/
Claude Codeの利用統計の可視化ツールとしてccusageが有名ですが、リモートサーバなど複数の環境で利用している場合では、それぞれの環境ごとにしか集計することができません。私の場合は手元のラップトップに始まり、Kaggleなどのデータコンペ用のGPUサーバやProxmoxで構築した各種開発環境などがいくつもあります。それらを横断してClaude Codeの利用統計を見る必要がありました。 Claude Codeには、標準でOpenTelemetryによるテレメトリ送信機能が実装されています。これを使うことで、自前のサーバにメトリクス・ログを集約し、複数環境の利用統計を一元管理できるようになります。単なる利用コストの確認のみならず、利用モデルの確認などにも使えて、とても便利です。 この記事では、Claude CodeのOpenTelemetryによる利用統計の集約および可視化までの
AWS監視の効率とコストを最適化：OTel 1.0形式（Protobuf）サポート開始 AWS CloudWatch Metric Streams連携における、高効率なProtobuf（OTel 1.0）形式への移行手順と、JSON（OTel 0.7）形式とのGZIP圧縮効率の技術的な違いを解説します。 1. AWS OTEL 1.0（Protobuf）形式に正式対応 多くのお客様が、AWS環境のオブザーバビリティを担保するために、New RelicとAWS CloudWatch Metric Streamsを連携させています。 しかし、監視対象のAWSリソースが増加するにつれ、CloudWatchからNew Relicへ転送されるメトリクスデータの量もまた増大します。特に、従来の opentelemetry0.7（JSONベース）形式ではデータサイズが大きくなりがちで、データ転送コストや
DMARC レポートを Mackerel + OpenTelemetry でいい感じに可視化する - 作成に至るまで - Hatena Developer Blog
はてなのシステムプラットフォームチーム (以下シスプラ) で SRE として働いている id:KashEight です。社会人 2 年目です。 この記事は、はてなの SRE が毎月交代で書いているSRE連載の 4 月号です。3 月の記事は id:onk さんのはてなの「PWG」という取り組みを builderscon 2024 で話してきましたです。 この記事では DMARC レポートを自社サービスである Mackerel、オブザーバビリティデータをいい感じに扱うためのプロジェクトである OpenTelemetry を用いて可視化した話の導入編となります。 文量の都合上、実際の実装やサービス提供の話は次の SRE 連載に回します。 DMARC、DMARC レポート 今までの運用 問題点 Mackerel 化するに至るまで とある改善要望 使用用途のヒアリング ニーズから考えてみる Open
OpenTelemetryプロジェクトが日本のコミュニティに注目している話 - YAMAGUCHI::weblog
はじめに こんにちは、AWSのデベロッパーアドボケイトをしているものです。本来であれば昨日投稿されるはずだったOpenTelemetryアドベントカレンダーの24日目の記事です。本当はここにここ1週間くらい完全にAIアシスタントに設計から実装までやらせたデモについて書きたかったんですが、現時点で重大な問題に対応できてない*1ので、かわりにこの記事ではOpenTelemetryプロジェクトが日本のコミュニティに注目しているという話をします。 TL;DR いままさに日本のユーザーが注目されています。ぜひこれらの投稿にリアクション（フォームへの回答や返信）をください！ www.linkedin.com www.linkedin.com なぜ日本なのか そもそも世界各国ある中で、なぜ日本のコミュニティが注目されているのか、というと単純に日本のコミュニティやユーザーに次のような特徴があるからです。
CloudNative Days Summer 2025 Datadog Sponsor Session https://event.cloudnativedays.jp/cnds2025
さくらインターネットの藤原です。今回はモニタリングとOpenTelemetryの話をします。 私は2011年から2024年まで14年間、面白法人カヤックというところにおりました。最後の方はSREをやってました。そして2025年2月にさくらインターネットに入りまして、主にIaaS基盤開発を担当しています。それからISUCONで何度か優勝や出題をしたことがあります。それに関連して、Webパフォーマンスチューニングの本も共著で書いています。OSSの開発もしていて、カヤックにいたときにAmazon ECSのデプロイツールであるecspressoというものを作って結構使われたり、AWS Lambdaのデプロイツールであるlambrollを作ってたりしました。最近はさくらのAppRunのデプロイツールも作っています。趣味はランニングで、今朝も10kmぐらい走ってきました。北海道は涼しくていいですね。
OpenTelemetry+Go 計装サンプル大全 with Cloud Trace ~意外なつまづきポイントを添えて~
はじめに こんにちは。クラウドエース株式会社で主にアプリケーション開発を担当している水野です。 今回は、Go 言語でトレース計装する際のサンプル集をご紹介します。 OpenTelemetry は、アプリケーションのオブザーバビリティを実現するための OSS です。 対象読者 手動計装は、アプリケーションコードを煩雑化してしまう可能性もあるため 「できるだけ最小限な構成で手軽に導入したい」という方もいると思います。 そんな方に すぐ活用できる！ような記事となっています。 使用技術 Golang OpenTelemetry Google Cloud Cloud Trace Cloud Logging Cloud Pub/Sub Cloud SQL 方針 アプリケーション実装は最小限にする（ライブラリの力をできるだけ借りる） 計装箇所 API (incoming, outgoing) http
大規模システムへの OpenTelemetry Collector 導入の勘所と OpAMP に見る未来 / getting-started-opentelemetry-collector-with-opamp
CloudNative Days Winter 2024 の登壇スライドです。 https://event.cloudnativedays.jp/cndw2024/talks/2440
OpenTelemetry入門
分散かつ複雑化するアプリケーションの内部動作を把握するためには、伝統的なメトリクスによるモニタリングやログの egrep だけでは不十分です。 オブサーバビリティの概念を取り入れ、予見しない状態に変化したときにもアプリケーションの内部動作を把握し、早急な回復を行う準備を整えることが求められます。 オブサーバビリティを実現する方法は多くありますが、その中でも OpenTelemetry はオープンソースでベンダー非依存のプロジェクトとして注目されています。 この本は OpenTelemetry をこれから始めるエンジニアに向けて、基礎を学ぶ入門書として活用していただくたい思いで執筆しました。 この本で書く内容は OpenTelemetry の基本となっています。詳しく知りたい方は公式ドキュメントを参照してください。 https://opentelemetry.io/docs/
Deno v2.2 でビルドインの OpenTelemetry サポートが追加されました。アプリケーションのコードに変更を加えることなく、Deno のビルトイン API から自動的にテレメトリーデータを計装できるようになります。 Deno v2.2 でビルドインの OpenTelemetry サポートが追加されました。OpenTelemetry は分散トレーシングのためのオープンソースの規格です。OpenTelemetry の規格に従うことで、トレース・メトリクス・ログなどのテレメトリーデータをベンダーやツールにとらわれずに収集・エクスポートできるようになります。 一般的に OpenTelemetry を使用してテレメトリーデータを計装するにはプログラミング言語ごとに用意されている SDK を使用します。Deno のビルドイン OpenTelemetry サポートは、追加の SDK のイン
少し前に比べるとだいぶOpenTelemetry界隈もにぎやかになってきたなーと感じる今日この頃です。私も２年ほど前からコントリビュートしたりブログ記事を書いたりしていましたが、どこかで同期的に開催されるイベントにも参加したいなーと思っています。 さて、皆さんは普段アプリケーションを計装したり計装用のライブラリを書く際は、ローカルでの動作確認をどのように行っているでしょうか？ 自身の観測範囲内ではローカルでjaegerやGrafanaなどを上げている人が多い印象ですが、今回新たな方法としてターミナル上でOpenTelemetryを閲覧できる自作ツール「otel-tui」をご紹介できればと思います。 なお、今回の記事では使い方などユーザー向けの内容となっているので、実装周りの詳細については下記のブログ記事をご参照ください。 モチベーション ローカルでの開発に「ちょうど良い」ツールがほしかった
OTel meets Wasm: プラグイン機構としてのWebAssemblyから見る次世代のObservability
OpenTelemetry (OTel) Collectorは、テレメトリーデータの受信、処理、エクスポートを行うベンダー非依存の実装です。これにより、個別のエージェントを導入せずに、さまざまなサービスに対応できます。公式が提供するバイナリには、最低限の機能を持つ「core」と、コミュニティ提供の機能を…
GitHub - open-telemetry/opentelemetry-go-instrumentation: OpenTelemetry Auto Instrumentation using eBPF
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Project announcement by OpenTelemetry maintainers In 2023, OpenTelemetry announced that it achieved stability for logs, metrics, and traces. While this was our initial goal at the formation of the project, fulfilling our vision of enabling built-in observability for cloud native applications requires us to continue evolving with the community. This year, we’re proud to announce that exactly two ye
OpenTelemetryで環境ごとにObservability Backend（Jaeger、Datadog）を切り替えてエンジョイしてみたよ - Timee Product Team Blog
こんにちは！ タイミーでPlatform Engineerをしている @MoneyForest です。 こちらは Timee Product Advent Calendar 2024 の10日目の記事です。 2024年8月に入社して、幸いにもチームメンバーにも恵まれて楽しく働いています。 個人的にキャッチアップがあまりできていなかった OpenTelemetry を題材にして実装をしてみたので、ここから得られた気づきや知見を共有したいと思います。 はじめに アプリケーションの可観測性（Observability）を担保する上で、APM(Application Performance Monitoring)は重要です。 現在、JaegerやPrometheusのような非商用のものから、DatadogやNew RelicやSplunkなど様々なAPMを利用できるツールが存在します。（本記事では
本記事執筆時点のopentelemetry-go-instrumentationはWork in Progress(v0.8.0-alpha)となっています。その後大きく変わっている可能性にご注意を。 自動計装とは？OpenTelemetryを中心とした分散トレーシングでは、Contextを伝播したりMetrics, Logs, Tracesを出力したりするための計装(Instrumentation)をアプリケーションに施す必要があります。この作業はアプリケーションに手を加える必要があり手間です。そこで計装を自動化する、つまりアプリケーションのコードに手を加えずに実現する方法がJavaなどで実現されています1。 しかしGoはJavaやPythonなどとは違って、マシンコードにネイティブにコンパイルされます。そのため実行時にコードを追加することができません。少なくとも自分はGoでの自動計装は
概要 本記事では、OpenTelemetry 日本語化プロジェクトにより気軽に参加するために、より具体的な手順について解説していきます。 自身が、OpenTelemetry 日本語化プロジェクトに参加して、コントリビューション関連のページの翻訳と DRIFTED files（後述）の更新を一通り終えた後の経験をもとに作成しました。 より多くの人に関わってもらいたので記事を作成しました。 先に読んでおいた方が良いコンテンツ 先に次の 2 のコンテンツを読みましょう。 コントリビューション OpenTelemetry 公式ドキュメントが公開している、ドキュメントにコントリビュートするガイドラインが一通り記載されています 特にサイトのローカリゼーションを読みましょう ほかのページもすべて翻訳済みまたは翻訳中です。 OpenTelemetry の公式ドキュメント日本語化プロジェクトのメンバーを募集
Building Observability Infrastructure with OpenTelemetry and SaaS
Building Observability Infrastructure with OpenTelemetry and SaaS
GitHub - uptrace/uptrace: Open source APM: OpenTelemetry traces, metrics, and logs
Uptrace is an open source APM that supports distributed tracing, metrics, and logs. You can use it to monitor applications and troubleshoot issues. Uptrace comes with an intuitive query builder, rich dashboards, alerting rules, notifications, and integrations for most languages and frameworks. Uptrace can process billions of spans and metrics on a single server and allows you to monitor your appli
さくらのクラウド モニタリングスイート専用OpenTelemetry Collector exporterを作りました
さくらのクラウドで提供しているモニタリングスイート向けに OpenTelemetry Collector (otelcol) 用のエクスポーターを開発し、sacloud-otel-collector v0.5.0 に同梱してリリースしました。 sacloud-otel-collectorはOpenTelemetry Collectorのカスタムビルド版で、さくらのクラウド上で利用するのに便利なコンポーネントを組み込んで配布しています。 さくらのモニタリングスイートに対しては、ログとトレースはOTLP(OpenTelemetry Protocol)で、メトリクスはPrometheus Remote Write Protocolで送信できます。そのため、これまではotlpexporterとprometheusremotewriteexporterを利用する方法を案内していました。 今回、さくら
23 tasks | 11 languages | 14 models | 14% pass rate | Updated 16 Jan 2026 | QuesmaOrg/otel-bench Distributed tracing requires stitching together distinct user journeys across complex microservices, rather than just writing isolated functions. We tested whether top models can successfully instrument applications with OpenTelemetry to see if they are actually ready to handle real-world Site Reliabil
OpenTelemetry Metricsを手軽に投稿できるCLIツールotlcのv0.2.0をリリースしました - Diary of a Perpetual Student
blog.arthur1.dev でご紹介した、OpenTelemetry Metricsを手軽に投稿できるCLIツール「otlc」のv0.2.0をリリースしたので再度ご紹介します。 github.com 使い方 インストール (macOS, Linux)×(x86_64, arm64)向けのバイナリをGitHubのReleaseで配布しています。 Homebrewをお使いの方は以下のコマンド1つでインストールが可能です。 $ brew install Arthur1/tap/otlc $ otlc --version otlc is a Command-line Tool to Export Telemetry by OTLP (OpenTelemetry Protocol). Version: unknown Go version: go1.22.4 Arch: arm64 go in
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ログ設計ガイドラインを公開しました | フューチャー技術ブログ
Claude Codeの動きをOpenTelemetryで可視化したら「何してたか分からない」が消えた
【OpenTelemetry】オブザーバビリティバックエンド8種食べ比べ
GitHub - nginxinc/nginx-otel
OpenTelemetryは何を送信しているのか - Mackerel ブログ #mackerelio
実践OpenTelemetry - Classi開発者ブログ
Claude Codeのログとメトリクスをさくらのクラウド「モニタリングスイート」に送る - すぎゃーんメモ
feature flag と OpenTelemetry
OpenTelemetry の Log を使いこなそう
複数環境でのClaude Code利用統計をOpenTelemetryで一元管理する
AWS監視の効率とコストを最適化：OTel 1.0形式（Protobuf）サポート開始
スタートアップ創業期を支えるオブザーバビリティ基盤のこれまでとこれから
さくらのIaaS基盤のモニタリングとOpenTelemetry | さくらのナレッジ
Deno v2.2 で追加されたビルドイン OpenTelemetry サポートを試してみる
ターミナルでOpenTelemetryのトレースを閲覧できるツール「otel-tui」を作りました
OpenTelemetry announces support for profiling
eBPFを使ったOpenTelemetryのGo自動計装ライブラリを調べる
OpenTelemetryの 公式ドキュメント日本語化プロジェクトにコミットする一連の流れ
OTelBench - OpenTelemetry AI Benchmark
qiita.com/sen-ltd
hizasupple-labo.com
catc.hatenablog.jp
www.smartnews.com
www.nikkei.com
www.sankei.com