Graphite hiển thị không có ai cho tất cả các điểm dữ liệu mặc dù tôi gửi dữ liệu


8

Tôi đã cài đặt Graphite qua Puppet ( https://forge.puppetlabs.com/dwerder/graphite ) với nginx và PostgresQuery. Khi tôi gửi dữ liệu theo cách thủ công, nó sẽ tạo ra số liệu nhưng tất cả các điểm dữ liệu của nó là "Không" (còn gọi là null). Điều này cũng xảy ra nếu tôi chạy example-client.py được vận chuyển bằng Graphite.

echo "jakub.test 42 $(date +%s)" | nc 0.0.0.0 2003 # Carbon listens at 2003
# A minute or so later:
$ whisper-fetch.py --pretty /opt/graphite/storage/whisper/jakub/test.wsp | head -n1
Sun May  4 12:19:00 2014    None
$ whisper-fetch.py --pretty /opt/graphite/storage/whisper/jakub/test.wsp | tail -n1
Mon May  5 12:09:00 2014    None
$ whisper-fetch.py --pretty /opt/graphite/storage/whisper/jakub/test.wsp | grep -v None | wc -l
0

Và:

$ python /opt/graphite/examples/example-client.py 
# Wait until it sends two batches of data ...
$ whisper-fetch.py /opt/graphite/storage/whisper/system/loadavg_15min.wsp | grep -v None | wc -l
0

Theo ngrep, đây là dữ liệu đến cổng [từ lần thử sau] (dòng 3):

####
T 127.0.0.1:34696 -> 127.0.0.1:2003 [AP]
  jakub.test  45 1399362193. 
####^Cexit
23 received, 0 dropped

Đây là phần có liên quan của /opt/graphite/conf/storage-schemas.conf:

[default]
pattern = .*
retentions = 1s:30m,1m:1d,5m:2y

Bất cứ ý tưởng gì là sai? Số liệu và dữ liệu riêng của Carbon được hiển thị trong UI. Cảm ơn bạn!

Môi trường: Ubuntu 13.10 Saucy, than chì 0.9.12 (qua pip).

PS: Tôi đã viết về các nỗ lực khắc phục sự cố của mình ở đây - Graphite hiển thị số liệu nhưng không có dữ liệu - Xử lý sự cố

CẬP NHẬT :

  1. Điểm dữ liệu trong các tệp thì thầm chỉ được truy xuất sau mỗi 1m tối thiểu ngay cả khi chính sách lưu giữ chỉ định độ chính xác cao hơn như "1s" hoặc "10s".
  2. Giải pháp thay thế cho dữ liệu bị bỏ qua: Sử dụng lược đồ tổng hợp với xFilesFactor = 0.1(thay vì 0,5) hoặc đặt độ chính xác thấp nhất là 1m thay vì <số trong khoảng 1-49> s. - xem các bình luận bên dưới câu trả lời được chấp nhận hoặc câu trả lời của Graphite. Theo các tài liệu : " xFilesFactorphải là số có dấu phẩy động trong khoảng từ 0 đến 1 và chỉ định phần nào của các vị trí của mức lưu giữ trước đó phải có các giá trị khác không để tổng hợp thành giá trị không null. Mặc định là 0,5. " Vì vậy, dường như không liên quan đến việc có độ chính xác xác định là 1 giây, dữ liệu được tổng hợp thành 1 phút và kết thúc là Không vì dưới 50% giá trị trong khoảng thời gian là không có gì.

GIẢI PHÁP

Vì vậy, @jlawrie dẫn tôi đến giải pháp. Hóa ra dữ liệu thực sự ở đó nhưng được tổng hợp thành không có gì, lý do là gấp đôi:

  1. Cả UI và whisper-fetch hiển thị dữ liệu được tổng hợp với độ chính xác cao nhất kéo dài toàn bộ thời gian truy vấn, mặc định là 24h. Tức là mọi thứ có độ giữ <1d sẽ không bao giờ hiển thị trong UI hoặc tìm nạp trừ khi bạn chọn khoảng thời gian ngắn hơn. Vì thời gian lưu của tôi trong 1 giây là 30 phút, tôi cần chọn khoảng thời gian <= 30 phút cuối để thực sự thấy dữ liệu thô với độ chính xác cao nhất được thu thập.
  2. Khi tổng hợp dữ liệu (từ 1 giây đến 1 phút trong trường hợp của tôi), theo mặc định, Graphite yêu cầu 50% (xFilesFactor = 0,5) của các điểm dữ liệu trong khoảng thời gian có giá trị. Nếu không, nó sẽ bỏ qua các giá trị hiện có và tổng hợp nó thành Không có. Vì vậy, trong trường hợp của tôi, tôi cần gửi dữ liệu ít nhất 30 lần trong vòng một phút (30 là 50% của 60 giây = 1 phút) để chúng hiển thị trong giá trị 1 phút tổng hợp. Nhưng ứng dụng của tôi chỉ gửi dữ liệu cứ sau 10 giây nên tôi chỉ có 6 trong số 60 giá trị có thể.

=> giải pháp là thay đổi độ chính xác đầu tiên từ 1 giây thành 10 giây và nhớ chọn khoảng thời gian ngắn hơn khi tôi muốn xem dữ liệu thô (hoặc mở rộng lưu giữ của nó thành 24h để hiển thị theo mặc định).


Câu hỏi Đáp án Graphite Bộ dữ liệu chứa đầy null? là điều thú vị trong bối cảnh này (đề cập đến việc bổ sung mặc định null sau mỗi 60 giây, chỉ trong 24 giờ qua) và b / c khuyến nghị của nó về ngrep để khắc phục sự cố.
Jakub Holý

Tôi cũng đã yêu cầu trợ giúp tại Câu trả lời của Graphite - answer.launchpad.net/graphite/+question/248242
Jakub Holý

Bạn đã kiểm tra các bản ghi? Nếu có vấn đề với số liệu nhận được (không có \ n hoặc sử dụng \ r \ n thay thế), bạn sẽ thấy một cái gì đó trong console.log hoặc created.log. Các nhật ký này được lưu trữ trong / opt / graph / lưu trữ / log / carbon-cache / carbon-cache-a / nếu bạn sử dụng đường dẫn cài đặt mặc định.
mattsn0w

Vâng, tôi đã kiểm tra các bản ghi. Không có gì quan tâm. Nhật ký bảng điều khiển về cơ bản chỉ có "[..] ServerFactory bắt đầu từ 7002 [..] Bắt đầu xuất xưởng <twist.iNET.protatio.ServerFactory tại 0x1bc4248>" và có hồ sơ tạo số liệu dự kiến ​​nhưng không đề cập đến dữ liệu - f. Ví dụ. (đối với một số liệu không có dữ liệu khác) "[..] tạo tệp cơ sở dữ liệu /opt/graphite/st Storage / whisper / ring / handling-time / ARST / 15MinuteRate.wsp (archive = [(1, 1800), (60, 1440 ), (300, 210240)] xff = 0,5 agg = trung bình) "
Jakub Holý

@ JakubHolý Bạn có thể cập nhật câu trả lời của jlawrie hoặc đăng câu trả lời khác vì câu hỏi có chứa câu trả lời ngay bây giờ
030

Câu trả lời:


8

Tôi gặp vấn đề tương tự bằng cách sử dụng mô-đun con rối đó. Tôi không chắc chắn chính xác tại sao, nhưng thay đổi chính sách duy trì mặc định dường như để sửa nó, vd

class { 'graphite':
  gr_storage_schemas => [
    {
      name       => 'carbon',
      pattern    => '^carbon\.',
      retentions => '1m:90d'
    },
    {
      name       => 'default',
      pattern    => '.*',
      retentions => '1m:14d'
    }
  ],
}

Cảm ơn rất nhiều! Sự thay đổi bí ẩn này đã thực sự giúp ích. Điều thú vị là việc thay đổi giữ lại từ "1s: 30m, 1m: 1d, 5m: 2y" thành "1m: 14d" không "sửa chữa" nó. Tôi sẽ cố gắng chơi nhiều hơn với nó. Có thể có một số vấn đề với độ chi tiết 1s?
Jakub Holý

Nó thực sự có vẻ là một vấn đề với thời kỳ s - trong khi '1m:1d,5m:2ycác công trình (dữ liệu được thu hồi) 10s:30m,1m:1d,5m:2ythì không. Trên thực tế, từ tệp .wsp, có vẻ như độ chi tiết <1m bị bỏ qua vì dấu thời gian trong 10 giây: ... cấu hình vẫn ở các khoảng thời gian 1 phút - "08:17:00, 08:18:00, v.v."
Jakub Holý

OK, do đó, vấn đề liên quan đến chính sách tổng hợp và xFilesFactor, (mặc định) áp dụng ở đây là trung bình và xFilesFactor=0.5(xem /opt/graphite/conf/storage-aggregation.conf). Khi tôi thay đổi thành sum0.1bằng cách thay đổi tên, dữ liệu sẽ được lưu trữ (mặc dù số nguyên tố vẫn ở mức 1m freq):echo -e "jakub.test.10s30m+1m1d+5m2y.count 42 $(date +%s)" | nc 0.0.0.0 2003
Jakub Holý

Tôi đã chơi với diff. tổng hợp. lược đồ, dữ liệu được ghi lại (ở khoảng cách 1m) khi tôi đặt xFilesFactor = 0.1, agg. phương pháp không quan trọng (ít nhất là tất cả công việc trung bình, cuối cùng, tổng).
Jakub Holý

Theo đó , các lược đồ tổng hợp chỉ đi vào hoạt động với nhiều chính sách duy trì. Nếu tôi chỉ có một chính sách duy trì, thậm chí ở độ phân giải 10 giây (đó là tần suất tôi gửi dữ liệu), thì nó sẽ thu thập từng điểm dữ liệu riêng lẻ. Với nhiều chính sách duy trì, nó chọn một chính sách dựa trên phạm vi thời gian của truy vấn, với whisper-fetch.py ​​mặc định cho đến ngày cuối cùng, đó là lý do tại sao bạn chỉ nhìn thấy các điểm dữ liệu mỗi 1 phút. Vẫn không chắc chắn tại sao họ hiển thị Không, thay vì giá trị tổng hợp mặc dù.
jlawrie

1

Có nhiều cách mà Graphite sẽ mất dữ liệu, đó là lý do tại sao tôi thực sự cố gắng tránh sử dụng nó. Hãy để tôi bắt đầu với một cái đơn giản - thử kết nối ứng dụng của bạn, đợi một giây (nghĩa là một giây) và sau đó xuất dữ liệu được đánh dấu thời gian. Tôi đã tìm thấy trong nhiều trường hợp điều này sẽ khắc phục vấn đề chính xác đó. Một điều khác bạn nên thử là gửi dữ liệu với tần suất cao hơn nhiều so với tần suất ghi nhật ký dữ liệu. Tôi sẽ đi sâu hơn một chút. Một lỗi thường gặp khác là sử dụng tiện ích thì thầm, không thực sự hiệu quả với tôi. Nếu dữ liệu của bạn chưa quan trọng, chỉ cần xóa các tệp thì thầm và để chúng được tạo với cài đặt lưu giữ mới.

Các tệp lưu trữ của Graphite, các tệp thì thầm, thay vì lưu trữ dữ liệu dưới dạng một điểm có giá trị và thời gian (như bạn đã cung cấp chương trình) thực sự lưu trữ nó như một chuỗi các vị trí mà giá trị được lưu trữ. Chương trình sau đó cố gắng tìm ra khe nào tương ứng với một khoảng thời gian sử dụng tệp dữ liệu lưu giữ. Nếu nó nhận được một dữ liệu không chính xác vừa với một vị trí, tôi nghĩnhững gì xảy ra là nó sử dụng mức trung bình, tối thiểu hoặc tối đa tùy thuộc vào một tệp khác trong cùng thư mục với tệp lưu giữ. Tôi thấy rằng cách tốt nhất để giữ cho mọi thứ không bị rối tung là gửi dữ liệu với tần suất cao hơn nhiều so với tần suất lưu trữ than chì. Nó thực sự trở nên siêu phức tạp - không chỉ có các giai đoạn duy trì cho than chì và các thuật toán trung bình điền vào các điểm (tôi nghĩ), mà các giá trị này cũng được áp dụng cho các tệp thì thầm. Những điều rất kỳ quặc sẽ xảy ra khi những điều này không khớp, vì vậy cho đến khi cấu hình của bạn hoạt động, tôi sẽ đề nghị xóa các tệp thì thầm của bạn nhiều lần và để than chì tái tạo chúng.

Chương trình này thực sự gây ấn tượng với tôi vì hành động khá lỗi, vì vậy nếu bạn gặp phải điều gì đó như thế này thì đừng cho rằng đó là lỗi của bạn.


Cảm ơn bạn, tôi đoán tôi nên tìm hiểu thêm về cách hoạt động của việc truy xuất và tổng hợp dữ liệu, có lẽ đó thực sự là nguyên nhân của vấn đề. Tuy nhiên tôi nghĩ rằng " gửi dữ liệu ở tần số cao hơn nhiều so với tần suất lưu trữ dữ liệu than chì " là một giải pháp tối ưu vì chỉ có điểm dữ liệu cuối cùng nhận được trong mỗi giai đoạn than chì được ghi lại, đó là lý do tại sao f.ex . Thời gian tuôn ra thống kê phải = Thời gian than chì .
Jakub Holý

1
Dữ liệu "mất" BTW, Graphite / Carbon có thể liên quan đến cài đặt Carbon, chẳng hạn như MAX_UPDATE_PER_SECOND = 500, MAX_CREATE_PER_MINUTE = 50 (Tôi đoán các điểm / số liệu dữ liệu vượt quá giới hạn vừa bị bỏ).
Jakub Holý

Có vẻ như tôi đã sai, tài liệu - nếu tôi diễn giải chính xác - cho biết các cài đặt trên giới hạn truy cập đĩa nhưng dữ liệu / số liệu vẫn được giữ trong bộ nhớ (mặc dù tôi muốn thực sự xác minh điều này trước).
Jakub Holý

Một vài trong số đó chắc chắn có thể giải thích một số vấn đề mà tôi gặp phải với ứng dụng đó.
Một số Linux Nerd
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.