メタデータによるオブザーバビリティの向上

　メタデータは情報技術のいたるところに存在します。コンピューターシステムでの「メタデータ」についての最初の記述は、1967年にMITのDavid Griffel氏とStuart McIntosh氏が記したとされています。当初、メタデータの主な目的は、棚上のパンチカードやテープからデータの物理的な場所を見つけることであり、その後、デジタル技術の進歩に伴い、ディスクドライブやフォルダーにデータが保存されるようになりました。

　制限がほとんどないテレメトリーデータベースにおいては、物理的配置の詳細はユーザーにとってさほどの重要性を持ちません。その代わり、メタデータが物理的な構造を論理的なグループ化 —例えば、アカウントIDや名前で区別される環境（QA、DEV、Prodなど）— に置き換える役割を果たします。

　本質的に、テレメトリーデータは単なる数字の羅列です。カウントや大きさを表すものもあれば、OK、PASS、FAILなどの条件を示す定性的な文字列を表す場合もあります。1時間前よりも高い値もあれば、低い値もあります。これが、New Relicの構成要素である時系列データの特徴です。類似グループと非類似グループを比較対照して、テレメトリーデータを分析する能力がなければ、情報やデータに基づく意思決定を行うことは不可能です。最上位レベルでは、New Relicの標準エージェントはすべて、少なくとも共通のアプリケーション名とIDでテレメトリーをグループ化します。これは現代のオブザーバビリティにとって必要ですが、十分ではありません。

　このブログでは、メタデータがどのように役立つのか、New Relicでメタデータを管理する方法、エンティティメタデータのシンプルな標準がどのようなものなのかを説明します。

メタデータが必要な理由

最上位レベルのメタデータでは以下のことが行えます。

• 対象の特性を知っているが、関連するエンティティやレコードをすべて知っているわけではない（あるいは、1つの大きなセットとして分析するには数が多すぎる）場合に、エンティティとテレメトリーを検索する
• 対象の特性ごとにエンティティとテレメトリーを可視化する。グループの相対的な大きさを確認し、グループの大きさが適切でないと思われる場合に異常を視覚化できる
• 関連するエンティティのタグに基づいてワークフローを振り分けし、対応する
• アクティビティを計画し、さまざまなエンティティのコンプライアンスを評価する（たとえば、チームのすべてのサーバーが最新のLinuxバージョンにアップグレードされていることを確認する）
• ビジネスと組織の高レベルのKPIを報告し、ビジネスのどの分野で成功しているのか、あるいは改善が必要なのかを把握する

タグを使った実際のオブザーバビリティのユースケースの一例として、あるアプリケーションが突然大量のエラーが発生していることに気づくシナリオを紹介します。適切なタグを持つインシデントがワークフローがすでにセットアップされているかもしれません。

• このエンティティを所有しているチーム（必要に応じて連絡を取ること）
• コードリポジトリの管理者は誰か（インシデント対応のトークルームに招待する）
• 影響を受ける運用リージョン（ビジネスに及ぼす影響のトリアージ、リージョンに設定されたSLA/コンプライアンス）
• 影響を受ける事業部門（ビジネスに及ぼす影響のトリアージ、1時間あたりのインシデントコスト）

アプローチ 1：エンティティ組織のタグ付け

タグは、場合によっては、以下のソースからエンティティに自動適用されます。

• アカウントのメタデータ
• New Relicエージェントのコンテキスト
• OpenTelemetryエージェントのコンテキスト
• インフラエージェントのコンテキスト

New Relicでタグを表示および操作するには、いくつかの方法があります。最も簡単な方法は、APMなどのプレビルドされたビューの 1 つで、タグアイコンをクリックすることです。このアイコンには、関連付けられているタグの数も表示されます。

すべてのタグを表示したり、手動でタグを追加したりすることもできます。

より全体的なビューを表示するには、エンティティエクスプローラを使用して、エンティティ別に、フィルタリングおよびグループ化することができます。

APMのような標準的なエンティティタイプでは、New Relicのクエリ言語（NRQL）のクエリにタグを組み込むことが可能です。この結果、データの整理と分析を同時に実施できます。例えば、以下のクエリでは、特定のチームに関連するトランザクションエラーの数を表示することができます。NRQLで利用可能なタグには、先頭に「tags」が付いています。

FROM TransactionError select count(*) facet tags.Team

結果は、他の属性ファセットと同様に表示されます。

タグの最も価値のある用途の1つは、言うまでもなく、データをより実用的なものにすることです。上に示したように、インシデントや問題を「グルーピング」するというアイデアは、コードの管理者や問題への対処方法について一定の知識があれば、より効果的に行うことができます。

ほとんどのチームは、チーム名と環境をタグ付けして終わりですが、「help-channel」のタグなどのコンテキストを追加できない理由はありません。

これらのタグを可視化するだけでなく、New Relicのインシデントワークフローの一部としてインシデントペイロードに含めることができます。タグの様々な使い方について詳しくは、ドキュメントをご覧ください。

アプローチ 2：動的な分析のためのカスタム属性

タグはエンティティ中心の設定されるため、テレメトリーデータのレコード間で必要な細かな違いを表現できません。テレメトリーの個々の単位を動的に分類する必要がある場合、カスタム属性を検討しましょう。カスタム属性は、ユーザー体験固有の特性や、特定のリクエストに対する、特定の時点でのアプリケーションやシステムの「状態」をキャプチャするためによく使用されます。動的な状態の情報の例としては、以下があります。

• ユーザーコンテキスト
  • ユーザーID
  • ユーザーの位置
  • その他のユーザー属性情報（BasicとPro）
• リクエストコンテキスト
  • 使用されている製品またはサブ製品
  • 製品の種類
    • 保険契約の種類（バイク、自動車、RV）
    • ストリーミングビデオの種類（SF、コメディなど）
    • ユーザー端末の詳細情報（Androidバージョンなど）

カスタム属性は、メタデータのニーズに対する素晴らしいソリューションですが、いくつかの欠点に注意が必要です。

• これらの管理は一元化されておらず、コードレベルで行われる
• 多くの時代遅れの属性が蓄積されることがよくある
• 属性が追加されるごとに、テレメトリーの取り込みコストが発生する
• 多重度が非常に高い属性は、クエリのパフォーマンスに問題や影響を及ぼす可能性がある
• アカウントの制限（たとえば、アプリが行うリクエストごとに一意のIDを作成することは持続可能ではない）

New Relic APM、Browser、モバイルエージェントはすべて、カスタム属性を挿入する機能が組み込まれています。詳細は、ドキュメントをご覧ください。

アプローチ 3：特定の目的のための分析に利用するLookup Table

　計装時に有用なメタ情報をすべて把握するのは、ほぼ不可能です。多くのメタデータはプロジェクトのライフサイクルの関連で一時的に使用されるケースがあります。場合によっては、主に特定の目的のための分析に使用される何十ものタグや属性に対して、メタデータの標準化を実施するオーバーヘッドは望ましくありません。

　New Relicではこれに対する解決策があります。CSVファイルをLookup Tableとして、New Relicにアップロードできます。このCSVは、他のテレメトリーのネームスペース（Log、Transaction、SystemSampleなど）と同様に使用できます。NRQLのJOIN構文を使用すると、共通キーがあると仮定して、CSV内のあらゆるものを既存のテレメトリーに関連付けることができます。つまり、1つか2つの非常に高レベルなメタデータ要素を設定しさえすれば、必要に応じてアドホックな検索を関連付けることができます。

　実例として、組織全体でAPP_IDタグを使用している顧客がいます。このタグは、APMからインフラ、AWSストリーミングメトリクスまで、あらゆるものに使用されます。このコンテキストではAPP_IDは、「在庫管理」のような論理的なビジネスサービスを構成するすべての関連アプリケーションとインフラストラクチャを指す、より論理的な概念です。これは特にプロジェクトの追跡に役立ちます。

組織に、一部のアプリのクラウド移行ステータスを追跡する「migration_status」というCSVファイルがあるとしましょう。

以下のNRQLを使えば、Lookup Tableの内容を表示できます。

FROM lookup(migration_status) SELECT *

APP_IDという最低限のタグを設定すれば、移行したホストを所有するチームに関連する、詳細なレポートを作成することができます。

FROM SystemSample
JOIN (FROM lookup(migration_status)SELECT count(*) WHERE MIGRATED = 'Yes' FACET APP_ID, TEAM LIMIT MAX)
ON APP_ID
SELECT uniqueCount(hostname) as 'チーム別に移行したホスト数' WHERE APP_ID is NOT NULL FACET TEAM  since 1 week ago

標準的なメタデータの例

この簡単な5つのタグ付けの「標準」は、多くの組織でオブザーバビリティに使用されている様々なアプローチを抽出したものです。これを変更し、大幅に拡張する可能性がありますが、組織におけるメタデータの価値を実証するために使用できる、かなり軽量なタグのセットを表しています。