Azure VMのバックアップジョブ監視

 

Azure VMのバックアップジョブ監視について試してみました。

Azure VMのバックアップ設定はRecovery Services コンテナーにあり、実行ジョブ結果もAzure Portal上で確認可能出来ます。。。

ですが、Azure Monitorの設定を確認をするとバックアップジョブの監視設定がRecovery Services コンテナーのメトリックには存在しません。

Recovery Services コンテナーで取得されるログをLog Analyticsワークスペースへ転送する事でバックアップジョブの監視をAzure Monitorで行う事が出来ます。

今回実施した内容はこちらになります。

      • Recovery Services コンテナーの診断設定
      • Log Analyticsワークスペースでバックアップログの確認
      • Azure Monitorでの監視設定

Recovery Services コンテナーを使ったAzure VMのバックアップ設定はこちらに記載しております。

Azure VMのバックアップ設定

1.Recovery Services コンテナーの診断設定を使ってLog Analyticsへログ転送する

Recovery Services コンテナーのログをLog Analyticsワークスペースへ転送する設定を行います。Log Analyticsへの転送は診断設定で行います。

1)Recovery Services コンテナーを開き診断設定を選択すると下記画面が表示されますので、診断設定を追加するを選択します。

2)診断設定の画面では以下の項目にチェックを選択します。

      • log(以下の項目にチェック)
        • CoreAzureBackup
        • AddonAzureBackupJobs
        • AddonAzureBackupAlerts
        • AddonAzureBackupPolicy
        • AddonAzureBackupStorage
        • AddonAzureBackupProtectedInstance
      • Log Analyticsへの転送:チェックを入れる
        • Log Analyticsワークスペース:転送先を選択
        • ターゲットテーブル:リソース固有

なお、バックアップジョブの監視だけであれば、AddonAzureBackupJobs​のみにチェックで大丈夫です。

これでLog Analyticsワークスペースへのログ転送設定は完了です。

2.Log AnalyticsでRecovery Services コンテナーのログを確認する

Recovery Services コンテナーのログをLog Analyticsで確認します。

バックアップジョブの結果が確認できるログは、AddonAzureBackupJobs​になります。

転送先に指定した、Log Analyticsワークスペースで以下の通りクエリを入力し実行するとバックアップジョブの実行結果が表示されます。

AddonAzureBackupJobs​

| where JobOperation==”Backup”​

バックアップジョブの実行結果はJobStatusで確認します。

        • Complatedの場合はバックアップ成功
        • Failedの場合はバックアップ失敗

この結果を使って、バックアップ失敗時に通知するような設定をAzure Monitorを使って行ってみたいと思います。

3 .Azure VMのバックアップジョブの実行結果をAzure Monitorで監視する

Azure VMのバックアップ監視設定を行います。

今回はバックアップジョブが成功した場合にアラート発生させるようにしています。(意図的に失敗させての確認出来ないのので。。。)

Recovery Services コンテナーのログを転送しているLog Analyticsワークスペースで警告を選択します。

下記画面が表示されるので、新しいアラートルールを選択します。

アラートルールの作成画面が表示されますので、条件の選択をクリックします。

システムロジックの構成画面が表示されますので、Custom Log Searchを選択します。

詳細の入力画面が表示されますので、以下の通り設定します。

検索クエリに以下の通り設定します。

1時間以内に、1VMに対して1回でもバックアップが成功した場合にカウントが発生するクエリとしています。

AddonAzureBackupJobs

| where JobOperation==”Backup”
| where TimeGenerated > ago(1h)
| summarize countif(JobStatus==”Completed”) by BackupItemUniqueId​
| where countif_ > 0

上記クエリを1時間に1回実行し成功結果が1回でもあればアラート発生するよいうに構成しています。

アクショングループやアラートルール名を適時設定し、完了したらアラートルールの作成をクリックします。

これでアラートルールの作成は完了です。

.Azure MonitorでRecovery Services コンテナーのバックアップジョブ実行結果を監視した結果

バックアップジョブで成功した場合にアラートメールでの通知設定した後に実際の確認してみました。

無事以下のような形でメールを受信する事が出来ました。今回の設定の場合、実際のメール本文には下記のような内容が記載されます。

      • BackupItemUniqueId ロケーション名;JOB関連の情報;リソースグループ名;VM名
      • countif_ 成功回数

今回はバックアップジョブの成功を条件にしていますが、Failedを条件にすると失敗の場合にアラート通知も同様に実現出来そうです。

Azure VMのバックアップ設定

 

Azure VMのバックアップ設定について試してみました。

Azure VMのシステムバックアップとして、Azure backupを利用してRecovery Services コンテナーにバックアップデータを保管する構成でやってみました。

    • 各サービスに関するマイクロソフト様解説サイト
      • Azure バックアップ

https://docs.microsoft.com/ja-jp/azure/backup/backup-overview

      • Azure Recovery Services コンテナー

https://docs.microsoft.com/ja-jp/azure/backup/backup-azure-recovery-services-vault-overview

Azure Portal上で確認するとわかるのですが、Azure VMのバックアップ設定自体はAzure Recovery Services コンテナーになります。

Azure Portalで実施する場合は、以下の2つのメニューから実施出来ます。

      • 仮想マシンのメニューからの設定
      • Recovery Services コンテナーのメニューからの設定

Recovery Services コンテナーのメニューから設定すると、複数のAzure VMを設定が可能です。

1.Azure VMのバックアップを仮想マシンのメニューから設定する

仮想マシンのメニューでバックアップを選択すると、バックアップの設定が行えます。

      • Recovery Services コンテナー(新規作成か既存のものを選択)
      • リソースグループ:新規作成の場合のみ指定
      • バックアップポリシーの選択

下記画面ではBackupというRecovery Services コンテナーを新規作成し、バックアップポリシーをデフォルトにしています。

設定自体はこれで完了です。

2.Azure VMのバックアップをRecovery Services コンテナーのメニューから設定する

Recovery Services コンテナーのメニューからAzure VMのバックアップ設定を行ってみます。

Recovery Services コンテナー自体の作成はこちらで試しております。

ARMテンプレートを使ってAzure Recovery Services コンテナーをデプロイ

Azure VMのバックアップ先となるRecovery Services コンテナーを選択すると概要が表示されます。バックアップをクリックします。

バックアップの目標が表示されます。以下の通り選択しバックアップをクリックします。

      • ワークロード:Azure
      • 何をバックアップしますか?:仮想マシン

 

バックアップの画面が表示されます。実施するのは下記2つになります。

      • バックアップポリシーの作成
      • バックアップ対象の仮想マシンを選択

まず、バックアップポリシーの作成を行ってみます。

バックアップの画面で新しいポリシーを作成するを選択すると、バックアップポリシーの設定画面が表示されます。

今回は以下の内容で設定しています。

      • ポリシー名:Backup01
      • バックアップスケジュール
        • 頻度:毎日
        • 時刻:2:00
        • タイムゾーン:日本時間
      • インスタントリストア
        • インスタント回復スナップショットの保持期間:1日
      • 保持期間:10日

設定画面はこのような感じになります。OKをクリックすれば設定は完了です。

次にバックアップ対象の仮想マシンの選択を行います。

バックアップの画面で追加をクリックすると仮想マシンの選択画面が表示されますので、バックアップ対象のAzure VMを選択します。

   

最後に、バックアップの画面で、バックアップの有効化をクリックすればAzure VMのバックアップ設定が完了です。

バックアップジョブの監視の監視についてはこちらで試しております。

Azure VMのバックアップジョブ監視

—–

3.Azure VMの初回バックアップを取得する

設定が終わった仮想マシンのメニューでバックアップを選択すると下記画面が表示されます。

Azure VMのバックアップ設定を行った段階では、初回バックアップは取得されておらず警告メッセージが表示されています。

今すぐバックアップで初回バックアップを取得すればAuzre VMのバックアップが開始されます。

初回バックアップ取得が完了した時点で、警告のメッセージは表示されなくなります。

4.Azure VMのバックアップを停止する

Azure VMのバックアップ停止を行う場合はバックアップの停止を行います。

バックアップ停止対象の仮想マシンのメニューでバックアップを選択すると下記画面が表示されます。バックアップの停止をクリックします。

バックアップの停止の画面が表示されます。

      • バックアップデータの保持:バックアップのジョブだけが削除され、取得済みのバックアップデータは保持されます。(課金は停止しません。)
      • バックアップデータの削除:バックアップジョブ、バックアップデータ共に削除されます。(課金も停止します。)

バックアップデータが必要が無ければ削除を選択します。バックアップの停止をクリックすればバックアップが停止します。

Azure Front Doorのルールエンジンを試してみた

 

Azure Front Doorにルールエンジンと言う機能があります。

https://docs.microsoft.com/ja-jp/azure/frontdoor/front-door-rules-engine

こちらの機能の詳細はマイクロソフト様のサイトに記載の通り、Front Doorからバックエンドに送る前にどう処理をするかを規定するものになります。

以前であればルーティング規則でやる必要があったような内容もルールエンジンで実現出来ます。とくりにルーティング規則は課金が発生する為ルールエンジンに置き換える事でコスト削減も期待が出来ます。

具体的には、HTTP→HTTPへのリダイレクトや画像等の特定のパスへのアクセスのみをキャッシュする等の制御が可能になります。

今回は、HTTPからHTTPSへのリダイレクトとサブドメイン無しURLをサブドメイン付URLへリダイレクトをルールエンジンを使って試してみました。

      • ルール エンジンの構成で新規ルールエンジンを作成
        • HTTP→HTTPSへのリダイレクトルールを作成する
        • サブドメイン無しURLをサブドメイン付きURLへリダイレクトする
      • 作成したルールエンジンをルーティング規則を割り当てる

サブドメインのリダイレクトについてはAzureDNSの設定も必要になります。

ルーティング規則での実装は下記記事に記載しております。こちらも併せて参考にして頂ければと。

Azure Front DoorでHTTPからHTTPSへリダイレクトする

Azure Front Door+Azure DNSでサブドメインのリダイレクト

1.Azure Front DoorのルールエンジンでHTTP→HTTPSへリダイレクトするルールを作成する

Azure Front Doorのメニューにルールエンジンの構成を選択すると下記画面が表示されますので追加を選択します。

ルールエンジンの構成画面が表示されます。設定内容は条件とアクションの2つになります。

      • 条件の追加(HTTPでアクセスが来た場合)
      • アクションの追加(HTTPSへリダイレクトする)

ルールエンジンの構成を設定します。

今回HTTPからHTTPSへリダイレクトさせる為に設定した内容は下記内容になります。(それ以外はデフォルト値になります。)

    • ルールエンジン
      • ルールエンジン名:rulesengine01
    • ルール(条件)
      • ルール名:rule01
      • 条件:要求プロトコル
      • 演算子:次の値と等しい
      • 要求プロトコル:HTTP
    • ルール(アクション)
      • アクション:ルーティングの構成
      • ルートの種類:リダイレクト
      • リダイレクトの種類:Moved(301)
      • プロトコルをリダイレクトします:HTTPSのみ

設定が終わったら保存します。

2.Azure Front DoorのルールエンジンでWWW無しアクセスをWWW付へリダイレクトさせるルール作成する

ルールエンジンの構成を設定します。今回サブドメイン無しからサブドメイン付きへリダイレクトさせる為に設定した内容は下記内容になります。(それ以外はデフォルト値になります。)

    • ルールエンジン
      • ルールエンジン名:rulesengine01
    • ルール(条件)
      • ルール名:rule02
      • 条件:要求URL
      • 演算子:リダイレクト前のURL(https://xxx.com)
    • ルール(アクション)
      • アクション:ルーティングの構成
      • ルートの種類:リダイレクト
      • リダイレクトの種類:Moved(301)
      • 送信ホスト:置換
      • 宛先ホストを置換します:リダイレクト後のURL(https://www.xxx.com)

設定が終わったら保存します。

3.ルールエンジンはすべてのルールを処理します

ルールエンジンですが設定されているルールをすべて処理します。

ですので、今回のルールを両方設定すると、http://xxx.com→https://www.xxx.comへのリダイレクトが出来ます。

それ以降のルールの実行を止める場合は、残りのルールの評価を停止するにチェックを入れます。

Azureアクテビティログ監視をAzure MonitorとLog Analyticsでやってみた

Azureプラットフォーム上でAzure VMを作成、起動、削除した等の作業が記録されるログとしてアクテビティログがあります。

    • Azure アクテビティログ

https://docs.microsoft.com/ja-jp/azure/azure-monitor/platform/activity-log

アクテビティログで収集される内容はマイクロソフト様のサイトに記載を参照して頂きたいのですが、アクテビティログについても診断設定を使ってLog Analyticsでのデータ収集が可能です。

Log Analyticsデータ収集が可能という事は、Azure Monitorでの監視も可能なんじゃないか?という事で試してみました。

今回は、サンプルとして15分間の間に1人のユーザーがAzure VMを2台作成した場合にアラートを上げるような設定を試してみました。

      • アクテビティログの診断設定
      • Log Analyticsワークスペースでアクテビティログの確認
      • Azure Monitorでの監視設定

Log Analyticsのワークスペース作成はこちらの記事に纏めております。

Log Analyticsワークスペースを複数まとめてデプロイ

1.アクテビティログをLog Analyticsへ転送する為に診断設定をする

アクテビティログを事前に準備したLog Analyticsワークスペースへ転送する設定を行います。Log Analyticsへの転送は診断設定で行います。

1)アクテビティログのメニューで診断設定を選択します。

2)診断設定の画面が表示されますので、診断設定を追加するを選択します。

3)診断設定画面が表示されます。Azure VM作成を収集するのであれば、以下の項目にチェックをします。(今回はお試しなのですべてにチェックをつけています。)

      • カテゴリの詳細:Administrative(Log)にチェック
      • 宛先の詳細:Log Analyiticsへの送信にチェック
      • Log Analytics ワークスペース:事前に準備したLog Analyticsワークスペースを指定

10分ほどすると、Log Analyticsでアクテビティログの確認ができるようになります。

2.Log Analyticsでアクテビティログを確認してみる

Log Analyticsのワークスペースでログの確認をしてみます。

1)Azure PortalのメニューでLog Analyticsを選択します。

2)Log Analyticsでログを選択すると下記画面が表示されますので、クエリ欄に下記の通り入力し、実行をクリックします。これですべてのアクテビティログが表示されます。

AzureActivity

アクテビティログが結果として表示される事が確認できました。

実際に、Azure VMを作成した際のログを確認すると、以下のログが出力される事が分かりました。

      • ActivitySubstatusValue :Created
      • OperationNameValue:MICROSOFT.COMPUTE/VIRTUALMACHINES/WRITE
      • Caller:作成者のアカウント

こちらの情報をもとにAzure Monitorでの監視設定を行ってみます。

3.Azure MonitorでLog Analyticsを使ったアクテビティログの監視設定をしてみる

まず、Log Analyticsの画面で実際のクエリを作成してみます。特定のアカウントで15分以内にAzure VMが2回以上作成された場合にアラートを発生させる設定としてみました。

    • Logの検索条件
      • ActivitySubstatusValue :Created
      • OperationNameValue:MICROSOFT.COMPUTE/VIRTUALMACHINES/WRITE
    • 検出条件 
      • Caller:同じアカウントの場合
      • 検索時間:15分
      • 回数:2回以上

上記条件を実際にクエリとして記載するとこんな感じになりました。

AzureActivity

| where ActivitySubstatusValue == “Created”
| where TimeGenerated > ago(15m)
| summarize countif(OperationNameValue == “MICROSOFT.COMPUTE/VIRTUALMACHINES/WRITE”) by Caller
| where countif_ > 1

この条件でAzure Monitorの設定を行います。今回はLog Analyticsの画面から設定を行ってみます。

1)Log Analyticsのクエリ画面に新しいアラートルールという設定がありますので、こちらをクリックします。

2)Azure Monitorのアラートルールの作成画面に遷移します。スコープはLog Analyticsワークスペース名が設定されていますので、条件を選択し設定を行います。

3)シグナル ロジックの構成画面が表示されますので、アラートロジックと評価基準の設定を行います。今回は15分単位での設定としています。

    • アラートロジック
      • 基準;結果の数
      • 演算子:次の値より大きい
      • しきい値:0
    • 評価基準
      • 期間:15
      • 頻度:15

注意点ですがしきい値は0より大きいになります。該当のクエリの結果が1行でも表示されていた場合にアラートとして検出するようにしています。

4)アクショングループの設定をクリックし、アクショングループを適時選択します。

アラート通知をSMSで行うような設定も行っております。興味がある方はぜひ一緒に見て下さい。

Azure Monitorのアラート通知をSMSで行ってみた

5)アラートルールの詳細でアラートルール名(必要に応じてその他項目)を設定し、完了したらアラートルールの作成をクリックします。

これでアラートルールの作成は終了です。

4.Azure VM作成をしてアクテビティログアラートを発生させてみた

実際にAzure VMを作成しアラート発生させてみました。

こんな感じでアラートを発生させる事が出来ました。

      • 件名:Alert Notification “VM-Create” raised for “Log Analyticsワークスペース名”
      • Name:VM-Create
      • Severity:3
      • Resource:Log Analyticsワークスペース名
      • Search interval start time:時刻
      • Search interval duration 15 min
      • Caller :作成者アカウント名
      • countif_ 2

今回はサンプルとして作成してみましたが、適切な情報が出力されるように改善を加えていきたい所です。

Azure Monitorのアクションルールを使って非監視設定(非通知)を試す

 

Azure Monitorにアクションルールという機能があります。

    • アクションルール(2020年7月19日現在はプレビュー)

https://docs.microsoft.com/ja-jp/azure/azure-monitor/platform/alerts-action-rules

詳細はマイクロソフト様のサイトに記載を参照して頂きたいのですが、アクションルールを使って特定のリソースに対してのアラート通知を抑制をすることが出来ます。

例えば、毎週金曜日の夜にVMを再起動するからその時間帯だけでアラート通知を止める、そんな非監視設定と同じような事がアラートルールを使えばできます。

今回は、アラートルール自体を無効にするような非監視ではなく、アクションルールの発動を抑える内容を試しています。フィルターでルールIDの指定も行えるのでアラートの発生自体の抑制も可能なのかは、今後試してみたい所です。

1.Azure Monitorでアクションルールの設定してみた

今回は、以下の設定で試してみました。

      • スコープ(対象):Azure VM
      • 対象のアラートルール:すべての重要度のアラートルール
      • アクション(スコープの定義):抑制
      • 時間:10分間(1回限り)

Azure Portalでモニターを選択し、Azure Monitorの設定画面に移動します。

アラートを選択すると下記画面が表示されますので、アクションの管理を選択します。

2)アクションルールのタブを選択します。

そうすると、アクションルールの設定画面が表示されます。

  • アクションルール固有の重要な設定項目
      • スコープ(アクションルールの対象。抑制の場合は抑制を行うサービスを指定)
      • フィルター(どういう条件に合致したものに適用するか?という設定(任意なのですべての場合は設定しない)
      • スコープでの定義(抑制するのか、アクショングループの定義にするのか?)
      • 抑制の構成(抑制を選択したい場合に表示されます。抑制を行う時間帯等を指定します。)

その他ルール名等のアクションルールに関する設定を行います。

3)スコープを選択します。今回はAzure VMに対しての抑制なので、Virtual Machinesを選択します。

4)フィルターの設定を行います。どういう条件の場合は抑制を行うのかの指定ができます。

Azure VMに対してすべて抑止を行う場合はフィルターの設定が必要ありません。今回は設定内容を確認したかったので重要度をすべて選択しています。

実際に重要度=すべての重要度で設定すると下記のようになります。

5)次にスコープの定義を設定します。今回はアラート通知を止めたいので抑制を選択します。

6)そうすると抑制の構成が表示されますので、編集ボタンをクリックして設定を進めます。

7)抑制の構成ですが、スケジュールした時刻や定期的なスケジュール設定が可能です。

スケジュールされた時刻の場合

定期的に抑制を行う場合

今回はテストなので下記の通り、10分間だけ抑止を行う設定にしてみました。

 

8)最後にアクションルール名や、保存するリソースグループを選択します。

9)最終的に確認画面が表示されますので、内容を確認して問題がなければ保存します。(サンプルは一度保存した後の画面になります。)

これで設定は完了です。

実際に作成されたアクションルールは、アクションの管理の画面で一覧表示して確認する事が出来ます。

設定内容に慣れる必要はありそうですが、設定自体は非常に簡単にできます。

2.Azure Monitorのアクションルールを実際に使ってみて

今回、Azure VMの再起動で試してみました、アクションルールの設定によりアラート通知は止められていました。

定期的にメンテナンスするような場合には非常に有効かと思われました。

スコープではアクショングループも選択が可能なようなので、夜だけは特定の通知(アクショングループ)を止めるような設定も可能なようです。

またフィルターで色々な条件設定も可能なので、今後引き続き試して行きたい所です。

Azure リソース正常性(Resource Health)の監視設定

 

今回はリソース正常性(Resource Health)の監視、アラート通知設定をAzure Monitorを使って試してみました。

リソース正常性(Resource Health)では、自身のリソースが使用可能な状況にあるのかどうかを知る事が出来ます。

Azure 基盤の障害だけではなく、ユーザー自身が行った操作による影響も知る事が出来ます。例としては、ユーザー自身が行ったAzure VMの停止もリソース正常性の1つとして通知されます。

リソース正常性(Resource Health)に関する詳細は下記サイトを参照ください。

    • リソース正常性(Resource Health)

https://docs.microsoft.com/ja-jp/azure/service-health/resource-health-overview

なお、Service Health(サービス正常性)に関しては、下記に記載しております。併せて見て頂ければと。。。

Azure サービス正常性(Service Health)の監視設定

—-

1.リソース正常性(Resource Health)をAzure Portalで確認してみた。

リソース正常性(Resource Health)は、サービス正常性(Service Health)の中にあります。

Azure Portalで確認するには、まずモニターのService Healthのメニューを選択します。

サービス正常性の画面が表示されますので、リソース正常性を選択します。次にリソースの種類を選択します。(下記例では仮想マシンを選択しています)。選択したリソースの種類に関するリソース正常性状況が表示されます。

詳細を確認したい場合は、リソースを選択します。正常性の状況や利用できない場合はその理由が表示されます。

Azure Portal上でも確認が可能ですが、リソース状態の変化を都度確認するのも大変です。これをAzure Monitorを使って通知する設定を行ってみました。

2.Azure Monitorでリソース正常性(Resource Health)の監視設定をしてみた

Azure Monitorを使ってリソース正常性の監視設定を行ってみました。

1)まずモニターでService Healthを選択します。

2)サービス正常性の画面が表示されますのでリソース正常性を選択します。

3)リソース正常性の画面が表示されますので、リソース正常性アラートの追加を選択します。

下記のようなResource Healthアラートルールの作成画面が表示されます。まずアラートの対象の設定を行います。

      • サブスクリプション
      • リソースの種類
      • リソースグループ
      • リソース

4)リソースの種類について設定します。リソースの種類は以下の通りAzureのサービスが個別に表示されます。設定対象のサービスを選択します。

Azure Resource Health で利用できるリソースの種類と正常性チェック

https://docs.microsoft.com/ja-jp/azure/service-health/resource-health-checks-resource-types

 

※サービス正常性に比べて利用できる対象はまだ少ない状況です。

5)次にリソースグループを選択します。設定したリソースが存在するリソースグループ名を選択します。

6)次に監視対象としたいリソースを選択します。リソースの種類とリソースグループで絞り込まれたリソースが表示されますので適時選択します。

次にアラートの条件を設定します。アラートの条件で設定するのは以下の通りになります。

      • イベントの状態
      • 現在のリソースの状態
      • 以前のリソースの状態
      • 理由の種類(何に起因して発生したのか)

7)イベントの状態を選択します。

8)現在のリソースの状態を選択します。状態は下記3つになります。

      • Available(使用可能)
      • Degraded(パフォーマンス低下(リソースは使用可能))
      • Unavailable(使用不可)

例えばサービス影響を受けた場合検出したい場合は、DegradedとUnavailableにチェックを入れます。

9)以前のリソースの状態を選択します。利用可能な状態から状態遷移した場合のみを検知したい場合等はAvailableに選択を入れます。

10)理由の種類を選択します。

      • Platform Initiated(Azure側起因)
      • User Initiated(User操作起因)

プラットフォーム起因の影響のみ検出したい場合は、Platform Initiatedを選択します。User Initiatedにはユーザー自身が意図的に行ったAzureVMの再起動等が含まれます。

11)アクショングループで通知方法を選択します。アクショングループの選択をクリックすると、作成したアクショングループが表示されますので、適時選択します。

12)アラートルールの詳細を設定します。アラートルール名やアラートルールを保存するリソースグループ名を指定します。

設定が終わったら、アラートルールの作成をクリックしルールを作成します。

これで設定作業が終了です。



3.リソース正常性(Resource Health)をAzure Monitorを使ってアラート通知してみた感じ

Azure VM等がAzure基盤影響でハングアップした場合等も通知出来る為、Azure Portalを確認しなくても済むため非常に便利だと思いました。

しばらく、様子を見ながら試したいと思いますが、少なくともプラットフォーム起因の部分は設定しておいたほうが良さそうな感じでした。

Azure サービス正常性(Service Health)の監視設定

 

Azure基盤の障害やメンテナンス作業影響で自身のリソースや、サービス全体の影響が発生した場合に検知する方法としてサービス正常性とリソース正常性2つの方法があります。

    • サービス正常性(Service Health)

https://docs.microsoft.com/ja-jp/azure/service-health/service-health-overview

リージョン単位で発生しているような大規模なサービスの障害や、メンテナンス計画等の情報を表示します。(リージョン内の特定リソースを対象にしたようなものは表示されません。)

    • リソース正常性(Resource Health)

https://docs.microsoft.com/ja-jp/azure/service-health/resource-health-overview

リソース単位で発生している障害や、利用可能な状態にあるかの情報を表します。

サービス正常性(Service Health)にはメンテナンス計画等が含まれたり、リソース正常性(Resource Health)はリソース自体をユーザーが停止した場合も含まれるなど、同じ正常性でも用途や範囲が異なります。

Azure Portal上でも正常性の確認も出来ますが、Azure Monitorを使った監視、アラート通知する事が可能です。

今回はAzure Monitorでサービス正常性(Service Health)の アラート ルールを作成してみました。

なお、リソース正常性に関しては、下記に記載しております。併せて見て頂ければと。。。

Azure リソース正常性(Resource Health)の監視設定

1.Azure Service Health(サービス正常性)をAzure Portalで確認してみた。

Azure Portalで確認するには、モニター(Azure Monitor)のService Healthを選択します。

現在のサービス正常性が表示されます。(なお、本画面では過去の履歴を含めてサービスに関する問題も確認可能です。)

なお、デフォルトすべてのサービスが選択されているので、自身の利用していないサービスの問題も表示されます。(サンプルは何も発生していない場合の画面になります。)

2.Azure MonitorでService Health(サービス正常性)のアラート通知設定してみた

Azure Monitorを使ってService Health(サービス正常性)の監視設定を行ってみます。

1)まずモニターでService Healthを選択します。

2)サービス正常性の画面が表示されます。サービス正常性アラート追加を選択します。

3)下記のようなアラートルールの作成画面が表示されます。サービス正常性(Service Health)で設定する内容は下記の通りになります。

      • サービス(通知対象のAzureサービス)
      • リージョン(通知対象のリージョン)
      • イベントの種類
      • アクショングループ(アラートの通知方法)
      • アラートルールの詳細(ルール名や保存するリソースグループ名等)

4)サービスについて設定します。サービスは以下の通りAzureのサービスが個別に表示されます。自身が利用するサービスのみを選択します。

※かなりの数がありどれを指定すればよいのかわかりにくいものも多いです。ある程度広めに設定しておき、どんどん削っていくのが良さそうな感じです。

5)次にリージョンを選択します。Azureで展開されるているリージョンがすべて表示されます。アラート通知したい(利用しているリージョン)を選択します。

6)次にアラート通知を行う、イベントの種類を選択します。

イベントの種類については下記サイトに記載があります。適時選択します。

https://docs.microsoft.com/ja-jp/azure/service-health/service-health-overview#service-health-events

  1. サービスの問題 – ユーザーに今すぐ影響を及ぼす Azure サービスの問題。
  2. 定期的なメンテナンス – お使いのサービスの可用性に将来影響を及ぼす可能性のある今後のメンテナンス。
  3. 正常性に関する勧告 – ユーザーが注目する必要のある Azure サービスの変化。 例としては、Azure の機能が非推奨となることやアップグレードの要件 (サポートされている PHP フレームワークへのアップグレードなど) が挙げられます。
  4. セキュリティに関する勧告 (プレビュー) – Azure サービスの可用性に影響する可能性があるセキュリティ関連の通知。

※サービスの問題と計画メンテナンスと正常性の勧告&セキュリティ アドバイザリと3つそれぞれ別々にサービス正常性アラートを作るのが、受け取った時に一番わかりやすいかなぁと思います。

7)アクショングループで通知方法を選択します。アクショングループの選択をクリックすると、作成したアクショングループが表示されますので、適時選択します。

8)アラートルールの詳細を設定します。アラートルール名やアラートルールを保存するリソースグループ名を指定します。

設定が終わったら、アラートルールの作成をクリックしルールを作成します。

これで設定作業が終了です。

3.Azure サービス正常性(Service Health)を使ってみて

メンテナンス通知等がメールで来るので、こういうところは非常に便利だと思いました。

実際の障害時にがサービス正常性が来るのが、実際のサービスが影響発生してしばらくしてから来るので、この編は参考情報程度に近いかと思います。

幅広く設定すると色んなメールが来るので、内容確認に慣れていく必要があるなぁという感じです。




ZabbixからSendGrid経由でメール送信してみた

 

今回は、Azure上に構築したZabbixサーバから、Send Grid経由でメール送信を行ってみました。

なお、Send Gridアカウントの作成については、こちらの記事を参照ください。

AzureでSend Gridのアカウントを作ってみた

なお、AzureではSMTP25番ポートを利用した通信(インターネット向け)が禁止されています。Azure上からのメール送信はSend Grid等の利用が推奨されております。

https://docs.microsoft.com/ja-jp/azure/virtual-network/troubleshoot-outbound-smtp-connectivity

1.Azure ネットワークセキュリティグループの許可設定を行う。

SendGridを利用するにあたって、NSG(ネットワークセキュリティグループ)の許可設定を行います。まずはSendGrid様のサイトで必要な情報を確認します。

https://support.sendgrid.kke.co.jp/hc/ja/articles/204187885-SMTPの接続情報を教えてください-

以下のように記載があります。

  • サーバ名    :smtp.sendgrid.net
  • ポート番号   :25 / 465 / 587 / 2525

平文もしくはTLSを利用する場合:25、587および2525(587を推奨)
SSLを利用する場合:465 

送信先をInterNetで開けても良いのですが、今回は送信先サーバとなるsmtp,sendgrid.netのみ許可としてみます。NSGはFQDNでの許可設定が出来ませんので、nslookupコマンドでIPを調べます。

Windows端末のコマンドプロンプトで、下記の通りnslookupコマンドでsmtp.sendgrid.netのIPアドレスを確認します。

確認したIPアドレスをNSGの許可設定します。メール送信する(今回はZabbixサーバのNSG)を確認します。送信のセキュリティ規則で、宛先のIPアドレスを先ほど確認した入力します。

ポート番号は、今回はSSLを利用しますので、465を利用します。

追加をクリックしてNSGの設定は完了です。

2.Zabbix上で、Mail送信設定を行う。

以前作成したZabbixサーバを利用して、メール送信確認を行ってみました。Zabbixサーバの構築手順は下記記事を見て頂ければと。

Zabbix5.0をAzure Database for MariaDB を使って構築してみた

Zabbixのログインし、メディアタイプを選択します。

メディアタイプが表示されますので、下記のEmailをクリックします。

Emailをクリックすると、設定画面が表示されますので設定を行います。

    • 名前;適時設定下さい(デフォルトのEmailのままで問題ないです。)
    • タイプ:メール
    • SMTPサーバ:smtp.sendgrid.net
    • SMTPサーバポート:465(今回はSSL利用する為)
    • 送信元メールアドレス;適時設定下さい。
    • 接続セキュリティ:SSL/TLS
    • 認証:ユーザー名とパスワード
    • ユーザー名:SendGridのユーザー名
    • パスワード:SendGridのパスワード

更新ボタンをクリックすると、設定が完了します。

これで設定が終わりましたので、テストメール送信を行います。メディアタイプの画面でテストの項目が表示されていますので、こちらをクリックします。

クリックするとテスト画面が表示されます。送信先のメールアドレスを設定しテストボタンをクリックします。

テストメールが送信されますので、メールソフト側で受信される事が確認されたら終わりです。

※なお、逆引き設定等がされてない状態ですので、メール受信環境によっては受信できないケースがります。この点は注意して下さい。

 

AzureでSend Gridのアカウントを作ってみた

 

AzureではSMTP25番ポートを利用した通信(インターネット向け)が禁止されています。

https://docs.microsoft.com/ja-jp/azure/virtual-network/troubleshoot-outbound-smtp-connectivity

Zabbix等の監視サーバ等を構築した場合Send Gridを利用してメール送信する必要があります。

今回はAzure上からメール送信を行う為の下準備として、Azure上にSend Gridアカウントの作成してみました。(Zabbixを使ったメール送信は次回記事で試しております。)

1.Azure上でSend Gridアカウントを作成する

まず、Azure PortalでSendGridと入力します。サービスにSendGrid Accountsが表示されますので、これを選択します。

SendGrid Accountsで追加をクリックします。

Create SendGrid Accountの画面に遷移します。作成するリソースグループ名や場所(リージョン)、Azure Portal上での表示名、SendGrid Accountのパスワードを入力します。

このパスワードはメール送信時の認証に利用されます。 PricingTierはFreeを選択します。(SendGrid Accountのユーザー名は別途払い出しされます。)

画面下の方では、連絡先の情報入力になります。氏名やメールアドレス、会社名、webサイトを入力します。(Emailアドレスは、確認メールが来ますので、受信可能なアドレスを入力します。)

TAGを設定しない場合は、そのままReview+Createをクリックすると確認画面が表示されます。修正点が無ければ、Createで作成するとアカウントが作成されます。

アカウントが作成されますと、設定したメールアドレス宛に、確認メッセージが来ます。リンクをクリックして承認すればアカウントが利用できるようになります。

2.Azure上で作成されたSend Gridアカウントを確認する

先ほど作成したアカウントを選択します。下記画面が表示されますので、

SendGridの画面が表示されます。Account Detailsをクリックします。

Account Detailsでアカウントの情報が確認できます。表示されているユーザー名とSendGrid Account作成時に設定したパスワードでメール送信時の認証に利用します。

上記画面のTime Zone表示の右端の編集ボタンをクリックすると下記画面が表示されます。TimeZoneを時間を日本時間に変更します。

これで作成したアカウント情報の確認は終了になります。

実際のZabbixサーバを利用したメール送信は下記記事に記載しております。併せて見て頂ければと。

ZabbixからSendGrid経由でメール送信してみた

※セキュリティ的な観点を考えると、ユーザー名もデフォルトから変更する事が望ましいと思われます。適時変更するようにします。

Azure Monitorのアラート通知をSMSで行ってみた

 

Azure Monitor のアラート通知をSMSでやってみました。

Azure Monitor でアラート通知を行う際には、どういう方法で通知を行うかをアクショングループで定義をします。

https://docs.microsoft.com/ja-jp/azure/azure-monitor/platform/action-groups

この通知方法に関しては、メールだけではなく、SMSを選択する事も可能です。

今回は、SMSを利用したアラート通知の設定を作成し、アラートを出して実際に受信する所までを試してみました。

実施した作業の流れは、以下の通りになります。

1) Azure Monitorで通知方法にSMSを指定したアクショングループを作成する。

2)1)で作成したアクショングループを指定して、Azure Monitorのアラートルールを作成する。

※なお、電話は米国(国番号1)のみで提供されています。(2020年7月5日現在)

1.Azure Monitorで通知方法にSMSを指定したアクショングループを作成

Azure Portalを利用して作業を実施します。

1)Azure Portalのメニューでモニターを選択します。以下の画面が表示されますので、アクションの管理を選択します。

2)以下の画面が表示されますので、アクショングループを追加を選択します。

3)アクショングループの作成の画面が表示されます。基本設定として、リソースグループ名、アクショングループ名、表示名を入力します。

4)アクショングループの通知の設定を行います。通知の種類でSMSメッセージを選択します。

5)SMSの登録を行います。国コード(日本の場合81)を選択し、通知を行う電話番号を入力します。登録が終わったらOKで保存をします。

6)アクショングループの設定を行います。今回はSMSの通知のみですので、何もせずに次へで進みます。

7)タグの設定を行います。環境に合わせて適時入力します。投入が終わったら次へ進みます。

確認をおよび作成画面が表示されますので、作成をクリックします。これでSMSの通知を行うアクショングループの作成作業は完了です。

正しく設定出来ていると、下記のようなSMS通知が届きます。(AlertSMS01という名前でアクショングループの表示名を作成した場合の例になります。)

2.Azure MonitorでAzure VMに起動時に発動するアラートルールを作成

次にSMSの通知確認を行う為に、Azure Monitorのアラートルールを作成します。今回は、Azure VM起動時にアラート通知を行うように設定を行います。

1)Azure Portalのメニューでモニターを選択します。以下の画面が表示されますので、新しアラートルールを選択します。

2)アラートルールの作成を行います。最初に監視対象のリソースを選択します。下記画面が表示されますので、リソースの選択をクリックします。

3)リソースの選択画面が表示されます。今回はリソースの種類でフィルターでVirtual Machineを選択します。

4)監視対象のリソースを選択します。監視対象のVMを選択しOKをクリックします。

5)監視条件を設定します。条件の選択をクリックします。

6)シグナルロジックの構成(監視条件の設定)を行います。今回は仮想マシンの起動を選択します。(3ページ目に表示されます。)

7)監視アラートの通知方法を設定します。このアラートルールにアタッチするアクショングループを選択するという項目がありますので、先ほど作成したSMSメッセージのアクショングループを選択します。

8)アラートルールの詳細を設定します。今回はアラートルール名をVM Startで作成します。

アラートルールの作成を行えば、Azure Monitorの設定は完了です。

3.実際にAzure MonitorでSMS通知してみる

実際にAzure VMを起動して試してみました。以下のようにどのVMが起動したかがSMSで通知されます。通知速度的にはメール通知と同時という形でした。

※AlertSMS01はアクショングループの表示名、VM Startはアラートルール名になります。

4.SMS通知の場合の注意点

マイクロソフト様のサイトに記載の通り、SMS通知には5分に1度しか通知出来ない(同じ通知先)というレート制限があります。

https://docs.microsoft.com/ja-jp/azure/azure-monitor/platform/alerts-rate-limiting

このレート制限はアクショングループ単位ではなく、サブスクリプション単位になる為、複数のアラートが発生した場合には、一番最初のアラートだけがSMS通知され、それ以降のアラートが通知されない可能性があります。実際の利用にあたっては注意が必要かと思われます。

認証方法にSSH公開キーを利用しAzure VMにログインする(Cent OS)

 

Cent OSのAzure Virtual Machine(Azure VM)は作成時に、管理者アカウントの認証方式(ログイン方法)を、パスワードかSSH公開キーか選択する事が出来ます。

今回は、以下のサイトを参考に、管理者アカウントの認証方式をSSH公開キーでVMを作成し接続までを試してみました。

https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/ssh-from-windows

今回実施した作業は大きく分けて3段階になります。

1)PuTTYgenを利用して公開鍵、秘密鍵を作成する。

2)1)で作成した公開鍵を利用して、Azure VMを作成する。

3)1)で作成した秘密鍵を利用して、作成したAzure VMにログインする。

1.PuTTYgenを利用して公開鍵、秘密鍵を作成する

PuTTYがインストールされていない場合は、下記サイトよりダウンロードしてインストールします。

https://www.putty.org/

※Download PuTTYに、You can download PuTTYとありますので、こちらをクリックするとダウンロードのページに移動します。Package filesとありますので、こちらからダウンロードします。(通常のWin環境であれば64bitのMSIファイルで良いかと思います。)

1)PuTTYgenを起動し、Generateをクリックし、公開鍵と秘密鍵を作成します。

※空白部分でマウスを動かさないとKeyが生成されませんので注意して下さい。

2)作成されたら、公開鍵、秘密鍵をそれぞれ保存します。公開鍵はSave Public Key、秘密鍵はSave Private Keyをクリックして行います。

これでPuTTYgenを利用した鍵の発行作業は完了です。

2.Azure VMの認証方法でSSH公開キーを選択する

Azure VM作成時の認証方法でSSH公開キーを選択する場合の設定になります。

先ほど保存した公開鍵のファイルをテキストエディタで開き、オレンジ色の部分をコピーします。

—- BEGIN SSH2 PUBLIC KEY —-
Comment: “rsa-key-20200705”
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
—- END SSH2 PUBLIC KEY —-

Cent OSのAzure VM作成時に管理者アカウントの認証方法でSSH公開キーを選択すると下記画面が表示されますので、下記の通り入力します。

    • ユーザー名は管理者アカウント名を入力します。
    • SSH公開キーのソースは既存の公開キーを選択します。
    • SSH公開キーには、PuTTYgenで発行した、公開鍵情報をコピペします。

後は通常通りAzure VMの作成を行えば、作業は完了です。

3.SSHキー(秘密鍵)を利用してAzure VM(Cent OS)にログインする

作成したAzure VMに、PuTTYを利用してログインします。(認証方法にSSH公開キーを設定した場合、サーバ上に公開鍵が配置されます。ですのでログイン時に使用するのは秘密鍵になります。)

1)PuTTYを起動し、接続先IPアドレス(もしくはホスト名)を入力します。

2)PuTTYのCategoryでAuthを選択すると下記画面が表示されます。最初に作成した秘密鍵を指定します。(SSHログイン時に利用する秘密鍵になります。)

3)PuTTYでOpenをクリックし、Azure VMに接続します。下記画面が表示されますので、管理者アカウントにユーザー名を入力してください。

この方法で、認証に公開SSHキーを利用してAzure VMにログインが出来ました。

4.認証方法にSSH公開キーを利用した場合の注意点

Azure Portalのシリアルコンソールを利用してログインする場合、認証方法にSSH公開キーを設定したユーザーは利用できません。(2020年7月5日現在)

シリアルコンソールを利用するには、別途パスワードでログインできるユーザーを作成する必要があります。

なお、rootアカウントのパスワード設定方法はこちらの記事に記載しております。

Azure VMのroot初期パスワードについて(Cent OS)

Azure VMのroot初期パスワードについて(Cent OS)

 

Cent OSのAzure Virtual Machine(Azure VM)を作成した場合、rootアカウントの初期パスワードは非公開となっておりAzure VM作成時点では分かりません。

では、どうするのか? 

自身が作成した初期アカウントにはsudoの権限が付与されています。このsudo権限を利用してrootになり、root自身としてパスワードの初期化を実施する事でパスワードを設定する事が出来ました。

今回は、その手順を記載します。

1.Azure VMのrootのパスワードを設定する

1)まずAzure VM作成時に設定したアカウントでOSにログインします。

2)sudo su -でルートになります。この際にパスワードを聞かれます。Azure VM作成時に設定したユーザーのパスワードを入力します。

[user@test-vm ~]$ sudo su –
Password:  #Azure VM作成時のユーザーパスワード
[root@test-vm ~]#

3)rootになれたら、passwdコマンドでパスワードの初期化を行います。

[root@test-vm ~]# passwd
Changing password for user root.

New password: #新規設定するrootのパスワードを入力
Retype new password: #新規設定するrootのパスワードを再入力

これでrootのパスワードが設定できました。

2.Azure VMのrootのパスワードを設定する(keyでログインした場合)

Azure VM作成時にパスワードでは無く、keyで設定した場合にはどうなるでしょうか?

この場合も同じ方法で設定可能です。sudo実行時にパスワードを聞かれません。

sudo su -でルートになり、passwdコマンドでパスワードを初期化します。

[root@test-vm ~]# sudo su –

[root@test-vm ~]# passwd
Changing password for user root.

New password: #新規設定するrootのパスワードを入力
Retype new password: #新規設定するrootのパスワードを再入力

同じくrootのパスワードが設定できました

3.初期作成アカウントのsudo権限を剥奪する

Azure VM作成時の初期アカウントには、sudo権限が付与されています。

セキュリティ面を考えると、sudo権限を剥奪しておいた方が良いと思われます。

今回はこちらの手順もあわせて記載します。

初期作成アカウントのsudo権限は、/etc/sudoers.d/waagentにて定義されています。これをコメントアウトする事でsudo権限が剥奪出来ました。

[root@test-vm ~]#vi /etc/sudoers.d/waagent

#コメントアウトします。

username ALL=(ALL) ALL

#username ALL=(ALL) ALL

これでsudo権限を剥奪する事が出来ました。

※sudo権限の剥奪は必ずrootアカウントのパスワード設定後に実施して下さい。

認証方法にSSHキーを用いた場合はこちらで試しております。

認証方法にSSH公開キーを利用しAzure VMにログインする(Cent OS)

その他に初期設定を下記にも記載しております。参考にしていただければ幸いです。

Azure VMデプロイ直後のOS初期設定(CentOS 7.5編)

Azure Database for MariaDBを使ってCactiを構築してみた

 

今回は、Azure環境上に、Cactiをセットアップしてみました。Cent OS 7.7のAzure VMとAzure Database for MariaDB(10.3)を組み合わせて構築してみました。

今回構築したシステム環境は下記の通りになります。

    • CactiサーバはAzure VMを利用 (Market Placeからデプロイしたものを利用)
    • CactiサーバのOSはCentOS 7.7を利用
    • DBはAzure Database for MariaDB を利用
    • パッケージはRPMを使ってセットアップする

実際にやってみるとわかるのですが、Cactiセットアップ時の事前チェック(MySQLのパフォーマンス部分)で引っ掛かります。今回は勉強の為そのまま作成しています。実環境で使用するには注意して下さい。

なお構築にあたっては下記サイトを参考に進めております。

https://qiita.com/bashaway/items/47d8eb868f31ab3c20e1

1.作業にあたっての事前準備

今回は、以下の事前準備が完了している前提で作業を進めます。

    • Cactiサーバ用のAzure VM(CentOS 7.7)はすでにデプロイ済み。
    • Azure Database for MariaDBはすべてデプロイ済みである。
    • Azure Database for MariaDBのSSL強制は無効化しておく。
    • SElinuxやFirewalldは簡略化のため、停止している前提で作業を進めます。

※Azure Database for MariaDBへの接続は暗号化せずに実施しています。Cactiの設定ファイルのDB接続暗号化を設定してみたのですがDB接続でエラーとなりました。現時点では原因不明です。。。(何か情報があれば教えて頂きたい感じです。)

なお、Azure Database for MariaDBの構築は、以下の記事に纏めておりますので、こちらを参照願います。

Azure Database for MariaDBを作ってみた

Azure Database for MariaDBに接続してみた

.パッケージのインストール作業

まず、最初にパッケージのインストール作業を実施します。今回セットアップが必要なパッケージは下記の通りになります。(httpdが入ってない場合は併せてインストールしてください)

    • MariaDB関連のパッケージ (DB自体はAzure Database for MariaDBを利用しますので、Clientだけをインストールします。)
    • Cacti関連のパッケージ
    • その他のパッケージ

まず最初にMariaDBのパッケージをインストールします。

#MariaDBクライアントをインストールします。最初にリポジトリを登録しています。

[user@server ]#curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | bash
[user@server ]#vi /etc/yum.repos.d/MariaDB.repo 

#新規にファイルが作成されますので、以下の内容を貼り付けて保存します。

[mariadb]
name = MariaDB-10.3.14
baseurl=http://yum.mariadb.org/10.3.14/centos7-amd64
# alternative: baseurl=http://archive.mariadb.org/mariadb-10.3.14/yum/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1

[user@server ]#yum -y install MariaDB-client mariadb-devel

次にCactiのパッケージをインストールします。

#cactiをインストールします。epelを利用しています。

[user@server ]#yum -y install epel-release
[user@server ]#yum -y install cacti  

最後にその他に必要となるパッケージをインストールします。

#cactiをセットアップする際に必要となるパッケージをインストールします。

[user@server ]#yum -y install php cacti-spine ipa-*-fonts  

これでパッケージのインストール作業は終了です。

.PHPの設定を行う

PHPの環境設定を行います。

#PHPの設定を行います

[user@server ]#cp -p /etc/php.ini /etc/php.ini.`date “+%Y%m%d”`
[user@server ]#vi /etc/php.ini

#以下の内容を変更しています。

max_execution_time = 60
memory_limit = 800M
date.timezone = ‘Asia/Tokyo’

4.apacheの設定を行う

Cactiを利用する為に、apacheの環境設定を行います。

#httpdの日本語設定を行います

[user@server ]#cp -p /etc/sysconfig/httpd /etc/sysconfig/httpd.`date “+%Y%m%d”`
[user@server ]#vi /etc/sysconfig/httpd

#以下の通り変更します。(オレンジ部分が修正部分になります。)

#LANG=C
HTTPD_LANG=ja_JP.UTF-8

#Cron関連の設定を行います

[user@server ]#vi /etc/cron.d/cacti

#以下の行のコメントアウトを削除しています。

#*/5 * * * * apache /usr/bin/php /usr/share/cacti/poller.php > /dev/null 2>&1
 
*/5 * * * * apache /usr/bin/php /usr/share/cacti/poller.php > /dev/null 2>&1

#confの設定を行います

[user@server ]#cp -p /etc/httpd/conf.d/cacti.conf /etc/httpd/conf.d/cacti.conf.`date “+%Y%m%d”`
[user@server ]#vi /etc/httpd/conf.d/cacti.conf

#17行目をコメントアウトし、オレンジの部分(18行目)を追加します。

14 <Directory /usr/share/cacti/>
15  <IfModule mod_authz_core.c>
16   # httpd 2.4
17   #Require host localhost
18   Require all granted
19  </IfModule>

 

5.Azure Database for MariaDBでCactiを利用する為の設定を行う

事前にCactiをセットアップしているVMからAzure Database for MariaDBへ接続可能なように設定を行っておきます。これは以前のMariaDB接続の記事を参考にして下さい。

Azure Database for MariaDBの画面で、サーバパラメータを選択し設定を行います。

下記画面が表示されます。

サーバパラメータ設定を下記の通り実施します。

    • collation_server:utf8mb4_unicode_ci
    • character_set_client:utf8mb4
    • max_connections:最大(100以上がCacti推奨)
    • max_heap_table_size:最大(30MB以上がCacti推奨)
    • join_buffer_size:最大(60MB以上がCacti推奨)
    • innodb_io_capacity:最大(5000以上がCacti推奨)
    • innodb_io_capacity_max(10000以上がCacti推奨)
    • innodb_read_io_threads:32
    • innodb_write_io_threads:16
    • log_bin_trust_function_creators:ON

上記記載の通り、Cactiの推奨設定にできない内容があります。設定できるものは最大とし、tmp_table_size、innodb_file_per_table、innodb_doublewrite、innodb_buffer_pool_instancesについては設定できない為そのまま進めます。

また、log_bin_trust_function_creators をONにする必要があります。これをONにしないとCactiセットアップ用のSQL実行時にエラーになります。

設定が終わったら保存します。

6.Azure Database for MariaDBにCactiを利用する為の設定を行う

Azure Database for MariaDBの設定が終わったら、次にDB自体にCactiを利用する為の設定を行います。

サーバ名、サーバ管理者名はAzure Database for MariaDBの概要で確認します。

確認した値で、DBサーバに接続し、データベースとDBユーザーを作成します。DBユーザーはcactiで作成しています。DBユーザーを@Localhostで作成すると外部からアクセスできないので、今回はcactiをインストールしたサーバが接続に行くIPを設定します。DBユーザーのパスワードは適時設定して下さい。

#DBログイン時にAzure Database for MariaDBサーバ管理者のパスワードが必要になりますので適時入力してください。

[user@server ]#mysql -h サーバ名 -u サーバ管理者名 -p –ssl

MySQL [(none)]>create database cacti ;

MySQL [(none)]> garnt all on cacti.* to cacti@アクセス元のIP identified by ‘パスワード’;

MySQL [(none)]> garnt select on mysql.time_zone_name to cacti@アクセス元のIP identified by ‘パスワード’;

MySQL [(none)]> quit

次に、cactiの初期設定を行うSQLを流します。(PATHはセットアップしたバージョンに合わせて適時修正して下さい)

#Cactiの初期設定用SQLを実行する。

[user@server ]#mysql -h サーバ名 -u cacti cacti -p –ssl </usr/share/doc/cacti-1.2.12/cacti.sql

7.CactiのConfを設定する

config.php、spine.confにDB接続のための設定します。

#設定ファイルのバックアップを取得してから設定します。

[user@server ]#cp -p /usr/share/cacti/include/config.php /usr/share/cacti/include/config.php.`date “+%Y%m%d”`
[user@server ]# vi /usr/share/cacti/include/config.php

#設定箇所は、下記の3か所です。

$database_hostname = サーバ名(XXX.mariadb.database.azure.com)
$database_username = ユーザ名(cacti@XXX)
$database_password = パスワード(DB上に作成したCactiユーザのパスワード)

#設定ファイルのバックアップを取得してから設定します。

[user@server ]#cp -p /etc/spine.conf /etc/spine.conf.`date “+%Y%m%d”`
[user@server ]# vi /etc/spine.conf

#設定箇所は、下記の3か所です。

DB_Host = サーバ名(XXX.mariadb.database.azure.com)
DB_User = ユーザ名(cacti@XXX)
DB_Pass = パスワード(DB上に作成したCactiユーザのパスワード)

8.cactiを起動する

Cacti(httpd)に関するサービスの起動設定を行います。

#cactiはhttpd上で動作する為、httpdサービスを起動設定をします。

[user@server ]# systemctl start httpd
[user@server ]# systemctl enable httpd

9.Cactiにアクセスして設定をする

Cactiにアクセスし利用開始設定を行います。初期設定では下記の通りになっています。

    • アクセス先URL : http://CactiサーバのIP/cacti/
    • ユーザー名、パスワード:admin

URLにアクセスすると下記画面が表示されます。ユーザー名、パスワードを入力しログインします。

確認し問題が無ければ、Accept GPLのチェックボックスにチェックを入れて開始をクリックします。

Cactiインストールの事前チェックが行われます。MySQL Settingの部分がNGになります。

これは、Azure Database for MariaDBで設定できない部分がある為です。今回は勉強の為に作成していますので、無視して次にをクリックします。

ここから先はそのまま次にをクリックして前に進めます。(実際の利用開始時に設定を見直します。)

Template Setupはすべてチェックを入れて次にをクリックします。

そのまま次にで進めていくと、確認画面が表示され、インストールが開始されます。

完了すると、下記画面が表示されます。これでCactiのセットアップは完了です。

※今回は勉強の為実施しております。実際の利用にあたってはパフォーマンス面や各種設定をご確認の上、利用可否を検討願います。



Azure Database for MariaDBのTime Zone設定をしてみた

 

Azure Database for MariaDBのTime Zone設定ですが、何もせずにAzure Portalを利用してサーバパラメータの設定を行うとエラーになります。

今回はAzure Database for MariaDBのTime Zone設定について、一連の作業実施内容のメモを記載します。

1 .Azure Database for MariaDBでTime Zoneを設定するとエラーが表示される

まず、いつも通りサーバパラメータを設定してみます。

設定のサーバパラメータを選択すると、下記のようにMariaDBのパラメータが表示されます。

下の方に行くと、TimeZoneの設定があり、デフォルトでは下記の通りsystemが表示されています。

これを下記の通り、Asia/Tokyoに設定し、保存してみます。

そうすると、以下のようなメッセージがAzure Portalに表示され保存ができません。

非常に誤解されそうなエラーメッセージが表示されます。

2 .Azure Database for MariaDBで正しくTime Zone設定をしてみる

調べてみた結果、下記サイトに記載がある通り、事前にストアド プロシージャを呼びだす必要がありました。

https://docs.microsoft.com/ja-jp/azure/mariadb/howto-server-parameters#working-with-the-time-zone-parameter

実際に実施してみます。今回はAzure Database for MariaDBに接続可能なCent OSの端末から実施しています。

#DBログイン時にAzure Database for MariaDBサーバ管理者のパスワードが必要になりますので適時入力してください。

[user@server ]#mysql -h サーバ名 -u サーバ管理者名 -p –ssl

#TimeZoneを引いてみます。初期設定のSYSTEMが戻ってきます。

MySQL [(none)]>select @@time_zone;
+————-+
| @@time_zone |
+————-+
| SYSTEM |
+————-+
1 row in set (0.003 sec)

#TimeZoneのストアドプロシージャを呼び出します

MySQL [(none)]>CALL mysql.az_load_timezone();

ストアドプロシージャを呼び出した後に、再起動するように記載がありましたので、再起動を実行します。

Auzre Portalの概要に戻ると、再起動が表示されますので、こちらをクリックします。しばらくすると再起動が完了します。

再起動後、再度以下のようにTimeZoneを設定し、保存をクリックします。

そうすると、今度はちゃんと保存されました。

DB上でTime Zoneを確認してみます。

#再度DBに接続し、SQLを実行します。

[user@server ]#mysql -h サーバ名 -u サーバ管理者名 -p –ssl

MySQL [(none)]> select @@time_zone;
+————-+
| @@time_zone |
+————-+
| Asia/Tokyo |
+————-+
1 row in set (0.003 sec)

Asia/Tokyoに設定されている事が確認できました。

Azure VMデフォルトのまま作ると危険なのでNSG設定しましょう

 

Azure Portalを使って仮想マシン(VM)をそのまま作成すると、外部からのRDPやSSHアクセスが許可された状態になります。

これはネットワークセキュリティグループ(NSG)の受信規則が、Windowsの場合はRDP(3389)、Linux系の場合はSSH(22)がAnyで許可された状態になる為です。

AzureのパブリッククラウドのグローバルIPに対しては、作成した瞬間から不正なアクセスが来ます。インターネットからのアクセスをすべて許可した状態で放置する事は非常に危険な状態になります。

今回は、実際にやってみて、メッセージが表示される意味や、VM作成作業中に接続許可IPを指定する方法を確認してみました。

なおネットワークセキュリティグループ(NSG)はAzureで接続許可や拒否設定を行うものになります。

1 .仮想マシン(VM)をそのまま作成した際の、ネットワークセキュリティグループ(NSG)設定を確認してみました。

今回は、にAzure PortalでWindowsの仮想マシン(VM)作成を作成する時にネットワークセキュリティグループに関する設定を確認します。

まず基本画面で受信ポートの規則という以下の項目が表示されます。デフォルトこの画面で3389のポートが許可されます。

次にネットワーク画面で、以下の項目がデフォルトで表示されます。

デフォルトはBasicを選択されてます。このままデフォルト設定のまま進んでみます。

この設定のまま仮想マシン(VM)を作成してみます。

作成後、ネットワークインターフェースの設定を確認してみました。

ネットワークインターフェースに対して、NSG(ネットワークセキュリティグループ)が作成されているのですが、受信規則として下記ルールが作成されていました。

AnyでRDP(3389)が受信が許可された状態になってます。RDPでどこからでもアクセスできる状態になっています。

デフォルトのまま進んでしまうと、このように非常に危険な状態になる事がわかりました。

.仮想マシン(VM)と共に作成される、ネットワークセキュリティグループ設定を変更してみる

次に、仮想マシン(VM)作成時のどこで設定するのかを確認してみました。

Azure Portalで仮想マシン(VM)作成時に表示されるメッセージの通りで、基本画面の受信ポートの設定では何もできません。

ネットワークの画面で行います。下記の通りNICネットワークセキュリティグループで詳細を選択します。

ネットワークセキュリティグループの構成で、新規作成をクリックします。

そうすると下記画面が表示されます。ここで受信規則をクリックします。

そうすると下記画面が表示されます。ソースでIPアドレスを選択しますと、ソースIPアドレスが表示されますので、自身がアクセスするIPアドレスを入力します。

IPアドレスや名前等を入力して保管しますと、特定のIPからのみアクセス可能なネットワークセキュリティグループ(NSG)が作成されます。

なお自身のIPアドレスは、下記サイト等で確認が可能です。(Proxy等をご利用の方は社内システム管理者さん等に確認下さい。)

https://www.cman.jp/network/support/go_access.cgi

.そのままにしておくとどうなるのか

自身の経験ですが、実際にそのままにしておくと、5分後位から秒で辞書攻撃的なアクセスが来ました。

検証環境だから、すぐ消すからとか言ってそのままにしている事を多くみかけますが、要件が無い限り、ログイン元のIPアドレスは制限するようにした方が良いかと思います。

使う時しか上げないとかって、絶対に忘れますから!!

※実際のシステムではサブネットや、すでに作成済みのネットワークセキュリティグループ(NSG)を使うケースが多いと思いますが注意しましょう。