Log Analytics Query のSummarize と Join オペレータの推奨

2018年5月29日 [Log Analytics query language recommendations for Summarize and Join operators]粗訳

このアップデートではsummarize と join のAzure Log AnalyticsおよびApplication Insightsのクエリ言語構文の推奨事項について説明します。既存の構文は引き続きサポートされていますが、結果のあいまいさを避けるために、保存されている検索およびアラートで該当する場合は、クエリ構文を変更することを強くお勧めします。

これらの推奨事項に関する質問については、contact us(英語)を参照してください。

現在、日時キーによって集計されたデータは、自動的に時間別ビンにグループ化されます。この例では、Summarize演算子で使用されるTimeGenerated列は自動的に時間単位のビンに丸められています。

SecurityEvent
| where TimeGenerated > ago(1d)
| where EventID == 4625
| summarize count() by TimeGenerated

クエリの結果は次のとおりです。

TimeGenerated [UTC] count_
2018-02-04T09:00:00.000

2018-02-04T10:00:00.000

2018-02-04T11:00:00.000

2018-02-04T12:00:00.000

2018-02-04T13:00:00.000

2018-02-04T14:00:00.000

2018-02-04T15:00:00.000

2018-02-04T16:00:00.000

2018-02-04T17:00:00.000

2018-02-04T18:00:00.000

1,205

1,268

1,234

1,173

1,007

1,042

1,041

1,049

1,090

1,113

推奨処置:

  • 保存された検索やアラート(たとえば、TimeGeneratedで要約)で自動ビンニング機能に頼らない場合は、何もする必要はありません。
  • 自動ビンニング機能を認識していない場合は、クエリで無人の時間別集計を行った結果が返されることがあります。datetimeキーでデータを集計しているかどうかを確認します(たとえば、TimeGeneratedで要約)。そのような場合は、明示的なビンティングを使用するようにクエリを修正します。たとえば、bin(TimeGenerated、1h)でSummarize します。
  • 自動ビンニング機能を認識してそれに頼っている場合:明示的ビンティングを使用するようにクエリを修正します。たとえば、bin(TimeGenerated、1h)でSummarize します。

現在、言語構文では、望ましくない結果をもたらす結合属性(たとえば、key1 == key2)であいまいな等価式を使用できます。この動作を避けるため、あいまいな等価式を変更することをお勧めします。

あいまいな結合式の例を次に示します(コンピュータごとの1日のセッション時間を合計します)。


SecurityEvent
| where EventID == 4624
| join kind= inner (
SecurityEvent
| where EventID == 4634
) on TargetLogonId == TargetLogonId
| extend Duration = LogoffTime - LogonTime
| summarize sum(Duration) by bin(LogonTime, 1d), Computer

推奨処置:

  • 結合演算子で保存された検索またはアラートのいずれかで等式を使用しない場合:アクションは必要ありません。
  • 結合演算子で等価式を使用する場合:Join operator syntax(英語)を訂正してください。クエリを修正してください。列名は、$ leftおよび$ right表記で示される適切な所有者テーブルで修飾されている必要があります。


| join … on $left.Col1 == $right.Col2
| join … on X (equivalent to: | join … on $left.X == $right.X)

 

広告

非推奨となるAzure Log Analytics の Log Search API

2018年4月24日 [Deprecating the Log Search API for Azure Log Analytics]粗訳

2017年11月、Azure Log Analyticsを利用するお客様に、Log Search APIが廃止されることをアナウンスいたしました。このAPIは、古いLog Analyticsクエリ言語で使用されます。

ログ検索APIはAzure Log Analytics REST API(英語)に置き換えられました。 REST APIは、返された行数とペイロード・サイズの点でクエリ制限(英語)と同様に、新しいクエリ言語をサポートしています。

PowerShellコマンドレットのGet-AzureRmOperationalInsightsSearchResultsは、新しいクエリ言語もサポートするInvoke-LogAnalyticsQuery コマンドレット(英語)に置き換えられました。

Log Search APIは2018年4月30日の週に非推奨になります。この日付の後にLog Search APIを呼び出すと、” Log Search API is deprecated and has been replaced with the new Azure Log Analytics REST API.” メッセージとともに410エラーコードが返されます。

クエリ結果を取得するには、従来のAPIおよびPowerShellコマンドレットの使用をすべて移行してください。

 

Azure Log Analyticsの新機能 – 2018年4月

2018年4月17日 [What’s new in Azure Log Analytics – April 2018]粗訳

Azure Log Analyticsで新しい機能が利用できるようになりました。

[ログ分析設定]メニューに、[表示]セクションが追加され、2つの新しい機能が公開されました。

最初の新しい機能は自動ソートです。クエリ結果は、デフォルトで時間フィールド( “TimeGenerated”)でソートされるようになりました。ただし、この設定はクライアント側の並べ替えを制御します。 10,000を超える結果を返すクエリは、真の順序で表示されないことがあります(並べ替えは、表示された結果にのみ適用されます。部分的で連続的ではありません)。結果が10,000を超えるクエリの場合は、クエリに “… | sort by TimeGenerated”を追加してサーバー上でソートを実行する必要があります。

もう1つの新しい設定は、1ページに表示される結果の推奨数です。結果が50件に満たない場合は、表を調整してページあたり200件の結果を表示することができます。

また、クエリエクスプローラでは、保存された各アイテムの横にコンテキストメニューが表示されるため、アイテムの名前の変更や削除が簡単にできます。

最近、これらの新しいクエリ言語関数が追加されました:

hash_sha256():入力値に対してsha256ハッシュ値を返します
row_cumsum() : レコード全体の列の累積合計を計算する
strcmp(): 2つの文字列を比較
stdevif(), varianceif() : 与えられた条件を満たす結果間の式の標準偏差または分散を計算する

詳細については、full change log(英語)を参照してください。

Operations Management Suiteポータルで作成されたアラートが Azure に拡張

2018年4月13日 [Alerts created in the Operations Management Suite portal can extend into Azure]粗訳

Microsoft Operations Management Suiteポータル(OMSポータル)を使用する顧客は、OMSポータルおよびAzureポータルで、Azure Log Analyticsのログクエリベースのアラートを管理できるようになりました。 2018年5月14日から、Microsoftは自動的にOMSポータルで作成されたアラートをAzureアラートに拡張します。監視は影響を受けず、ダウンタイムもありません。

アラート定義、クエリ、または設定を変更する必要はありません。 Azureでは、電子メール通知、Webhookコール、オートメーションランブックの実行、ITSMツールへの接続などのアクションは、アクショングループを介して行われます。

2018年5月14日より前にAzureアラートとアクショングループを使用するベネフィットにアクセスできます。これを行うには、OMSポータルまたはREST APIのウィザードを使用して手動でOMSポータルからAzureにアラートを拡張します。

OMSポータルで作成したアラートは、2018年5月14日からAzureに自動的に拡張されます。この更新後もアラートはOMSポータルに引き続き表示されます。しかし、すべての管理措置のために、Azureアラートに透過的に取り込まれます。

Log Analytics Alert REST API(英語)を使用してプログラムでアラートにアクセスする場合は、API呼び出し、Azure Resource Managerテンプレート、およびPowerShellコマンドでアクションの代わりにアクショングループを使用する必要があります。

Azureのアラートエクスペリエンスは、新鮮な外観と更新された機能を備えています。新しいアラートエクスペリエンスは、メトリック、アクティビティ、およびログアラートルールの統合されたオーサリングエクスペリエンスを提供します。ログ分析アラートだけでなく、すべてのアラートタイプを管理、列挙、表示できます。 action groups(英語)を使用すると、SMS、音声通話、オートメーションランブック、ウェブフック、ITSMコネクタなど、各アラートに対して複数のアクションを設定できます。

詳細については、「Extend alerts from the OMS portal to Azure(英語)」を参照してください。

Log Analyticsでデータ量上限を定義する

2018年4月9日 [Define a data volume cap in Log Analytics]粗訳

Azure Log Analyticsでは、1日の容量上限を有効にして、ワークスペースの毎日の処理を制限することができます。 1日の上限は、管理対象リソースから予期しないデータ量の増加を管理し、制限内に留まるのに役立ちます。また、この機能を使用すると、ワークスペースの計画外な料金を制限することもできます。

ワークスペースから日単位の上限を定義するには、左側のペインで「使用量」と「見積りコスト」を選択します。過去31日間に収集されたデータ量の傾向と保持されているデータ量の合計を示します。使用状況の詳細をドリルインしてデータを分析し、データボリューム管理を選択して、1日のボリューム上限とデータ保持を設定できます。

この機能はすべての地域で展開されており、利用可能です。

Log Analytics ワークスペースによるデータ保持のコストの管理の方法を学んでください。

Log Analytics への runbook のジョブステータス・ジョブストリームの送信

2016年8月12日 [Send runbook job status and job streams from Automation to Log Analytics] 粗訳

runbookの ジョブステータス・ジョブストリームを Azure Automation から Azure  Log Analytics (Operations Management Suite)  ワークスペースに送信できるようになりました。この利用シナリオ例は以下の通りです:

  • Automation ジョブ上のインサイトの取得
  • runbook ジョブステータス(失敗、中断)をトリガーにしたメール送信やアラート
  • ジョブストリームをまたいだクエリーの作成
  • 過去のジョブ履歴の可視化

ログを Log Analytics に送信開始したのち、Automation ログに対し、クエリーが記述できるようになり、アラートを設定できます。以下がログを利用し、可視化するクエリーのサンプルです:

  • 失敗もしくは中断したジョブ: Category=JobLogs (ResultType=Failed || ResultType=Suspended)
  • エラーストリームジョブ (ジョブIDごと): Category=JobStreams StreamType_s=Error | measure count() by JobId_g
  • 特定ジョブ向けジョブストリームの調査: Category=JobStreams JobId_g=”INSERT RUNBOOK JOB ID HERE” | sort TimeGenerated | select ResultDescription
  • 実行したジョブの履歴: Category=JobLogs NOT(ResultType=”Started”) | measure Count() by ResultType interval 1day

Log Analytics への Automation ログの送信について学習するには、Forward job status and job streams from Automation to Log Analytics (OMS) (英語)をご覧ください。

その他情報については以下をご覧ください。