Nagiosが効果的にホストのWindows、LinuxやUnixの状態を監視することができ、オープンソースのコンピュータシステムやネットワーク監視ツールで、回復した後の状態、異常なシステムやサービスの状態やアラームメッセージサイトの運用・保守担当者に通知するのは初めてでメッセージを発行しました通常のメールやSMS通知を送りました。
主な特長
集中管理モデル - Nagiosは、分散の使用です。メインプログラムと監視対象ホスト上でNagiosのエージェントをインストールし、サーバー上のNagios Nagiosのプラグインをインストールします。メインプログラムとNagios Nagiosのエージェントの間の通信、状態監視オブジェクトによって。
1）ネットワークサービスとホストのリソースを監視する機能（SMTP、POP3、HTTP、FTP、SSH、CPU負荷、ディスク使用量、システムログは）2）ユーザーは、彼らが多くの開発言語（シェルスクリプトをサポートするために必要な簡単なスクリーニングサービスを開発することができ、 C ++、Perlの、ルビー、Pythonの 、PHP、C＃のなど、）、あなたは、ネットワーク上のデータを収集するために、どのような状況（温度、警告を......）を監視するために、独自の書かれたプラグインを指定することができます）3を事前に定義されたスクリプトのリモート実行をプラグインNagiosのリモート実行を設定することができますオブジェクトが問題があると、自動的に対応するハンドラを呼び出すイベントハンドラ; 4）並列サービスチェック5）、冗長ホスト監視サポートすることができる6）を自動的にサイクルログ7）現在のネットワーク状態を表示するWebインターフェイスを含みます、通知、問題の歴史、ログファイルなど
1.2のnagiosの作品
Nagiosが監視サービス機能とホストが、自分の機能のこの部分を含まない、モニタリングの全ては、検出は、プラグインのさまざまによって達成されます。
1）Nagiosの開始後、それが自動的にNagiosはにcheck_nrpe Nagiosがそれにインストールにプラグインし、検出するために、サービスを何にcheck_nrpe教えて行う、キューを維持しながら、サーバーの状態を検出するために、定期的にプラグインを呼び出します。
2）SSLにより、織機の遠位端に接続CHECK_ NRPE NRPEデーモン。
3）ローカルNRPEが、）ローカルサービス及び状態（check_disk、check_load、等を検出簡単に多くのサービスのステータスを監視することができ、これらのプラグインを使用するために、様々なプラグインを実行し、check_diskプラグインディスクスペースをチェックすることで、check_loadは、等をCPU負荷を確認することですように。各プラグインは./check_xxx -hを実行して、その使用法及び機能を見ることができます。
NRPEホストに検出結果にcheck_nrpe 4）最後に、結果は、キューにステータス情報へのすべてのプラグイン・リターンをNagiosのステータスキューにcheck_nrpeする; 5）Nagiosが最初のチームからの情報の読み出しを開始するたびに、および後処理、結果はステータスウェブを介して表示されます。Nagiosはすなわち0（OK）通常の条件下/緑、1（警告）警告/ 2（クリティカル）、黄色は非常に深刻な障害/赤、3（UNKNOWN）を表し示し、ステータス情報の4種類返さ認識できる未知のエラーを表現/黄色。Nagiosのプラグインに応じて監視対象の状態を決定するために値を返し、そして故障を検出するには、管理者のために、ウェブを介して表示されます。
1.1プロメテウスとは何ですか？
プロメテウスはSoundCloudが警告キットの前身であり、オープンソース監視システムです。2012年以降、多くの企業や組織がプロメテウスを使用して開始しました。プロジェクトの開発者とユーザーコミュニティは、より多くの開発者やユーザーがプロジェクトに参加するために、非常に活発です。現時点では、独立したオープンソースプロジェクトであり、そしてどのような企業に依存しません。Kurberntes後に2016年にこのポイント、プロジェクトの明確なガバナンス構造、プロメテウスを強調するために、彼はクラウドコンピューティングのネイティブ財団に参加しました。主に以下の機能があります。
-
多次元データモデル（シーケンス名で構成され、メトリックのk / Vのラベル）の。
-
柔軟なクエリ（PromQL）。
-
无依赖存储，支持 local 和 remote 不同模型。
-
采用 http 协议，使用 pull 模式，拉取数据，简单易懂。
-
监控目标，可以采用服务发现或静态配置的方式。
-
支持多种统计数据模型，图形化友好。
1.2 核心架构
我们将通过prometheus的基础结构来详细了解，他的功能以及如何实现监控、告警的。如下如所示：
从这个架构图，也可以看出 Prometheus 的主要模块包含， prometheus server, exporters, pushgateway, PromQL, Alertmanager, WebUI 等。下面我就简单介绍各个组件实现的功能：
1. prometheus server： 定期从静态配置的 targets 或者服务发现（主要是DNS、consul、k8s、mesos等）的 targets 拉取数据。
2. exporters：负责向prometheus server做数据汇报的程序统。而不同的数据汇报由不同的exporters实现，比如监控主机有node-exporters，mysql有MySQL server exporter，更多请参考链接。
3. pushgateway：主要使用场景为：
Prometheus 采用 pull 模式，可能由于不在一个子网或者防火墙原因，导致 Prometheus 无法直接拉取各个 target 数据。在监控业务数据的时候，需要将不同数据汇总, 由 Prometheus 统一收集。
总结：实现类似于zabbix-proxy功能；
4. Alertmanager：实现prometheus的告警功能。
5. webui：主要通过grafana来实现webui展示。
1.3 适用场景
Prometheus在记录纯数字时间序列方面表现非常好。它既适用于面向服务器等硬件指标的监控，也适用于高动态的面向服务架构的监控。对于现在流行的微服务，Prometheus的多维度数据收集和数据筛选查询语言也是非常的强大。Prometheus是为服务的可靠性而设计的，当服务出现故障时，它可以使你快速定位和诊断问题。它的搭建过程对硬件和服务没有很强的依赖关系。
Prometheus，它的价值在于可靠性，甚至在很恶劣的环境下，你都可以随时访问它和查看系统服务各种指标的统计信息。 如果你对统计数据需要100%的精确，它并不适用，例如：它不适用于实时计费系统。
二、基础概念
2.1 数据模型
Prometheus 存储的是时序数据, 即按照相同时序(相同的名字和标签)，以时间维度存储连续的数据的集合。时序(time series) 是由名字(Metric)，以及一组 key/value 标签定义的，具有相同的名字以及标签属于相同时序。时序的名字由 ASCII 字符，数字，下划线，以及冒号组成，它必须满足正则表达式 [a-zA-Z_:][a-zA-Z0-9_:]*, 其名字应该具有语义化，一般表示一个可以度量的指标，例如 http_requests_total, 可以表示 http 请求的总数。
时序的标签可以使 Prometheus 的数据更加丰富，能够区分具体不同的实例，例如 http_requests_total{method="POST"} 可以表示所有 http 中的 POST 请求。标签名称由 ASCII 字符，数字，以及下划线组成， 其中 __ 开头属于 Prometheus 保留，标签的值可以是任何 Unicode 字符，支持中文。
2.2 时序4种类型
Prometheus 时序数据分为 Counter, Gauge, Histogram, Summary 四种类型。
-
Counter：表示收集的数据是按照某个趋势（增加／减少）一直变化的，我们往往用它记录服务请求总量，错误总数等。例如 Prometheus server 中
http_requests_total, 表示 Prometheus 处理的 http 请求总数，我们可以使用data, 很容易得到任意区间数据的增量。 -
Gauge：表示搜集的数据是一个瞬时的，与时间没有关系，可以任意变高变低，往往可以用来记录内存使用率、磁盘使用率等。
-
Histogram：Histogram 由
<basename>_bucket{le="<upper inclusive bound>"}，<basename>_bucket{le="+Inf"},<basename>_sum，<basename>_count组成，主要用于表示一段时间范围内对数据进行采样，（通常是请求持续时间或响应大小），并能够对其指定区间以及总数进行统计，通常我们用它计算分位数的直方图。 -
Summary：Summary 和 Histogram 类似，由
<basename>{quantile="<φ>"}，<basename>_sum，<basename>_count组成，主要用于表示一段时间内数据采样结果，（通常是请求持续时间或响应大小），它直接存储了 quantile 数据，而不是根据统计区间计算出来的。区别在于：
a. 都包含 <basename>_sum，<basename>_count。
` b. Histogram 需要通过<basename>_bucket` 计算 quantile, 而 Summary 直接存储了 quantile 的值。
2.3 总结
prometheus是属于下一代监控，现在企业中大部分通过使用zabbix来实现主机、服务、设备的监控。与zabbix相比，zabbix还是存在一定的优势，比如丰富的插件、webui能完成大部分工作，而prometheus更多的配置是通过配置文件还实现，并且prometheus相当消耗资源。建议在使用的过程中，认真对比慎重选择，如果使用prometheus，就要配置更好的服务器资源，因为它的监控粒度更细，需要计算相关数值，最好使用SSD硬盘来提高性能。