> Source: https://www.ymotongpoo.com/works/otel-specs-ja/semconv/how-to-write-conventions/t-shaped-signals/


# T-shaped Signals

セマンティック規約は、T字型の考え方でオブザーバビリティに取り組みます。これは、シグナルを「T」の形をした2つの種類に分割するものです。

```mermaid
block-beta
        columns 3
          Broad["Broadly Applicable Signals"]:3
        columns 3
          space:1
          Deep("Rich,\nDeep\nSignals")
          space:1
```

これは80-20の法則に対応しています。ユーザー（または使用事例）の80%は広く適用可能なシグナルを活用でき、残り20%のユーザー（または使用事例）は、深いシグナルを使って問題を深く掘り下げます。

## 広く適用可能なシグナル（Broadly Applicable Signals）

これらは、ある領域全体にわたって基本的なオブザーバビリティ体験を提供することを意図した規約です。例えば、HTTP（マイクロ）サービスに対する汎用的なダッシュボード化、アラート、診断を可能にするHTTPセマンティック規約が挙げられます。これらのシグナルは、オブザーバビリティに対して「水平的な」カバレッジを提供すべきです。

例は次のとおりです。

- Golden Signals / REDメトリクス（Saturation、Rate、Error、Duration）
- 高レベルのスパン
- エラーログ、クラッシュレポート
- リクエスト・レスポンスのログ

## リッチで深いシグナル（Rich, Deep Signals）

これらは、特定のシステム、ライブラリ、モジュール、アプリケーション、サービスについて深い理解を提供することを意図した規約です。これらは、そのシステムに固有の問題を診断するために使われます。

例は次のとおりです。

- Linuxのslabメモリ使用量
- 特定のデータベースに関するシグナル（MySQLのインデックス使用状況など）
- 言語固有のガベージコレクションメトリクス（JVM、Go、.NETなど）

## 推奨事項

セマンティック規約を定義することは、広く適用可能なシグナルを生成することと、特定の技術に対するリッチなオブザーバビリティを確保することの間のバランスです。特定の領域については、まず*広い*使用事例とシグナルから始めることが推奨されます。その領域に対する基本的なシグナルの集合を提供した後、ベンダーや実装に固有の、より深い統合を検討してください。

例えば、[データベースのセマンティック規約](/works/otel-specs-ja/semconv/db/)では、データベースとの通信に関するスパンの汎用的なガイダンスがあり、さらに、その汎用ガイダンスの拡張として、データベース固有のガイダンスもあります。