LinuxユーザーがイジるはじめてのAzure

LinuxユーザーがAzureを使いこなせるように応援するブログです

Log Analytics(Azure Monitor Logs) + Azure Monitor Alert Rule + Runbook PowerShell + SendGrid

タイトルで、ある程度何やろーとしているか想像できる方は

きっともうAzureの初心者ではなさそうですね。

そしてやろうとしたけどなんだかうまくいかねぇーって泣きそうな

顔してる方もいらっしゃるかと思うので疎通とった記事をまとめて

おきますかね。

 

今回の記事でやりたいことは以下です。

f:id:akazure:20190308171511j:plain


 

やりたいのは、特定のログを定期的にチェックし、閾値を超えて検知

された場合は、一次処理を行った上でメールで終わったよ通知したい、

というものです。

 

①、ここは純粋にLog Analytics(Azure Monitor Logs)のワークスペースVM

  入っているomsagentからのログを飛ばすだけ。

②、Log Analyticsのワークスペースで検索したクエリ(Kusto)から、特定の

  ログを抽出し、その件数を閾値にアラートルールを作成。

③、アラートルールではAzure Automationアカウントに登録してある

  Powershell Runbookを実行するように指定。

④、Runbook内に登録したPowershellでは、特定のAzure VMのステータスを

  確認。

⑤、VMステータスをメール本文に入れてSendGridへ送信。

⑥、管理者(ここでは私)がメールの通知を受け取ってハッピー。

 

この①~⑥を自動実行(定期実行)したいわけですね。

ということでAzure上で必要なコンポーネントを並べると以下です。

 

● Azure Log Analytics (Azure Monitor Logs)

● Azure Monitor

● Azure Automation

Powershell スクリプト

● SendGrid

 

じゃ早速いってみましょー。

 

今回疎結合された単体テストができるよう進めているので、以下の

2系統で進めます。

 

1系統:Automation powershell runbookの動作(④~⑥)

2系統:Log Analytics (Azure Monitor Logs) とAzure Monitorの設定(①~③)

 

まず最初に準備するのはAzure MarketPlaceにあるSendGridです。

ここは単純にFreeプラン(無償)でアカウント作ってパスワード設定

するだけなので割愛します。

smtp serverと587 submissionポート接続用にユーザー名とパスワード

 はどこかにメモっておいてね。(SMTP認証するんで)

 

次にAzure Automationを用意しておきましょ。Azutomationアカウント名

は任意で作成しておいてください。

 

最初にやるべきは「Azure モジュールの更新」!!

これをやっておかないと、1.2.1といった超絶古いバージョンのpowershell

モジュールを使った処理がAuzre Automation側で実行されるので

1.2.1の記載をしなければ動かないです。また、ローカルPCで動いてる

hogehoge.ps1が5.7.1とかのバージョンで動作していると、動かないん

だけどー?って事態になります。(結構落とし穴w)

 

f:id:akazure:20190308095521j:plain

更新するとこんな感じです。(10分ぐらいで終わります)

最新すぎるだろ!って突っ込みはスルーして進めますw

 

続いてRunbookを開いてPowershellをコネコネしていきます。

f:id:akazure:20190308095804j:plain

Runbookの作成、から、powershellを選びます。

Python2やグラフィックpowershell ワークフローなんかも選べます。

※Python3マダー

 

で、ぶちこむPowerShellはこんな感じ。

powershell/automationpowershell.ps1 at master · akkoike/powershell · GitHub

 

入れる変数の説明だけ少し。

$rg_name = ""
$target_vm_name = ""

   ポンチ絵でいう④の部分です。対象となるVM名とRG名を入れましょう。

# Setting for E-mail
$SmtpServer = 'smtp.sendgrid.net'
$Port = 587
$UserName = ''
$Password = ''
$MailFrom = ''
$MailTo = ''
$Encode = 'UTF8'
$Subject = 'テストメール from runbook'

  メールの設定です。MailFromは確実にエラーメールが届くように

  存在するメールアドレスを入れないとRFC的にしばかれます。

 

じゃテストウィンドウからテスト実行しましょ。

f:id:akazure:20190308102213j:plain

ロードして実行されて宛先のメールアドレスにTest Mailという件名のメールが

届いたでしょうかね。本文には対象としたVMの稼働状態を示す文字列が1行だけ

記載されているはず。

※メールこないんだがー、って時は、runbookが正常に終わったのかどうかを

 確認してください。正常に終わっててこない場合は、メールの問題か

 宛先アドレス側で設定されているスパムフィルタの問題などが考えられる

 かな。SendGridポータルで確認してください。

 

ここまでうまくできれば、1系統は終わり。

最後にAutomationのrunbookの画面で「公開」を押しておきます。

※「開始」ではない点注意です。開始は単体で実行してみる、という意味合い

 です。

 

続いて2系統目に入ります。

 

リソース追加からLog Analyticsと検索し、WorkSpaceを1つ作成します。

対象VMのログ設定がまだされていない場合は以下のように設定します。

f:id:akazure:20190308132820j:plain

 

ここではazure01とcentlog001というVM名の2つがLog Analytics WorkSpaceへ

ログを取り込む設定がされていることがわかります。

※しばらくほっておくと左ペインの「ログ」からHeatbeatなどのログが飛んで

 きていることがわかります。また、対象VMを選択した後、Azure Portalから

 該当のVMへ自動的にエージェントをインストールしてくれます。

 LinuxVMならomsagentというプロセスが上がります。

 

ではログ検索にいきましょう。

ここでは単純に「今から10分前までのデータでHeartbeatで出力されたレコード」

を一覧で出しています。

f:id:akazure:20190308133624j:plain

 

Splunkでもそうですが、Log AnalyticsでもKusto(くすと)と呼ばれる

専門の言語をつかって検索クエリをかける必要があります。

 

Heartbeat

| where TimeGenerated > ago(10m)

 

※Heartbeatテーブルの中でTimeGeneratedの時間が10分前のもの、という

 指定です。

 

Linuxのログだとsyslogやカスタムログでも構造的にシンプルな構造に

入っていますが、Windows ServerのAuditlogsやActivityLogsなんかは

ツリー形式で登録されていたりします。

その場合は、mv-expandやprojectという関数を使って整形するとよいです。

 

AuditLogs
| where OperationName == "Add group"
| where TimeGenerated > ago(365d)
| extend localtime = TimeGenerated+9h
| mv-expand TargetResources
| mv-expand InitiatedBy
| project DisplayName = TargetResources.displayName , InitiatedBy.user.userPrincipalName

※AuditLogsテーブルの中で、OperationNameがAdd Groupになっている

 レコードを対象に、JSTで365日前までのデータを対象にする。

 ツリー構造になっているレコード(>TargetResourcesみたいな表示)に

 なっているものは、TargetResourcesとInitiatedByの2つをmv-expandで

 1行に整形し、project関数を使って表示したいdisplaynameとuserPrincipal

 Nameの項目だけを出力する、という命令。(わけわからんよねw)

 

ま、今回はここは難しいクエリにせずにHearbeatの件数を閾値

アラートルールを設定しましょ。

 

f:id:akazure:20190308163721j:plain

 ログ検索した画面の右上にNew alert ruleというボタンがあるので、そこを

クエリ結果が出た状態のままクリックします。

 

f:id:akazure:20190308164248j:plain

 

「条件」を押すと、先ほどかけたクエリがそのまま適用された状態に

右側へブレードが移ります。

基準では、このクエリが出力された結果の”行数”が1以上の場合、っと設定

しています。

最後の評価基準では、このクエリをかける対象範囲を今から30分前までの

データを対象とし、5分間隔で定期実行する、という設定の意味です。

 

完了を押して、次のアクショングループの設定にいきます。

 

f:id:akazure:20190308165827j:plain

 

ここでは1系統目で用意していたRunbook powershellを指定していきます。

特に迷うところはない、かな。

 

最後に「アラートの詳細」で、「アラートルール名」と「説明」を

適当に入力して、「最後にアラートルールの作成」ボタンを押します。

 

以上です。5分間隔で以下のようなメールが飛び続けますw

 

f:id:akazure:20190308170218j:plain

停止するときは以下のようにLog Analytics WorkSpaceの画面で

「警告」>「アラートルールを管理します」「無効化」で停止しましょう。

f:id:akazure:20190308170355j:plain

 

今回はテスト的に疎通を取ることに注力しましたが、いくらでも応用はできます。

VMのステータスを見て、VMを起動、停止するもよし、VM以外のリソースを

コントロールする処理をPowerShellで記載すれば、とあるログの結果から一次処理

を実行する、といったことができます。

また、今回はAutomation Runbook Powershellで行いましたが、アクショングループ

を設定する際にAzure Functionを呼び出すこともLogic Appsを呼び出すことも

できます。このあたりは好みで。

あとLog AnalyticsではHeartbeatテーブルを対象にしましたが、Linuxであれば

rsylogd経由のFacilityに対して独特のログを飛ばし、その独特のログの件数を

閾値に処理を行う、といったことや、Azure VM OS内の個別のログファイルを

対象(カスタムログ)にLog Analytics WorkSpaceへ飛ばすこともできます。

 

「ログから、とある処理を自動実行したいんだけど」

といった状況があれば、上記は1つの解決策ですね。べんりやね~~♪