Log Analyticsに仮想マシンが追加できなくてハマる

Azure Log Analyticsで仮想マシンのメトリクスを見るために仮想マシンを追加する場合に、仮想マシンのディスク容量が満杯だと失敗するという話です。

Log Analyticsに仮想マシンを追加するのは、普通なら数分程度で終わるはずが、その時は接続中のまま何時間も費やし、最終的にエラーと表示されてしまいました。切断しようとしても同じように失敗します。

当然ながら原因など出してくれないので、途方に暮れていましたが、ふと仮想マシンにログインした際にディスクスペースが一杯になっていたのに気付き、不要なファイルを削除してから試したらあっさりと解決しました。

よく考えてみると、エージェントソフトをインストールして動かすのだから、その分の空き容量が無いといけないので失敗は当然なのですが、原因を示してくれないと今回のように無駄に時間を費やしてしまいます。ここは改善してほしいところです。

Azure Log Analyticsのアラートでアクションのカスタマイズが出来なくてハマる

Azure Log Analyticsでアラートを検知した時に、Webhookを実行しようとたらアクションのカスタマイズが出来ませんでした。

元々やろうとしたのは、仮想マシンのメトリクスをLog Analyticsに接続し、閾値を超えた場合にWebhookでSlackに通知させることでした。Slack側の設定は完了しており、URIとパラメータが正常であれば通知されることは確認済みです。

アラートの条件、アラートの詳細をそれぞれ設定し、アクショングループの定義でWebhookを選んだのですが、パラメータを記述するテキストボックスが何故か出てこなくて困りました。

どうやらアラートの条件の内容によってパラメータが設定できるケースと出来ないケースに分かれるようです。

MNP8月分収支

Azure8月使用料

仮想マシン系(IPアドレスやデータ転送含む) ¥9322
ストレージ系(データ転送含む) ¥1287
コンテナレジストリ系 ¥71
合計 ¥10680

今月はAKS(Azure Kubernates Service)のセミナーの分が入ったため、いつもと調整の仕方が異なり、全体で92.9%となりました。使用率95%は中々達成が難しいです。

terraform applyでデプロイしたVMをdestroyしても消えない

Azure仮想マシンのデプロイをterraformのコマンドで行った後に、削除しようとしたらリソースの一部が残っていて、手動で消さなければなりませんでした。

VMのデプロイはPowerShellで行っていたのですが、複数台をまとめてやりたいのでterraformで試してみました。

構成ベースで作成するのでtfファイルに複数台作るように書き、terraform applyコマンドの実行すると、複数同時に作ってくれるのでありがたかったのですが、少しずつ違った設定で作ろうとすると途端にハードルが上がります。具体的には、VMごとにネットワークセキュリティグループの開放ポートを変えなければならず、ここでつまずきました。

結局諦めることになり、作ったVMを消去しようとしたのですが、terraform destroyコマンドを実行してもOS仮想ディスクだけはどうやっても消えずに残ってしまいます。これは手動で消去しなければいけないので忘れないようにしましょう。

MNP7月分収支

MPN(Microsoft Partner Network)のAzure使用量と料金の7月版です。

Azure7月使用料

仮想マシン系(IPアドレスやデータ転送含む) ¥9492
ストレージ系(データ転送含む) ¥1235
合計 ¥10727

仮想マシンの使用量をさらに先月よりも増やし、全体で93.3%となりました。
95%ぐらいまでを目標にしたいと思います。

Azure VMをUbuntuからRHELに代えたら色々ハマった

セキュリティを強化しようということでAzure VMのLinuxのディストリビューションをUbuntuからRedHad Enterprize Linuxに代えた時に、セキュリティ周りで色々と違っていたのでハマりました。SELinuxをONにする前提です。

ハマった点は以下の2点です。

  1. 開放するポート
  2. sudo時のパス設定

1. 開放するポート

Azureのポータル等でNSG(Network Securiy Group)の設定を行い、受信するポートの許可設定を行うのですが、RHELの場合、マシン内部のファイアウォール設定も行わないとポートを開放したことになりませんでした。
firewalldのサービスを使ってポートを開放する必要があります。

2. sudo時のパス設定

sudoした時のパス設定に/usr/local/binが含まれていなかったため、docker-composeを使う前提のインストールスクリプトが途中で失敗していました。docker-composeの手動インストールは/usl/local/binに行う人が多いようです。そのため、sudo docker-composeというコマンドのパスが見つからないエラーになります。

MNP6月分収支

MPN(Microsoft Partner Network)のAzure使用量と料金の6月版です。

Azure6月使用料

仮想マシン系(IPアドレスやデータ転送含む) ¥8240
ストレージ系(データ転送含む) ¥1282
Azure Databricks系(仮想マシン含む) ¥132
Azure Data Lake系 ¥6
HDInsight系 ¥62
合計 ¥9722

仮想マシンの使用量を先月よりも増やしましたが、全体で84.5%とまだ行けそうです。
分析系を扱っていたので、それ系統の料金がかかりました。金額だけ見ると安く見えますが、1時間程度動かしてすぐに消去しているだけです。
本番で使う際にはきちんと考えた方がよさそうです。

Azure DatabricksのデータソースでAzure SQL Databaseに接続できない(Python)

Azure DatabricksのJDBCドライバを使ってAzure SQL Databaseにデータを保存したかったのですが、失敗してしばらく悩みました。Scala版はうまくいくのですが、Python版で失敗します。

これは結論から言うと、サンプルが間違っていたからでした。正しいコードを記述するとうまく接続できました。

具体的には

https://docs.azuredatabricks.net/spark/latest/data-sources/sql-databases.html

のPython Exampleの説明に従い、URLを以下のように定義していました。

jdbcUrl = "jdbc:sqlserver://{0}:{1}/{2}".format(jdbcHostname, jdbcPort, jdbcDatabase)
connectionProperties = {
  "user" : jdbcUsername,
  "password" : jdbcPassword,
  "driver" : "com.microsoft.sqlserver.jdbc.SQLServerDriver"
}

しかし、上記だとPort番号がおかしいと言うエラーになります。

正しくは、

jdbcUrl = "jdbc:sqlserver://{0};{1};database:{2}".format(jdbcHostname, jdbcPort, jdbcDatabase)
connectionProperties = {
  "user" : jdbcUsername,
  "password" : jdbcPassword,
  "driver" : "com.microsoft.sqlserver.jdbc.SQLServerDriver"
}

とすべきです。

これできちんとSQL Databaseに読み書きができました。

Azure Web Appの診断ログのエクスポート先が同じリージョンのストレージしか選べない

タイトル通りです。

複数あるWeb Appのログを同一のストレージBlobに出したかったのですが、特定のWeb Appのみ出力先のストレージが表示されませんでした。何故かと思い、きちんと表示されているものと見比べると、作成されたリージョンが違っていました。どうやらWeb Appは自身と同じリージョンにしかエクスポートできないみたいでした。

Web App自体のリージョンを動かせない仕様だったので、出力先も分散させることにしました。

Application Insightsなどは出力先のリージョン自体を選択できるので、それと同じようになってほしいと思います。

Azure Databricksを使おうとしてvCPUのクォータに引っかかる

MPNのサブスクリプションでAzure Databricksを試そうとしたらデフォルト設定でvCPUのコア数が足りなかったという話です。

データ分析プラットフォームの調査をしていて、HDInsightやData Lake AnalyticisとともにAzure Databricksを試そうとしました。HDInsightとAzure Databricksは動作基盤が仮想マシンなので、作成時にインスタンスを用意する必要があります。

HDInsightはHDInsight用の60コア分の確保領域?のようなものが用意されていたのですが、Azure Databricksは通常の仮想マシンと共用になっていました。

MPN自体はデフォルトで一つのリージョン当たり、10コアまでしか用意されておらず、Databricksを3台(12コア)で動かそうとしたらコア数が足りず、作成時にエラーになってしまいました。一応、最低条件では2台(8コア)で動かすことはできるのですが、それだと並列動作をさせることが出来ないので、サポートに頼んでコア数を増やしてもらい、動作させることが出来ました。

サポートは当日中に対応してくれたのでありがたかったです。