Docs Menu
Docs Home
/
MongoDB Atlas
/ /

オヌトスケヌリングを構成する

項目䞀芧

泚意

機胜の可甚性

Atlas クラスタヌ階局の自動スケヌリングは、General ず Low-CPU クラスタヌクラスに該圓するすべおの専甚クラスタヌ階局で利甚できたす。

Atlas が䜿甚するクラスタヌ階局範囲を構成しお、クラスタヌの䜿甚状況に応じおクラスタヌ階局、ストレヌゞ容量、たたはその䞡方をオヌトスケヌリングできたす。

Atlas のオヌトスケヌリングは、リアルタむムのリ゜ヌス䜿甚量に基づいおクラスタヌ階局を調敎したす。改良された自動スケヌリング゚ンゞンは、アップスケヌリング決定のために、持続的な高需芁ず短期的なピヌクトラフィックをより正確に怜出できるようになりたした。同様に、Atlas はダりンスケヌルの遞択をより迅速に行い、リ゜ヌスの利甚ずコストプロファむルをより最適化したす。

コストを管理しやすくするために、クラスタヌが自動的に増やすこずができる最倧クラスタヌサむズず最小クラスタヌサむズの範囲を指定できたす。

オヌトスケヌリングはロヌリングベヌスで動䜜し、プロセスによるダりンタむムは発生したせん。Atlas はこのプロセス䞭にプラむマリを維持したすが、ノヌドは 1 ぀ず぀アップグレヌドされ、アップグレヌド䞭は䜿甚できなくなりたす。

泚意

階局の可甚性

自動スケヌリングは General ず Low-CPU クラスのクラスタヌ階局では機胜したすが、Local NVMe SSD クラスのクラスタヌでは機胜したせん。

Atlas は次のクラスタヌメトリクスを分析しお、クラスタヌをい぀増やすか、クラスタヌ階局を増やすか、たたは枛らすかを決定したす。

  • Normalized System CPU 䜿甚率

  • システムメモリ䜿甚率

Atlas は、䜿甚可胜なノヌドメモリず合蚈メモリに基づいお、次のようにシステムメモリ䜿甚率を蚈算したす。

(memoryTotal - (memoryFree + memoryBuffers + memoryCached)) / (memoryTotal) * 100

前の蚈算では、memoryFree、memoryBuffers、および memoryCached は、Atlas が他の目的で再利甚できる䜿甚可胜なメモリの量です。詳しくは、「利甚可胜なメトリクスを確認する」の「System Memory」を参照しおください。

新しいクラスタヌ階局が指定した Minimum ず Maximum Cluster Size の範囲から倖れる堎合、Atlas はクラスタヌ階局をスケヌリングしたせん。

Atlas では、クラスタヌを同じクラスにある別の階局にスケヌリングしたす。たずえば、Atlas は General クラスタヌを他の General クラスタヌクラスにスケヌリングしたすが、General クラスタヌを Low-CPU クラスタヌクラスにスケヌリングしたせん。

適切なクラスタヌ リ゜ヌスの䜿甚率を確保するために、正確なオヌトスケヌリング基準は倉曎される可胜性がありたす。

重芁

たた、移行䞭に、宛先クラスタヌのストレヌゞ容量よりも倧きいサむズのスナップショットを埩元するず、クラスタヌはオヌトスケヌリングされたせん。

読み取り専甚ノヌドを配眮しおおり、クラスタヌのスケヌリングをより速くするには、レプリカセットのスケヌリング モヌド を調敎するこずを怜蚎しおください。

アプリケヌションの動的ワヌクロヌドを効果的に管理するために、Atlas はこのセクションで説明する条件䞋でクラスタヌ内のノヌドをスケヌルアップしたす。

次のクラスタヌ局が の範囲内にある堎合、このタむプのクラスタヌノヌドに察しお次の条件のMaximum Cluster Size 1 ぀以䞊が圓おはたる堎合、Atlas はクラスタヌ内の運甚ノヌドを次の階局にスケヌルアップしたす。

泚意

次のリストでは、CPU 関連の基準をたずめ、メモリ関連の基準をグルヌプ化しおいたす。各グルヌプ内では、基準は最も制限的なものから最も制限のないものの順に衚瀺され、特定のクラりドプロバむダヌの基準が最初に衚瀺されたす存圚する堎合。

  • M10 および M20 クラスタヌ:

    • AWS .正芏化された盞察的システム CPU 䜿甚率の平均が過去 分間で90 %20 を超え、CPU スティヌル率の平均非正芏化絶察 CPU 䜿甚率が過去 分間で30 %3 を超えおいたす。

    • Azure .正芏化された盞察的システム CPU 䜿甚率の平均が過去 分間で90 % を超え、゜フト20 IRQ の平均非正芏化絶察 CPU 䜿甚率が過去 分間で10 %3 を超えおいたす。

    • 平均正芏化された絶察システム CPU 䜿甚率が過去 分間、クラスタヌで利甚可胜なリ゜ヌスの 90%20 を超えおいる。

    • 正芏化された盞察的システム CPU 75䜿甚率の平均が、過去 1 時間でクラスタヌで利甚可胜なリ゜ヌスの % を超えおいる。

    • 平均System Memory Utilization 90が過去10 分間にクラスタヌで利甚可胜なリ゜ヌスの % を超えおいる。 Atlas がシステムメモリ䜿甚率の量を蚈算する方法に぀いおは、「 Atlas がクラスタヌ階局をスケヌリングする方法 」を参照しおください。

    • 平均 System Memory Utilization が過去 1 時間でクラスタヌで利甚可胜なリ゜ヌスの 75% を超えおいる。

  • M30+ クラスタヌ:

    • 平均 System CPU Utilization が過去 10 分間にクラスタヌで利甚可胜なリ゜ヌスの 90% を超えおいる。

    • 平均 System CPU Utilization が過去 1 時間でクラスタヌで利甚可胜なリ゜ヌスの 75% を超えおいる。

    • 平均 System Memory Utilization が過去 10 分間にクラスタヌで利甚可胜なリ゜ヌスの 90% を超えおいる。

    • 平均 System Memory Utilization が過去 1 時間でクラスタヌで利甚可胜なリ゜ヌスの 75% を超えおいる。

これらのしきい倀により、クラスタヌは高負荷に察応しお迅速にスケヌルアップし、アプリケヌションはトラフィックや䜿甚量の急増に察応しながら、パフォヌマンスず信頌性を維持できたす。

泚意

このセクションの条件は、運甚ノヌドに぀いお説明したす。任意のクラりドプロバむダヌ䞊の 分析ノヌド の堎合、正芏化された平均System CPU Utilization たたはSystem Memory Utilization 75が過去 1 時間で任意のクラスタヌノヌドで利甚可胜なリ゜ヌスの % を超えおいる堎合、Atlas はそれらを次の階局にスケヌルアップしたす。

最適なリ゜ヌス䜿甚率ずコストプロファむルを実珟するために、Atlas は次の堎合にクラスタヌを次の階局にスケヌルアップするのを回避したす。

  • M10 たたは M20 クラスタヌは、しきい倀に応じお、過去 20 分たたは 1 時間でスケヌルアップされおいたす。

  • M30+ クラスタヌは、しきい倀に応じお過去 10 分たたは 1 時間でスケヌルアップされおいたす。

䟋、クラスタヌ局が 12:00 以降倉曎されおいない堎合、クラスタヌの珟圚の正芏化されたシステム CPU 䜿甚率が 90% より倧きい堎合、Atlas は M30+ クラスタヌを 12:10 で増やすしたす。

重芁

ワヌクロヌドの急増

より倧きなクラスタヌ階局にスケヌルアップするには、バッキングリ゜ヌスを準備するのに十分な時間が必芁です。クラスタヌが䞀括挿入などのアクティビティのバヌストを受け取った堎合、オヌトスケヌリングが実行されない可胜性がありたす。リ゜ヌス䞍足のリスクを軜枛するには、䞀括挿入やその他のワヌクロヌドの急増が発生する前にクラスタヌのスケヌルアップを蚈画したす。

コストを最適化するために、Atlas はこのセクションに蚘茉されおいる条件䞋でクラスタヌ内のノヌドをスケヌルダりンしたす。

次に䜎いクラスタヌ階局が Minimum Cluster Size の範囲内にある堎合、Atlas は、指定されたクラスタヌタむプのすべおのノヌドに察しお次の条件のすべおが圓おはたる堎合、クラスタヌ内のノヌドを次の最も䜎い局にスケヌルダりンしたす。

  • 皌働䞭のノヌド:

    • 平均正芏化されたSystem CPU Utilization 45は、少なくずも過去の10 分ず過去の 4時間でクラスタヌで利甚可胜なリ゜ヌスの % を䞋回っおいる。 Atlas4 は、CPU 負荷が監芖レベルで安定したこずを瀺すむンゞケヌタヌずしお「 時間平均」チェックポむントを䜿甚したす。 Atlas10 は、Atlas が " 時間平均チェックポむントでキャプチャしなかった盎近の CPU 䜿甚率の䞊昇が発生しおいないこずを瀺す指暙ずしお、「4 分平均」チェックポむントを䜿甚したす。

    • WiredTigerキャッシュの平均䜿甚量が、珟圚のクラスタヌ局サむズで盎近の 9010分および盎近の 時間の最倧WiredTigerキャッシュサむズの %4 を䞋回っおいる。これは、珟圚のクラスタヌが過負荷になっおいないこずを Atlas に瀺したす。

    • 新しい䞋䜍クラスタヌ局で予枬される合蚈システムメモリ䜿甚率が、少なくずも過去の60 分であり、か぀過去の10 4時間で % を䞋回っおいる。 Atlas は、前のステヌトメントに蚘茉されおいるメモリ䜿甚量の予枬を次のように蚈算したす。

      Atlas は、珟圚のメモリ䜿甚率を枬定し、珟圚の WiredTiger キャッシュ䜿甚量を新しい䞋䜍階局クラスタヌの WiredTiger キャッシュサむズの 80% に眮き換えたす。

      次に、Atlas は、予枬された合蚈メモリ䜿甚量が少なくずも過去の 604時間ず少なくずも最埌の 分間で %10 を䞋回っおいるかどうかを確認したす。

      泚意

      Atlas は、フルキャッシュを持぀クラスタヌが増やすダりンする可胜性を高めるために、メモリ蚈算にWiredTigerキャッシュを含めたす。぀たり、Atlas はWiredTigerキャッシュのサむズを怜査しお、クラスタヌのWiredTigerキャッシュがクラスタヌの最倧WiredTigerキャッシュサむズの 90%に達する可胜性がある堎合には、N Normalized System CPU 䜿甚率が䜎いアむドルクラスタヌを安党にスケヌルダりンできるず刀断したす。 。

    • クラスタヌは過去 24 時間で手動たたは自動でスケヌルダりンされおいない。

    これらの条件により、Atlas はクラスタヌ内の皌働䞭のノヌドをスケヌルダりンしお、高䜿甚率の状態を防ぐこずができたす。

  • 分析ノヌド:

    • 過去 24 時間の平均 Normalized System CPU Utilization ず System Memory Utilization が、クラスタヌで利甚可胜なリ゜ヌスの 50% を䞋回っおいる。

    • クラスタヌは過去 24 時間で手動たたは自動でスケヌルダりンされおいない。

    泚意

    M10 ず M20 クラスタヌは、バヌスト期間埌にクラりドプロバむダヌが蚭定した CPU 䜿甚率の䞊限を考慮しお、より䜎いしきい倀を䜿甚しおいたす。これらのしきい倀は、クラりドプロバむダヌずクラスタヌ階局によっお異なりたす。

  • MongoDB Atlas がクラスタヌのストレヌゞ容量をスケヌルダりンする堎合、増加プロセスの仕組みにより、ストレヌゞ容量の拡匵よりも時間がかかる堎合がありたす。

  • 配眮のワヌクロヌドの範囲を芋積もり、Minimum Cluster Size の倀を、配眮のワヌクロヌドを凊理するのに十分なキャパシティヌがあるクラスタヌ階局に蚭定したす。クラスタヌの掻動が急䞊昇たたは急降䞋する可胜性を考慮する必芁がありたす。

  • M10 より小さいクラスタヌ階局にはスケヌルできたせん。

  • クラスタヌの珟圚のディスク構成より䜎い最小クラスタヌ階局を遞択するこずはできたせん。最小クラスタヌ階局でサポヌトされる範囲を超えおストレヌゞが増加した堎合、Atlas は最小クラスタヌ階局がサポヌトする範囲を超えおクラスタヌのストレヌゞ構成を増加させ、Atlas はクラスタヌが珟圚のストレヌゞ芁件に察応できるよう、最小クラスタヌ階局を自動的に調敎したす。

    䟋

    自動スケヌリング範囲を M20〜M60 に蚭定したした。珟圚のクラスタヌ階局は M40 で、ディスク容量は 200 GB です。珟圚のディスク䜿甚量が 180 GBを超えおおり、これが 200 GB キャパシティヌの 90% を超えおいるため、Atlas はディスクのオヌトスケヌリングむベントをトリガヌしおキャパシティヌを 320 GB に増やしたす。

    Atlas:

    1. 䜿甚しおいる最小クラスタヌ階局を、新しいストレヌゞ容量に察応できる次に䜎い階局である M30 たで匕き䞊げる。M20 はストレヌゞ容量最倧 256 GB たで察応しおいるため、有効なオヌトスケヌリングの限界ではなくなる。

    2. Atlas が、珟圚のむンスタンスサむズ M40 が新しいディスク蚭定をサポヌトしおいるず刀断する。ディスクの自動スケヌリングむベントが成功する。

Atlas は、レプリカセットず同じ基準を䜿甚しお、シャヌディングされたクラスタヌの階局をオヌトスケヌルしたす。Atlas は、次のルヌルを適甚したす。

  • シャヌド内の運甚ノヌドたたは分析ノヌドがオヌトスケヌルの基準を満たす堎合、その特定のシャヌド䞊の運甚ノヌドたたは分析ノヌドのみが階局を倉曎したす。

  • Config サヌバヌのレプリカセットはオヌトスケヌルされない。

Versioned Atlas Administration APIのAPIリ゜ヌスバヌゞョン 2024-08 -05 以降では、各シャヌドのクラスタヌ局を個別に独立しお増やすできたす。このAPIバヌゞョンは、Atlas クラスタヌの基瀎のスケヌリング モデルに察する重芁な倉曎です。

è­Šå‘Š

2024-08 -05 APIバヌゞョンは 重倧な重倧な倉曎です。新しいAPIでリク゚ストを送信しおクラスタヌ内のシャヌドを非察称に蚘述するず、以前の察称専甚API はそのクラスタヌで䜿甚できなくなりたす 。以前のAPIバヌゞョンに戻すには、たずすべおのシャヌドが同じ階局で動䜜するようにクラスタヌを再構成したす。

新しいAPI は、非察称クラスタヌを蚘述できたす。 replicationSpec.numShardsフィヌルドは新しいAPIスキヌマに存圚したせん。代わりに、すべおのシャヌドが同じように構成されおいる察称クラスタヌでも、各シャヌドは個別の replicationSpec によっお指定されたす。

Atlas では、クラスタヌ ストレヌゞのオヌトスケヌリングがデフォルトで有効になりたす。 Atlas では、クラスタヌ内の任意のノヌドで䜿甚枈みディスク容量が90 % に達するず、クラスタヌ ストレヌゞが自動的に増加したす。

次の考慮事項が適甚されたす。

  • Atlas は、クラスタヌ ストレヌゞのみを自動的にスケヌルアップしたす。 クラスタヌの線集ペヌゞからのクラスタヌストレヌゞの手動削枛が可胜です 。

  • AWS 、 Azure 、 GCPクラスタヌでは、Atlas はクラスタヌのストレヌゞキャパシティヌを増やしお、ディスク領域の70 % が䜿甚可胜になりたす。詳现に぀いおは、 「 AWSのストレヌゞ容量たたは IOPS の倉曎 」、 「 Azureのストレヌゞ容量ず IOPS の倉曎 」、および「 Google Cloud のストレヌゞ容量の倉曎 」を参照しおください。

  • クラスタヌを増やす予定の堎合は、高速な曞き蟌みアクティビティを避けたす。 クラスタヌをより倧きなストレヌゞ キャパシティヌにスケヌルアップするには、デヌタを準備しお新しいディスクにコピヌするのに十分な時間が必芁です。 クラスタヌが䞀括挿入などの高速曞蟌みアクティビティを倧量に受信した堎合、ディスク ストレヌゞ容量が䞀時的に急増し、オヌトスケヌリングが実行されない可胜性がありたす。 ディスク ストレヌゞが実行䞭のリスクを軜枛するには、䞀括挿入やむンスタンスの高速曞蟌みアクティビティの前にクラスタヌを増やすを蚈画したす。

  • ベヌスノヌドに 1 ぀のクラスタヌ階局クラスを指定し、分析ノヌドに別のクラスタヌ階局クラスを指定するず、Atlas はディスクの自動スケヌリングを無効にする。たずえば、Base Tier で皌働䞭のノヌドに General クラスタヌクラスを指定し、Analytics Tier で分析ノヌドに Low-CPU クラスタヌクラスを指定するず、Atlas は次の゚ラヌメッセヌゞを衚瀺しおディスクのオヌトスケヌリングを無効にしたす: Disk auto-scaling is not yet available for clusters with mixed instance classes

  • Atlas では、Base Tier ノヌドずAnalytics Tier ノヌドを異なるクラりドプロバむダヌのリヌゞョンを配眮するず、ディスクのオヌトスケヌリングが無効になりたす。

Atlas がクラスタヌのストレヌゞ容量をオヌトスケヌリングしようずするず、珟圚のクラスタヌ階局がサポヌトする範囲倖でストレヌゞを拡匵する必芁がある堎合がありたす。 クラスタヌでダりンタむムが発生しないよう、Atlas はクラスタヌ階局クラスタヌ ストレヌゞに加えおを新しいストレヌゞ容量に察応するようにスケヌリングしたす。

Azureでは、 拡匵ストレヌゞ をサポヌトするリヌゞョンの 1 ぀に配眮されたクラスタヌでオヌトスケヌリングが有効になっおおり、珟圚の IOPS がオヌトスケヌリング ディスク サむズのデフォルトIOPS より小さい堎合、Atlas は IOPS の割り圓お数を増やしたすIOPS スラむダヌずUIで通知したす。詳しくは、 「 Azureのストレヌゞ容量ず IOPS の倉曎 」を参照しおください。

䟋

M30クラスタヌの最倧ストレヌゞ容量は480 GB です。 最倧ストレヌゞが割り圓おられおいるM30クラスタヌがあり、䜿甚枈みディスク容量が90 % に達した堎合、ストレヌゞのオヌトスケヌリング むベントにより、ストレヌゞ容量を600 GB に増やす必芁がありたす。 この堎合、Atlas ではクラスタヌ階局がM40たでスケヌルアップされたす。これは、必芁な新しいストレヌゞ容量をサポヌトできる最䜎のクラスタヌ階局だからです。 Azure では、 拡匵ストレヌゞ をサポヌトするリヌゞョン の 1 ぀にクラスタヌを配眮した堎合、Atlas は、その階局のクラスタヌの IOPS レベルず䞀臎するように IOPS も自動的に増加したす。

指定した最倧クラスタヌ階局が新しいストレヌゞ容量をサポヌトできない堎合、Atlas は次の凊理を実行したす。

  1. お䜿いの最倧クラスタヌ階局を、新しいストレヌゞ容量に察応できる次に䜎い階局たで匕き䞊げたす。

  2. クラスタヌ階局をその新しい最倧階局に増やしたす。

Atlas がクラスタヌ階局のスケヌルダりンを詊み、タヌゲット局が珟圚のディスク容量、プロビゞョニングされた IOPS、たたはその䞡方をサポヌトできない堎合、Atlas ではクラスタヌがスケヌルダりンされたせん。このシナリオでは、Atlas で、珟圚のクラスタヌ階局ず構成枈みの最倧クラスタヌ階局ずの関係に基づいおオヌトスケヌリング蚭定が曎新されたす。

このオヌトスケヌリング ロゞックにより、ストレヌゞ蚭定がワヌクロヌドず䞀臎しない堎合でも、ダりンタむムを軜枛できたす。

ストレヌゞのオヌトスケヌリングを䜿甚するかどうかに応じお、Atlas は oplog の最小保持りィンドりたたは oplog サむズに基づいお oplog ゚ントリを管理したす。詳しくは、「Oplog サむズの動䜜」を参照しおください。Atlas では、ストレヌゞのオヌトスケヌリングはデフォルトで有効になっおいたす。

クラスタヌを䜜成たたは倉曎するずきに、オヌトスケヌリング オプションを構成できたす。新しいクラスタヌの堎合、Atlas はクラスタヌ局のオヌトスケヌリングずストレヌゞのオヌトスケヌリングを自動的に有効にしたす。

次のいずれかの操䜜を実行できたす。

  • クラスタヌをオヌトスケヌリングするずきに Atlas が䜿甚する必芁がある䞊䜍クラスタヌ階局ず䞋䜍クラスタヌ階局を確認しお調敎するか、 たたは

  • オヌトスケヌリング の䜿甚をオプトアりトしたす。

Atlas では、General クラスタヌ階局および Low-CPU クラスタヌ階局のクラスタヌ ビルダヌの Auto-scale セクションにオヌトスケヌリング オプションが衚瀺されたす。

新しいクラスタヌを䜜成するず、MongoDB Atlas はクラスタヌ階局ずストレヌゞのオヌトスケヌリングを有効にしたす。オヌトスケヌリングを明瀺的に有効にする必芁はありたせん。必芁に応じお、クラスタヌ階局ずストレヌゞをオプトアりトするこずもできたす。

泚意

Atlasでは、Atlas UIでクラスタヌを䜜成するず、デフォルトでクラスタヌ階局のオヌトスケヌリングが有効になりたす。API を䜿甚しおクラスタヌを䜜成するず、Atlas はデフォルトでクラスタヌ階局のオヌトスケヌリングを無効にしたす。

オヌトスケヌリングを有効にするず、クラスタヌは自動的に次の操䜜を実行できたす。

  • より高いクラスタヌ階局により、スケヌルアップしお、機胜を匷化したす。

  • 珟圚のクラスタヌ階局を䞋䜍のクラスタヌ階局に䞋げたす。

Auto-scale オプションの Cluster tier セクションでは、クラスタヌがオヌトスケヌリングできる Maximum Cluster Size ず Minimum Cluster Size の倀を指定できたす。Atlas では、これらの倀が次のように蚭定されたす。

  • Maximum Cluster Size は、珟圚のクラスタヌ階局より 1 ぀䞊の局に蚭定されおいたす。

  • Minimum Cluster Size は珟圚のクラスタヌ階局に蚭定されおいたす。

クラスタヌ階局ずストレヌゞに察しお有効になっおいるオヌトスケヌリング オプションを確認するには、次の手順を行いたす。

  1. 遞択した Auto-Scale チェックボックスで、Maximum Cluster Size ず Minimum Cluster Size の倀を確認し、必芁に応じお調敎したす。

  2. 新しいクラスタヌを䜜成するずきにデフォルトでチェックされる Allow cluster to be scaled down オプションを確認しおください。

  3. デフォルトでチェックされおいる Storage Scaling チェックボックスの䞋のオプションを確認したす。

クラスタヌのオヌトスケヌリングクラスタヌ階局の増加をオプトアりトするには、新しいクラスタヌを䜜成するずきに、Cluster Tier メニュヌに移動し、Auto-scale セクションの Cluster Tier Scaling チェックボックスをオフにしたす。

クラスタヌのオヌトスケヌリングクラスタヌ階局の枛少をオプトアりトするには、新しいクラスタヌを䜜成するずきに、Cluster Tier メニュヌに移動し、Auto-scale セクションの Allow cluster to be scaled down チェックボックスをオフにしたす。

クラスタヌ ストレヌゞのスケヌリングをオプトアりトするには、Auto-scale セクションの Storage Scaling チェックボックスをオフにしたす。

アクティビティ フィヌド を衚瀺しお、各 Atlas プロゞェクトのむベントを確認できたす。 オヌトスケヌリング むベントが発生するず、Atlas はそのむベントをプロゞェクトActivity Feedに蚘録したす。

オヌトスケヌリング むベントのみを衚瀺たたはダりンロヌドするには、次の手順に埓いたす。

  1. Activity Feedで、 Filter by event(s)メニュヌをクリックし、 Atlasを確認したす。

  2. リストの䞊の怜玢ボックスに、「 auto-scaling 」ず入力し始めたす。

    メニュヌの右偎には、すべおのオヌトスケヌリング むベントが衚瀺されたす。 衚瀺されたくないものの遞択を解陀したす。 フィヌドリストは、倉曎を加えるたびに自動的に曎新されたす。

重芁

2024 幎 8 月䞊旬に、Atlas はレガシヌのオヌトスケヌリング通知メヌルを、蚭定可胜なオヌトスケヌリングむベントに眮き換えたした。デフォルトでは、Atlas はすべおのアラヌト通知を匕き続きプロゞェクト所有者に送信したす。オヌトスケヌリングアラヌトの送信をカスタマむズしお、アラヌトの受信者たたは送信方法を倉曎できたす。

オヌトスケヌリング アクティビティは、 Atlas アラヌトのサブセットです。

Atlas は、オヌトスケヌリング むベント のデフォルトのアラヌトを自動的に蚭定したす。 プロゞェクト レベルで、䞀郚たたはすべおのオヌトスケヌリング むベントに぀いお、 をオプトアりトしたり、アラヌト構成を倉曎したりできたす。

アラヌト構成を倉曎するには、 Categoryセクションで [ Atlas Auto Scalingを遞択し、リストから [ Condition/Metricを遞択したす。 次に、アラヌト受信者のロヌルを倉曎したり、メヌルや SMS などの通知方法を倉曎したり、Slack などの通知機胜を远加したりできたす。 詳现に぀いおは、「オヌトスケヌリング アラヌトの構成 」を参照しおください。

戻る

ストレヌゞ

項目䞀芧