AzureのLog Analyticsにデータ投入するOMSAgent、すごい便利なので重宝しているのだけど、docker-civというsolutionがよく問題を起こす。 それに、OMSAgentの実態はruby bundledなfluentdなので、カスタマイズしたログ転送をやろうとするとfluentdの設定で色々やる必要がある。 そしてVMやVMSSのExtensionを使ってOMSAgentをVMにインストールして運用していると、OMSAgentのlatestがある日降ってくる。
OMSAgentが唐突にupdateされた場合、私の経験上以下が起こる。
- カスタム設定が消え去り、ある日突然Log Analyticsにカスタムデータが投入されなくなる
- docker-civが不正な設定ファイルを適用し、不正な設定のためOMSAgentが起動不可となる
- bundleされたrubyのバージョンアップにより、今までいけてた設定が死に、不正な設定のためOMSAgentが起動不可となる
- bundleされたrubygemsの欠落により、必須モジュールが足りないためOMSAgentが起動不可となる
rubygemsの欠落は本当に不可解だけれど、まぁこれらのような現象が発生した訳です。 少なくとも私の環境では。
なので結局、OMSAgentを運用するなら、ExtensionでなくCustomScriptや自前でVM Image作るなどして、OMSAgentのバージョンを管理下に置かないといけないと思う。 それにOMSAgentがLog AnalyticsにData Collector APIを通してデータ投入する際に、VM台数が増えるに従い、スロットリングにより特定のVMにのみログバッファが溜まり続けて、fluentdで有名なバッファ溢れによる死を迎える確率が上がる。 恐らくfluentdのリトライ間隔あたりが問題なんだと思うんだけど、大量のログを処理する必要がある場合非常に困る。
ちなみに特定のVMにのみログバッファ溜まり続ける問題は、fluentdを運用していたときにも発生したため、fluentdの問題なんじゃないかと思ってる。 ただあまりソースコードは追えてないから、現象からの推測でしかないけれど。
このへん、何らか解決策考えて実施しないといけないなぁ。
