メインコンテンツまでスキップ
Sumo Logic Japanese

transaction operator

Web サイトのサインアップから e コマース データ、さらには分散型システムのアクティビティのトラッキングまで、どのような種類のデータを分析するかには関係なく、transaction operator は、さまざまな使用事例で活用できます。データは常に (最低でもタイムスタンプで) 順序付けられます。transaction operator は、分析中において通常は順序付けられていないデータを処理し、順序付けられたデータ (順序付きフローを持つデータ) を使用して結果を生成できます。

たとえば小売りの Web サイトを運営しているとすると、transaction operator を使用して、ログイン、カート、支払い、チェックアウトなどのトランザクションの状態を判断するログ イベントによって顧客の移動をトラッキングすることもできます。クエリの結果から、顧客の移動やサイト内での「フロー」をフロー図として視覚化し、支払い状態でのドロップオフなど、購入の完了の妨げとなる問題を識別することができます。

transaction operator は以下を必要とします。

  • 関連するログ メッセージをグループ化するための 1 つ以上のトランザクション ID。セッション ID、IP、ユーザ名、メール アドレスなど、クエリにおいて一意の ID を使用できます。トランザクション ID はクエリで定義します。トランザクション ID は、parseparse regex などの operator で抽出されます。
  • ログ メッセージから状態へのマッピング。matches operator の構文を使用するか、またはすでに parse されたフィールドを使用して、ログ メッセージから状態へのマッピングを指定します。

以下のビデオで transaction operator の概要を学習してください。このビデオでは、G Suite App で提供されているドキュメント フロー ダイアグラムを構築するための検索を紹介しています。

構文

  • transaction on <field1> [, <field2>]... [fringe=<timespec>] with <states> results by [transactions | states | flow] 

状態を (state) は、一致ステートメントとして機能し、指定された状態をログで検索します。状態の指定では、任意の 1 文字または複数文字と一致するワイルドカード文字の * を使用できます。たとえば、次のログにおいて、parse されたフィールド「sessionId」に基づいてセッション開始状態を取得する必要がある場合:

2018-02-15 13:00:28,799 -0800 INFO  [hostId=nite-spark-app-1] [module=sumo-app] [localUserName=sumo-app] [logger=sumo.app.SumoAppSearchSessionProtocolHandler] [thread=DTP-soa.sumo-app-soa.SearchSessionProtocol-32] [auth=Customer:0000000000000111:0000000000000111:0000000000000111:false:DefaultSumoSystemUser:-1:UNKNOWN] [sessionId=B6C329D84D1E37C6] [customer=0000000000000111] [remotemodule=sumo-app] Starting session B6C329D84D1E37C6

この状態を sessionId に対する一致ステートメントとして次のように指定します。

| transaction on sessionid with "Starting session *" as init

状態の指定

状態とは、データの変化をプロットするためにログのログ イベントとフィールドを使用する手段だと考えてください。transaction operator で結果を生成するためには、これらの状態を定義する必要があります。状態の定義方法は 2 通りあります。

<states> の構文

"<match string>" [in <fieldName>] as <stateName>

with "*LinkAccountAction category=Google*" as linkGoogle,
with "*LinkAccountAction category=Facebook*" as linkFacebook,
with "*LinkAccountAction category=LinkedIn*" as linkLinkedIn,
with "*LinkAccountAction category=Other*" as linkOther

states <state1> [as <alias1>] [,<state2> [as <alias2>]]... [in <fieldName>]

with states login, cart, checkout, shipping, shipping_method, billing, review, progress

状態はフィールド内のテキストです。

順序付けられているデータに対して状態を定義したら、次のセクションで説明する fromstate 引数と tostate 引数を使用して、データの順序付けに使用できます。

順序付きデータと順序なしデータ

順序付きデータを使用する場合は、2 つの異なる状態間の遷移をモニタリングすることで、トランザクションの遷移を視覚的に表すフロー図を構築し、遷移間に発生するトランザクション数を調べることができます。順序なしデータの場合は、transaction operator を使用して結果テーブルを構築できます。

順序付きデータと順序なしデータの違いは、トランザクション クエリで定義するフロー (順序) です。どちらの種類のデータの場合も、状態を定義する必要があります。results by flow を指定して状態間のレイテンシを参照すると、順序付きデータが返されます。operator によって作成されるフィールドである latency には、状態間のレイテンシがミリ秒数として格納されます。 

下記の 2 つのクエリはほぼ同じです。左側では順序無しデータを検索し、結果はテーブルとして表示されます。右側では results by flow を追加し、それぞれの fromstate と tostate の間のレイテンシをカウントすることで、フロー図を作成しています。

順序なし 順序付き

_sourceCategory=oursite
| where !(user_agent matches "*Pingdom*")

| where status_code = "200"
| parse regex "(?<ip>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})"
| parse regex field=url "^/(?<urlprefix>[A-Za-z0-9.-]+)"
| fields urlprefix, ip
| replace(urlprefix, "-", "") as urlprefix
| transaction on ip with states aboutus, company, blog, shopping, api in urlprefix

_sourceCategory=oursite
| where !(user_agent matches "*Pingdom*")

| where status_code = "200"
| parse regex "(?<ip>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})"
| parse regex field=url "^/(?<urlprefix>[A-Za-z0-9.-]+)"
| fields urlprefix, ip
| replace(urlprefix, "-", "") as urlprefix
| transaction on ip with states aboutus, company, blog, shopping, api in urlprefix results by flow
| count, max(latency) by fromstate, tostate

順序なし

unordered transaction table.png

順序付き

ordered flow diagram.png

ループ バック

状態のフロー (順序) のループ バックを追跡し、フロー図のそれぞれの状態をループする赤い線として表示します。ループにカーソルを置くと、それぞれの状態が以前の状態に戻った回数が表示されます。

hover loop back.png

フリンジ カットの指定

transaction operator は、時間ウィンドウで制約されるため、ウィンドウの端付近で発生するトランザクションの一部がカットされる場合があります。fringe 引数を使用することで、これらをフィルタリングできます。

クエリの時間ウィンドウを tw とすると、次の条件を満足するトランザクションはフィルタリングされます。

  • [tw.start, tw.start + fringe) 内に終了
  • (tw.end - fringe, tw.end] 内に開始

例:

... | transaction on sessionid fringe=10m 
with "Starting session *" as init, 
with "Initiating countdown *" as countdown_start, 
with "Countdown reached *" as countdown_done, 
with "Launch *" as launch 
results by transactions

制限事項

順序付きデータには最大 10,000 のグループ制限があります。transaction operator は、最も古いトランザクションから消去します。そのため、トランザクション数が制限に達した場合、結果には最初の 10,000 件ではなく、最後の 10,000 件のトランザクションが含まれます。この理由は、次のエラー メッセージに述べられているように、古いトランザクションの一部が未完了で終了しているためです。

このメッセージは、transaction operator で 10,000 を超えるグループを使用した場合に表示されます。

Group or memory limit exceeded, some transactions may have ended prematurely.

順序なしデータの場合は、グループ制限の 10,000 に達した後のトランザクションは無視されます。

transaction の例

以下の例で、transaction operator の動作をわかりやすく示します。

セッション ID を使用した transaction の実行

transaction operator を使用するには、関連するログ メッセージをグループ化するための 1 つ以上のトランザクション ID が必要です。ID としては、セッション ID、IP、ユーザ名、メール アドレスなど、クエリにおいて一意の ID を使用できます。

この例では、ブラウザのセッション ID をトランザクション ID として使用し、countdown_start と countdown_done の状態を定義します。

... | transaction on sessionid
with "Starting session *" as init,
with "Initiating countdown *" as countdown_start,
with "Countdown reached *" as countdown_done,
with "Launch *" as launch
results by transactions showing max(_messagetime),
sum("1") for init as initcount

transaction が作成したフィールドの使用

transaction operator は、_start_time_end_time というフィールドを作成します。これらのフィールドは、[Aggregates (集計)] タブでは [Start Time (開始時刻)] と [End Time (終了時刻)] として表示されますが、クエリではアンダースコア付きの名前で参照しないと認識されません。

これらのフィールドには、タイムスタンプがミリ秒数で割り当てられます。

たとえば、次のクエリにおいて:

_source=Syslog (New session) OR (Session deleted) 
| transaction on sessionid with "*New session*" as started, with "*Session deleted*" as ended
| where started > 0 
| ((_end_time - _start_time)/1000)/60 as time_difference_minutes

_end_time フィールドと _start_time フィールドを参照して sessionid の期間を計算します。

fields created by transaction.png

潜在的な e コマース障害の検出

e コマース サイトの状態をトラッキングすることで、潜在的な障害を示す状態間での切断やドロップオフを特定できます。

次のようなクエリを実行するとします。

_sourceCategory=[sourceCategoryName]
| parse regex "(?<ip>[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})" nodrop
| transaction on ip
with "*/cart*" as cart,
with "*/shippingInfo*" as shipping,
with "*/billingInfo*" as billing,
with "*Verifying credit card with external service*" as billingVerification,
with "*/confirmation*" as confirmation,
with "*Order shipped*" as ordershipped
results by flow
| count by fromstate, tostate

各種の状態 (cart、shipping、billing、billingVerification、confirmation、および order shipped) における通常のドロップオフ レートを示すフロー図が生成されます。

ecommerce flowchart.png

このクエリを実行すると次の結果が表示され、verification 状態でのドロップオフが異常に多いことがわかります。その情報を元に、検証サービスに問題があると考えて調査を開始することができます。

ecommerce flowchart missing states.png

 

  • この記事は役に立ちましたか?