เมตริก การเฝ้าติดตาม การแจ้งเตือน

สารบัญ:

สรุป
รายละเอียด
ที่เกี่ยวข้อง
หมายเหตุ

สรุป

ประเด็น

เราต้องการใช้เมตริก การเฝ้าติดตาม และการแจ้งเตือน เพราะเราต้องการทราบว่าแอปพลิเคชันของเราทำงานได้ดีเพียงใด และทราบเมื่อมีปัญหา

การตัดสินใจ

อยู่ระหว่างดำเนินการ

สถานะ

กำลังรวบรวมข้อมูล เราเริ่มจากปลายสุดที่สมเหตุสมผลของสเปกตรัม: เครื่องมือฟรีที่เก่าแก่ที่สุดและได้รับการแนะนำมากที่สุด (Nagios) และเครื่องมือเสียเงินที่ใหม่ที่สุดและได้รับการแนะนำมากที่สุด (New Relic)

รายละเอียด

สมมติฐาน

เราต้องการสร้างเว็บแอปสมัยใหม่ที่รวดเร็ว เชื่อถือได้ ตอบสนองดี ฯลฯ

เราต้องการซื้อแทนที่จะสร้างเอง

ข้อจำกัด

เราต้องการเครื่องมือที่ทำงานได้ดีกับไปป์ไลน์ devops และคลาวด์ที่เราติดตั้งใช้งานของเรา

จุดยืน

ขณะนี้เรากำลังสำรวจจุดยืนต่าง ๆ

AlertManager
AppDynamics
AppOptics
Azure Monitor/Analytics/Insights/Dashboards
Bosun
Checkly
Circonus
Cloudwatch
EFK
ELK
Grafana
Grafana
Graphite
Graylog
Healthchecks.io
Heroku
icinga2
InfluxDB
Instana
Kafka
Logagent
Logz.io
Loki
Monitis
Nagios
Nagios
Nagiosgraph
NewRelic
OpsGenie
Outlyer
PagerDuty
Pagerduty
PagerDuty
Papertrail
Prometheus
Rollbar
Scalyr
Sematext Metrics, Logs, Experience, Tracing
Sensu
SignalFX
Slack
Splunk
Stackdriver
Stackstorm
Telegraf
Telegraf
Thanos
VictorOps
Wavefront
Zabbix

ข้อโต้แย้ง

จนถึงตอนนี้ Nagios และ New Relic เป็นปลายสุดของสเปกตรัม Nagios เป็นเครื่องมือที่เก่าแก่ที่สุด เรียบง่ายที่สุด ฟรี และใช้งานได้จริง New Relic เป็นเครื่องมือที่มีฟีเจอร์ใหม่ที่สุด ครบถ้วนที่สุด เสียเงิน และใช้งานได้จริง เราเริ่มจากการประเมินสองตัวนี้ และเมื่อจำเป็นจะขยับเข้าหาตรงกลางของสเปกตรัม

จนถึงตอนนี้ Zabbix ได้รับคำแนะนำดีที่สุดและมีความสามารถครบถ้วนที่สุดด้วย

จนถึงตอนนี้ ELK เป็นที่นิยมที่สุดในกลุ่มโอเพนซอร์สแบบสร้างเองแทนซื้อ

จนถึงตอนนี้ Prometheus + Grafana เป็นที่นิยมที่สุดโดยรวม

นัยยะ

ต้องทำ

ที่เกี่ยวข้อง

การตัดสินใจที่เกี่ยวข้อง

ตัวเลือกจะส่งผลต่อความสามารถในการทดสอบ เทเลเมทรี และอาจรวมถึงระบบอื่น ๆ เช่น การสนับสนุนลูกค้า วิศวกรรมความน่าเชื่อถือของไซต์ ฯลฯ

ข้อกำหนดที่เกี่ยวข้อง

ต้องทำ

ผลงานที่เกี่ยวข้อง

ต้องทำ

หลักการที่เกี่ยวข้อง

ย้อนกลับได้ง่าย

ต้องการความเร็ว

หมายเหตุ

สแต็กโอเพนซอร์สที่ค่อนข้างดีคือ:

Prometheus สำหรับเมตริกและการแจ้งเตือนตามเมตริก
Grafana เพื่อแสดงเมตริก
Elasticsearch/Logstash/Kibana (ELK) สำหรับบันทึกและเหตุการณ์แบบมีโครงสร้าง
Pushover สำหรับการแจ้งเตือนบนมือถือ

ข้อความรูปแบบอิสระเทียบกับข้อความเหตุการณ์แบบมีโครงสร้าง

ข้อความรูปแบบอิสระ: เช่น สิ่งสุ่มที่คุณพบใน /var/log/messages และสิ่งที่แอปพลิเคชันสร้างขึ้นโดยตั้งใจ ข้อความมีประโยชน์ในการระบุสิ่งอื่นที่เกิดขึ้นบนเครื่อง เช่น หน่วยความจำไม่พอหรือข้อผิดพลาดของฮาร์ดแวร์ แต่มีขยะมาก

ข้อความเหตุการณ์แบบมีโครงสร้าง: สร้างโดยแอปพลิเคชัน โดยมีชุดแอตทริบิวต์คงที่หรือไดนามิก เช่น บันทึกคำขอ HTTP บันทึกบัญชี การเข้าสู่ระบบของผู้ใช้

โดยทั่วไป เป็นเรื่องดีที่จะบันทึกรายละเอียดของทุกคำขอในแบบที่คุณเจาะลึกตามแอตทริบิวต์ได้ ดังนั้นการเพิ่ม เช่น userid หรือ sessionid ให้ทุกอย่างช่วยให้ติดตามได้ การติดตามอย่างชัดเจนก็ดีแน่นอน การใช้ ELK สำหรับสิ่งนี้เป็นเหมือน https://www.honeycomb.io/ แบบคนจน

Graylog ง่ายกว่า

จากประสบการณ์ของฉัน Graylog ตั้งค่าได้ง่ายกว่า

Prometheus ต้องปรับจูนเล็กน้อย

โดยรวมฉันพอใจกับ Prometheus สำหรับเมตริก การแจ้งเตือนต้องปรับจูนเล็กน้อย แต่ค่อนข้างดี ขึ้นอยู่กับแอปพลิเคชันของคุณ ฉันคิดว่าดีที่สุดคือแจ้งเตือนตามเงื่อนไขที่ผู้ใช้ปลายทางมองเห็น ไม่ใช่สาเหตุเบื้องหลัง ตัวอย่างเช่น เวลาโหลดหน้าเว็บดี จำนวนคำขอต่อวินาทีไม่ดี แม้ว่าศูนย์คำขอต่อวินาทีจะบ่งชี้ว่ามีบางอย่างผิดปกติ

ข้อได้เปรียบของบริการคือให้ความฉลาดเพิ่มเติมตั้งแต่เริ่มต้น โดยทั่วไปฉันชอบ Datadog บริการอาจแพงน่ากลัวหากคุณมีข้อมูลมาก และบางครั้งมีโมเดลราคาที่ไม่เป็นมิตรกับคลาวด์ เช่น คิดตามอินสแตนซ์ ทั้งที่อินสแตนซ์เป็นแบบไดนามิก นอกจากนี้ยังมีความแตกต่างระหว่างบริการที่ทุกคำขอมาจากผู้ใช้ที่จ่ายเงิน กับบริการที่เกี่ยวกับโฆษณา ซึ่งมีเพียงเปอร์เซ็นต์เล็กน้อยของคำขอที่ทำเงินให้คุณ คุณอาจจบลงด้วยข้อมูลมากแต่งบประมาณไม่มาก

ฉันทำงานกับบริการบางตัวที่ได้รับ 1B คำขอต่อวัน จึงสมเหตุสมผลที่จะโฮสต์การเฝ้าติดตามและบันทึกเอง หากปริมาณของคุณต่ำกว่านั้น บริการที่โฮสต์ให้จะง่ายกว่า

บริการของ AWS มีทั้งดีและไม่ดี

ประสบการณ์ของฉันกับบริการของ AWS มีทั้งดีและไม่ดี บริการ Elasticsearch ของพวกเขาไม่เสถียร เราจึงรันอินสแตนซ์ของเราเอง เมตริก CloudWatch แพง เราจึงมักใช้เฉพาะเมตริกระดับ "โครงสร้างพื้นฐาน" ไม่ใช่ระดับแอปพลิเคชัน กล่าวคือเมตริกที่เกี่ยวกับสุขภาพซึ่ง AWS รู้ว่าเกิดอะไรขึ้นได้ดีกว่าซอฟต์แวร์ที่รันบนอินสแตนซ์ CloudWatch Logs อาจอัปเดตช้าและมีข้อมูลเมตาไม่มาก การรัน ELK ช่วยในเรื่องนี้ หากต้องการข้อมูลเรียลไทม์จริง ๆ การใช้ Kafka เป็นตัวขนส่งบันทึกดีกว่า ซึ่ง Logstash รองรับได้ดี แต่การจัดการคลัสเตอร์ Kafka ไม่เหมาะกับคนใจไม่แข็ง มีโครงสร้างภายในที่เปิดเผยอยู่มาก

Kafka

ความเห็น: Kafka อาจยุ่งยากมากในบางครั้ง หรือ Kafka อาจมั่นคงเหมือนหินจนคุณแทบลืมว่ามันอยู่ตรงนั้นเชื่อมทุกอย่างเข้าด้วยกัน

ความเห็น: Kafka มั่นคง แต่การทำให้ทำงานได้ใช้งานมากอย่างน่าประหลาดใจ ฉันมองมันเหมือนฐานข้อมูลเชิงสัมพันธ์ แต่คุณทำงานเฉพาะที่ชั้น "กายภาพ" เช่น tablespace ไฟล์ และพาร์ทิชัน ในช่วงแรกมีบางครั้งที่ยูทิลิตีการจัดการขาดแคลน และเราต้องเขียนโปรแกรมเอง เช่น เพื่อรีเซ็ตกลุ่มผู้บริโภค http://howfuckedismydatabase.com/nosql/

ความเห็น: เราใช้ Kafka เป็น "บัฟเฟอร์" สำหรับข้อความบันทึกและเป็นที่ที่เราประมวลผลสตรีมแบบเรียลไทม์กับข้อมูลที่มาจากหลายเซิร์ฟเวอร์ หากถูกโจมตี DDOS เราต้องมีวิธีวิเคราะห์ข้อมูลข้ามหลายอินสแตนซ์ หากเราบันทึกตรงจากเซิร์ฟเวอร์ไปยัง ELK ภาระอาจทำให้คลัสเตอร์ Elasticsearch ล่มได้

ความเห็น: Kafka ดีสำหรับเราเพราะหากถูกโจมตี DDOS เราต้องมีวิธีวิเคราะห์ข้อมูลข้ามหลายอินสแตนซ์ หากเราบันทึกตรงจากเซิร์ฟเวอร์ไปยัง ELK ภาระอาจทำให้คลัสเตอร์ Elasticsearch ล่มได้

ความเห็น: Kafka ทำงานน้อยกว่าและมีประสิทธิภาพกว่า จึงรองรับภาระได้ดีกว่า และเราเข้าคิวงาน Kafka แล้วลองใหม่ และการที่ Kafka โอเวอร์โหลดไม่กระทบผู้ใช้ที่ทำงานโต้ตอบกับ Kibana เหมือนอย่างที่จะเป็นหาก Elasticsearch กำลังติดขัด

ความเห็น: การประมวลผลสตรีมส่วนใหญ่คือการมองหาการใช้งานในทางที่ผิด เช่น ทราฟฟิกมากเกินไปจาก IP เดียวทั่วทั้งคลัสเตอร์ แล้วแบ่งปันการบล็อกไปทั่วทั้งคลัสเตอร์

ความเห็น: ปลั๊กอิน logstash-output-kafka ค่อนข้างไม่น่าเชื่อถือในขณะนี้ ฉันเจอหลายปัญหาในหน้า GitHub issues ของมันที่ดูเหมือนจะไม่เคยได้รับการแก้ไข ฉันอยากเลิกใช้มันและส่งตรงจากแอปของเราไปยัง Kafka

ความเห็น: ตอนนี้เราส่งเหตุการณ์แบบมีโครงสร้างตรงจากแอปไป Kafka แรงจูงใจหลักคือแตะข้อมูลบันทึกให้น้อยครั้งลงและหลีกเลี่ยงการอ่านและเขียนดิสก์หลายครั้ง ในระบบปริมาณสูง การบันทึกอาจใช้งานมากกว่าตัวแอปเอง ฉันกำลังคิดจะให้ journald ส่งบันทึกตรงด้วยเช่นกัน จากโปรแกรม C

Loki

จับตาดู Loki อย่างใกล้ชิด ยังไม่พร้อม แต่เมื่อพร้อมฉันคาดว่าจะเหมาะกับสแต็กนี้ดีกว่า Loki เป็นตัวรวมบันทึกที่สร้างโดย grafana labs ใช้การขูดข้อมูลและไวยากรณ์แท็กคล้าย Prometheus

Prometheus + alertmanager + Rollbar + Graylog + Grafana

Prometheus + alertmanager สำหรับเมตริก รัก Prometheus

Rollbar/Graylog สำหรับการบันทึก/การรายงานข้อผิดพลาด (มีความซ้ำซ้อนอยู่บ้าง บริการขนาดเล็กอาจไม่ต้องใช้ทั้งสอง)

ขณะนี้การแจ้งเตือนไปที่ช่อง Slack ไม่กี่ช่องที่ผู้เกี่ยวข้องเปิดการแจ้งเตือนไว้ หากเราจริงจังกับการเข้าเวรมากกว่านี้ก็จะส่งไป PagerDuty/VictorOps/ฯลฯ

Grafana สำหรับกราฟและแดชบอร์ด และตั้งตารอดูว่าความสามารถด้านการบันทึกที่กำลังจะมาของพวกเขาจะทำให้ Graylog ไม่จำเป็นหรือไม่

Thanos

เราใช้ Thanos เป็นส่วนหน้าของการตั้งค่า HA ของเรา มันรู้วิธีลบข้อมูลซ้ำของคู่ HA

ขณะนี้เราเก็บข้อมูล Prometheus ในเครื่อง 6 เดือน ซึ่งใช้ได้ดีพอสมควร แต่ฉันกำลังอยู่ระหว่างติดตั้งการจัดเก็บแบบ bucket ให้การตั้งค่า Thanos ของเราเพื่อจัดเก็บข้อมูลระยะยาว ในทางทฤษฎี การจัดเก็บ GCS จะถูกกว่าดิสก์ถาวรมาตรฐานของ GCE ที่เราใช้อยู่ประมาณ 30%

ตอนนี้เราไม่สำรองข้อมูล Prometheus ข้อมูลไม่สำคัญสำหรับเราเกินกว่าการมีพอสำหรับการแจ้งเตือน การติดตั้งใช้งานกองเรือโดยรวมของเราเปลี่ยนแปลงมากในแต่ละปี ข้อมูลย้อนหลังที่เก่ากว่าไม่กี่เดือนจึงไม่น่าสนใจนัก อาจน่าสนใจที่จะมีสถิติหลักไม่กี่อย่างเทียบปีต่อปี ฉันอาจตั้งชุดกฎการบันทึกสถิติหลักแล้วจัดเก็บด้วย Federation หรือปล่อยให้ Thanos จัดการ

แก้ไข: ข้อความปฏิเสธความรับผิดเล็กน้อย ฉันเป็นนักพัฒนา Prometheus

Prometheus HA

HA ใน Prometheus ทำโดยการทำซ้ำ คุณรันตัวดึงข้อมูลหลายตัว มีวิธีดึงจากหลายตัวและลบข้อมูลซ้ำ

การปรับขนาดทำโดยการแบ่งเครือข่ายและให้ Prometheus ต่างตัวดึงข้อมูลจากส่วนต่าง ๆ ของเครือข่าย

การจัดเก็บระยะยาวไม่ใช่จุดแข็งของ Prometheus แต่ถ่ายโอนไปยังสิ่งเช่น influx หรือ timescaledb (ซึ่งในทางเทคนิคก็ติ๊กถูก HA ด้วย) บทความที่ฉันอ่านเรื่องนี้ https://blog.timescale.com/prometheus-ha-postgresql-8de68d19b6f5?gi=7df160f10e07

ยังไม่ได้ลองส่วนระยะยาว เพราะฉันยังอยู่ระหว่างทดลองและใช้สำหรับกราฟระยะสั้น ในขณะที่ librenms เฝ้าติดตามเครือข่ายของฉันสำหรับระยะยาว

Datadog + PagerDuty + Threat Stack

เราใช้ Datadog (พร้อม PagerDuty) และ Threat Stack และมีความสุขมาก ข้อบ่นเดียวของฉันเกี่ยวกับ DD คือค่าจัดเก็บเมตริกที่ค่อนข้างสูง

Zabbix

Zabbix พร้อมสคริปต์กำหนดเองเพื่อเฝ้าติดตามเกือบทุกอย่าง ทำงานได้ราบรื่นดี

Outlyer

ฉันใช้ Outlyer แต่ต้องปฏิเสธความรับผิดว่าฉันทำงานที่นี่ และการใช้ผลิตภัณฑ์ของตัวเองเป็นสิ่งจำเป็น

ยังต้องใช้ Graylog, Sentry และ Statuscake เพื่อเสริม

ฟังดูมีอคติ แต่เมื่อเคยรัน Nagios และระบบเฝ้าติดตามอื่น ๆ ภายในอย่างมีความสุข ฉันจะซื้อโซลูชันที่โฮสต์ให้ในงานใหม่ทุกที่ และโยนความเจ็บปวดนั้นออกไป

Nagios + Nagiosgraph

เราใช้ Nagios สำหรับการเฝ้าติดตามและการแจ้งเตือนทั้งหมด การแจ้งเตือนเกิดขึ้นทางอีเมล (คำเตือนและการแจ้งเตือนวิกฤต) และการแจ้งเตือนแอปแบบมีเสียง (สำหรับการแจ้งเตือนวิกฤต)

Nagiosgraph ใช้สำหรับการแสดงภาพ

การตั้งค่านี้มีประสิทธิภาพมากในการทำให้เราได้รับข้อมูลครบถ้วนว่าเกิดอะไรขึ้นในสภาพแวดล้อมของเรา เรารันและเฝ้าติดตามเซิร์ฟเวอร์ที่สำคัญต่อภารกิจประมาณ 110 เครื่องและจุดข้อมูลประมาณ 760 จุด และมีระบบนี้มาเกินเจ็ดปีแล้ว

ฉันอยากรวมบันทึกด้วย Graylog หรือ ELK สักเวลาหนึ่งเช่นกัน

Prometheus + Grafana + AlertManager

Prometheus + Grafana + AlertManager ผ่าน helm chart Prometheus Operator ที่ยอดเยี่ยม บันทึกยังคงไปที่แผน birch ของ LogDNA เพราะเราสังเกตว่า ELK หนักเกินไปสำหรับ GKE ขนาดเล็กของเราที่มีขั้นต่ำ 3 สูงสุด 5 โหนด

DataDog + Sentry + PagerDuty.

ฉันเคยรันโซลูชันเฝ้าติดตามทั้งหมดเองโดยใช้ซอฟต์แวร์ทุกชนิด รวมถึง Nagios, Icinga, Zabbix, ELK, Greylog2, Influx และเครื่องมืออื่นอีกมาก แต่ความจริงคือการรันโครงสร้างพื้นฐานการเฝ้าติดตามเองต้องใช้ความพยายามมากเกินไป โดยเฉพาะเมื่อคุณจ่ายให้คนอื่นทำแทนได้ในอัตราที่ต่ำเช่นนี้!

การจ่ายให้ผู้อื่นรันโครงสร้างพื้นฐานการเฝ้าติดตามทำให้ลูกค้าของฉันมุ่งเน้นการรันแพลตฟอร์มของตนแทนการเฝ้าติดตามตัวเฝ้าติดตาม หมายความว่าคุณค่าที่พวกเขาได้รับจากเสถียรภาพของแพลตฟอร์มมากกว่าต้นทุนใด ๆ ของการเฝ้าติดตามเป็นบริการอย่างมาก

Sensu + Graphite + ELK

บริษัทของฉันชอบสิ่งที่โฮสต์เองมาก

Sensu -> PagerDuty

Graphite/Grafana

ELK (Elasticsearch, Logstash, Kibana)

Prometheus + Alertmanager

Prometheus + Alertmanager สำหรับการแจ้งเตือน ทีมของฉันเชื่อว่าการเฝ้าติดตามที่เรียบง่ายคือการเฝ้าติดตามที่ดี

ระบบอื่นเช่นการบันทึกและการติดตามจะให้บริบทที่สมบูรณ์เพื่อวินิจฉัยเมื่อผู้เข้าเวรได้รับการแจ้งเตือน แต่เราไม่เคยสร้างการแจ้งเตือนจากสิ่งเหล่านี้

Sensu + Grafana + Graylog + Kibana + NewRelic.

Sensu, grafana, graylog, kibana, newrelic

Prometheus + Circonus

บริการที่ติดตั้งเครื่องมือวัด Prometheus => การวิเคราะห์และการแสดงภาพของ Circonus

icinga2 + VictorOps + NewRelic + Sentry + Slack

เราใช้บริการต่อไปนี้:

icinga2 สำหรับการเฝ้าติดตามและ VictorOps สำหรับการแจ้งเตือน

NewRelic สำหรับการเฝ้าติดตามรายละเอียดของบริการ

Sentry สำหรับการติดตามข้อผิดพลาดในบริการ

Slack/อีเมลเป็นส่วนหนึ่งของการแจ้งเตือนที่ถูกกระตุ้นจาก NewRelic หรือ icinga2

AppDynamics + Papertrail + PagerDuty + Healthchecks.io + Stackdriver

AppDynamics

Papertrail

PagerDuty

Healthchecks.io

Stackdriver

icinga2 + elasticsearch

icinga2 พร้อมการรวม elasticsearch สำหรับการวิเคราะห์ และการรวม graphite+grafana สำหรับกราฟ

ด้วยความยืดหยุ่นของกฎ apply ใน icinga2 นักพัฒนาจะเห็นเฉพาะบริการที่ตนได้รับการแจ้งเตือน

และผ่าน icinga2 director โปรแกรมเมอร์กำหนดการตรวจสอบของตนเองได้อย่างง่ายดาย (ซึ่งพวกเขาทำทุกไม่กี่วัน - 100 การตรวจสอบออกไป 100 การตรวจสอบอื่นเข้ามา) ในระดับใหญ่โดยไม่ยุ่งยาก

DataDog + New Relic + ELK + EFK + Sentry + Alertmanager + VictorOps

สิ่งที่เรามีตอนนี้:

DataDog สำหรับเมตริก

New Relic สำหรับการเฝ้าติดตามแอปพลิเคชัน

ELK (Elastic Search + Logstash + Kibana) สำหรับบันทึก

Sentry (โฮสต์เอง) สำหรับบันทึกข้อยกเว้น

อีเมล + Slack + VictorOps สำหรับการแจ้งเตือน (ตามความรุนแรง)

สิ่งที่เราอยากมี:

Prometheus สำหรับเมตริก (Grafana สำหรับการแสดงภาพ)

New Relic (อาจเป็น Elastic Search APM) สำหรับการเฝ้าติดตามแอปพลิเคชัน

EFK (elastic search + fluentd + kibana) สำหรับการบันทึก อาจเป็น Loki โดย Grafana ที่จะพร้อมใช้งานจริงเมื่อเราไปถึงจุดนั้น

Sentry สำหรับข้อยกเว้น

Alertmanager + อีเมล + VictorOps สำหรับการแจ้งเตือน

Wavefront + Scalyr + PagerDuty + Stackstorm + Slack

Wavefront + Scalyr + PagerDuty + Stackstorm + Slack (ข้อความปฏิเสธความรับผิด: ทำงานที่ VMware)

Telegraf + Prometheus + InfluxDB + Grafana

Telegraf สำหรับเมตริกเซิร์ฟเวอร์ เช่น CPU ดิสก์ หน่วยความจำ และเครือข่าย เรายังใช้ Telegraf สำหรับการเฝ้าติดตาม SNMP ของอุปกรณ์เครือข่ายของเรา

Prometheus สำหรับเมตริกแอปพลิเคชัน เราเขียนการตรวจสุขภาพไว้ในแอปพลิเคชันซึ่ง Prometheus ขูดข้อมูล

InfluxDB สำหรับการจัดเก็บอนุกรมเวลา ที่นี่คือที่ข้อมูล Telegraf ของเราถูกส่งไป

Grafana สำหรับแดชบอร์ดและการแจ้งเตือน เอนจินการแจ้งเตือนไม่แข็งแกร่งนัก แต่ทำงานได้ เรายังส่งการแจ้งเตือนเข้า Slack

สิ่งที่ตอนนี้ฉันไม่มีคือโซลูชันการบันทึกแบบรวมศูนย์ ELK ทรงพลังแต่ตั้งค่าและจัดการยาก และฉันไม่รู้จักทางเลือกฟรีที่ใกล้เคียงพอที่จะไปศึกษา

Sematext + Logagent + Experience

Sematext สำหรับเมตริก บันทึก ร่องรอย และเร็ว ๆ นี้สำหรับการเฝ้าติดตามผู้ใช้จริงด้วย เรียบง่ายกว่า/ถูกกว่าการใช้เครื่องมือ/บริการ N ตัวที่แตกต่างกัน ในความเห็นของฉัน

สำหรับการส่งบันทึก เราเคยใช้ rsyslog แล้วเปลี่ยนมาใช้ Logagent

สำหรับการรายงานการขัดข้องฝั่งส่วนหน้าเราใช้ Sentry แต่เราจะเปลี่ยนไปใช้ Experience เร็ว ๆ นี้

ข้อความปฏิเสธความรับผิด: ฉันเป็นชาว Sematext

Azure Monitor/Analytics + OpsGenie

ฉันอยากให้ Log Analytics มีส่วนติดต่อที่ดีกว่านี้ เรากำลังย้ายออกจาก splunk ซึ่งนำทางง่ายกว่ามาก

Prometheus + Alertmanager + Grafana + Splunk + PagerDuty

Prometheus, Alertmanager, Grafana, Splunk, PagerDuty

คุณไม่อยากรันระบบการแจ้งเตือนของตัวเองจริง ๆ คุณแทนที่ Splunk ด้วย ELK ได้ เว้นแต่ทีมความปลอดภัยของคุณชอบ Splunk

Telegraf + Prometheus + Grafana + Alertmanager

Telegraf เป็นตัวรวบรวม Prometheus + Alertmanager สำหรับการเฝ้าติดตามและการแจ้งเตือน รวมกับช่อง slack และ pagerduty สำหรับการแจ้งเตือนวิกฤต Grafana สำหรับการแสดงภาพเมตริกของโฮสต์

Prometheus + Grafana + Cloudwatch + sentry + kibana + elasticsearch

Prometheus สำหรับเมตริก + การแจ้งเตือน

Grafana สำหรับแดชบอร์ด Prometheus

Cloudwatch เฝ้าติดตามอินสแตนซ์ Prometheus

sentry สำหรับการติดตามข้อยกเว้น

kibana + elasticsearch

graylog

prometheus Push Gateway สำหรับงานแบตช์/cronjob

SOP https://github.com/rapidloop/sop เพื่อ "ผลัก/ส่งต่อ" เมตริกจากอินสแตนซ์ Prometheus หนึ่งไปอีกอินสแตนซ์

ไคลเอนต์ใช้ไคลเอนต์ Prometheus เราพยายามใช้ opencensus.io ฝั่งไคลเอนต์

PagerDuty + Monitis

PagerDuty + Monitis และยังมี Azure Functions ที่เขียนเฉพาะกิจเพื่อทดสอบสุขภาพของบางบริการ

กำลังมองหาทางนำ Prometheus และ Grafana เข้ามาในปีนี้

Prometheus + Grafana + Bosun

Prometheus สำหรับจัดเก็บข้อมูลอนุกรมเวลา Grafana สำหรับการแสดงภาพ Bosun สำหรับการจัดการการแจ้งเตือน

Azure Monitor/Analytics/Insights/Dashboards

องค์กรที่ใช้ Azure อย่างเดียว Azure Monitor, Log Analytics, App Insights, Azure Dashboards + Pager Duty

Grafana + Monitis + OpsGenie + Slack

Grafana สำหรับเฝ้าติดตามบริการคอนเทนเนอร์ใน Kubernetes ผ่าน Prometheus

Monitis สำหรับการเฝ้าติดตามบริการแบบ end-to-end ส่วนใหญ่สำหรับ API เว็บและเว็บแอปพลิเคชัน

OpsGenie สำหรับการจัดการการแจ้งเตือน

Slack สำหรับรับข้อมูลสถานะจากระบบของเรา

Checkly + AppOptics + Cloudwatch + Heroku + Pagerduty + Papertrail

วิศวกร (dev)ops มานาน เติบโตมากับ Nagios อยากรับฟังความเห็นเกี่ยวกับ SaaS ที่ลงทุนเองของฉัน https://checklyhq.com เราทำการเฝ้าติดตาม API และการเฝ้าติดตามธุรกรรมของไซต์พร้อมการแจ้งเตือนที่ค่อนข้างลึก

ฉันเริ่ม Checkly เพราะการเฝ้าติดตามเชิงรุก/สังเคราะห์ในพื้นที่ API ค่อนข้างจำกัด (และแพง) การเฝ้าติดตามบนเบราว์เซอร์/ด้วยสคริปต์ยิ่งเป็นกรรมสิทธิ์และแพงกว่า เราใช้ Puppeteer และรักษาราคาให้ต่ำที่สุดเท่าที่ทำได้

สแต็กการเฝ้าติดตามของเรา:

Checkly (ใช้ผลิตภัณฑ์ของตัวเอง...)

AppOptics (กราฟกำหนดเอง)

AWS Cloudwatch และ SNS สำหรับข้อความ SMS

การแจ้งเตือนในตัวของ Heroku

Pagerduty

Papertrail

Instana + Logz.io + slack

Instana แจ้งเตือนเราใน slack เกี่ยวกับปัญหาโครงสร้างพื้นฐานหรือประสิทธิภาพที่ลดลง และเราตั้งค่า logz.io ให้แจ้งเตือนใน slack เมื่อบันทึกระดับข้อผิดพลาดจากชั้นแอปพลิเคชันถึงปริมาณหนึ่ง

SignalFX + Splunk + PagerDuty + Slack

ปัจจุบันใช้: SignalFX, Splunk, PagerDuty และ Slack ฉันไม่ค่อยชอบ SignalFX แม้ทีมสนับสนุนของพวกเขาจะเป็นมิตรและตอบสนองรวดเร็วมาก ฉันชอบ Splunk (คุ้มถ้าจ่ายไหว) PagerDuty และ Slack

ฉันเคยใช้สแต็ก TICK ซึ่ง C ส่วนใหญ่แล้วคือ G หรือ Grafana แม้ฉันจะใช้ Chronograf เล็กน้อยด้วย มันยอดเยี่ยมแต่จัดการลำบาก คำถามกลืนไม่เข้าคายไม่ออกแบบคลาสสิกของ SaaS เทียบกับการโฮสต์เอง

ฉันเคยใช้ DataDog, New Relic, Graylog, ELK และ BugSnag ฉันชอบ DataDog และ New Relic มาก Graylog ค่อนข้างดี ฉันไม่ใช่แฟนตัวยงของ ELK BugSnag ดี ฉันรู้สึกว่าการติดตามข้อผิดพลาด/ข้อยกเว้นเป็นตัวแทนที่ค่อนข้างดีของการเฝ้าติดตามบันทึกเต็มรูปแบบในหลายกรณี

ELK + Prometheus + Grafana

เหมือนคนอื่น ๆ เราใช้ ELK สำหรับบันทึก และ Prometheus+Grafana สำหรับทุกอย่างที่เหลือ

การดูแลการตั้งค่านี้ง่ายหากคุณอนุญาตให้ตัวเองสูญเสียข้อมูลเป็นครั้งคราว ตัวอย่างเช่น หากฐานข้อมูล ElasticSearch ของเราเข้าสู่ภาวะซบเซา (ซึ่งน่าเสียดายที่เกิดขึ้นทุก 2-3 เดือน) เราไม่สนใจ HA แต่ทิ้งข้อมูลแล้วดำเนินชีวิตต่อไป หากคุณจำเป็นต้องมี HA หรือการเก็บรักษาระยะยาวจริง ๆ ขอให้โชคดี

Datadog + Prometheus + Grafana

ฉันตั้งค่า Datadog แบบรายเดือนเพราะตอนมาถึงที่นี่ไม่มีการเฝ้าติดตามและไม่มีการแจ้งเตือน มีเพียงไม่กี่ไซต์ของเราที่ถูกเฝ้าติดตามทุก 5 นาทีเพื่อดูเวลาทำงาน Datadog ตั้งค่าง่ายที่สุดอย่างไม่ต้องสงสัย เมื่อฉันแก้ปัญหาอื่นทั้งหมดเสร็จ ฉันจะเปลี่ยนไปใช้ Prometheus+Grafana ยังไม่แน่ใจ 100% เกี่ยวกับการจัดการบันทึก

Nagios + ELK

เรามีผลิตภัณฑ์มากกว่า 100 รายการที่เราสนับสนุน

สำหรับ on-prem ส่วนใหญ่เป็น Nagios และ ELK สำหรับคลาวด์ เรากำลังย้ายจาก DataDog ไป NewRelic

Datadog เทียบกับ Site24x7 + StatusCake + PagerDuty + SumoLogic + Slack

เราเคยใช้ datadog แต่พบว่าแพงเกินไปสำหรับความต้องการของเรา อย่าเข้าใจผิด มันยอดเยี่ยม แต่ก็มีต้นทุนมหาศาล เราตั้งค่า site24x7.com ด้วยการสมัครสมาชิกรายปีในราคาประมาณ 2-3 เดือนของ DD ได้

สแต็กการเฝ้าติดตามของเรา:

Site24x7 - APM การเฝ้าติดตาม URL ภายนอก การเฝ้าติดตามการไหลของอีเมล SMTP วันหมดอายุ ssl และการเฝ้าติดตามกระบวนการ

StatusCake - สำหรับการเฝ้าติดตามและยืนยัน URL - เป็นตัวสำรองของเราเผื่อ site24x7 พลาดบางอย่าง (ไม่เคยพลาด) แต่ SC ยืดหยุ่นกว่าสำหรับการเฝ้าติดตามพอร์ตและบริการภายนอกตามความต้องการของเรา

ทั้งสองเครื่องมือยกระดับไปที่ PagerDuty แล้วเราได้รับการยกระดับใน slack

SumoLogic - สำหรับการเฝ้าติดตามบันทึก (เป็นเครื่องมือที่ยอดเยี่ยมแต่ค่อนข้างซับซ้อนสำหรับความต้องการของเรา)

จาก slack เรายืนยันรับทราบ (ack) หรือแก้ไขการแจ้งเตือนได้

จากนั้นเรามีระบบอัตโนมัติ site24x7 มากมายที่เชื่อมต่อกับ commando.io สำหรับสิ่งที่เราเรียกว่า 'BedOps' - เมื่อมีการแจ้งเตือนถูกกระตุ้น เราเริ่มสคริปต์หรือระบบอัตโนมัติไม่กี่อย่างเพื่อพยายามแก้ไขสถานการณ์ (99% ของเวลาระบบอัตโนมัติ + สคริปต์ของเราช่วยให้เรารอดพ้นปัญหา)

เรามี runbook ภายในใน KB ของเราสำหรับเมื่อระบบอัตโนมัติล้มเหลวหรือหากมีบางอย่างนอกขอบเขตที่ต้องแก้ไข

Prometheus + AlertManager + Grafana + Stackdriver

Prometheus (Operator) / AlertManager / Grafana สำหรับเมตริกในคลัสเตอร์ GKE และ VM ของเรา

Google Stackdriver สำหรับบันทึก (เพราะรวมมาและเปิดใช้งานโดยค่าเริ่มต้น และตอนนี้เพียงพอสำหรับความต้องการของเรา)

Zabbix

Zabbix สำหรับทุกอย่าง ไม่ต้องใช้ซอฟต์แวร์เพิ่มเติม