2020年7月21日火曜日

仮想マシンの停止時や起動時のLog Analytics Agentの動作について

Log Analytics AgentはOSのログ情報やメトリック情報を Azure Monitor の Log Analytics ワークスペースに送信するものですが、仮想マシンの停止時や起動時 (＝OSの停止時や起動時) にどのような動作をするのか調べてみました。 ここでは、対象は仮想マシン、OSはCentOS 7.5、Syslogの送信、とします。また、SyslogのINFOログを送信するように設定済みであるとします。

調査方法：
  1. SyslogにINFOログを10秒ごとに送信するスクリプトを実行する。
    2. ここでは、以下のスクリプトを実行します。 
    $ while true; do currentdate=$(date); logger -p user.info message for info on $currentdate; sleep 10s; done
  2. Log AnalyticsワークスペースにINFOログが送信されることを確認したら、SyslogにINFOログが送信された直後に仮想マシンを停止する。
  3. 5分ほど停止させ、Log Analyticsワークスペースにログが送信されてこないことを確認したのちに、仮想マシンを起動する。
結果：
  • 仮想マシン停止時には、直前にSyslogに送信されたログがLog Analyticsワークスペースに送信されませんでした。
  • 仮想マシンを起動すると、仮想マシン停止の直前にSyslogに送信したログがLog Analyticsワークスペースに送信されました。
Agentはどこまでのログを送信したかという情報をバッファに持つのですが、AgentはLog Analyticsワークスペースに定期的にログを送信するのみで、仮想マシン停止時にバッファを見てログを送信するという動作はしていないことになります。なお、Agentがログを送信するタイミングは/etc/opt/microsoft/omsagent/conf/omsagent.confに記述されており、CentOS 7.5の場合はバッファのフラッシュが10s毎、リトライ回数6回、リトライインターバル30sになっています。

なお、ドキュメントには
エージェントが Azure Monitor または Operations Manager に接続できない場合は、そのままデータの収集を続け、接続が確立されたときにデータを送信します。 データの量がクライアントの最大キャッシュ サイズに達した場合、またはエージェントが 24 時間以内に接続を確立できなかった場合は、データが失われることがあります。
という記述があるので(https://docs.microsoft.com/ja-jp/azure/azure-monitor/platform/agent-data-sources#data-collection) 、調査方法の手順3での停止時間を24時間以上にしてテストしてみましたが、仮想マシン起動後に未送信のログがLog Analyticsワークスペースに送信されました。起動状態で24時間なのかどうかは今後要調査です。
投稿者 時刻: 0 件のコメント:

2020年5月29日金曜日

Azure Data Factoryでzipファイルを展開して格納する方法について

Azure Data Factory (ADF) で、zipファイルを展開して格納する方法について記述します。
ADFのコピーアクティビティにはzipファイルを展開してくれる機能がありますが、いくつか注意点があります。
  • zipファイルはバイナリファイル、展開されたファイルはフラットファイル (Json、CSV等) になるので、コピーアクティビティの入力フォーマットは「Binary」、出力フォーマットは「Json、DelimitedText等」になると思われますが、コピーアクティビティでは入力フォーマットが「Binary」の場合は、出力フォーマットも「Binary」として定義する必要があります。
  • ワイルドカードでファイル指定をする場合は、データセットでファイルを指定せず、コピーアクティビティの設定でファイルを指定します。
  • コピーアクティビティにはファイル処理の中でエラー行をスキップする機能があるのですが、zipファイルが破損している場合、破損ファイルをスキップすることができません。つまり、複数のzipファイルをコピーアクティビティで処理させる場合には、事前にzipファイルの破損の有無をチェックしておく必要があります。
設定例を以下に記載します。こちらの例では、Azure Data Lake Storage Gen2のフォルダに複数のzipファイルが格納されており、これを抽出して展開、別のフォルダに展開されたファイルを格納するという処理を行います。
  1. 入力用のデータセットの設定
    • フォーマットを「Binary」としてデータセットを作成
    • File pathには、zipファイルが格納されているフォルダ (例：filesystem1/folder1) まで指定
    • Compression typeには、「ZipDeflate」を指定
  2. 出力用のデータセットの設定
    • フォーマットを「Binary」としてデータセットを作成
    • File pathには、展開されたファイルを格納するフォルダ (例：filesystem1/folder2) を指定
    • Compression typeには、「none」を指定
  3. コピーアクティビティのソースの設定
    • Source datasetには、1で作成したデータセットを指定
    • File path typeには、「Wildcard file path」を指定
    • Wildcard pathには、ファイル名 (例：filesystem1/folder1/*.zip) まで指定
  4. コピーアクティビティのシンクの設定
    • Sink datasetには、2で作成したデータセットを指定
    • Copy behaviorには、zipファイル内部の構造やファイル名を維持する場合は「Preserve hierarchy」、維持せずフラットな構造にする場合は「Flatten hierarchy」を指定 
      • 「Preserve hierarchy」を指定した場合は、zipファイル名のフォルダが作成され、その配下にzipファイルが展開されます
      • 「Flatten hierarchy」を指定した場合は、指定されたフォルダの直下に全てのzipファイルが展開されますが、ファイル名は勝手に生成されます


投稿者 時刻: 0 件のコメント:
ラベル: ,

2020年4月27日月曜日

Synapse Analyticsのメンテナンススケジュールの注意点

Synapse AnalyticsのSQLプールでは、ユーザー指定でのメンテナンススケジュールが設定できるようになっています。
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/maintenance-scheduling/

ただし、DWUが400c以下の場合には、占有リソースにならないこともあり、指定したメンテナンススケジュール通りにはならないことがあります。これは上記のドキュメントにも記載されています。

なお、DWUが400c以下の場合にはメンテナンススケジュールが設定できなくなっているため、どうしても設定したい場合には一度DWUを500c以上に上げてメンテナンススケジュールを設定したのち、DWUを400c以下に変更してください。

繰り返しになりますが、この場合はメンテナンススケジュール通りにメンテナンスされる保証はありません。
投稿者 時刻: 0 件のコメント:
ラベル: ,

2020年4月14日火曜日

Ubuntu 18.04LTSにMinikubeをインストールする手順

様々なパブリッククラウドでKubernetesのマネージドサービスが出てきており、すぐにKubernetesを使える環境が得られるようになっていますが、一から作った環境で調査するのも有用な場合があります。ここでは、1台のPC上に仮想的にKubernetesの環境を構築できるMinikubeの環境構築手順を記述します。なお、OSはUbuntu 18.04LTS、ハイパーバイザーとしてはKVMを使います。

Visualizationのチェック：
以下のコマンドを実行します。何かしら出力されればOKです。 
$ grep -E --color 'vmx|svm' /proc/cpuinfo


kubectlのインストール： 
$ sudo apt-get update && sudo apt-get install -y apt-transport-https
$ curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
$ echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
$ sudo apt-get update
$ sudo apt-get install -y kubectl


Hypervisor(KVM)のインストール： 
$ sudo apt install libvirt-clients libvirt-daemon-system qemu-kvm


KVM2ドライバーのインストール： 
$ curl -LO https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-kvm2 && sudo install docker-machine-driver-kvm2 /usr/local/bin/


Minikubeのインストール： 
$ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_1.8.1-0_amd64.deb \
 && sudo dpkg -i minikube_1.8.1-0_amd64.deb


Minikubeの起動： 一旦minikube deleteコマンドを実行したほうがよいです。 
$ minikube delete
$ minikube start
投稿者 時刻: 0 件のコメント:
登録: 投稿 (Atom)