Azure の診断設定が設定されていないリソースの確認方法と注意点について。
注意が必要なのはスクリプトを使用した取得になるかと。
SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
Azure のリソースで診断設定で Log Analytics ワークスペースにログを格納すると「AzureDiagnostics」テーブルに対してログの取得が行われることがあります。
この AzureDiagnostics テーブルについての理解度が低かったので一度整理してみました。
Azure VM からエージェント経由で各種データ (イベントログ / Syslog / メトリック) を取得する方法として、以下の 2 つの方法が提供されています。
DCR を使用して情報収集を行う場合のメモを。
Microsoft Copilot in Azure では、SQL Database 向けのスキルが組み込まれており、Azure ポータルから Copilot で、データベース向けの質問をチャットすることで、SQL Database に特化した回答を得ることができます。
大きなカテゴリとして、次の二つの機能があり、データベースの稼働状況の調査を行う場合には「1.」を活用することになります。
この機能を活用すると、次の画像のように実際のデータベースの稼働状況に応じた回答が生成されます。
この機能がどのようにして動作しているのかが気になったので少し調べてみました。
この機能については Microsoft Copilot in Azure と SQL Database で公開されている記事も参考となります。
Azyre VM の構成情報には osProfile という設定があります。Windows の場合、osProfile 配下の windowsConfiguration にパッチの自動適用の設定が登録されています。
Azure VM のブレードでは JSON ビューというリンクがあります。
このリンクをクリックすると、osProfile の設定を確認することができ、Marketplace で登録されている標準の Windows イメージで展開した Azure VM であれば基本的にはこの設定が含まれている状態となっています。
しかし、enable for existing vms? #62655 のように、VM に対してパッチ関連の設定を変更しようとすると「Couldn't find 'windowsConfiguration' in 'osProfile'. 'osProfile' does not support further indexing.
」が発生するケースがあります。
このエラーが発生する VM では、JSON を確認すると、上述の osProfile が存在しない状態となっています。
直近で Bicep を使用する機会があったのですが、その際に得られた知見についてまとめておきたいと思います。
Bicep と書いていますが、ARM でも共通する内容となるかと思います。
2024/07/29 追記
本投稿について X でコメントをいただいていたので、そちらを追記させていただきました。
素晴らしいbicepの記事を発見、いくつかコメントhttps://t.co/7ObOpZoRXb
— OMI Takekazu (@takekazuomi) July 28, 2024
miteta // Bicep の Tips (2024/07 版) at SE の雑記https://t.co/u1B3Yyp5lH
— guitarrapc_tech (@guitarrapc_tech) July 28, 2024
Azure ではリソースに対して 診断設定 を実施することで、リソースに対しての各種情報を指定した宛先に保存することができます。
取得する項目の取得については、カテゴリ グループとカテゴリを使用して選択することができるのですが、この設定について、いくつか理解度が低いところがあり、改めて情報を確認した内容についてまとめておきたいと思います。
Bicep を使用して、Azure リソースの設定を行う際に、scope / parent で 拡張リソース を使用することで、設定を行うというケースがあります。
これらの属性にリソースを設定する際には、リソースの ID / 名称ではなく、Bicep 内で定義しているリソースのシンボリック名を指定する必要があります。
実際の設定例としては、診断設定のリソースとなる Microsoft.Insights/diagnosticSettings があります。
このリソースは Azure の「診断設定」を行うためのリソース定義となりますが、「どのリソースに対して診断設定を行うか」については、「scope」に対して、「resourceSymbolicName」を指定する必要があります。
Azure ストレージを例とすると、ストレージアカウントを作成するための Microsoft.Storage/storageAccounts の Bicep 内で診断設定を実施するのであれば、同一のファイル内にストレージアカウントを作成する定義があるため、ストレージ対しての診断設定のためのシンボリック名を指定することは容易です。
診断設定は様々なリソースに対して設定が可能なため「診断設定をまとめたモジュールを作成したい」というような場合には、診断設定を行うための Bicep のファイル内でシンボリック名を定義する必要があるのではないでしょうか。
本投稿では、異なるモジュールで定義されたリソースを、シンボリック名として作成するための方法について考えてみたいと思います。
サンプルとして作成した Bicep ファイルについては https://github.com/MasayukiOzawa/bicep-sample/tree/main/diagSetting で公開しています。
今回は作成したストレージアカウントに対して、診断設定を行うというシナリオを検討しています。
Azure の診断設定について調べておく必要があったので、メモを残しておきたいと思います。
データ収集ルール (DCR) を使用した情報の取得を検討する必要があり、基本となる情報は次のドキュメントの内容となります。
先日、Azure の 既定の送信アクセス廃止後の KMS によるライセンス認証について (2024/06/19 時点の動作) という投稿を書きました。
廃止予定の機能のアナウンスは Azure updates で実施されていますが、他にどのような方法があるのかが気にかかりましたので調べてみました。