LogicMonitorのテクニカルオペレーションチームは、LogicMonitorのSaaSベースのアプリケーションを昼夜を問わず常に実行し続ける責任があり、24時間年中無休で誰かを呼んでいます。 LogicMonitorのアプリケーションの稼働時間とセキュリティはチームにとって最優先事項ですが、その傘下にある他のサービスもあります。 LogicMonitorカスタマーサポートチームが使用するサービスなど、顧客に影響を与えるものもあれば、JIRAやConfluence（それぞれ社内の問題追跡プラットフォームとwiki）などの社内リソースもあります。 TechOpsチームは、ビルドおよびテストシステムの側面を含め、開発者環境のサポートと保護においても大きな役割を果たします。
LogicMonitorでTechOpsが使用する監視プラットフォームが…LogicMonitorであることは当然のことです。 上記のすべてのシステムのすべての側面は、可能な限り最大限に監視されます。 LogicMonitorが優れているのは、ハードウェアからOS、データベース、アプリケーションに至るまで、すべてがシステム内にあることです。 私たちが利用するサードパーティのサービスでさえ監視されています（LogicMonitorを介して） サイトモニター）。 プラットフォームを幅広く使用しているため、TechOpsチームがすぐに気付かないような問題が発生することは非常にまれです。 これは、Opsの誰かの観点から言った、私のお気に入りのスローガンと一致します。上司または顧客が問題に気付く前に問題について話している場合、監視システムは失敗しています。
とはいえ、すべてがどれだけ適切に監視されていても、TechOpsは障害が自動的に検出されない状況に備える必要があります。 LogicMonitorと企業の問題追跡システムであるJIRAを使用して、従業員がアラームを鳴らし、すぐに対処する必要のある問題を昼夜を問わずTechOpsに通知する方法を作成しました。 このアプローチの優れた点は、通知がLogicMonitorアカウントの通常のアラートとエスカレーションに使用されるのと同じアラートパスに従うことです。つまり、最初にオンコールエンジニアに通知し、そこからすばやくエスカレーションします。
最初のステップは、自動アラートに使用するTechOpsプロジェクトでJIRA課題タイプを定義することでした。 私たちはXNUMXつを選びました：
| 問題の種類 | Use Case | 例 |
| 機能停止 | 顧客の観点からサービスを受け入れられないものにするLogicMonitorプラットフォームに関連する問題 |
|
| サービスの中断 | 内部のLogicMonitorリソースが利用できないか、許容できる方法で機能していないため、従業員が仕事をすることができません。 |
|
次のステップは、このタイプのチケットがアラートを生成するタイミングを定義することでした。 いずれかの問題タイプのチケットが「オープン」状態で存在する場合、LogicMonitorにERRORアラートがあるはずであると判断しました。これにより、通常のLogicMonitorエスカレーションチェーンを介してTechOpsチームにアラートが送信されます。
データソース「JIRAIssuesCount」（利用可能）を作成することで、上記を実現しました。 輸入用 LogicMonitorコアリポジトリから）を実行するだけです 「JIRAクエリ言語」（JQL） JIRAAPIを使用してJIRAインスタンスに対してクエリを実行します。 クエリは単純です。
| 説明 | JQL |
| オープン停止チケット | Project =” Technical Operations” AND issuetype = Outage AND status = Open |
| オープンサービス中断チケット | Project =” Technical Operations” AND issuetype =” Service Disruption” AND status = Open |
データソースのヘルプページで説明されているように、これらの各クエリはデータソースインスタンスとして入力され、「インスタンス名」が説明であり、「インスタンスワイルドカード値」が生のJQLクエリとして設定されます。 その結果、データソースはJIRAサーバーにクエリを実行し、返された上記の各レコードの数を取得します。 数値がゼロより大きい場合、LogicMonitorでエラーが生成されます。 アラートが生成されると、受信者はアラートを確認するか、チケットを「オープン」状態から「進行中」に移行して、JQLの結果を一致させることができます。
このセットアップでは、「進行中」の問題の数を追跡し、存在する場合はWARNアラートを生成するXNUMXつの追加のデータソースインスタンスもあります。 これは、問題の解決にかかる時間を追跡するのに役立つだけでなく、他のTechOpsエンジニアが[アラート]タブで未解決の「停止」または「サービスの中断」チケットがあることを確認できるようにします。
| 説明 | JQL |
| 進行中の停止チケット | Project = TECHOPS AND issuetype = Outage AND status =” In Progress” |
| 進行中のサービス中断チケット | Project = TECHOPS AND issuetype = Outage AND status =” In Progress” |
その結果、TechOpsチームは、Jiraの問題を作成するだけで、社内の誰からも発生した問題についてアラートを受け取ることができ、すべてのTechOpsエンジニアは未解決の問題があるかどうかを簡単に確認できます。
「進行中」のサービス中断アラートの例を次に示します（WARN状態）。
停止チケットが「進行中」から「クローズ」、または「オープン」から「進行中」にどれだけ速く移行したかを確認できます。
そして最後に、概要グラフを使用すると、すべての状態を同じグラフで確認できます。
このデータソースは、さまざまな種類の問題の数を追跡するだけでなく、特定の問題の種類がSLAから外れた場合に警告するなど、さまざまな目的で使用できます（たとえば、4時間以内に解決する必要があります）。 ）。
面白い使い方を思いついたらコメントを残してください！
LogicMonitorTechOpsチーム