ファセット

概要

ファセットは、ログインデックスに入ったログのタグや属性のうち分析に使うものとして登録した目印です。値の種類を数える定性的なファセットと、値の大きさを測る定量的なメジャーの二種類があり、メジャーには時間や大きさの単位を設定できます。ファセットが無くても検索や加工は動くため、役割は入力補完と集計の選択肢に名前を出すことです。作成後は以降のログから中身が埋まり、過去のログには遡りません。増やす前に既存のものを探し、名前が揃っていない場合は別名の設定で標準のものへ寄せるのが基本の作法です。

検索を速くするための目印

ファセット (Facet) は、ログインデックス に入ったログのタグや属性のうち、分析に使うものとして登録した目印です。登録しておくと Log Explorer での絞り込み、ログの型の洗い出し、件数や平均値の集計に使えるようになり、ログを条件にしたモニター、ダッシュボードのウィジェット、ノートブックからも扱えます。ここで押さえておきたいのは、ファセットが検索の必須条件ではないことです。ログの加工、流れているログの確認、Log Explorer での検索、ログからのメトリクス生成、保管先への転送とその読み直し、フィルタによる振り分けや除外は、ファセットが無くても動きます。ファセットが効くのは入力補完で、候補として名前が出てくるかどうかが変わります。届いているログに一致する条件なら、登録していなくても入力すれば検索できます。つまりファセットは、調査のたびに属性名を思い出す手間を省くための目印です。よく使う属性に付けておくと、原因にたどり着くまでの時間が縮みます。

数えるものと測るもので種類が変わる

ファセットには性質の異なる二種類があります。値の種類を数えたいのか、値の大きさを測りたいのかで選び分けます。

迷ったら、絞り込みの条件として使うだけなら定性的なファセット、グラフの縦軸に載せたいならメジャーと考えるとよいでしょう。文字列型は常に使えるので、範囲での絞り込みが要らない場面で型に悩む必要はありません。

単位はフィールドではなくメジャーに付く

メジャーには単位を設定できます。大きさなら bit・byte・kibibyte から exbibyte まで、時間なら nanosecond・microsecond・millisecond から week までが選べます (2026 年 8 月時点)。単位を持たせておくと、桁の大きな値を検索するときも表示するときも人が読める形になります。ここで間違えやすいのは、単位がフィールドの性質ではなくメジャーの性質だという点です。たとえば、あるサービスは duration をミリ秒で出し、別のサービスは同じ名前でマイクロ秒を出しているとします。この状態で単位をナノ秒と決めても、両者の値は揃いません。正しい直し方は、取り込む時点で桁を揃えることです。計算のプロセッサで前者に 1000000 倍、後者に 1000 倍をかけてナノ秒に統一しておけば、duration:>20ms という一つの条件で両方のサービスのログを同時に検索でき、集計結果も比べられる値になります。単位の設定は、桁を揃えたあとの読みやすさを担う仕組みだと考えてください。

一覧は自分用に整えられる

画面左のファセット一覧は、開くと、検索条件で絞り込んだ範囲の中身を要約して見せてくれます。定性的なファセットは値の上位と一致件数が並び、値をたどるだけで条件を足したり外したりできます。メジャーは最小と最大を示すつまみが出るので、範囲を動かして絞り込めます。検索窓に構文を書くほうが自由度は高いのですが、まず一覧を触るほうが目的の場所へ早く着きます。組織で使うファセットは全体の用途を網羅するため数が多くなりがちです。日常的に見ないものは隠せます。隠したものは一覧の検索窓からはまだ見えるので、必要になったら戻せます。隠すと入力補完や集計の選択肢からは消えますが、検索の条件としては有効なままです。共有されたリンクを開いたときに条件が失われないのは、この扱いのためです。隠す操作の影響範囲は二つの意味で限定されています。一つは Log Explorer の外には及ばないこと (流れているログの確認、モニター、ダッシュボードのウィジェットの定義は変わりません)。もう一つは自分の画面だけに効くことです。ただし保存したビューを更新すると、隠した状態もそのビューの一部として同僚に共有されます。並び順のためのグループ分けは表示だけの話で、検索や集計の結果には影響しません。

作るのは早いが、遡っては埋まらない

ホストやサービスといったよく使うものは最初から用意されており、予約属性と多くの標準属性のファセットは既定で使えます。インデックスを選ぶためのファセットは、組織に複数のインデックスがあるか、過去のログを読み直している場合にだけ現れます。新しく作る方法は二つあります。楽なのはログの詳細パネルからで、フィールド名や型があらかじめ埋まっているため確認するだけで済みます (値が文字列ならファセットのみ、数値ならメジャーも選べます)。該当するログが手元に無いときは一覧の追加ボタンから作り、タグならタグのキー名、属性なら @ を付けた経路を自分で指定します。JSON オブジェクトの配列を対象にしたい場合は、先に Grok の解析で属性を取り出してから作ります。ここで一つ、後戻りできない性質があります。作ったファセットの中身が埋まるのは、それ以降に届いたログだけです。障害の最中に思い立って作っても、そのとき調べたい過去のログには内容が付きません。必要になりそうな属性は落ち着いているうちに登録しておくのが、この仕組みでの備え方になります。数の目安として、Datadog は 1000 個までに収めることを推奨しています (2026 年 8 月時点)。

名前を揃えると調査がつながる

作る前に既存のものを探す、というのが最も効く作法です。同じ性質の情報が一つのファセットに集まっていれば、担当をまたいだ集計や突き合わせがそのまま成り立ちます。逆に似たものが分かれていると、片方にしか入っていない情報を探して回ることになります。すでに名前が揃っていない場合は、別名の設定で標準のものへ寄せられます。寄せ方は二通りで、複数の担当がそれぞれ作ってしまった既存のファセットを標準のものへ寄せる方法と、新しく取り込み始めた属性を最初から既存の標準のものへ寄せる方法があります。後者を選べば、作ってから使わなくなるものを増やさずに済みます。寄せた側のファセットも引き続き検索に使えますが、標準のものへ乗り換えるよう促される扱いになります。別名を設定する前のログを調べたいときは、寄せた側を残しておくと役に立ちます。反対に削除は慎重に行います。そのファセットをインデックスやモニター、ダッシュボード、閲覧範囲の制限条件が使っていたり、他の担当が日常的に使っていたりすると、消した時点で動かなくなるものが出ます。使われていないと言い切れるまでは、隠す操作で自分の視界から外しておくほうが安全です。詳細は Datadog の Facets を参照してください。