Giám sát mọi thứ mà bạn có thể thường xuyên như bạn có thể. Tôi đặc biệt khuyên dùng Graphite w / statsd làm vị trí trung tâm để thu thập tất cả các số liệu của bạn. Nó cung cấp một giao thức văn bản đơn giản rất đơn giản để ghi nhật ký gần như bất kỳ dữ liệu số liệu nào và giao diện người dùng giúp dễ dàng so sánh một số liệu này với một số liệu khác. Trên hệ thống của mình, tôi thu thập rất nhiều thông tin và hầu hết thông tin đã được chứng minh là vô giá vào lúc này hay lúc khác. Dưới đây là một vài trong số họ:
Tôi đã viết một daemon gọi mysampler rằng gửi đầu ra của SHOW GLOBAL STATUSđể graphite (hoặc csv, nếu bạn muốn) đều đặn. Chúng tôi ghi nhật ký này ở các khoảng thời gian 5s, nhưng có những lúc tôi ước chúng tôi đã đặt nó thành các khoảng thời gian 1 giây. Bạn bắt đầu thấy một số mô hình rất thú vị ở mức độ chi tiết đó. Nó nhận thức được các số liệu thống kê nào là các bộ đếm và giá trị tuyệt đối (Câu hỏi là một bộ đếm, Themes_rucky là một giá trị tuyệt đối) và sẽ xuất ra các đồng bằng cho các bộ đếm.
ab-tblstats2g chạy từ cron mỗi đêm và gửi số liệu thống kê kích thước bảng đến than chì để chúng tôi có thể theo dõi sự tăng trưởng của bảng. Tôi dự định mở rộng nó để bao gồm giá trị khóa chính tối đa và số lượng hàng (từ thống kê bảng) trong tương lai gần. Nó cũng hoạt động với MSSQL Server.
mysql_logger ghi nhật ký đầu ra của SHOW FULL PROCESSLIST để syslog mỗi khoảng thời gian X. Nó làm cho nó trở nên tầm thường để tìm ra chính xác những gì đang chạy đồng thời khi có điều gì đó kỳ lạ (khóa bảng, truy vấn chạy dài, v.v.). Chúng tôi kết xuất dữ liệu đó vào Splunk để dễ dàng tìm kiếm, nhưng đôi khi tôi vẫn chỉ sử dụng grep trong nhật ký nhật ký hệ thống.
pt-stalk từ Percona Toolkit là tuyệt vời cho "chuyện gì vừa xảy ra?" kịch bản. Nó theo dõi các biến trạng thái máy chủ vượt quá một giá trị nhất định ( Threads_connected> 25 theo mặc định, nhưng Threads_runningthường là một số liệu có giá trị hơn, theo kinh nghiệm của tôi) và khi được kích hoạt, thu thập một loạt dữ liệu về MySQL và hệ thống có thể được xem xét bằng pt-sift hoặc chỉ bằng cách xem lại các tập tin được tạo ra. Nó thậm chí sẽ tạo ra các dấu vết tcpdumps, gdb, oprofile và strace.
Về cơ bản đó là những gì chúng tôi theo dõi , khác với cảnh báo. Để cảnh báo, tôi khuyên bạn nên cảnh báo về một số lượng rất nhỏ. Bạn có thể bao gồm 90% các trường hợp chỉ bằng cách chọn truy vấn đại diện khối lượng công việc và đặt ngưỡng về thời gian cần trả lại. Nếu vượt quá ngưỡng đó, cảnh báo ... có vấn đề. Nếu không, bạn ổn. Không cần phải kiểm tra "là quá trình đang chạy" hay bất cứ điều gì tương tự. Những thứ khác cần tìm là các mục trong nhật ký lỗi của MySQL, tiếp cận quá nhiều kết nối và mức độ sao chép hoạt động tốt (độ trễ nô lệ, chạy nô lệ, bảng đồng bộ). Tỷ lệ trúng hoàn toàn vô dụng cho mục đích cảnh báo - tất cả vấn đề là các truy vấn sẽ trở lại trong một khoảng thời gian.
Để đọc thêm, sách trắng Ngăn chặn các trường hợp khẩn cấp của MySQL bởi những người Percona là một bài đọc tốt đi sâu vào chi tiết về những gì cần theo dõi và cảnh báo. Percona cũng đã phát hành một bộ Plugin Nagios (nên hoạt động với Zabbix, tôi tin) mà bạn có thể sử dụng.
realtimecông cụ thay vì công cụ này?