皆さん、Elevateコミュニティセッションへようこそ。本日はロジックモニターAPIについて少しお話させていただきます。
もっと簡単に言えば、ロジック モニターの管理だけでなく、組み込みたいあらゆる種類の統合やワークロードを統合および簡素化するために、自動化にどのように活用できるかということです。
それでは、早速始めましょう。今日はAPIエコシステムについて少しお話します。アーキテクチャ認証方式、利用可能なSDKやその他のリソースについて、概要レベルでご説明します。その後、実用的な例のデモをいくつかご覧いただきます。
そこで、リソース管理に関するお客様からの一般的なユースケース、お客様がお持ちの統合とワークフローの一部をどのように強化できるか、そして、環境内で発生しているアラートなどに対して追加のコンテキスト レイヤーを提供するために実践できる自動化のアイデアをいくつかご紹介します。
次に、ドキュメントについても見ていきましょう。LogicMonitorのAPIを実際に使い始めるにはどうすればいいのでしょうか？最初のAPI呼び出しから認証情報の生成までの流れを説明します。
そして最後に、ベストプラクティスの情報をいくつか紹介します。
ここでは、レート制限と統合に関するセキュリティのベストプラクティスについて説明します。
そして、ロジック モニターの価値をさらに高めるために使用できる、さらに重要な情報をいくつか提供します。
ロジックモニターAPIを見てみると、基本的に2つの認証方法に分かれています。つまり、いわゆるレガシー認証方法とでも言うべきでしょうか、厳密にはレガシーではありません。LMV One認証方法と、ベアラートークンを使ったより伝統的な認証方法があります。
ロジックモニターについて考えると、APIは長年にわたり何度も改良されてきました。現在はバージョン3で、顧客向けAPIの最新バージョンであり、どちらの認証方法もサポートしています。
APIへのアクセス方法を見てみると、すべてのAPIがポータルのベースURL（スラッシュ/Santava/Rest）を共有していることに気づくでしょう。つまり、実際のURLにはバージョン番号はありません。バージョンは、ax versionヘッダーの有無によって決まります。あるいは、クエリ内で追加のパラメータ（v equals）を指定して、呼び出したいAPIバージョンの値を指定することもできます。これは、他のAPIとは少し異なりますが、常に最新バージョンのv 3を使用することが重要です。v 3には、パッチメソッドなど、活用したい機能がすべて含まれています。
したがって、デフォルトでは、ロジック モニターの API を使用していない場合は、最新の機能セットが提供されるバージョン 3 から始めることをお勧めします。
SDKや利用可能な様々なモジュールについて見てみると、実際には3つの種類があり、どれを選ぶかはお客様の環境や開発環境によって異なります。多くのお客様にとって、Python SDKは、他のワークフローや統合をサポートするという点で最も機能が豊富です。これは、Pythonには利用可能な既存のライブラリが多数あるためです。しかし、Go SDKも提供しており、APIを活用する必要がある高パフォーマンスアプリケーションに最適です。そして本日は、コミュニティカンファレンスということで、PowerShellモジュールに焦点を当てます。ご存知ない方のために、私はSteve Velardiです。最初のスライドで自己紹介すべきだったのですが、Logic Monitorの主任セールスエンジニアの一人であり、PowerShellモジュールの主要な貢献者兼開発者です。
これの良いところは、Logic Monitorが構築し、Logic MonitorがメンテナンスするSDKとは異なり、PowerShellモジュールは完全にコミュニティによって開発されていることです。そのため、私や他のお客様は、PowerShellモジュールをできるだけ使いやすく、セットアップと使用が簡単なものにするために多大な努力を払ってきました。ここではこれを例として取り上げますが、本日のデモやビデオで紹介する内容はすべてSDKにも当てはまります。この点に留意して進めてください。
したがって、一般的なユースケースを見ると、私たちが目にする多くのシナリオと統合は、これら 5 つの異なるカテゴリに分類されます。
まず、オンボーディングについてです。つまり、顧客や新規サイトのオンボーディング方法に関する標準的な運用手順を策定することです。デバイスのオンボーディング方法、デバイスグループ、アラートルールなどを標準化する必要があります。
そして、オンボーディングが完了したら、どのようにインベントリを管理するかという点も考慮する必要があります。そうですよね？そこで、ライフサイクル管理に関するユースケースをいくつか見ていきましょう。デバイスをどのように削除するか、廃止時にどのようにクリーンアップするか、そして、稼働中のデバイスを把握するために、メタデータやプロパティをどのように追加するかといった点です。
そうですね？そういうことです。それから、プロセス統合についてさらに詳しく見ていきます。変更リクエストの対応状況を確認したり、コンテキストとロジックの監視を改善するためにワークフローを追加したりすることは可能でしょうか？
あるいは、何か追加の自動化も行いたいですね。例えば、オンボーディングや自動化など。アラート処理やコンテキストエンリッチメントなども行いたいと考えています。
そこで、ロジック モニターのコンテキストでの操作メモなどについて見ていきます。また、これらが、ロジック モニター API を既存のワークフローに組み込むための適切な使用例となる可能性についても見ていきます。
まず最初に、ロジックモニターに初めて接続する方法を説明したいと思います。ロジックモニターの設定方法、PowerShellモジュールの設定方法、そして最初にデータを抽出する方法について、簡単なビデオで説明します。それでは早速ご覧ください。
皆さん、さあ、早速始めましょう。まずはロジックモニターAPIへの初回接続から始めましょう。今回の例ではPowerShellモジュールを使用します。SDKもご利用いただけます。
Postman を使うこともできますよね？SDK に関するドキュメントはすべてサポートサイトで公開されており、認証や例も紹介されています。また、PowerShell モジュールについても、GitHub リポジトリにあるドキュメントサイトで機能の使い方を詳しく説明しています。今回の場合は、lm ポータルを使用します。API トークンまたは Bear トークンなど、使用するトークンは既に作成済みで、適切な権限が付与されています。
そうですか？つまり、プラットフォームの特定の部分を管理したり、書き込んだりできるということですね。
これらの項目が揃ったら、Versus Codeに戻ってください。まずはインストールモジュールを実行します。
すでにインストール済みなので、「いいえ」をクリックします。この手順を簡単にお見せしたいだけです。モジュールをインストールすると、認証に使用できる方法が2つあります。
認証情報をキャッシュできます。これは、Microsoft のシークレット管理スイートを使用して、アカウント認証情報のキャッシュ版を安全に保存するものです。これにより、本番環境とサンドボックス環境のアカウント間を移動する場合に、簡単に切り替えることができます。あるいは、connect, lm account コマンドを使用して、接続時にベアラートークンまたは lmv one トークンを指定することもできます。
では、これら2つを作成します。実行すると、既に利用可能なトークン、あるいは新たに作成されたトークンがあることがわかります。これらのアカウントの1つに接続するには、基本的にconnect lm accountコマンドを実行し、そのアカウントに付与した認証情報を参照します。この場合、接続するとLMVトークンに接続されていることがわかります。一方、ベアラートークンで接続する場合も、ほぼ同じプロセスですが、今回はベアラートークンで接続されます。
特定のポータルに接続したら、接続テストを行って、データを取得できるか確認するなど、様々な操作を行います。まずは簡単な例として、デバイスを取得するコマンドを実行します。表示名にはglob式を使って、lm dash, coalで始まるものを取得します。今回の場合は、コレクター名を指定する必要があります。それでは、コマンドを実行してみましょう。すると、コレクター名と、参加者へのウェルカムメッセージ（Elevateの参加者を歓迎する説明）が表示されます。
これで接続設定が完了しました。ポータルの他の機能についても詳しく見ていきましょう。いくつかの自動化ですね。
そうですか？他にも活用したいものがありますね。それから、必要に応じてキャッシュされたアカウントを削除することもできます。APIトークンも削除できます。
とりあえず、ここはそのままにしておきます。でも、全て終わったら、切断してセッションをクリアするだけです。disconnect lm account を実行するだけで、もう「うわっ」なんて言わなくなります。
このコマンドはもう実行できません。まずログインする必要があると表示されます。これは非常に簡単で迅速です。5分以内に起動して実行し、ロジックモニターからプログラムでデータを抽出できるようになります。非常に簡単で、すぐに使い始めることができます。次のデモでは、より実用的なシナリオでこれをどのように活用できるか、さらにいくつかの例を見ていきます。
ロジックモニターへの接続方法とデータの抽出方法を確認しましたので、実際にそのデータを活用し、ロジックモニターから特定の情報を取得するプロセスを改善していきたいと思います。そこで、フィルタリングに関するユースケースをいくつか見ていきましょう。具体的には、ポータル全体を操作して自動化作業を行うことなく、ロジックモニターから必要な情報を絞り込んで抽出する方法です。
では、早速見ていきましょう。さて、セットアップが実行できるようになり、ロジックモニターからデータを取得できるようになりました。次は、これをさらにどう活用するかです。
そうですか？つまり、ロジックモニターから必要なデータを取得する場合、表示名などの単純なプロパティだけであれば、フィルタリングは比較的簡単です。そうですよね？以前も少し見たことがありますね。
アカウントに再接続して、デバイスを手に取って、オブジェクト自体を確認します。そうですよね？
表示名や一部のプロパティといった項目でのフィルタリングは、単一のテキストフィールドで済むため、比較的簡単です。少し複雑になるのは、特定の種類のデータをフィルタリングする際に、リソースに蓄積してきたプロパティを活用したい場合です。デバイスレベルやデバイスグループレベルで設定されたものでも、アクティブディスカバリによって取得されたものでも、そういったものが対象になります。
ロジック モニターに保存される方法は、実際には、さまざまなプロパティのすべてのキーと値のペアのハッシュ テーブルとして返されます。
したがって、それをフィルターを通して抽出するのは、多少難しい場合があります。
ロジック モニターには、特定のエンドポイントの概念があり、具体的には先ほど述べたプロパティなどに対して、高度なフィルターと呼ばれる機能を実行できます。
フィルターの構造化方法は、一部の人にとっては少々分かりにくいかもしれません。そこで、特にPowerShellモジュールでは、フィルターの構築方法に関するガイド付きの手順を用意しました。つまり、今回のケースでは、カスタムプロパティ、またはサイトプロパティに「Ohio asterisk」という文字列が含まれる場所を検索したいとします。その場合のフィルター構築手順は以下のとおりです。build lm filterコマンドを実行すると、フィルター処理したい対象が順を追って示されます。基本的なフィルター処理については既に説明したので、今回は高度なフィルター処理について見ていきます。ここで探しているのはカスタムプロパティです。
当然ですが、検索には様々な演算子がありますが、ここでは特定の値が含まれている場所を見つけたいだけです。そこで「contains」と指定します。そして、探しているプロパティは、先ほどsiteと名付けたカスタムプロパティです。つまり、値はまさに検索したいもの、つまり「Ohio asterisk」になります。
さて、明らかに、追加の and または の組み合わせをタグ付けすることができます。
つまり、サイトをオハイオにして、ホストのステータスを生存か死亡かにしたいということですね。そうですよね？ 何かクリーンアップしてるのかもしれません。
これがフィルターを簡単に構築する方法です。他に条件がないので、「いいえ」を選択します。こうすることで、何をエスケープする必要があるかなどを考える必要がなくなり、フィルターが自動的に構築されます。つまり、特定のフィルターを呼び出すだけで済みます。非常に簡単に実行できます。get lm device コマンドを実行したいだけなら、コマンドが保存したフィルター変数を渡すだけで済みます。
そして、最終的に私が受け取るのは、オハイオ州のサイトが刻印されたすべてのものです。
とてもシンプルですね。実行したコマンドをデバッグフラグ付きで実行してみると、すべてが完了した後には、きれいにフォーマットされたフィルターが表示されます。すべて処理済みなので、実際に何かを構築する必要はありません。複雑なフィルターを構築し、それがロジックモニターAPIに受け入れられるかどうかを検証したい場合に最適です。そしてもちろん、その後はスクリプトやオートメーションで使用できます。文字列として保存することも、フィルタープロパティに直接渡すこともできます。
しかし、これにより、複雑なフィルターを非常に迅速に構築できるようになります。
ポータル内の多数のデバイスに対してメンテナンスなどを行う場合、変更があったものだけをターゲットにしたいという場合がよくあります。例えば、ポータルに5,000台のデバイスがある場合、最近更新したデバイスや変更されたデバイスだけをターゲットにしたい、あるいは元のリストと比較して何が変更され、何が変更されていないかを確認したい、といった状況です。
ここでデルタフラグが役立ちます。ここに戻って「デルタAPI」を検索すると、リンクされているものがすべて表示されます。デルタは、基本的に変更された部分だけを返す差分ビューを作成する方法です。比較するたびにデバイスツリー全体を返す必要がなく、ロジックモニターで実際に変更されたかどうかも確認できます。デルタの呼び出し方法は、このデルタスイッチを使用する方法です。以前と同じフィルターを使用できますが、唯一の違いは、ここで少しフィルターをクリアすることです。これを実行すると、ビルドフィルターと同様に、デルタIDが返されることがわかります。このIDを参照することで、前回実行してから特定のクエリにどのような変更が加えられたかを常に確認できます。
この場合、同じデバイスセットを取得し、最初の5つを選択します。そして、それらの説明を「更新済み」に更新します。これは技術的には既に設定されていますが、ここで更新します。つまり、実際には少し違う「更新済み」にします。
はい、できました。いかがですか？では、これを実行すると、先ほど更新した5台のデバイスが返されます。
元のクエリを実行して何が変更されたかを確認する場合、当然のことながら、これらをすぐに同時に実行することはできませんが、他の自動化やその他の処理が行われている可能性があります。GetLMデバイスをDeltaフラグ付きで実行するだけで済みます。返されるのは変更された情報だけです。これをもう一度実行すると、最後にDelta IDを確認したときから何も変更されていないため、何も返されません。つまり、変更内容が期待どおりに正しく設定されていることを確認するだけであれば、すべてを取得する必要がなくなり、スクリプトのパフォーマンスを向上させる非常に簡単な方法になります。
スライドの最後に、Deltaの記事へのリンクを貼っておきます。繰り返しますが、終わったらすぐにセッションに進んでください。そして、このフィルターデータを使って、メンテナンスモードやオンボーディングなどの作業を進めていきます。それでは、次のデモに進みましょう。
よし。ロジックモニターを接続しました。デルタスイッチなどの機能を使って、変更された箇所の差分表示など、データの抽出と使用ができるようになりました。これで、必要なデータを操作したり調整したりするための基本的な構成要素が揃いました。
では、これらの原則を実際に適用し、自動化アクティビティを組み込んでいきたいと思います。これから見ていくのは、デバイスグループ、オンボーディングサイト、サービスの設定など、様々な機能を一括インポートでどのように活用できるかです。これらの機能を活用することで、Mとアクティビティの作成時やMSPとして新規顧客を獲得した際に、オンボーディング業務を標準化できるようになります。それでは、早速見ていきましょう。フィルタリング方法や目的のデータの見つけ方が分かったので、次は、このモジュールを実際にどのように活用してオンボーディングを行い、ライフサイクル管理を行うかを見ていきましょう。
そうですか？新しい会社を買収したばかりで、その会社のデバイスをロジックモニターに一括インポートする必要がある場合や、現在監視対象になっていないもののインベントリスプレッドシートを誰かから提供され、すぐにオンボードする必要がある場合などです。
これらは、それを実現する方法の例です。そうですよね？あるいは、CMDBでのレイアウトに合わせてフォルダツリーを再構築するだけでも構いません。
そうですか？いずれにせよ、これらはオンボーディングにどのようにアプローチするかという点で、考えるための材料を提供してくれるでしょう。そうですか？ここでの例では、これらはモジュール自体の一部ではないことにお気づきでしょう。そうですか？この場合、これは単なるカスタム関数です。
ただし、ここで行うことはすべて、ドキュメントから抜粋した例ですので、ご理解いただければ幸いです。
コード スニペット ライブラリにアクセスすると、実際に CSV からデバイスをインポートしている様子を確認できます。
この関数全体は、実はここから来ています。デバイスグループ用の関数も同様です。先ほども言ったように、このドキュメントには、参考として活用できる優れた実用的な例が数多く掲載されています。ぜひご一読いただき、フィードバックもお寄せください。今回は、この2つのコマンド、つまり関数を参照することにします。
ターミナルに戻って、まず最初にやることは、CSV をインポートすることです。
では、このファイルを見てみましょう。実行して、中身を確認してみましょう。つまり、ちょっと違うことをするんです。
もう少し分かりやすくするために、リスト形式にしましょう。すみません、表形式です。IPアドレス、表示名、ホストグループ（これらの情報を配置したい場所へのフルパス）、そしてプロパティ、説明、コレクターの割り当てといった情報がCSV形式で入っています。
そうですね？オンボードしたい項目を整理したリストです。LogicMonitorポータルに戻ってみると、必ずしもフォルダ構造がここにあるわけではないことにお気づきになるでしょう。APIを使う利点の一つは、これらの項目の多くを、プロセスの一環としてプログラムで処理できることです。
では、ここに戻って実際にインポートを実行し、Shift キーを押しながら実行してみましょう。
ああ、これが入っているモジュールをインポートすれば役立つと思います。
それを明確にさせてください。
このコマンドを実行すると、関数が実行され、グループが存在するかどうかが確認されます。グループが存在しない場合は、ネスト構造を順に確認し、必要なグループをプロビジョニングします。これは非常に便利です。事前にグループが存在するかどうかを確認する必要がないからです。Excelで好きなようにフォルダ構造をレイアウトしておき、それをここにドラッグするだけで自動的に作成されます。そのため、フォルダの再構築、特に動的グループ化などの作業が非常に簡単になります。
これを実行してみましょう。完了するまでの間、すぐにポータルに戻ってください。ポータルを更新すると、新しいフォルダが作成されます。他のリソースと共に、すべてのサブフォルダのプロビジョニングが開始されます。
リソースには、所有者、サービスタイプ、アプリケーションチーム、重要度が設定してあります。これらはすべてここに入力して、適切な所有者やチームでチケットを開く際に活用できるようにしたいと考えていました。そして、これですべてが整理されたので、特定の種類のリソースへのアクセスを必要とするユーザーに基づいてRBACを割り当てることができるようになりました。
でも、これは本当に便利です。最小限の労力で、大量のデバイスをオンボードできる簡単な方法ですよね？ 実際にインポートしたいものの大部分をCSVファイルにまとめるだけで、あとは手間がかかるだけです。
グループでも同じことが起こります。例えば、ロジックモニターに既にこれらのデバイスがすべてあるとします。そうですよね？そして、実際にそれらを取り出して、少し再構成したいとします。
そうですね？動的なグループとかを作りたいですね。それでは、このグループをインポートして、テーブルをフォーマットしてみましょう。
そうですか？ここにはいくつかのグループとそのパス、そして説明がありますが、それらには先ほど作成したものの一部を参照するロジックも適用されています。
それで、これで準備が整いました。それでは、実際に表示してみましょう。よし。実行したら、すぐにこれをクリアします。
最終的に、同じようなプロセスになります。親グループを作成する必要があるかどうかを判断し、存在しない場合は、構築したレイアウトに基づいてメインの動的グループを作成します。
では、少し待って、完了させましょう。これは本当に便利です。特に、しばらく放置されていた古いポータルをお持ちで、フォルダ構造を一新したり、再割り当てしたりしたい場合に、この機能が非常に役立つと感じています。Logic Monitor内のデバイスは複数の場所に存在できることを覚えておいてください。これは、Logic Monitorにあるものをエクスポートし、新しい標準やグループ化の規則に基づいて再配置するのに最適な方法です。
では、ここに戻って、これを最小化します。これですべて完了です。それでは、先ほど作成した動的グループを見てみましょう。このグループには、それぞれ異なるベースレベル、つまり「クリティカル」があります。「クリティカルシステム」、「高優先度」、「低優先度」、つまり開発中のものなど、あらゆるものが含まれています。
環境別に設定できるのも便利ですね。つまり、ここで全てを確認できるということですね。API接続、本番環境サービス、顧客向けサービス、社内向けサービスなど、Logic Monitorで何も操作しなくても、全てがすぐに使える状態で設定されています。
これらすべてを活用できます。今すぐここに来て、これをロジックモニターに接続し、環境やアプリケーションチームごとにグループ化できます。どうぞ。
これで、何があるのか​​を非常に簡単に確認できるようになりました。オンボードしたばかりですが、環境全体をリソースエクスプローラーで見やすく表示できるようになりました。
たった 5 分で完了しましたが、これは、CSV ファイルと少しのコード (大量ではありませんが、少しのコード) を活用するだけで、オンボードやオフボードなどを迅速に実行し、価値を引き出す非常に効果的な方法です。このプロセスを促進するのに役立ちます。
それでは、これらのデバイスをどのようにメンテナンスするかを見ていきましょう。運用メモや様々なコンテキストを環境にどのように追加するか？
それでは早速見ていきましょう。さて、ロジックモニターでオンボーディングのプロセスを自動化する方法を確認しました。
これをさらに一歩進めると、今ではこれらすべて、新しい優れたデバイス、デバイス グループ、監視を開始して物事を可視化するために必要なすべての構造が整えられています。
でも、ライフサイクルプロセスを管理しないといけないんです。パッチ適用やメンテナンスのためにデバイスを停止したり、サーバーの電源を交換したりする場合、大量のアラートが出ないように、そのデバイスをメンテナンスモードに切り替えます。
これらは自動化できるプロセスです。ロジックモニターの管理者がポータルにアクセスしてダウンタイムをスケジュールする代わりに、パッチサイクルやCMDBとの統合など、プロセスを自動化する様々な方法を検討できます。それでは、いくつかの例を見て、このプロセスをどのように改善できるかを見ていきましょう。では、
デバイスのオンボードとリソースグループの設定が完了したので、Logic Monitor を使って他の操作をどのように実行できるか検討してみましょう。データの抽出ではなく、コンテキストなどを設定してアラートを抑制したり、コンテキストを追加したりといった操作です。まず、リソースのメンテナンス期間やスケジュールされたダウンタイムを設定するのは、非常に簡単です。ここでは4つの例を挙げています。
これらはすべて基本的にSDTを作成していますが、ロジックモニター内の様々なレベルで実行されます。それでは早速、これらを作成してみましょう。最初の例を見てください。これは、Webサーバー、あるいはグループ内の最初のWebサーバーに緊急メンテナンスウィンドウを設定するだけです。
これは、例えば変更要求が承認されたら緊急変更要求として処理する自動化プロセスに組み込みたい場合に最適です。SDTメモを必ず入れておきましょう。他にも、サーバーグループをターゲットにしたい場合もあるでしょう。今回の場合は、データベースチーム、サーバー、サーバーグループです。週次メンテナンスを最初の日曜日に実施したいのですが、3時間かかるようです。
素晴らしいですね。そうでしょう？これは、新しいサイトやサーバーなどを立ち上げる際に、様々なメンテナンスウィンドウの設定を自動化するための手段になります。
あるいは、本番環境規模のメンテナンスを実施していて、変更を調整しようとしているのかもしれませんね。そして、それらはすべて特定の変更要求に結びついています。ですから、これも追加してみましょう。これらについては後ほど詳しく見ていきます。最後のものは、CSVファイルを扱う完全な自動化スクリプトです。今回は、CSVファイルを作成するか、カンマ区切りのテキスト配列から変換するだけです。
デバイスのメンテナンス日（今日）と、メンテナンス時間、そしてパッチ適用の理由がセットになっています。いいですね？ こうすれば、例えば特定のサーバーグループに対して、それぞれ異なる期間などを持つスクリプトやメンテナンスタスクを実行したい場合、シンプルな「for each」ループで自動化できます。では、これを実行してみましょう。
これですべて完了し、スケジュールが設定されていることがわかります。ロジックモニターに戻って更新してみましょう。
わかりましたか？今表示されているのは、Webチーム用に設定した現在のSDTです。データベースチーム用に、毎月第1日曜日の1時から4時までのグループSDTがあります。本番環境グループは6時間に設定されています。そして、CSVインポートでリソースレベルのSDTを様々な期間に設定し、実際に何が起こっているかに関するメモと本番環境SDTウィンドウの変更要求も含めました。
これらすべては自動的に管理・設定できます。また、作業が完了したら、既存のものをクリーンアップすることもできます。先ほど作成したものをクリーンアップします。Logic Monitorからそれらを削除することもできます。これで、SDTが表示されず、すっきりとしたポータルが完成しました。つまり、多くのコードを記述することなく、これらの自動化を迅速に構築し、運用領域を強化することができます。
承認済みの変更をメンテナンスモードにしたり、定期的なメンテナンスウィンドウの設定や変更、修正など、これらはすべて自動化できるため、ポータルUI内で実際に操作する必要はありません。最後に、ロジックモニター内でトラブルシューティングや特定の問題の調査を行っているユーザー向けに、追加のコンテキストを提供することで、この部分をもう少し進めていきます。さて、これで、既存のワークフローにAPI呼び出しを追加して、ロジックモニターの設定とメンテナンスを自動化する方法が少しは理解できたかと思います。
さて、次のビデオは最後のビデオですが、私がこれから始めようとしているのは、コンテキスト強化の考え方を実際に取り除くことです。
操作ノートとロジック モニターについて、そして操作ノートに馴染みのない方のために説明すると、これらは基本的に、データやメトリックにタグを付けることができる時系列マーカーです。そのため、スイッチやサーバーを調べてその CPU グラフを見ているときなど、人々が情報を見るときに役立ちます。
そうですか？100%まで急上昇したら、何が原因なのか知りたいですよね。でも、もしかしたらサービスの問題ではないかもしれません。アプリケーションの問題でもないかもしれません。もしかしたら、環境内で何かが起こったのかもしれません。誰かがアップデートをプッシュしたり、上流のデバイスに変更を加えたりして、それが最終的にそのサービスやサーバーに影響を与えるかもしれません。オペレーションノートを使えば、誰かがどこか別の場所で何かを行ったというコンテキストを時系列データに結び付けることができます。そうすることで、サービスやリソースの可用性に影響を与える可能性のある、より非メトリックな要因を単一の画面で把握できるようになります。
これから、既存のワークフローにオペレーションノートを統合して活用する方法を見ていきましょう。最後のデモでは、オペレーションノートについて少しお話ししたいと思います。これはロジックモニターの非常に便利な機能の一つで、環境の変化に詳細なコンテキストを追加するのに役立ちます。
そうですね？新しい本番ビルドのリリースであれ、メンテナンスタスクであれ、あるいは単に問題を調査していてCPU使用率の急上昇と環境の他の部分との相関関係を調べたいだけの人でも、これらは環境内で実際に何が起こっているかを組織全体と結びつける非常に簡単な方法になります。ですから、ここで挙げた例をすべて説明するつもりはありません。最後の例、つまり一連のサーバーから新しいリリースビルドを運用ノードとして実行する例だけを説明します。
これはおそらく、リリースパイプラインの一部として行う作業でしょう。Logic Monitorに戻ると、フロントエンドWebサーバーの1つが表示されています。運用ノートを表示すると、実際のデプロイメント情報とタグ、バージョン番号などが表示されますが、時系列データでも参照できるようになりました。
つまり、もし私がそのデプロイメントプロセスに関わっていなかったり、デプロイメントが既に完了していたり​​して、突然このWebサービスに問題が発生したり、あるいはその影響でダウンストリームに何らかの影響が出たりしたとしても、時系列データにそれが反映されているのを確認して、新しいリリースが公開された直後に問題が発生していることを簡単に関連付けることができます。これは、サンドボックスポータルから本番環境への移行、コードリリース、パッチ適用など、様々な場面で非常に役立ちます。ロジックモニターポータル内で参照情報として活用できるのも非常に便利です。
わかりました。皆さんはロジックモニターAPIを活用する方法についてたくさんのアイデアをお持ちだと思います。
しかし、いくつか留意しておきたい点があります。APIには、当然ながらベストプラクティスに関する情報も含まれています。
SDK を使用している場合は、もちろん必須ではありませんが、好きな言語で記述して残りの呼び出しを行うことができます。Swagger ガイドとドキュメントの入手先についてもご案内します。ただし、SDK を使用せず、独自のコードを作成している場合は、レート制限についていくつか留意すべき点があります。Logic Monitor を使用すると、各エンドポイントで 1 分あたりに送信できるリクエスト数に制限が設けられます。そのため、自動化で何かを呼び出す場合は、レート制限があることを念頭に置いてください。エンドポイントのレート制限は、サポートドキュメントで確認するか、リクエストから返されるヘッダーを確認すれば確認できます。これにより、特定のエンドポイントのリクエストの残高がわかります。もう 1 つは、ページネーションについてです。
大量のデータがある場合、一度にすべてを取得することは不可能です。そのため、ページネーションやAPIの機能を活用して、必要なデータをすべて再帰的に取得できるようにする必要があります。そして、さらに重要なのは、セキュリティ対策です。これらのAPIキーは、ユーザーがポータルで実行できるほぼすべての操作を実行できます。そのため、自動化に実際に必要なものだけにアクセス権限を制限し、定期的にアクセス権限を見直し、必要に応じてローテーションさせる必要があります。
さらに重要なのは、カスタム統合作業を行う場合は、パフォーマンスを念頭に置くことです。先ほども紹介したDelta APIを使って結果をキャッシュし、バッチ操作を実行することで、順番に変更するのではなく、一括で変更するようにしましょう。ただし、APIをどのように効率化すれば処理が高速化されるかに注意してください。
そうですね？ リクエストを連続して送信するからレート制限に引っかからない、みたいな。それでは、まとめに入る前に、いくつか覚えておいていただきたいことがあります。QRコードへのリンクはこちらにあります。これはスライド資料で共有します。接続可能なエンドポイントがすべて記載されている公式APIガイドへのリンクです。
先ほどのビデオでご紹介したPowerShellのドキュメントに加え、APIの使い方に関する非常に優れた概要ガイドもご用意しています。また、PowerShellモジュールへの貢献をご検討されている場合にもご活用いただけます。先ほども申し上げたように、本日ご覧いただいた素晴らしい機能はすべて、私たちとお客様のコラボレーションの成果です。
したがって、貢献する次のプロジェクトを探していて、改善や強化に協力したい場合は、リポジトリをチェックして、先に進み、開始して、貢献を始めましょう。
それ以外は、本日はお時間をいただきありがとうございました。ご質問等ございましたら、LinkedInでご連絡ください。追ってご連絡させていただきます。