NQL FAQ

'with' と 'include' の違いは何ですか? どちらを使用すべきですか?

with 句は、イベントが少なくとも1つ記録されている場合にのみデータを返します。 イベントに条件を設けて、インベントリーオブジェクトをクエリする際に使用します。

include 句は、イベントが記録されていなくてもデータを返します。 すべてのオブジェクトの値を計算する際に、すべてのデータを考慮に入れたことを確認するために使用します。

'compute' と 'summarize' の違いは何ですか? どちらを使用すべきですか?

compute キーワードは、イベントから指標を計算し、それをオブジェクトに追加するためにオブジェクトをクエリするときに使用されます。 with の後に使用することができ、include の後には必須です。

summarize キーワードは、KPI 指標を計算するためや、プロパティや期間ごとの指標の内訳を持つために使用されます。

'during past 2d' と 'during past 48h' の違いは何ですか? どちらを使用すべきですか?

時間の選択は異なる単位を使用して表現され、NQL では異なる精度を意味します。 2d が 48h と等しくても、内部の最適化のため、Nexthink はこの時間の選択を異なって解決します。

  • during past 2d を使用することで、NQL はクラウドインスタンスのタイムゾーンを基準に日次データを取得します。

  • during past 48h を使用することで、NQL はユーザーのタイムゾーンを基準にして5分または15分ごとのサンプルからより高解像度のデータを取得します。

以下の例を考慮してください:

  • データを調査する際のユーザーの現地時間は11月11日11:26:15(中央ヨーロッパ時間、CET)です。

  • クラウドインスタンスはニューヨーク、東部時間 (ET) のタイムゾーンに設定されています。

  • ここで、2つの時間の選択が取得するものを示します:

ユーザーの時間選択
クラウドインスタンス時間 (東部時間)
ユーザー時間 (中央ヨーロッパ時間)

during past 2d

11月10日00:00:00 – 11月12日00:00:00 ET

11月10日6:00:00 – 11月12日6:00:00 CET​

during past 48h

11月9日06:00:00 – 11月11日06:00:00 ET

11月9日12:00:00 – 11月11日12:00:00 CET

'2023-01-19 00:00:00 から 2023-01-21 00:00:00まで' と '2023-01-19 から 2023-01-21まで' の違いは何ですか? どちらを使用すべきですか?

時間の選択は異なる精度で表現されます。 さらに、1日全体の時間枠はクラウドインスタンスのタイムゾーンを使用しますが、時間と分はユーザーのタイムゾーンを使用します。

ユーザーがCETタイムゾーンにあり、クラウドインスタンスがETタイムゾーンに設定されている場合、システムがどのように時間の選択を解決するかを示しています。

時間選択
クラウドインスタンスタイム (ET):
ユーザー時間 (CET):

2023-01-19 00:00:00 から 2023-01-21 00:00:00まで (真夜中まで、したがってNQLは2023-01-21を除外します)

1月18日18:00:00 – 1月20日18:00:00 ET

1月19日00:00:00 – 1月21日00:00:00 CET​

2023-01-19 から 2023-01-21まで (2023-01-21を含む完全な1日なので、3日間のデータです)

1月19日00:00:00 – 1月22日00:00:00 ET​

1月19日06:00:00 – 1月22日06:00:00 CET​

クエリで during past <period> を使用する際にタイムゾーンを考慮することが重要です。&#x20

以下のユースケースを考慮してください:

  • クラウドインスタンスは東部時間(ET)で設定されており、Nexthink の管理者はニューヨークを拠点としています。 これは彼のタイムゾーンがクラウドインスタンスゾーンと同じであることを意味します。

  • 2月27日11:10 CETにパリ拠点の従業員デバイスでクラッシュが発生し、Nexthinkデータベースには2月27日10:10 UTCに発生したと記録されました。

  • Nexthink管理者は2月27日05:12:00に自分の時間でデータをクエリします。

    • 彼はこのクラッシュが2月27日05:10:00に発生していると見ます。

    • during past 24h クエリを使用すると、web インターフェースに2月26日06:00:00 – 2月27日06:00:00 が表示されます。

    • during past 1d クエリを使用すると、web インターフェースに2月27日00:00:00 – 2月28日00:00:00 が表示されます。

  • IT サポートチームはマドリード (CET) にあります。 彼らは2月27日11:12:00に自分たちの時間でデータをクエリします。

    • 彼らはNexthink webインターフェースで2月27日11:10:00にクラッシュが発生していると見ます。

    • during past 24h クエリを使用すると、web インターフェースに2月26日12:00:00 – 2月27日12:00:00 が表示されます。

    • during past 1d クエリを使用すると、web インターフェースに2月27日06:00:00 – 2月28日06:00:00 が表示されます。

  • Nexthink の管理者が Nexthink web インターフェースで見るすべては、彼がクラウドインスタンスと同じタイムゾーンにいるため、クラウドインスタンスのタイムゾーンと等しいです。 マドリードのITサポートチームにとっては、6時間の差があります。 彼らは現地時間でクエリを行い、Nexthinkはクラウドインスタンス時間 (この場合はET) をCETの現地時間に変換します。

'context' とは何ですか? いつ使用し、なぜ使用しますか?

contextでは、内訳やトレンド分析をするときに関連するプロパティがNexthinkに記録されます。 デバイスがイベントを生成すると、その時点のデバイスのプロパティ値が context に保存されます。 イベントが発生した時点でデバイスが持っていたプロパティを取得するために context を使用します。

execution.crashes during past 31d
| where application.name == "Microsoft 365: Teams"
| summarize number_of_crashes_ = number_of_crashes.sum() by context.os_name

'context.os_name' と 'device.operating_system.name' の違いは何ですか?

多くの場合、これらの2つのフィールドは同じ値を持っています。 しかし、例えば、デバイスが本日早くにOSを新しいバージョンにアップグレードしたと想像してください。 昨日のイベントをクエリするとき、context.os_name は古いOSを示し、device.operating_system.name は新しいバージョンを示しています。

  • 昨日のイベントをクエリすると、context.os_nameには古いOSが表示され、device.operating_system.nameには新しいバージョンが表示されます。

  • 今日のイベントをクエリすると、context.os_namedevice.operating_system.name の両方が最も最新のOSバージョンを示しています。

'.avg' と '.avg()' と '.avg.avg()' と '.avg.max()' の違いは何ですか?

  • .avg は平均値を格納するデータベースフィールドです。 where 句で使用してください。

  • .avg() は集計関数です。 これは保存されたデータの実際の平均値であり、実際のイベント数を考慮します。 背後のカーディナリティに依存します。 compute または summarize で使用してください。

  • .avg.avg() はサンプルの平均です。 この数字は時間の選択によって変わります。 during past 2d の場合、2つのサンプルの平均を作成します。 during past 48h の場合、192 を超える (=48*4) の15分サンプルの平均を作成します。 製品チームはこの関数の使用を推奨していません。

  • .avg.max() は、ピークを見る場合、たとえば正規化されたCPU使用率のピーク割合を表示したい場合に使用します。 15分サンプルをクエリする場合(during past 48h)、これを使用することもできますが、日次サンプル(during past 2d)をクエリする場合には推奨されません。

なぜ 'execution.events' や 'connection.events' のクエリの一部が失敗し、他のすべてのイベントで成功するのですか?

デバイスは、特定のタイプのイベント、たとえば execution.eventsconnection.events に対して大量のサンプルを生成し、それがデータセット内で最大のテーブルになります。 したがって、このデータは限られた期間保存されます。 時間や分で表現された時間枠で高解像度サンプルの場合、過去最大8日間のデータをクエリすることができます。 日で表現された時間枠の低解像度サンプルの場合、保存期間は他のほとんどのテーブルと一致し、30日間持続します。

リモートアクションの実行を取得する下記の2つのクエリの違いは何ですか?

両方のクエリは同じ数の結果を返します。

最初のクエリを使用すると、システムはパラメータを1つのJSON文字列として返します。 これは、文字列操作のみが可能であることを意味します。 このようなクエリでは、追加の計算を行ったり、パラメータの実際のデータ型を活用することは不可能です。

第2のクエリはダイナミックデータモデルを使用しています。 これにより、入力および出力のパラメータに直接アクセスし、パラメータのデータ型に基づいて、例えばbool、整数、バイトのような適切な操作を透明に使用することができます。

なぜサンプルイベントに対して 'count()' を計算するのは良いプラクティスではないのですか?

サンプルイベントに count() を使用すると、保存されたデータのサイズを把握する以外にビジネス価値を提供することは通常ないサンプルの数を返します。

Last updated