T-shaped Signals

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

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など）

推奨事項

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

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