Microsoft Cloud

個人アカウントと組織アカウントの違いに関しては以前このブログ内の記事でも詳しく解説しています。 https://cloud.ebisuda.net/2018/04/26/%E5%80%8B%E4%BA%BA%E3%82%A2%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E3%81%A8%E7%B5%84%E7%B9%94%E3%82%A2%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88/ この記事自体は長年にわたってアクセス数も多い人気記事です。それだけ困っている人が多いということなんだろうと思います。 上記の記事を書いてからかなり時間も経ってますし、改めて一から説明をしている動画シリーズの一つとして解説を別の角度からやり直してみました。 https://youtu.be/s1Rm7M2tMAg 見ていただけると嬉しいです。

Microsoft.Data.SqlClientを使ってインタラクティブなAzure AD認証でSQL DBにアクセスしている状況で「現在のユーザー名」を取得する方法でかなり悩んでしまいました。自由にユーザー名を入手できる状況ですし、MSALライブラリは隠ぺいされているのでトークンの情報の取得方法もわからず。 かなり悩んでしまったのですが、結局SQL側でユーザー名を取得するようにすればそれでよいことに気がつきました。最近頭が固くてダメです。

Azure SQL DBの認証にAzure ADを利用している場合にプログラムからアクセスしたいとします。 Azure AD認証を行う方法は色々とあるのですが、Azure ADにアプリケーションを登録するところから始めると色々と面倒だったりもしますよね、管理者が登録を禁止してたりとか…。 そんな時に一番簡単にできるのはMicrosoft.Data.SqlClientを使ってインタラクティブにAAD認証する方法だと思います。これならアプリケーションのAADへの登録すら必要ありません。 u u n { } s s a i i m n n e g g s c { } p l S M a a y i c s s c e s s { } t r t e o A P a m s z r t ; o u o i s u } f r g c t s t e r r i . S a i n D Q m o n g c a L i g o t D d ( n a B C S n . A M o q . S u a n l O q t i n C p l h n e o e C e ( c n n l n s t n ( i t t i e ) e i r o c ; n c i n t t a n S i ; t g t o i [ r n o ] i n n c a g o r n g = n s ) @ = " S n e e r w v e S r q = l x C x o x n s n q e l c s t e i r o v n e ( r C n o a n m n e e x c x t x i . o d n a S t t a r b i a n s g e ) . ) w i { n d o w s . n e t ; A u t h e n t i c a t i o n = A c t i v e D i r e c t o r y I n t e r a c t i v e ; D a t a b a s e = t e s t d b ; " ; これだけでOKです。 ...

以前の記事に続いてMicrosoftのクラウドサービスを使うならこれだけは知っておかないとまずいこと その2です。前提としてAzure Active Directoryと「テナント」の関係を理解している必要がありますので前回のエントリが未読の方はそちらから先に読んでいただけると嬉しいです。 https://cloud.ebisuda.net/2021/09/23/azure-ad%e3%81%a8%e3%80%8c%e3%83%86%e3%83%8a%e3%83%b3%e3%83%88%e3%80%8d%e3%81%ae%e8%a9%b1-microsoft%e3%81%ae%e3%82%af%e3%83%a9%e3%82%a6%e3%83%89%e3%82%b5%e3%83%bc%e3%83%93%e3%82%b9%e3%82%92%e4%bd%bf/ 今回は前回の内容を踏まえた上で、「テナントをまたいだ外部組織とのコラボレーション」の仕組みについての解説です。自テナントのAzure Active Directoryにユーザーを作成するのではなく、ゲストとして招待し、さらにそのゲストのライフサイクル管理もきちんとしましょうねというお話です。 このエントリの内容はYoutubeの動画にもしていますので、動画の方がお好みの方は動画でご覧ください。 https://www.youtube.com/watch?v=lpatFbZnJyg テナントにはAzure ADが1つ テナントにはAzrue ADが1つです。Azure AD内にユーザーがあり、そのユーザーに対して各種サービスにアクセス権を付与することも可能です。 これは組織の外部も同様です。下図は2つの組織がそれぞれ独立している様子だと思ってください。 テナントをまたいだコラボレーション この時にAさんとBさんが一緒に作業したいことってありますよね。 AさんとBさんが同じTeamsのグループメンバーとしてチャットをしたりファイルを共有したり会議をしたりしたいわけです。でも、別々の異なるテナントに存在するAさんとBさんなのでこのままではコラボレーションできません。権限はテナントにあるAzure AD内に存在しているユーザーにしか出すことはできないのです。 コラボレーションするための良くない方法 コラボレーションをするための1つの方法として「新規にユーザーを自テナント内に作成する」という方法があります。下の図のような状況にする方法です。 この例ではAさんと同じAzure ADに、Bさんを新規にユーザーとして作成しています。こうしてしまえば確かにAさんとBさんはコラボレーションできるようにはなるわけですが、色々と良くないこともあります。 (左のテナントの)Bさんのために有償のライセンスを別途割り当てる必要がある。- Bさんは2つのアカウントの両方にきちんと異なるパスワードを設定する等適切に管理する必要がある。- Bさんはアカウントを切り替えるときには、サインアウトやサインインを繰り返す必要がある。 個人的にもこの構成は極力避けるべきと思います。 推奨構成：ゲストとして招待 推奨する構成は「ゲストとして招待する」です。これはAzure B2Bという名前がついています。 外部組織のユーザーもAzure ADであれば「ゲストとして招待」することができるのです。これは事実上「ゲストユーザーアカウントを自テナント内に作成する」というような感じです。招待された側は1つのアカウントで複数のテナントにアクセスすることが可能となります。 これはM365系でもそうですし、Azureでも同じです。 Active Directoryの時代にはこのような「他のテナントのユーザーに権限を出す」というようなことをするのはかなりハードルが高かったですし、完全に外部組織となれば不可能に近いところもありました。ですが、クラウド時代になってユーザーのメールアドレスだけ入力すれば簡単に外部のユーザーを招待して権限を付与することができるようになりました。これはものすごい技術革新です。 どれだけ簡単にできるのかは、実際のデモを見てもらうとわかりやすいです。是非動画でご覧ください。 https://www.youtube.com/embed/lpatFbZnJyg?start=313 ゲストの「ライフサイクル管理」も必要 良いことづくめのゲスト招待ではありますが、これによってオンプレミスのActive Directoryの時には存在しなかった「ゲストのライフサイクル管理」というタスクが発生します。 目的に沿うようにゲストを招待しつつ、ゲストのライフサイクル管理を行うのも招待元テナント管理者の仕事になります。 だれがゲストを招待するのか?(設定によってコントロール可能)- ゲストはどこに対して権限を持つのか?- いつ、ゲストは権限を無くすのか?- いつ、ゲストアカウントは削除されるのか? Azure ADのエンタイトルメント管理の機能などを用いてゲストユーザーを管理することが理想的です。 https://docs.microsoft.com/ja-jp/azure/active-directory/governance/entitlement-management-external-users まとめ テナント内のサービスにはテナント内のAzure ADに存在しているユーザーしか権限を出すことができない- Azure ADにはゲストを招待する機能がある(Azure B2B)- 招待することも招待されることも可能- 自組織のユーザーやグループと同じように、ゲストのライフサイクル管理が必須 オンプレミス時代のActive Direcotryにはできなかった「外部のユーザーを招待する」という機能をうまく使って企業間のコラボレーションを実現しましょう!

記録する機会があったのでブログにも記録しておきます。 Azure Active Directory管理者の設定 前提条件としてSQL ServerにてAzure Active Directory管理者を設定します。SQL DB自体ではなく、そのDBを稼働させているSQL Server側での設定です。 管理者として指定したAAD上の組織アカウントでSQL Serverにアクセスします。今回はAzure Data Studioを利用しました。 きちんとアクセスできることを確認します。ここではじかれる場合には条件付きアクセスの条件を満たしていないことなどが考えられます。条件付きアクセスの内容も確認してください。 きちんとAADのユーザーでアクセスできることが確認できました。 Azure ADグループの準備 次にAzure AD上にグループを作成し、その中にユーザーをメンバーとして追加しておきます。今回はsqldbaccessというグループにadmin@hccjp.orgというユーザーを追加しました。(アカウントの選択が適当でごめんなさい。) 権限を付与する前に、まずは、アクセスができないことを確認しておきます。 Login failed for user ‘’. と怒られました。AADで認証し、トークンは取得できている状態ですが、権限がなく認可されない場合にはこのようなメッセージが出るのですね。 SQL DBへの権限付与 今回はtestdbというテスト用のDBに権限を出していきます。まずはAAD上のグループに対応するユーザーを作成します。 C R E A T E U S E R F R O M E X T E R N A L P R O V I D E R ; ...

Microsoftのクラウドサービスを利用すると裏では必ずAzure ADが使われています。Azure ADを中心にして組織が利用可能な「テナント」が構成されるわけです。あまりにも重要な事なのですがあまりにも重要すぎて自動的にAzure ADが生成されることもあり、きちんと意識していない組織があります。 よくわかっていない状態で別のMicrosoftのクラウドサービス、特にAzureの利用を開始するととても変な構成になってしまい、修正するのにとても時間と手間がかかってしまうことにもなりかねません。 特に管理者の方、Microsoft 365やAzureの契約を担当する方はしっかりとAzure ADとテナントの関係を理解してから契約を進めてください。 Youtubeでも解説していますので、ブログでも動画でもお好きな方をご覧ください。 https://youtu.be/x2hkwqt-K80 Microsoft 365を契約したらどうなるか？ まず、Microsoft 365を契約したらどうなるかという話をしましょう。 Microsoft 365を契約する時には必ずAzure Active Directoryがセットです。Azure ADが存在します。あるいは存在しなければ作成されます。 そして、Azure Active DirectoryにM365のライセンスが紐づきます。1つの契約で入手したライセンスをどこでも好きな複数のAzure ADに割り当てることはできません。1契約で100ユーザー分購入し、50ユーザー分をAAD1に、30ユーザー分をAAD2に、20ユーザー分をAAD3に…というようなことはできないのです。 Azure Active Direcotryにはユーザーやグループを作成できます。そして、そのユーザーにライセンスを割り当てます。M365のライセンスはユーザーに割り当てるライセンスなのです。 ライセンスを割り当てられたユーザーはMicrosoft 365の様々なサービスにアクセス可能となります。 この時に、Azure Active Direcotryを中心として、ユーザーが存在し、様々なサービスが使える範囲を「テナント」と呼びます。「テナント」といえば1組織が利用しているサービスの範囲が明確にわかるわけです。 Microsoft 365においては… 1テナント内にAzure Active Direcotryは1つだけ存在する- 契約したライセンスはAzure Active Direcotryに紐づく- ライセンスはユーザーに付与される ということになります。 やろうと思えば同一組織が複数のMicrosoft 365の契約を行うことも可能ですが、その場合にはテナントが2つになります。 1企業が2つの契約をし、テナントを2つもつ…ということは通常行いませんが、やろうと思えばできます。ですが、それぞれのテナントは別の環境です。技術的にはほかの企業がMicrosoft 365の契約をしているのと何も変わりません。 ユーザーにライセンスを割り当てるサービス群はすべて一緒 ここまで、Microsoft 365を例として記載してきましたが、これはほかのサービス群でも同じです。Azureのみが唯一の例外です(後述します)。 Dynamics 365でも、PowerBIでも、契約をしてライセンスを入手するとそれはAzure Active Direcotryに紐づき、Azure Active Direcotry内のユーザーにライセンスを付与し、ライセンスを持ったユーザーがサービスを利用することができます。 間違ったテナントにライセンスを紐づけてしまわないように注意 テナント内にAzure Active Direcotryは1つだけですので、テストで作ったAzure Active Direcotryに本番用のライセンスが紐づいてしまわないように注意してください。 テスト用の適当な名前のAzure Active Directoryをそのまま本番利用するのは事実上問題ないとはいえ、やっぱり気持ちが悪いですよね。 ...

個人で管理しているブログをAzureのPaaSに移行しました。合計で6個ほどのブログを移行してみました。 いろいろとハマってしまって、結局丸一日かかってしまったので、事の顛末を記録しておきたいと思います。 動画でも同じ内容を喋っているので、動画でご覧になりたい方は下記からご覧ください。 環境 移行元と移行先は下記です。 移行元Azure VM(Wordpress on Apache2 + MySQL)- 移行先Azure App Service(Linux)- WebApp- Azure Database for MySQL- Azure Blob Storage Wordpress on AppService Wordpress自体はAppService上でコンテナとして動作させました。このコンテナ自体は以前からこのブログ含めて複数ブログで利用していたもので、それを再利用しました。 https://github.com/ebibibi/wordpress-cocoon Wordpressの公式のイメージをもとにそこに自分が利用するテーマやプラグインを追加しているだけのシンプルなものです。 レポジトリにコードをコミットすれば自動的にGitHub Actionsでイメージがビルドされたうえで、Azure Container Registryに格納され、AppServiceにPushされるところまで全自動で動きます。 画像データのAzure Blobストレージへのオフロード 移行先の環境はコンテナなので、画像データをコンテナ内に持っておくわけにはいきません。そこでWordpressプラグインでAzure Blobストレージにあらかじめ画像を逃がすようにしました。 つかったプラグインはこちらです。 https://wordpress.org/plugins/wp-azure-offload/ 少し古いプラグインなのですが、以前から使ってますし、今回もきちんとうまく動いてくれました。このプラグインを使って、あらかじめAzureのブログに画像をオフロードさせます。その際にこのプラグインはブログのエントリーの中に埋め込まれているURLも書き換えるところまで自動的にやってくれます。 MySQL間のデータ移行 MySQL間のデータ移行に関しては、当初Azure Database Migration Servicesを使おうと考えたのですが、スキーマ移行には別途MySQL Workbenchが必要でしたし、それならMySQL Workbenchでそのままデータ移行してしまえばよさそうな感じでした。もちろんこれは私がサイトを簡単に停めても大丈夫だし、データ量も少ないからです。何度もデータ移行を継続的に繰り返さなければいけない時にはAzure Database Migration Sericesが役に立つと思います。 ですが、この方法はうまくいかず文字化けしてしまいました。原因はそもそも私が以前作っていたデータベースの文字コード設定が間違っていたからです。下記の状況でした。 Latin1に設定されたDBにUTF8のデータが入っていた- データ移行をそのまま行うと文字化け…。 いろいろ悩みましたが、結局下記の方法で回避しました。 先に移行先DBをUTF8で作成- Mysqldumpでダンプしたデータ内のcharset関連の部分を置換してから取り込み 具体的には下記のように行いました。 # c # m s s # m D r D y e e D y B e B s d d B s 作 a ダ q 取 q 成 t ン l - - り l e プ d e e 込 u み d m s s - a p / / h t l l o a - a a s b u t t t a i i = s u n n n e s 1 1 e e / _ w w r u g m p t e y _ - f n s d p 8 e q b / r l n a d a - w l b m d p _ . e e _ c m f d s y c a b / s h u n u q a l a t l r t m f . a - e 8 d c c . _ a t h d g t e a u e a r r m n b a p e a s c r s e t > a e t e l . r w _ a U - p c z T s _ i u F e d / r 8 t b e = n w . c l a p c o a m _ o l t e d m l i _ b a n u n t 1 t a - e f m u w 8 e s u p . _ e t _ d u r f d u t = 8 b m f u _ n p 8 s g a . e e m d r n e u e m - r > p p a l w > w _ p p c _ w _ i d p d ; b _ b n d n a b a m n m e a e . m d e u _ m u p t f 8 _ g e n e r a l _ c i . d u m p その他のはまった点 その他にもあれこれはまりました…。 ...

今日は久しぶりにのんびりと自分が管理するサーバーの作業を行いました。今皆さんが見ているこのサイト(cloud.ebisuda.net)をAzureサブスクリプションをまたいでお引越しをしました。 もともとは、MVP特典でもらっていた月額2万弱の枠の中でやりくりしていたのですが、Azureの使える枠が広がったので別のAzureサブスクリプションに移動したうえでスケールアップさせようと思っていたのですが、なかなか時間が取れずにいました。それをやっとやることができました。 以下、躓いたところや気が付いたところを記録しておきます。 移行元環境がどこにあったか忘れてしまって探すのにかなり手間取ってしまった。Azure管理ポータルでAzureADを切り替えたあとには必ずフィルタを確認しないといけない…。やってたつもりでできてなかった…。- PaaSのMySQL同士のデータ移行にはAzure Database Migration Servicesが使えるが、スキーマの移行には(現在は)MySQL Workbenchが必要。- MySQL Workbenchでスキーマ移行時に規定値の部分でエラーが複数発生。「サーバーパラメーター」のsql_modeにて「NO_ZERO_DATE」「No_ZERO_IN_DATE」あたりを無効化したらスクリプト修正なしで大丈夫になった。(※細かく見ていないので適切な対応だったかどうかは不明)- MySQL Workbenchでそのままデータ移行を実行したところ結構失敗した。しかし、Azure Database Migration Servicesではうまくデータ移行できた。裏で色々と良しなにしてくれている模様。 もともと環境は、VMではなくPaaSのMySQLとAppService上で動いているコンテナ環境だったので、サーバーの構成をちまちまいじる必要なくデータ移行さえできてしまえばサクッと移行可能でした。 App Service上でドメインを取得したり、証明書を作成したりとかなりAzureに依存した構成だったので移行できないことを心配してましたが、それは杞憂でした。ドメインやDNS自体はまだ元のサブスクリプションに残したままですが、そのあたりは課金額少ないので当面はこのままにしておきます。 というわけで、ひとつやり方わかったので、同じ要領であといくつかブログをお引越し予定です。

マイクロソフトアカウントはとても便利なのでWindowsのサインインに使ったり、メールを送受信したり、クラウドストレージを使ったりなど皆さんされていると思います。 私はクラウドサービスでの利用、そしてWindowsでの利用から入ったのであまり意識していなかったのですが、マイクロソフトアカウントはMicrosoftのゲーム関連でも利用されていますね。Xbox Liveですとか。 そのため、「ゲームをするためにマイクロソフトアカウントを作成したい」というニーズもかなりあり、PC側の世界とは結構な断絶があるようです。我が家の子供たちにもMinecraftでゲームをするためにマイクロソフトアカウントを代理で私が作成しましたし、友人ともマインクラフトを一緒に遊んでますし、「マイクロソフトアカウントにサインインできない」という悲鳴も結構聞こえてきます。 私はいろいろと裏側の仕組みを考えたりそれを解説するのが好きなのですが、一度そういうのは抜きにして、本当に単純に一番簡単な方法でMinecraftでオンラインマルチプレイができる状態にするための解説動画を作ってみました。 「一番簡単にやる」というコンセプトなので下記のようにしました。 マイクロソフトアカウントを今持っていようが持ってなかろうが無視して、新規にマイクロソフトアカウントを作成する。- メールアドレスを今持っていようが持っていなかろうが無視して、新規にメールアドレスを作成する。 たしかにこれが一番簡単です。 ですが、このように簡単だからとマイクロソフトアカウントを複数作ってしまったり、メールアドレスを複数作ったりしてしまうことが正しいとはもちろん考えていません。本来であればマイクロソフトアカウントは1つ作成し、それをWindowsにもゲームにも使うべきですし、メールアドレスも複数持ってしまうよりは1つの方が日常は便利です。もちろん意図的に複数作成して使い分けたいならそれはそれで構わないとは思いますが、それは自分が何をしているのかわかっていてきちんと管理できることが大前提ですから。 とはいえ、そのようなことを解説しだすと理解されませんし、目的が達成できません。必要悪みたいなところはありますね。 最近はYoutubeに力を入れているのですが、Youtubeで視聴数を伸ばしたり、クリック率を上げたり、チャンネル登録者数を上げたりしようとすると、とにかく「わかりやすく」「目的まで最短で」解説する必要があるなと強く感じています。Youtubeで解決しようとする人は、そもそも文字を読むのすら面倒という人も多いものと思います。 というわけで、Youtubeに力を入れてるだけなのはダメかなと思い始めているところでもあります。なかなか難しいです。

下記のエントリがまとめエントリになっていますのでそちらも参照下さい。 Azure LogAnalyticsワークスペースに様々なログを取り込む(まとめエントリ) | Microsoft Cloud Administrators 今回はAzure Database for MySQLからログを取り込みます。 まずは、ログの取り込み対象のAzure Database for MySQLを作成します。 診断設定からログの取り込み設定を行います。 以上でログ収取設定は完了です。とても簡単ですね。 今回はさらに、監査ログも有効化してみました。 少しDBを操作して、ログを出力させます。今回は下記のチュートリアルに従って操作しました。 クイック スタート:Python を使用して接続する - Azure Database for MySQL | Microsoft Docs しばらくたつと、きちんとログが検索可能となりました。 きちんとクエリ内容も含めて出力されています。 なお、Azure Monitorでログを収集する場合にはファイルへのログ出力はOFFにしておいてかまいません。OFFにした方がサーバーの負荷が下がりますのでお勧めです。

Azure LogAnalyticsワークスペースに様々なログを取り込んでみます。他にも色々とやってますので下記エントリも確認お願いします！ Azure LogAnalyticsワークスペースに様々なログを取り込む(まとめエントリ) | Microsoft Cloud Administrators 今回はAzure Database for PostreSQLからログを取り込んでみます。 まず、Azure Database for PostreSQLを作成します。 これも、PaaSであり、診断設定からLog Analyticsワークスペースへのログの取り込みが可能です。 今回はさらに監査ログも取得するようにします。下記の記事に従って設定します。 監査ログ - Azure Database for PostgreSQL - Single Server | Microsoft Docs https://docs.microsoft.com/ja-jp/azure/postgresql/concepts-audit サーバーを再起動します。 pgAudit拡張機能を有効にします。 サーバーパラメーターにて対象のログを選択します。 少しDBを触って、実際にログを出したいと思います。今回は下記のクイックスタートの記事に従って操作しました。 クイック スタート:PostgreSQL に対する接続およびクエリ - Azure Data Studio | Microsoft Docs しばらく待つと、きちんとログが検索可能となりました。 ただし、ちょっとさすがにログの量が多すぎる感じがあります。監査ログでALLを選択していることが原因ですので、ALLは外しておくのが現実的かなという印象です。 ちなみに、docsのドキュメント含めてあちこちに、「Azure Monitorでログを収集するならlogging_collectorはOFFにしておいたほうがいいぞ」と書かれているにもかかわらず、サーバーパラメーターにはlogging_collectorの設定がなくて戸惑ってしまいました。 実際にクエリしてみるとOFFになっていたので、何もしなくてよいようです。

下記のエントリがまとめエントリになっていますのでそちらも参照下さい。 Azure LogAnalyticsワークスペースに様々なログを取り込む(まとめエントリ) | Microsoft Cloud Administrators 今回は、BIG-IPのVMからのログ取り込みを行ってみたいと思います。 BIG-IPはAzure上に展開できるものを使いました。 BIG-IPからは、リモートのSyslogサーバーにログを送信するように構成します。 Syslogサーバーは別途構築してログを受けられるようにしておきます。今回はCentOSをSyslogサーバーとして構成しました。 まず、Rsyslogパッケージをyumでインストールします。 s u d o y u m - y i n s t a l l r s y s l o g https://support.f5.com/csp/article/K13080　によるとBIG-IPからのsyslog送信はTCPを利用しているようです。TCPを利用するように/etc/rsyslog.confを構成します。 # $ $ M I P o n r d p o L u v o t i a T d d C e P s i S m e T t r C c v P p e r s R y u s n l o 5 g 1 4 r e c e p t i o n rsyslogを再起動します。 ...

Azure LogAnalyticsワークスペースに様々なログを取り込んでみます。他にも色々とやってますので下記エントリも確認お願いします！ Azure LogAnalyticsワークスペースに様々なログを取り込む(まとめエントリ) | Microsoft Cloud Administrators 今回はAzure Firewallからのログを取り込んでみたいと思います。 まずはAzure Firewallを適当にStandard tierで作成しました。 簡単に診断設定からLog Analyticsワークスペースへのログ送信が可能です。 取り込む対象のログとメトリックを選択し、宛先を選択します。 Firewallを利用するように、既存の仮想ネットワークに対してルートを追加します。 Windows Firewallを通る通信を行ってから暫く経つと、ログが検索可能となりました。

Azure LogAnalyticsワークスペースに様々なログを取り込んでみます。他にも色々とやってますので下記エントリも確認お願いします！ Azure LogAnalyticsワークスペースに様々なログを取り込む(まとめエントリ) | Microsoft Cloud Administrators さて、今回はApp Serviceからのログを取り込んでみます。 もともと作成してあったfunctionsの実行環境がありましたので今回はそちらを対象にしてみます。 診断設定からログを取り込む方法と、Application Insightsからログを取り込む方法の大きく2つがあります。 診断設定 まずは診断設定から見ていきます。 Functionsに関してのログがLog Analyticsワークスペースに取り込まれ検索可能となりました。 診断設定から取得できるのは、生のログに近いもの…というイメージでしょうか。 Application Insights より詳細な監視、分析はApplication Insightsを使うことで可能です。これも裏ではAzure Log Analyticsワークスペースにデータがため込まれておりそれが使われますが、1つのサービスとして利用可能となっています。 有効化するのも簡単です。 Application Insightsでは様々な観点で監視ができます。 かなりリッチな画面が並んでいますが、裏にあるのはどれもAzure Log Analyticsワークスペースのデータです。 Application Insightsにより様々なテーブルが定義されています。 こんな分析も… 裏にあるのはAzure Log Analyticsワークスペースのログです。 Azure Log Analyticsワークスペースにどのようにデータをためて、どのようなクエリでどんな分析ができるのか？という点のわかりやすいサンプルとしても、Application Insightsは優秀ですね。

Azure LogAnalyticsワークスペースに様々なログを取り込んでみます。他にも色々とやってますので下記エントリも確認お願いします！ Azure LogAnalyticsワークスペースに様々なログを取り込む(まとめエントリ) | Microsoft Cloud Administrators 今回はPaaSであるAzure SQL DBのログをAzure LogAnalyticsワークスペースに取り込んでみます。 まずはSQL DBとそれを動作させるSQL Serverを作成します。 作成後、診断設定を行います。 診断設定を追加する また、監査データもLog Analyticsワークスペースに取り込むことができます。これは「監査」で設定可能です。 既定の監査設定には、次の一連のアクション グループが含まれています。これにより、データベースに対して実行されたすべてのクエリとストアド プロシージャ、および成功したログインと失敗したログインが監査されます。BATCH_COMPLETED_GROUPSUCCESSFUL_DATABASE_AUTHENTICATION_GROUPFAILED_DATABASE_AUTHENTICATION_GROUP これでログの取り込み設定としては完了です。 実際にDBにクエリを実行しつつ、ログを確認してみます。(クエリは何でもいいので、適当にネットで検索して実行しています。) ログとしては、AzureDiagnostics, AzureMetricsというテーブルが定義され、データが取り込まれていることが確認できます。 SQLの実際のクエリなんかも記録されています。

Azure LogAnalyticsワークスペースに様々なログを取り込んでみます。他にも色々とやってますので下記エントリも確認お願いします！ Azure LogAnalyticsワークスペースに様々なログを取り込む(まとめエントリ) | Microsoft Cloud Administrators 今回はNSGのフローログを取り込みます。これはNetwork Watcherという独立したサービスのような仕立てになっています。 設定するには、対象のNSGにて、NSGフローログに移動します。 「NSGフローログの作成」をクリックします。 対象のネットワークセキュリティグループを選択し、保存対象のストレージアカウントを選択します。ストレージアカウントにまずデータが収集され、さらにそれをLog Analyticsワークスペースに送信する形になります。直接Log Analyticsワークスペースに収集するわけではないので注意が必要です。 「Traffic Analyticsを有効にする」にチェックを入れます。これが事実上Log Analyticsワークスペースにデータを送信するという設定です。対象のワークスペースを選択します。 作成します。 作成完了すると、裏側でNetworkWatcherRGというリソースグループにNSGフローログやネットワークウオッチャーが作成されています。(※下記の図は今回作成したもの以外のリソースも存在しています。) ネットワークセキュリティグループの視点でフローログが有効になっているものとなっていないものを一覧で識別することもできます。 ログの参照も含めて、様々なIaaS VMに対してのネットワーク関連の監視は「Network Watcher」というサービスから可能です。このサービスを支える基盤としてLog Analyticsワークスペースが存在しているイメージです。 有効化する対象のリージョンを選択できます。 Network Watcherには色々な機能があります。 NSGフローログを設定してある一覧は「NSGフローログ」から確認可能です。 Network Watcherのトラフィック分析にてログが様々な形に可視化され、見ることが可能です。 いろいろな見方ができて面白いですね。色々とビューはありますが、裏にあるのはすべてAzure Log Analyticsワークスペースに格納されたログです。実際のログはクエリを検索することで確認できます。 このようにログを取り込むところから可視化するところまでが、一つのサービスとなっていて、Azure Log Analyticsワークスペースをほぼ意識しなくてもよいようなものもあり便利ですね。だからこそ混乱する…という面も確かにあるのですが、このように簡単に目的ベースでログを収集してその文脈できちんと可視化してくれるのはとても良いことだと思います。

Azure LogAnalyticsワークスペースに様々なログを取り込んでみます。他にも色々とやってますので下記エントリも確認お願いします！ Azure LogAnalyticsワークスペースに様々なログを取り込む(まとめエントリ) | Microsoft Cloud Administrators 今回は、以前、「カスタムログ」の機能を使って取り込んだApacheのログを解析しやすい形にしたいと思います。カスタムログで取り込む部分に関しては下記のエントリを参照して下さい。 Azure LogAnalyticsワークスペースへのApacheログの取り込み | Microsoft Cloud Administrators さて、取り込んだログを見てみると「RawData」という列にカスタムログの1行がすべて入っている状況です。これをより扱いやすい状態にしたいと思います。 やり方は大きく2種類あって「収集時にデータを解析して新しいプロパティを「カスタムフィールド」を使って定義する」か、「クエリを実行するときにそのクエリ内でデータを複数のフィールドに分けてあげる」かです。今回は後者の方法を試してみます。 LogAnalyticsワークスペースのログの検索、解析にはKustoという言語が使えます。 今回は正規表現でRawDataの中身から値を抽出することにします。すべてのレコードはスペースで区切られており、時間の部分は[]で囲まれていて、リクエストとリファラーとエージェントがダブルクオーテーション("")で囲まれている状況です。これを正規表現で表現します。 @ " ^ ( . ) [ ( . ) ] " " ( . ) " " " " ( . ) " " " " ( . * ) " " " あとは、extendで列を追加し、RawDataの中身をもとに順番に抽出してあげればよいですね。下記のようなクエリにしてみました。 h t t p d _ a c c e s s _ l o g _ C L | e x t e n d h o s t = e x t r a c t ( @ " ^ ( . ) [ ( . ) ] " " ( . ) " " " " ( . ) " " " " ( . ) " " " , 1 , R a w D a t a ) , i d e n t = e x t r a c t ( @ " ^ ( . ) [ ( . ) ] " " ( . ) " " " " ( . ) " " " " ( . ) " " " , 2 , R a w D a t a ) , u s e r = e x t r a c t ( @ " ^ ( . ) [ ( . ) ] " " ( . ) " " " " ( . ) " " " " ( . ) " " " , 3 , R a w D a t a ) , t i m e I n L o g = e x t r a c t ( @ " ^ ( . ) [ ( . ) ] " " ( . ) " " " " ( . ) " " " " ( . ) " " " , 4 , R a w D a t a ) , r e q u e s t = e x t r a c t ( @ " ^ ( . ) [ ( . ) ] " " ( . ) " " " " ( . ) " " " " ( . ) " " " , 5 , R a w D a t a ) , s t a t u s = e x t r a c t ( @ " ^ ( . ) [ ( . ) ] " " ( . ) " " " " ( . ) " " " " ( . ) " " " , 6 , R a w D a t a ) , b y t e s = e x t r a c t ( @ " ^ ( . ) [ ( . ) ] " " ( . ) " " " " ( . ) " " " " ( . ) " " " , 7 , R a w D a t a ) , r e f e r e r = e x t r a c t ( @ " ^ ( . ) [ ( . ) ] " " ( . ) " " " " ( . ) " " " " ( . ) " " " , 8 , R a w D a t a ) , a g e n t = e x t r a c t ( @ " ^ ( . ) [ ( . ) ] " " ( . ) " " " " ( . ) " " " " ( . * ) " " " , 9 , R a w D a t a ) 実行すると、きちんと狙ったところが狙ったプロパティとして抽出されていることがわかります。 ...

Azure LogAnalyticsワークスペースに様々なログを取り込んでみます。他にも色々とやってますので下記エントリも確認お願いします！ Azure LogAnalyticsワークスペースに様々なログを取り込む(まとめエントリ) | Microsoft Cloud Administrators 今回はWindows仮想マシンを使ったVMSSからログを取り込んでみます。以前やったLinux仮想マシンを使ったVMSSとやりたいことは同じです。 VMSS(Virtual Machine Scale Set)のLinux仮想マシンからのログ取り込み VMSSは適当に作成しました。 WindowsにはWindows用のCustom Script Extensionというものが存在してますが、これを利用してエージェントをインストールするのはUACが邪魔をしてうまくいきません。ですので専用の拡張機能を利用する形でよいでしょう。 拡張機能はAzure CLIからインストールします。Azure CLIはどこから使っても構いませんが、今回はAzure管理ポータルからCloud Shellを利用します。 実行するのは下記のコマンドです。 a z v m s s e x t e n s i o n s e t - n a m e M i c r o s o f t M o n i t o r i n g A g e n t - p u b l i s h e r M i c r o s o f t . E n t e r p r i s e C l o u d . M o n i t o r i n g - r e s o u r c e - g r o u p v m s s - n a m e - s e t t i n g s " { ' w o r k s p a c e I d ' : ' ' } " - p r o t e c t e d - s e t t i n g s " { ' w o r k s p a c e K e y ' : ' ' } " ...

LogAnalyticsワークスペースには様々な種類のログを取り込むことが可能です。工夫すれば事実上すべてのログの取り込みが可能です。 シリーズとしてログをあれこれ取り込みまくってみたいと思います。記事を作成したら下記に項目を増やしてリンクしていきます。 ログの取り込み Azure LogAnalyticsワークスペース作成(Azure Monitorログ) - Azure上の仮想マシンからのログ取り込み- Azure外のWidows仮想マシンからのログ取り込み(エージェントインストール編)- Azure外のLinux仮想マシンからのログ取り込み(エージェントインストール編)- Azure Arcと連動したAzure外の仮想マシンからのログ取り込み- エージェントの構成(エージェントから取得するログの設定)- Azure LogAnalyticsワークスペースへのApacheログの取り込み - VMSS(Virtual Machine Scale Set)のLinux仮想マシンからのログ取り込み- VMSS(Virtual Machine Scale Set)のWindows仮想マシンからのログ取り込み - NSGフローログからのログ取り込み(Network Watcher) | Microsoft Cloud Administrators- App Serviceからのログ取り込み- Azure SQL DBからのログ取り込み- Azure Database for MySQLからのログ取り込み- Azure Database for PostreSQLからのログ取り込み- BIG-IP Cloud Editionからのログ取り込み ログの解析 Azure LogAnalyticsのカスタムログで収集した「RawData」を扱いやすくする(クエリ実行時のデータ解析)

Azure LogAnalyticsワークスペースに様々なログを取り込んでみます。他にも色々とやってますので下記エントリも確認お願いします！ Azure LogAnalyticsワークスペースに様々なログを取り込む(まとめエントリ) | Microsoft Cloud Administrators 今回はすでにAzure LogAnalyticsに接続しているLinuxVMに対してApacheを構成し、そのログを取り込んで検索可能となるところまでやってみたいと思います。 対象VMのAzure上での確認 対象のVMはlalinuxvmというlinux vmです。OSはCentOS 7です。 Apacheの導入～動作確認 まずは、VMにSSHでアクセスし、Apacheを導入します。 httpdをインストール s u d o y u m i n s t a l l h t t p d Apacheを起動 s u d o s y s t e m c t l s t a r t h t t p d このままだとNSGにブロックされてアクセスできないのでHTTPポート(TCP/80)をオープンします。 ...