Différences

Ci-dessous, les différences entre deux révisions de la page.

--- informatique:system_admin:server_monitoring [31/03/2017 18:36] – [Zabbix] cyrille
+++ informatique:system_admin:server_monitoring [21/03/2025 11:30] (Version actuelle) – [uptime-kuma] cyrille
@@ Ligne 1: / Ligne 1: @@
 ====== Server Monitoring ======
+Voir aussi: [[/informatique/web/webstats|/informatique/web/webstats]]
 À lire:
   * [[http://www.thegeekstuff.com/2011/03/linux-performance-monitoring-intro/|Linux Performance Monitoring and Tuning Introduction]]
   * [[https://www.libertycenterone.com/blog/five-of-the-best-free-network-monitoring-software-tools/|Five Of The Best Free Network Monitoring Software Tools]]
+  * [[https://www.webpagefx.com/blog/web-design/10-free-server-network-monitoring-tools-that-kick-ass/|10 Free Server & Network Monitoring Tools that Kick Ass]]
 ===== Outils =====
@@ Ligne 36: / Ligne 39: @@
 Présentation de ces outils:
   * http://www.cyberciti.biz/tips/top-linux-monitoring-tools.html
+==== Status page ====
+=== Cachet ===
+https://cachethq.io/
+The open source status page system. Beautifully crafted, Translated, JSON API, Scheduled maintenance, Metrics, Two-factor authentication.
 ==== sysstat ====
@@ Ligne 76: / Ligne 89: @@
 [[http://www.nagios.org/|Nagios]]
+==== Netdata ====
+https://github.com/firehol/netdata/wiki
+netdata is a scalable, distributed, real-time, performance and health monitoring solution for Linux, FreeBSD and MacOS. It is open-source too.
+Out of the box, it collects 1k to 5k metrics per server per second. It is the corresponding of: top, vmstat, iostat, iotop, sar, systemd-cgtop and a dozen more console tools running in parallel. netdata is very efficient in this: the daemon needs just 1% to 3% cpu of a single core, even when it runs on IoT.
+Many people view netdata as a collectd + graphite + grafana alternative, or compare it with cacti or munin. All these are really great tools, but they are not netdata. Let's see why.
+My primary goal when I was designing netdata was to help us find why our systems and applications are slow or misbehaving. To provide a system that could kill the console for performance monitoring.
+To do this, I decided that:
+  * high resolution metrics is more important than long history
+  * the more metrics collected, the better - we should not fear to add 1k metrics more
+  * effective monitoring starts with monitoring everything about each node
+==== Grafana ====
+http://grafana.org
+==== Prometheus ====
+[[/informatique/system_admin/Prometheus|Prometheus]]
+Prometheus differs from Loki by focusing on **metrics instead of logs**, and delivering logs via **pull**, instead of **push**.
+==== Grafana Loki ====
+https://github.com/grafana/loki
+Loki differs from Prometheus by focusing on **logs instead of metrics**, and delivering logs via **push**, instead of **pull**.
 ==== Glances ====
@@ Ligne 89: / Ligne 133: @@
   * [[http://blog.nicolargo.com/2012/11/installation-pas-a-pas-dun-serveur-de-supervision-shinken.html|Installation pas à pas d’un serveur de supervision Shinken]] par [[http://blog.nicolargo.com|nicolargo]].
+> Il existe aussi shinken, mais ça marche un peu comme ça veut et quand ça veut. Depuis, ça prend énormément de RAM pour le service rendu.
 ==== Zabbix ====
@@ Ligne 137: / Ligne 183: @@
 https://www.icinga.org/
+==== uptime-kuma ====
+  * https://uptime.kuma.pet/
+  * https://github.com/louislam/uptime-kuma
 ===== Services =====
+==== UpTimeRobot ====
+[[https://uptimerobot.com|https://uptimerobot.com]]
+Free plan
+==== HetrixTools ====
+[[https://hetrixtools.com|https://hetrixtools.com]]
+Free plan
+==== updown.io ====
+https://updown.io/
 ==== Server Density ====
@@ Ligne 156: / Ligne 225: @@
 http://www.pingdom.com/
+==== newrelic ====
+https://newrelic.com/
+==== LogMatic ====
+LogMatic.io