Than chì dừng thu thập dữ liệu ngẫu nhiên

8

Chúng tôi có một máy chủ Graphite để thu thập dữ liệu thông qua colld, statsd, JMXTrans ... Kể từ vài ngày, chúng tôi thường xuyên có lỗ hổng trong dữ liệu của mình. Đi sâu vào dữ liệu chúng ta vẫn có, chúng ta có thể thấy kích thước bộ đệm carbon tăng (từ 50K lên 4M). Chúng tôi không thấy sự gia tăng số lượng số liệu được thu thập (metricsReceured ổn định ở mức khoảng 300K). Chúng tôi có sự gia tăng số lượng truy vấn trung bình từ 1000 đến 1500.

Thật kỳ lạ, cpuUsage giảm nhẹ từ 100% (chúng tôi có 4 CPU) xuống 50% khi kích thước bộ đệm tăng.

Thật kỳ lạ, một lần nữa, chúng ta lại thấy sự gia tăng số lượng nếu các octet đọc từ đĩa và giảm số lượng octet được viết.

Chúng tôi có cấu hình carbon chủ yếu với các giá trị mặc định:

MAX_CACHE_SIZE = inf
MAX_UPDATE_PER_SECOND = 5000
MAX_CREATE_PER_MINUTE = 2000

Rõ ràng, một cái gì đó đã thay đổi trong hệ thống của chúng tôi, nhưng chúng tôi không hiểu điều gì, cũng như làm thế nào chúng tôi có thể tìm thấy nguyên nhân này ...

Có ai giúp đỡ không?

graphite metrics

— Guillaume
nguồn

Tôi thường bắt đầu từ cách tiếp cận cơ bản đến các vấn đề than chì; Có không gian trên đĩa để ghi vào? Có quyền thay đổi thư mục dữ liệu? Có sự thay đổi trong việc thu thập số liệu thống kê của người dùng daemon không? Nếu không có nguyên nhân rõ ràng, bạn hoàn toàn có thể bị tham nhũng RRD và có thể cần tìm cách xuất những gì bạn có và bắt đầu thu thập số liệu từ đầu.

— Stephan

Chúng tôi đã kiểm tra dung lượng đĩa và sự cho phép, không có gì lạ ở đó. Không có thay đổi trong dữ liệu thu thập daemon, có thể tăng số lượng số liệu, nhưng không lớn. Chúng tôi đang xem xét tham nhũng WSP.

— Guillaume

2

Đây không phải là lỗi của ngăn xếp than chì, mà là một nút cổ chai IO, rất có thể là do bộ lưu trữ của bạn không có IOPS đủ cao. Bởi vì điều này, hàng đợi tiếp tục xây dựng và tràn ra ở mức 4M. Tại thời điểm đó, Bạn mất nhiều dữ liệu được xếp hàng, được phản ánh sau đó, dưới dạng các 'khoảng trống' ngẫu nhiên trong biểu đồ của bạn. Hệ thống của bạn không thể theo kịp quy mô mà nó đang nhận được số liệu. Nó tiếp tục lấp đầy và tràn ra .

Thật kỳ lạ, cpuUsage giảm nhẹ từ 100% (chúng tôi có 4 CPU) xuống 50% khi kích thước bộ đệm tăng.

Điều này là do hệ thống của bạn bắt đầu hoán đổi và CPU nhận được rất nhiều 'thời gian nhàn rỗi', vì chờ đợi IO.

Để thêm ngữ cảnh, tôi có 500 IOPS được cung cấp tại aws trên một hệ thống mà tôi nhận được một số liệu 40K. Hàng đợi ổn định ở mức 50K.

— erbdex
nguồn

Tôi đang nhìn thấy cùng một vấn đề được mô tả trong câu hỏi. Tuy nhiên, việc sử dụng đĩa là tối thiểu (được báo cáo là 0% -3% khi ở trên đỉnh) và tôi chỉ đẩy ~ 80 số liệu / giây thông qua StatsD. Vì vậy, có vẻ như tôi không có nút cổ chai IO. Bất kỳ ý tưởng về những gì có thể gây ra vấn đề?

— heyman

1

Người trả lời khác đề cập đến nút cổ chai i / o. Tôi sẽ nói về tắc nghẽn mạng là một nguyên nhân khác của việc này.

Trong môi trường của tôi, chúng tôi chạy một cụm máy chủ UI mặt trước (httpd, memcached); một cụm khác của rơle lớp giữa (carbon-c-rơle thực hiện chuyển tiếp và tập hợp); và một lớp phụ trợ (httpd, memcached, carbon-c-rơle và carbon-cache.) Mỗi cụm này bao gồm nhiều trường hợp trong EC2 và trong toàn bộ quá trình 15 triệu số liệu mỗi phút.

Chúng tôi đã gặp sự cố khi chúng tôi thấy các khoảng trống cho các số liệu được tạo bởi hàm "tổng" và tổng các giá trị không chính xác (quá thấp). Vấn đề sẽ giảm bớt bằng cách khởi động lại carbon-c-rơle ở lớp giữa, nhưng các khoảng trống sẽ bắt đầu xuất hiện trở lại sau vài giờ.

Chúng tôi đã tổng hợp diễn ra ở cả lớp giữa và lớp phụ trợ (lớp phụ trợ tổng hợp các số liệu tổng hợp được truyền cho nó từ lớp giữa).

Các máy chủ lớp giữa không bị ràng buộc cpu, không bị ràng buộc đĩa và không có ràng buộc về bộ nhớ. Điều này kết hợp với thực tế là vấn đề sẽ chỉ xuất hiện vài giờ sau khi khởi động lại các quy trình chuyển tiếp, có nghĩa là có một nút cổ chai mạng. Giải pháp của chúng tôi chỉ đơn giản là thêm nhiều máy chủ vào lớp giữa. Làm điều này ngay lập tức dẫn đến các số liệu tổng hợp thực hiện chính xác và không gặp phải các khoảng trống.

Vị trí chính xác trong ngăn xếp mạng là nơi tắc nghẽn? Tôi không thể nói với bạn. Nó có thể đã được trên các máy chủ linux; nó có thể đứng về phía Amazon.

— Michael Martinez
nguồn