ログとメトリクスと私 〜 GitLab オブザーバビリティ機能（o11y）を試してみた 〜

こんにちは。2025年も残すところあと12日となりましたが、やりのこしたMRレビューはありませんか？ Duoコードレビューでも使ってレビューをちゃちゃっと終えて、気持ち新たに新年を迎えましょう。

ところで、GitLabでひっそりとo11y機能がリリースされているのはご存知でしょうか？18.1でリリースされ、現時点ではExperimental（実験段階）の機能になり、GitLab.comまたはSelf-managedインスタンス（機能フラグ）で利用できるようになっています。

GitLab日本語ドキュメントページ
https://docs.gitlab.com/ja-jp/operations/observability/

ところで o11yって？

o11yは、Observability（可観測性）を短縮したもので、頭と末尾の文字の間に11文字あるからこのような略し方のようです。このように省略された英文字数を使った略し方を、numeronym（数字入り略語）というそうです。

Claudeさんに聞いたところ、numeronymの起源は1980年代に遡るそうで、当時のプログラマーたちが長い単語をタイプするのが面倒で、最初の文字 + 省略された文字数 + 最後の文字という形式を使い始めたのが始まりだそうです。

特に広く広まったのが i18n (Internationalization) ということで、ソフトウェア国際化の文脈で頻繁に使われたことから生まれたそうです。確かにこんなのがしょっちゅう出てきたらタイポしまくって発狂しそうです。

最近では k8s（Kubernetes）の普及もあり、この手の略語は見慣れてきました。とはいえ、初見殺し感は否めず、最初みたときは" 1 "が" l (エル)”に見えて、「オ、オーライ..？」 と読んで、しょっぱい思いをしたのはここだけの話です。

GitLab o11yを試してみる

前置き長くなりました。さて、ここから実際に試してみたいと思います。

GitLab o11yの有効化

この機能は、グループレベルで有効にできます。グループのページから「可観測性」→ 「設定」と進みます。

「有効にする」ボタンをぽちります。2025年12月時点ではExperimental（実験機能）のため、無料で利用可能です。

すぐに有効化されました。テレメトリデータ収集用のOTel （Open Telemetry）のエンドポイントが払い出されました。

テストデータ送信

続いて、ドキュメントに則り、テスト用のテレメトリデータを送信してみます。今回はrubyのテストスクリプトを使います。テレメトリデータ送信に必要なOpen Telemetryのgemを自PCにインストールします。

gem install opentelemetry-sdk opentelemetry-exporter-otlp

テストスクリプトを用意します。endpointには自グループに割り当てられたHTTP OTelエンドポイントを指定します。サービス名はtest-serviceです。

require 'opentelemetry/sdk'
require 'opentelemetry/exporter/otlp'

# OpenTelemetryの初期化
OpenTelemetry::SDK.configure do |c|
  # サービス定義
  resource = OpenTelemetry::SDK::Resources::Resource.create({
    'service.name' => 'test-service',
    'service.version' => '1.0.0',
    'deployment.environment' => 'production'
  })
  c.resource = resource

  # Configure OTLP exporter to send to GitLab O11y
  c.add_span_processor(
    OpenTelemetry::SDK::Trace::Export::BatchSpanProcessor.new(
      OpenTelemetry::Exporter::OTLP::Exporter.new(
        endpoint: 'http://12345678.otel.gitlab-o11y.com:4318/v1/traces'
      )
    )
  )
end

# トレースとスパンの作成
tracer = OpenTelemetry.tracer_provider.tracer('basic-demo')

# 親スパン
tracer.in_span('parent-operation') do |parent|
  parent.set_attribute('custom.attribute', 'test-value')
  puts "Created parent span: #{parent.context.hex_span_id}"

  # 子スパン
  tracer.in_span('child-operation') do |child|
    child.set_attribute('custom.child', 'child-value')
    puts "Created child span: #{child.context.hex_span_id}"
    sleep(1)
  end
end

puts "Waiting for export..."
sleep(5)
puts "Done!"

そして実行。

# ruby test_o11y.rb
Created parent span: 0fdc49d44a25eabf
Created child span: 8623369b4939d749
Waiting for export...
Done!

結果確認

結果を確認してみます。GitLabのUIに戻り、グループのメニューより「可観測性」→ 「サービス」へ進みます。test-serviceが登録されているのが確認できました。開いてみます。

おっ、なんかデータとれてる！

さらにデータ送信

これだけではよくわからないので、何度かテストスクリプトを実行します。子スパンの sleep(1)をsleep(rand(8))に変え、レスポンスがランダムに変化するようにします。

Latency, スループット, Apdex (Application Performance Index）といったメトリクスが収集され時系列の変化が確認できます。

各スパンごとの処理時間や

トレース全体の実行時間も確認できます。

分散トレーシングにおける「トレース」「スパン」とは

スパン、トレースなど、わかったようなそうでもない用語が出てきましたが、分散トレーシングにおける基本的な構成要素ということです。メモメモ。

OpenTelemetryにおける「トレース (Trace)」は分散システム全体のリクエストの流れ（経路）を指し、「スパン (Span)」はそのトレースを構成する個々の作業や操作の単位（最小要素）です。スパンは「名前」「開始/終了時刻」「属性（キーバリュー形式のメタデータ）」などを含み、親子関係（ネスト構造）を持つことで、HTTP呼び出しやDBアクセスなど、リクエストがシステム内をどう流れて、どこで時間がかかっているか（ボトルネック）を詳細に把握（可視化）できるようにします。

ほかにもいろいろできる、、はず。

今回は簡単なテストを通じて、GitLabにメトリクスを送ることができましたが、それ以外にもログ収集やダッシュボード、アラートシステム、CI/CDのパフォーマンス分析など包括的なオブザーバビリティ機能にアクセスできるようです。（ちなみに、GitLab o11yとして組み込まれているのはオープンソースのSigNozというツールのようです。

時間ができたら、もう少し色々試してアップデートしたいと思います。

さいごに

DevSecOpsプラットフォームであるGitLabにオブザーバビリティが組み込まれることにより、開発者は本番サービスのパフォーマンス情報へ即座にアクセスすることができ、ツールを行き来することによるコンテキストスイッチに悩まされることなく顧客体験の向上に注力できるようになります。

生まれたてで荒削り感があり、育てがいがありますので、試してみて気がついたことがあればフィードバックイシューにコメントを残していけばプロダクトチームが嬉々として返信してくれるはずです 😄

それではみなさん良いお年を！