ドキュメント読んだり、説明されればそりゃーそうだっと納得できるのですが、説明されるまでは勘違いしていたのでメモしておく。

詳細説明は「公式ドキュメント」でされているので、そちらを参照して欲しい。

セカンダリへの反映は一定量の変更をセカンダリにトランザクションログを用いてします。
反映対象は、トランザクションが完了したものになります。

アクティブ geo レプリケーションは SQL Server の Always On テクノロジーを活用し、スナップショット分離を使用してプライマリ データベース上のコミットされたトランザクションを非同期的にレプリケートします。

特定の時点におけるセカンダリ データベースは、プライマリ データベースよりもわずかに古い可能性がありますが、セカンダリ データには部分トランザクションが含まれないことが保証されます。

トランザクションが完了すれば反映対象となるので、順番が前後するとつらい操作はトランザクションにする必要があります。

例えば、メンテナンス作業で、インデックスの再構成をする場合には、統計情報の自動更新が重ならないようにしておいたほうがいいので、統計情報の自動更新を停止することがあります。

マスターで、自動更新の停止、インデックスの再構成、自動更新の再開をすると、セカンダリーにも、自動更新の停止、インデックスの再構成、自動更新の再開が適用されます。

ただし、インデックスの再構成の実行時間によっては、セカンダリでは、自動更新の停止、自動更新の再開、インデックスの再構成の順番で適用されることがあります。
これがまずい場合には、「自動更新の停止、インデックスの再構成、自動更新の再開」で一括りのトランザクションにしましょう。

redash で、データソースにSQL Serverを選択し、Azure SQL Databaseに接続しようとすると以下のようなエラーが出ることがあります。

Cannot open server “1433D” requested by the login. The login failed.DB-Lib error message 20018, severity 20: General SQL Server error: Check messages
from the SQL Server DB-Lib error message 20002, severity 9: Adaptive Server connection failed (xxxxxxxxxxxxx.database.windows.net:1433)

これは、SQL Server とは違って、Azure SQL Databaseの実装上の違いによって生じています。SSMSであれば、明示的に指定しなくても自動的に裏側でしれくれるのですが、redashの場合には明示する必要があります。

接続先サーバー名が、xxxxServerName.database.windows.net と仮定すると、
Userには、「analysis@xxxxServerName」のように指定する必要があります。

もちろん、analysisの部分はあなたのDBのログインに置き換えてください。太字のように、@以下にサーバーのホスト名を指定します。

Azure Data Factory v1 で作成したジョブを日次バッチで動かすときの罠について説明します。

Azure Data Factory v1 でのトリガータイミングの指定画面は次のようになっています。

この画面では、Dailyでevery 1 day となっています。
Start date time (UTC)を指定するようになっています。

罠１　画面で日時（Daily）を選択すると必ずUTC12時に実行される

この画面だけ見ると、Start date time (UTC)で指定した時間に実行され、以後24時間おきに実行されるように見えます。

実際は、UTC12時、日本時間朝9時に実行されます。

ドキュメントを確認すると、以下のように記述されています。

既定では、毎日 ("frequency": "Day", "interval": 1) のスライスは UTC 時 12 AM (午前 0 時) に開始します。 開始時刻を 6 AM UTC にするには、次のスニペットに示すようにオフセットを設定します。

GUIで設定すると、Dailyの場合は必ず、UTC0時なので日本時間9時になります。
これを変更するには、Offsetを指定しないといけないのですが、画面からは指定できなくて、JSONを修正する必要があります。

罠２　JSON（Availability）を更新して、offsetを追加しようとするとサポートしてないとエラーがでる

offsetを指定して更新しようとすると、次のようなエラーが出ます。

Updating the availability section of a Dataset is not supported. Existing availability configuration: Frequency=Day, Interval=1, AnchorDateTime=01/01/0001 00:00:00, Offset=06:00:00, Style=StartOfInterval, new availability configuration: Frequency=Day, Interval=1, AnchorDateTime=01/01/0001 00:00:00, Offset=07:00:00, Style=StartOfInterval.

機能提供されていませんよと……なんとまぁ。
ちなみに大昔に改善要望が出ています。

How can we improve Microsoft Azure Data Factory?

現時点で対応されていないですし、きっと今後も対応されないでしょうね。
設定するには、再作成してねっと案内されています。
「The work-around is to delete the datasets and related piplelines and re-create them with the new settings. 」

罠3　availabilityにOffsetを追加したら、activitiesのschedulerにも追加しないといけない

仕方ないので、Outputを消して再作成して、Offsetを追加しました。
すると今度は、PipelineのactivitiesのschedulerにもOffsetを追加しないとエラーになりました。

罠4　Start date time (UTC)に過去日を指定すると、そこを起点にスライスされて、複数処理されてしまう

再作成するから、オリジナルをコピペするじゃないですか？
そーすると当然StartTimeが以前の古い日付になってるじゃないですか？
怖いことが起こりそうです。

パイプラインには過去の開始日を設定できます。 設定した場合、Data Factory によって過去のすべてのデータ スライスが自動的に計算 (バックフィル) され、処理が開始されます。 たとえば、開始日が 2017-04-01 のパイプラインを作成し、現在の日付が 2017-04-10 だとします。 出力データセットのパターンが 1 日ごとの場合、開始日が過去であるため、Data Factory は 2017-04-01 から 2017-04-09 までのすべてのスライスの処理をすぐに開始します。

 

やめて、、、、、事故になる（汗
再作成するときには、ちゃんと、Pipelineの「Start」を適切な日付にしましょう。

結論　V2素晴らしい

これがV2のトリガーの指定画面です。
日次で何時に実行するかというのがしっかりと指定できます。素晴らしい。

DatadogのAzure Integuretaionが強化され、Cosmos DB、Service Bus、Azure DB for MySQL / PostgreSQLなど60以上のAzure サービスに対応しました。Datadogは一つのインテグレーションでAzure統合監視を提供するために、Azure Monitorでサポートしている全てのサービスからタグとメトリックスを自動的に収集します。Azure Service Fabricにも正式に対応しました。DatadogのAzure VMエクステンションがService Fabricの自動スケールノード上で直接Datadogエージェントのデプロイを可能にしました。

既存でサポートしていたサービス、Azure ClassicとARM仮想マシン、Azure SQL Database、Azure App Serviceの上に追加で強化されました。Microsoft IISやWindows Management Instrumentationとの統合により、幅広いWindowsとWindowsエコシステムを可視化します。

タグ付けの改善

Azure Monitorの多次元メトリックが時系列データとして一つ以上の次元と属性を取得できます。それらのデータをDatadogインテグレーションはタグとして取得し、slice、group、フィルターを可能にします。

例えば、Blobストレージへのリクエスト数を追跡するTransactionsメトリックスでは、Azure Monitorは、ResponseType、GeoType、APINameを返します。

Datradogは自動的に、メトリックをkey:value形式に変更します。（例　responsetype:success）それらのタグを使用して、ダッシュボードやアラートでAzureインフラについて深い見識を得るのに使用できます。

次の例では、Blobストレージアカウントでトランザクション数を取得し、API名とレスポンス種類でブレイクダウンできます。

Azureは、REST API、Azure CLI、PowerShell、Azureポータルからリソースにkey:valueタグを設定できます。

Datadogは自動的にカスタムタグを収集し、それらをメトリックと関連付け、フィルターやグルーピングしてグラフやアラートを作成するのに使用できます。

Microsoftは最近、デプロイ、実行、スケールするKubernetesクラスターをマネージドサービスである、Azure Kubernetes Service(AKS)をリリースしました。追加設定不要でAKSインフラの総合的可視化をAzure MonitorとKubernetes のDatadogインテグレーションで実現できることを紹介します。

Datadogのインテグレートは、ヘルス状態、Docker、Kubernetes、Azure VMのリソースメトリックスを一つのスクリーンボード上で、簡単に可視化できます。

AKSでの動作方法

AKSは、Kubernetesクラスターを自動的にプロビジョニング、メンテナンス、スケールさせます。クラスター内のマスターノードを管理し、独自のコンテナーアプリケーションを、Azure VMノード、永続化ストレージ、仮想ネットワークのトラフィックルーティングなどに対応して実行します。
クラスターをスケールまたはアップグレードすると、AKSは確実に起動する処理を実施します。一つ以上の可用性セットにノードを配置すれば、各ノードで障害が発生してもアクセスができるように維持します。

クラスター用にAKSが自動的に作成したリソース

新しいAKSクラスターを作成すると、既存のリソースグループか新しいリソースグループに、必要なリソースが追加されます。Azure CLIを使用してAKS詳細を管理できるようkubeconfigファイルに書き込みます。一度、クラスターが起動すれば、kubectlやKubernetesダッシュボードでマニフェストの適用や管理タスクを処理できます。

AKSをDatadogで監視する

Kubernetes、Azure、コンテナーインフラ上で動作している全てのサービスからログと分散リクエストトレース、メトリックスを収集して、AKSのフル可視化をDatadogが可能にします。

AKSをDatadogで監視を始めるために、AzureとKubernetesのインテグレーションを設定する必要があります。Datadogが提供するYAMLマニフェストを使用してAKSクラスター内に、デーモンセットとしてDatadogエージェントをコンテナー化してデプロイします。AzureポータルとDatadog UIからAzureでDatadogに接続します。

Datadogエージェントの自動ディスカバリー機能がAKSで動かしているサービスとpodをトレースし続けます。

自動タグ付け

Datadogで、ほかの250種類以上に対応している監視できるテクノロジーと同じ場所で、AKSクラスターを監視できます。Datadogは自動的にリソースグループ、Kubernetes pod、Docker imageを含むAzure、Docker、Kubernetesからタグを取得します。AKSクラスターからデータを見るためにタグを使用できます。上の例では、Kubernetesサービス名とAzureリソースグループでフィルタリングして、クラスター内のコンテナーに出入りするネットワークトラフィックを比較しています。

コンテナーのヘルス状況概要をタグ（pod、可用性ゾーン、リソースグループなど）でグルーピングして、ダッシュボードにコンテナーマップとして追加できます。AKSクラスターがユーザーの行動や変化や、需要変化に応じてコンテナーのスケールアップ/ダウンをすると、自動的にコンテナーマップもリアルタイムにアップデートされて反映されます。

Kubernetesデプロイメントマニフェストの変更を反映するためにDatadogのコンテナーマップが更新される様子

ライブコンテナーとプロセス

数百から数千のコンテナーをKASで動かしている場合、DatadogのLive コンテナービューが、デプロイから流入するすべての運用データを素早く調べるのに役立ちます。Liveコンテナービューはリアルタイムにヘルスやリソース状況、すべてのクラスターのステータスなどAKSクラスターに関する情報を提供します。リソースメトリックスやグラフは、簡単にCPU使用率が高いや、メモリ使用率が高いコンテナーを探しだせます。

次の例では、resource_groupタグを使用して、特定のAKSクラスターを選択し、Kubernetesタグ「kube_service」でドリルダウンして、アプリケーションのフロントエンドサービス用のコンテナーのみを表示しています。

ライブプロセスモニタリングを設定すれば、ライブコンテナービューでプロセスやサブプロセスの階層関係を見たり、リソースをどれぐらい使用しているかを見ることができます。