Monte Carloガイド

概要と目的

Monte Carlo（MC）は私たちのデータオブザーバビリティツールで、より効率的に優れた結果を提供するのに役立ちます。

データの状態を観察するためのデータチームのデフォルトはMonte Carloを使用することです。テスト（Monte Carloではモニターと呼ばれる）の作成はMonte CarloのUIを使用して行われ、通知戦略に従って報告されます。近い将来の別のイテレーションでMonitors as Codeを実装し、これらのテストもバージョン管理される予定です。現在もdbtが既存のテストに使用されており、これらをMonte Carloに移行するロードマップはありません。

Monte Carloの運用方法

MC プラットフォーム関連のアラートには#data-pipelines Slackチャンネルを使用しています。 Monte Carloの完全な通知戦略を実装したらすぐに、モデル関連のアラートには#data-analytics Slackチャンネルを使用する予定です。 この作業はF23Q3向けのこのエピックで計画されています: Analytics EngineersをMonte Carloツールにオンボード

Monte Carloは日次データトリアージの不可欠な部分であり、TDトラステッドデータダッシュボードを置き換えます。

graph TD

mc(Monte Carlo)
sf(Snowflake Data Warehouse)
de(GitLab Team Member)

mc --> |alerts| de
de --> |improves| sf
sf --> |observes|mc

GitLabでのMonte Carloロールアウトをカバーする作業の全体は、エピック100%のTier 1テーブルカバレッジでのデータオブザーバビリティツールのロールアウトによるトラステッドデータ、データ品質、データチームメンバーの効率向上にまとめられています。

ログイン

Monte Carloへのログインはokta経由で行います。https://getmontecarlo.com/signin にアクセスしてください。 ログイン時に以下の画面が表示され、メールを入力して「Sign in with SSO」をクリックすると、Oktaログインにリダイレクトされます。 SSOでログインし、ユーザー名/パスワードではなくSSOを使用してください。

技術的にすべてがどのように設定されているかのRunbookはMonte Carlo Runbookで確認できます。

要点としては、データチームが管理しMonte Carloアプリが割り当てられたokta-montecarlo-usersというOktaグループがあります。 デフォルトでOktaを通じてMonte Carloにアクセスできるようにするには、ユーザーがokta-montecarlo-usersグループの一部である必要があります。 そのためには、ARを提出し（類似のAR: Example AR 1、Example AR 2）、Rigerta Demiri（@rigerta）に割り当てるか、ARにリンクした#dataチャンネルにpingを送ってください。

UIのナビゲーション

ログインすると、監視されているオブジェクトの詳細とすでにセットアップされたいくつかのカスタムモニターが表示されたMonte Carloモニターダッシュボードを確認できます。

新しいモニターを作成したり、定義・スケジュール・関連する異常などの既存のモニターの詳細を表示したりできます。 また、上部メニューバーの「Incidents」メニュー項目をクリックしてすべてのインシデントをリスト表示したり、「Catalog」ビューをクエリして特定のモデルを検索したり、「Pipelines」でデータがソースから本番モデルにどのように流れるかの詳細なリネージ情報を確認したりすることもできます。

ユーザーに割り当てられたロール（デフォルトでSSO経由でログインするすべてのユーザーにViewerロールが割り当てられます）によっては、Settingsを確認して既存のユーザーと統合（Slack統合、Snowflake統合、dbt統合など）を確認できる場合があります。

ロールの更新が必要な場合は、データプラットフォームチームの誰にでも連絡すれば既存のロールを変更できます。

UIのナビゲーションの詳細については、公式Monte Carloドキュメントを参照してください。

新しいモニターの追加

Monte Carloは、アクセスできるすべてのオブジェクトにデフォルトでボリューム、鮮度、スキーマ変更モニターを実行します。 ただし、これらのチェックはツールがデータから学習する更新パターンに基づいており、特定のスケジュールで実行される特定のカスタムチェックが必要な場合は、そのためのカスタムモニターを追加するとよいでしょう。

モニターに関する公式Monte Carloドキュメントはモニター概要ガイドで確認できます。

1つのMonte Carlo Snowflake統合があり、Snowflakeへの2つの別々の接続があります。 最初の接続はsnowflakeと呼ばれ、XSサイズのSnowflakeウェアハウスであるDATA_OBS_WH_1で動作します。 2番目の接続はsnowflake largeと呼ばれ、LサイズのSnowflakeウェアハウスであるDATA_OBS_WH_Lで動作します。

新しいカスタムモニターを追加する際に、最も意味のある接続を慎重に選択してください。 カスタムSQLクエリが合理的な時間内に実行されてタイムアウトを防ぐために本当に必要な場合にのみ、大きなウェアハウスでモニターを実行することを選択してください。

既存のモニターの調整

既存のモニターを修正したい場合は、モニターのタイプに応じて、スケジュール、考慮されるタイムスタンプフィールド、アラート条件などの異なる部分を修正できます。

Slackアラートへの対応

現在、異なるSlackチャンネルで通知を受け取っている場合、Fixed、Expected、Investigating、No action needed、False positive（No statusはMonte Carloのデフォルトステータス）から選択してステータスを割り当てることで、Slack経由でIssueをトリアージできます。 調査して結果が出たら、同じ通知スレッドにSlackでコメントを書くと、そのコメントはMonte Carlo上のインシデントに自動的に追加されます。

私たちの目標は、Monte CarloをGitLabと統合して、Slackでアラートを受け取るたびにGitLabで自動的にトリアージIssueが開かれ、データトリアージ手順と同じ手順に従えるようにすることです。

Slackでアラートに応答する方法については、公式Monte Carloドキュメントにビデオセクションを含む詳細情報がこちらにあります。

インシデントステータス

各Monte Carloインシデントには常にステータスがあります。どのステータスをいつ使用するかは以下のリストを参照してください:

異常検出モデルへのフィードバックの提供

Monte Carloの異常検出モデルに影響を与える唯一の2つの方法は、Monte Carloドキュメントのトレーニングデータセクションに記載されています:

1. 正常としてマークする: 異常はモデルをトレーニングするデータセットから自動的に除外されます。これはインシデントのステータスそのものではなく、Monte Carloのアラートグラフをホバーすることでアクセスできる特定の機能です
2. トレーニングデータを選択する: モニターのグラフと対話することで、ユーザーはモデルのトレーニングからデータの期間を除外できます。

Monte Carloでアラートを「正常」としてマークすると、アラートをトリガーした異常なデータポイントが異常検出モデルのトレーニングセットに再導入されます。これにより閾値が広がり、同様の異常が将来アラートをトリガーしなくなります。 このアクションの主な結果は:

• 閾値の調整: システムの検出閾値は、正常と識別したパターンに合わせて自動的に広がり、同様のイベントのアラートノイズが減少します。
• モデルの再トレーニング: 異常検出モデルはこのデータポイントが「正常な」パターンの一部として含まれた状態で再トレーニングされ、将来の異常検出に影響します。
• アラートノイズの削減: 以前は異常としてフラグされていたが実際には予期された動作を表す同様のパターンに対するアラートが減少します。

アラートを正常としてマークするタイミング

アラートを正常としてマークすべき場合:

• ビジネスの予期された変化: 統計的な観点からは有効な異常でしたが、パイプライン変更や計画されたメンテナンスなど予期された何かの結果でした。
• 非Issue: 同様の異常に対してこれ以上アラートを受けたくない場合、なぜならそれらは実際のデータIssueではなく通常のビジネスパターンを表すためです。
• 繰り返しパターン: システムには異常に見えるが実際には定期的なビジネスサイクルであるパターン（ボリュームスパイクを引き起こす月次処理ジョブなど）。

アラートステータス（「Expected」、「No action needed」、「False positive」）は閾値を生成するモデルへのフィードバックを提供しないことに注意することが重要です。提供されたアラートステータスに基づいて閾値は変更または調整されません。

DWH権限に関する注意

Monte CarloをSnowflakeと統合するために、監視する必要があるデータベースごとに公式ドキュメントで指定された権限スクリプトを実行する必要がありました。

これはPermifrostを使用する通常の権限処理手順の例外です。オブザーバビリティ権限はPermifrostのエッジケースであり、ツールではまだサポートされていないためです。

監視戦略

デフォルトでは、特定の理由がない限り、または契約で指定された制限に達しない限り、Monte CarloでRAW、PREP、PRODデータベースのすべてのテーブルを監視します。

サンドボックススキーマの除外

サンドボックス環境は通常テストの目的で作成されます。トリアージSlackチャンネルでアラートが来ても通常はアクションを取りません。そのため、sandboxを含むスキーマの監視を除外してアラートを受け取らないようにしています。

通知戦略

すべてのインシデントはMonte Carloインシデントポータルで報告されます。トリアージ目的のために最も重要なものはSlackにルーティングされます。

* COMMONはCOMMON_RESTRICTED同等品でもあります。COMMON_PREPとCOMMON_MAPPINGを除外します ** WORKSPACE-DATA-SCIENCEは通知戦略に含める唯一のワークスペーススキーマです *** LEGACYスキーマのこれら2つのモデル（snowplow_structured_events_400とsnowplow_structured_events_all）のみが、MR !7049に従って一時的に含まれています

この通知戦略はMonte CarloからSlackへのアラート送信の基準です。ただし、Notifications 2.0以降、Monte CarloはAudiencesを導入しています。

ドメイン

Monte Carlo環境でドメインを使用できます。現在ドメインは別々のチームメンバー向けに別々の環境を作成するために使用できます。

ドメインの使用

Monte Carlo UIの右上隅に、特定のドメインまたはすべてのドメインを選択できるドロップダウンボックスがあります。

BI統合

GitLabにMonte Carloを最初にデプロイしたとき、当時使用していたSisenseをデフォルトのBIツールとしました。 しかし、最近Tableauへの移行を開始したため、Monte CarloインスタンスにTableau統合を追加しました。

生モデルからTableauビュー、TableauライブデータソースまたはTableauエクストラクトデータソースなどのTableauオブジェクトへのテーブルとフィールドのリネージを確認できるようになりました。

Sisense統合とTableau統合はMonte Carlo上で共存しており、関連するすべてのSisenseチャートとTableauオブジェクトをリネージチャートで確認できます。

Monte Carloの内部ハンドブックページ

追加の内部情報は内部GitLabハンドブックで確認できます。

ページのソースコードを見る - ページの編集 - please contribute.