いくつかあります 興味深い議論 「サックの監視」の周りで、しばらくの間されています。 （Twitterのハッシュタグ#monitoringsucksを確認してください）。 これは新しい意見ではありません。監視がうまくいかないと思ったことが、LogicMonitorを始めた理由です。
しかし、LogicMonitorが吸わないための基準を満たしているかどうかを評価するのは興味深いことです。 明らかに、お客様は私たちが優れた監視を行っていると考えていますが、おそらくお客様の30％だけがSaaSタイプの企業であり、DevOpsの考え方を持っている場合と持っていない場合があります。
したがって、少なくとも参照されているブログ投稿で、モニタリングがうまくいかない理由の最初の基準は次のとおりです。
しかし、監視は本当にひどいですか？ 嫌です！ モニタリングは素晴らしいです。 指標は素晴らしいです。 大好きです。 これが私が好きではないことです：-ホストとサービスのバインディングのモデルに手を結び付けます。 -任意のメトリックをグループ化するためだけに「偽の」ホストを設定する必要があります-メトリックを5回収集する必要があります-XNUMX回はアラート用、もうXNUMX回はトレンド用です-XNUMX分間隔でしかメトリックを表示できません-くだらないインターフェースから選択する必要がありますが優れた監視またはくだらない監視ですが、優れたインターフェイス- IT 私の環境の真実のシステムです-Perl
LogicMonitorの観点からこれらのポイントを見てみましょう
ホストとサービスのバインディングのモデルに手を結びます。 誰かの手をある程度縛らない方法はわかりませんが、LogicMonitorは確かに柔軟性を提供しようとします。 通常、サービスはホストに関連付ける必要がありますが、あらゆる種類のもの（ホスト名、グループメンバーシップ、SNMPエージェントOID、システムの説明、サポートされるWMIクラス、カーネルレベルなど）で関連付けることができます。
任意のメトリックをグループ化するためだけに「偽の」ホストを設定する必要があります。 LogicMonitorは、ダッシュボードのカスタムグラフでこれをほとんど回避します。これにより、任意のメトリック（またはグロブ/正規表現に基づくメトリックのセット）を他のセットとグループ化し、上位10にフィルターするかどうかを指定できます。 一緒に集計（合計、最大、最小、平均）するかどうか。 また、一部のメタサービスはホストではなくグループに関連付けられており、特定のホストがサービスを正常に提供しているかどうかだけでなく、サービスを提供しているサーバーの数などのアラートを許可します。
メトリックをXNUMX回収集する必要があります。XNUMX回はアラート用、もうXNUMX回はトレンド用です。 私たちは確かにそれを必要としません。 収集されたデータポイントは、アラート、グラフ化、またはその両方を行うことができます。 （データポイントは、複数の入力から派生した他の計算されたデータポイントで使用されるときに収集される場合があります。）
5分間隔でのみメトリックを表示できます。 繰り返しになりますが、その制限はありません。各データソースの収集間隔を1分から1日XNUMX回まで指定できます。 （XNUMX分の解像度だけにすることは、一部のアプリケーションには理想的ではないことを私は知っていますが、SaaS配信モデルとして、現在、バックエンドストレージエンジンの次の書き換えまで、それを削除するまで、自分自身を保護するためにその制限を課しています。）
くだらないインターフェースだが素晴らしい監視か、くだらない監視が素晴らしいインターフェースかを選択する必要があります。私たちはかなり良いインターフェースと素晴らしいモニタリングを持っていると思います。 確かに、私たちのインターフェースは私たちが立ち上げたときよりも桁違いに良く、多くの人々が私たちにそれを称賛してくれます。 しかし、改善の余地はたくさんあります。
考える監視システムを扱う IT 私の環境の真実のシステムです。 LogicMonitorは、監視対象を監視する必要があるのは真実であると考えていますが、喜んで耳を傾けます。 🙂APIを使用して、フックをpuppetやkickstartなどに簡単に配置し、ホストを監視に自動的に追加したり、グループに割り当てたりすることができます。この問題をさらに進めるために、PuppetLabのMCollectiveイニシアチブなどとの統合を検討しています。 。
Perl。 私たちのコレクターは、スクリプトに関しては不可知論者です。 これらは、実行しているプラットフォームのネイティブ言語での収集および検出スクリプトをサポートします。つまり、WindowsではVBscript、PowerShell、C＃です。 Linuxではbash、ruby、perlなど。 ただし、コレクターはJavaベースであるため、クロスプラットフォームの優れたスクリプト言語としてGroovyをお勧めします。 コレクターは、独自の機能（snmp、JMX、expectなど）の束をグルーヴィーに公開するため、多くのことが非常に簡単になります。 つまり、これは、お客様のためにデータソースを作成および拡張するために使用する言語です。 しかし、Perlがあなたのものであるなら、それを維持してください。
それで、LogicMonitorは吸うのですか？ 私はそうは思いませんし、うまくいけば、DevOpsBoratもそうは思いません。
私は今週オースティンで開催されるDevOpsDaysカンファレンスに参加します（LogicMonitorが後援しています）ので、そこでさらにフィードバックが得られることを願っています。
または、以下に投稿して、「不愉快な」監視の構成要素をお知らせください。