Trước khi bạn bắt đầu xem xét công cụ giám sát máy chủ SQL, hãy nghĩ về môi trường cụ thể của bạn:
- Bạn muốn theo dõi bao nhiêu trường hợp?
- Những thứ này nằm ở một vị trí hay phân tán?
- Bạn có cần giám sát hệ điều hành và / hoặc trình giám sát không?
- Bạn cần bao nhiêu lịch sử để có được bức tranh chính xác về ranh giới hoạt động của phiên bản của bạn?
- Tất cả chúng đều tại chỗ hay một số ở trên đám mây?
- Các nhóm của bạn có được phân bổ không?
- Bạn mua phần mềm theo ngân sách chi tiêu đầu tư hay ngân sách chi hoạt động?
- Bạn có đủ khả năng đầu tư một lần vào cơ sở hạ tầng và giấy phép hay bạn muốn phân bổ chi phí của mình theo thời gian?
- Bạn có sẵn cơ sở hạ tầng và các phiên bản cơ sở dữ liệu để cung cấp cho công cụ giám sát không?
- Bạn có thời gian để xây dựng cơ sở hạ tầng giám sát không?
- Bạn có liên tục có chuyên môn cao trong nhóm của mình không?
- Bạn có sử dụng các tài nguyên cơ sở để thử nghiệm ban đầu hay phụ thuộc vào các chuyên gia của bạn về mọi thứ?
- Bạn có thời gian hoặc nguồn lực nội bộ để duy trì cơ sở hạ tầng giám sát không?
Tôi có nên tự mình triển khai không?
Tôi có thể tuyên bố sự thiên vị của chúng tôi ở đây. Quest Software đã xây dựng các công cụ giám sát hiệu suất trong 20 năm qua. Có một lý do tuyệt vời tại sao chúng tôi và nhiều người khác như chúng tôi đã ở lại phân khúc này quá lâu và tại sao chúng tôi có cơ sở khách hàng ngày càng tăng. Giám sát hiệu suất được thực hiện tốt không phải là điều dễ dàng!
Thực sự có một số cách tuyệt vời để thu thập số liệu từ SQL Server bằng PerfMon, dấu vết, DMV và XEvents, phải kể đến một số cách. Thực hiện điều này một lần cho một vấn đề duy nhất là tốt và tốt — nếu bạn có thời gian đầu tư vào việc nghiên cứu địa điểm và cách thu thập dữ liệu cho vấn đề đó. Khi các vấn đề bắt đầu tăng lên và số lượng các trường hợp tăng lên, điều này nhanh chóng trở nên không thể điều chỉnh được.
Có hàng trăm số liệu có sẵn đáng để theo dõi để có được bức tranh toàn cảnh về tình trạng hoạt động của SQL Server của bạn. Ngoài ra, còn có mã SQL chạy và các kế hoạch truy vấn được liên kết với mỗi lần thực thi giống nhau. Một số chỉ số nên được thu thập mỗi giây, một số mỗi giờ và một số dựa trên thời điểm mã thực thi. Một số phương pháp thu thập có thể ảnh hưởng đến phiên bản được giám sát và nên tránh.
Mỗi chỉ số sẽ có các ngưỡng khác nhau sẽ xác định trạng thái của nó. Các trường hợp cụ thể có thể có các mức không chuẩn. Sau đó, bạn phải lưu trữ tất cả những thứ này. Khối lượng dữ liệu tăng lên RẤT nhanh. Bạn sẽ cần phải đưa ra một chiến lược để lọc dữ liệu chi tiết một cách thường xuyên và sau đó, nếu cần cho xu hướng, hãy tổng hợp dữ liệu này để báo cáo.
Đó là rất nhiều công việc… và tất nhiên, mỗi khi một phiên bản SQL Server mới ra mắt, bạn phải đau đầu giải quyết hồi quy. Trừ khi bạn thực sự muốn bán một công cụ giám sát, tôi thực sự khuyên bạn không nên tự triển khai trừ khi khối lượng vấn đề ít và các vấn đề bạn phải giải quyết rất cụ thể.
Còn về các công cụ miễn phí?
Các công cụ miễn phí thường đáng xem xét, đặc biệt là đối với các nhóm nhỏ hơn với các trường hợp ít quan trọng hơn. Hãy coi đó là bước tiếp theo trong nấc thang khả năng mở rộng sau khi “tự mình xoay sở”. Nhiều công cụ giám sát máy chủ SQL thương mại cấp đầu vào phải có những cân nhắc tương tự. Hãy xem xét những điều sau:
- Công cụ có bao gồm đủ phạm vi số liệu để cung cấp cho bạn phạm vi phù hợp cho tất cả các trường hợp sử dụng trong các trường hợp được giám sát của bạn không? Nhiều công cụ miễn phí sẽ cung cấp một số loại "tùy chỉnh" để thêm số liệu của riêng bạn. Khi "tùy chỉnh" được sử dụng để lấp đầy những khoảng trống trong chức năng, thì bạn sẽ nhanh chóng nhận thấy nhóm của mình kết thúc "việc của riêng họ" với sự phân tâm cần thiết và đau đầu về bảo trì.
- Công cụ có hỗ trợ cảnh báo không? Nó có được cấu hình sẵn không? Việc định cấu hình cảnh báo có thể rất tốn thời gian. Cảnh báo out-of-box là cần thiết để ngăn chặn nhiều giờ làm mất công cấu hình công cụ của người khác. Nó cũng sẽ tạo điều kiện thuận lợi cho việc tùy chỉnh các cảnh báo đối với các trường hợp biên không tuân theo giá trị mặc định.
- Dữ liệu được lưu trữ như thế nào và ở đâu? Hầu hết các công cụ miễn phí giao nó cho bạn để quản lý việc lưu trữ dữ liệu hiệu suất. Hãy cảnh giác với việc giám sát "miễn phí" từ các nhà cung cấp dịch vụ đám mây. Họ tính phí bộ nhớ và điều này có thể trở nên lớn và tốn kém nhanh chóng!
Vì vậy, bằng mọi cách, hãy khai thác các công cụ miễn phí hiện có. Chỉ cần lưu ý những hạn chế của chúng và tìm kiếm các mô hình phản đối cổ điển trong nhóm của bạn, chẳng hạn như:
- Đã dành nhiều thời gian hơn để sửa hoặc bảo trì công cụ sử dụng nó để khắc phục sự cố
- Chi nhiều tiền hơn cho cơ sở hạ tầng và bộ nhớ
- Nhiều dữ liệu nhưng không có thông tin chi tiết
- Không đủ chuyên sâu trong chẩn đoán để giải quyết các vấn đề
- Không đủ khả năng mở rộng để phù hợp với nhu cầu của bạn
Nếu bạn nhận thấy bất kỳ điều nào ở trên, điều đó cho thấy cần phải nâng cấp lên một giải pháp mạnh mẽ hơn.
Kiến trúc điển hình của hệ thống giám sát máy chủ SQL
Khi cân nhắc nên sử dụng giải pháp tại chỗ truyền thống hay một phần mềm được lưu trữ dưới dạng giải pháp dịch vụ (SaaS), sẽ hữu ích khi xem xét kiến trúc ứng dụng giám sát. Dưới đây là tóm tắt về các thành phần kiến trúc chính.
Độ lệch chính giữa SaaS và tại chỗ liên quan đến nơi dữ liệu hiệu suất được lưu trữ và ai quản lý kho lưu trữ này. Đối với giải pháp tại chỗ, đây là trách nhiệm của người dùng cuối. Những kho lưu trữ này có thể lớn nhanh chóng, vì vậy chúng cần được quản lý cẩn thận. Cơ sở hạ tầng cần được lập kế hoạch và lập ngân sách cho (chi tiết bên dưới).
Trong giải pháp SaaS để giám sát máy chủ SQL, các thành phần cơ sở hạ tầng chính này được lưu trữ và quản lý cho bạn.
| Giải pháp tại chỗ truyền thống | Giải pháp SaaS |
|
|
Để biết thêm chi tiết, hãy xem blog của chúng tôi, Kiến trúc hệ thống giám sát cơ sở dữ liệu.
