前提
以下で作成した関数をAzureにのせたときに起きた話。
なかなか、原因がわからず2~3週間悩んだので
事象
Azureに作成したHTTPトリガー関数をデプロイしたところ、認識されなかった。
切り分け
デプロイ失敗?
デプロイはvscodeの拡張機能を使って手動で実施している
ちゃんとcompleted.
とでている。
ストレージアカウントにはどう?
Functionsの設定不備?
WEBSITE_RUN_FROM_PACKAGE
はちゃんとZIPファイルを向いている
Functionsの設定不備_その他
Bicepでリソース管理しているので、バージョンによる差異や指定の不足などの可能性を考慮してAzurePortalから作成したFunctionsに対して、動作を確認する
結果:なぜか認識できた
考察
ソースコードはデプロイができていて、FunctionsはちゃんとデプロイしたZIPファイルを見ている。
しかし、なぜか関数を認識できていない。
間違った方針に進んでしまったのが、手動で作成したFunctionsでは認識できているのでBicepの差異だと考えてしまったこと
ここからARMテンプレート出力したりやAzurePortalの環境変数を見たりして、両社の差分を調べていくことに時間を使ってしまった。
結論
ここでは突然思いついたことを試したらできたので、過程は省いて結論のみ
OpentelemetryとAzureMonitorの統合に使っていたuseAzureMonitor
が悪さをしていた。
useAzureMonitor
で定義されている環境変数は、なぜかリソース側で先に定義されていないと認識されないらしい。
通常、環境変数として外にだしている値は、関数起動時に読み取られるはずなのでデプロイ時には気にする必要はない。
今回のケースではカスタムメトリックの送信先として、ApplicationInsightsの接続文字列を先に設定する必要があった。
使っていたBicepでは、接続文字列への移行対応はまだ対応しておらず、インストルメンテーションキーを使っていたので、手動作成との差異がでていた。
useAzureMonitor({
azureMonitorExporterOptions: {
connectionString: APPINSIGHTS_CONNECTION_STRING,
},
enableLiveMetrics: true,
});
環境変数を修正
インストルメンテーションキーから接続文字列APPINSIGHTS_CONNECTION_STRING
に変更する
認識されるようになった。