پایش ‏Ceph: Prometheus‏، ‏ceph-exporter‏، هشدارها و مشاهده‌پذیری

۲۰-۱ پیش از شروع#

۲۰-۱-۱ این فصل به چه سؤال‌هایی جواب می‌دهد؟#

‏ceph -s‏ برای یک نگاه سریع کافی است، اما برای پاسخ به پرسش‌هایی مانند «تأخیر نوشتن از سه‌شنبه چرا بالا رفته؟» یا «کدام ‏OSD‏ در یک ساعت گذشته کندترین بوده؟» به سری‌های زمانی، قواعد هشدار و داشبورد نیاز داریم. ‏Ceph‏ امروز پشته‌ی پایش استانداردی دارد که ‏cephadm‏ آن را مستقر می‌کند: ماژول ‏prometheus‏ در ‏mgr‏، ‏daemon‏ ‏ceph-exporter‏ روی هر میزبان، ‏node-exporter‏، ‏Prometheus‏، ‏Alertmanager‏ و ‏Grafana‏، و در ‏Tentacle‏ دروازه‌ی ‏mgmt-gateway‏.

• هر مؤلفه‌ی پشته چه داده‌ای تولید می‌کند و چرا شمارنده‌های عملکرد از ‏mgr‏ به ‏ceph-exporter‏ منتقل شدند؟
• کدام متریک‌ها مهم‌ترین سیگنال‌ها هستند؟
• قاعده‌ی هشدار خوب برای ‏Ceph‏ چه ویژگی‌هایی دارد؟
• شمارنده‌های داخلی ‏daemon‏ها (‏perf counters‏) چگونه ساخته و خوانده می‌شوند؟
• ‏mgmt-gateway‏ و ‏oauth2-proxy‏ چه مشکلی را حل می‌کنند؟

۲۰-۲ معماری پشته‌ی پایش#

ceph mgr module enable prometheus
ceph orch apply node-exporter
ceph orch apply ceph-exporter
ceph orch apply alertmanager
ceph orch apply prometheus
ceph orch apply grafana
ceph orch ls --service-type prometheus
ceph dashboard get-prometheus-api-host

۲۰-۲-۱ ‏Prometheus‏ بیرونی#

# prometheus.yml — نمونه‌ی این کتاب برای Prometheus بیرونی
scrape_configs:
  - job_name: ceph
    honor_labels: true
    http_sd_configs:
      - url: http://mgr1.example.internal:8765/sd/prometheus/sd-config?service=mgr-prometheus
  - job_name: ceph-exporter
    honor_labels: true
    http_sd_configs:
      - url: http://mgr1.example.internal:8765/sd/prometheus/sd-config?service=ceph-exporter
  - job_name: node
    http_sd_configs:
      - url: http://mgr1.example.internal:8765/sd/prometheus/sd-config?service=node-exporter

۲۰-۳ از درون کد: ‏perf counters‏#

۲۰-۳-۱ ساخت شمارنده‌ها#

هر ‏daemon Ceph‏ شمارنده‌های خود را با ‏PerfCountersBuilder‏ (‏src/common/perf_counters.h‏) تعریف می‌کند. هر شمارنده یک کلید عددی، یک نام، یک نوع و یک اولویت دارد. انواع اصلی:

اولویت‌ها از ‏PRIO_CRITICAL=10‏ تا ‏PRIO_DEBUGONLY=0‏ هستند (‏PRIO_INTERESTING=8‏، ‏PRIO_USEFUL=5‏). این اولویت نقش عملی دارد: ‏ceph-exporter‏ فقط شمارنده‌هایی با اولویت دست‌کم ‏exporter_prio_limit‏ را منتشر می‌کند که در ‏src/common/options/ceph-exporter.yaml.in‏ پیش‌فرضش ۵ است. بنابراین شمارنده‌های ‏DEBUGONLY‏ به ‏Prometheus‏ نمی‌رسند مگر این حد را کاهش دهید (که حجم متریک‌ها را بسیار زیاد می‌کند).

# خواندن مستقیم شمارنده‌ها روی میزبان
ceph daemon osd.3 counter schema | jq 'keys' | head
ceph daemon osd.3 counter dump | jq '.osd[0].counters | {op_w, op_r}'
ceph daemon osd.3 perf dump osd | jq '.osd.op_w_latency'       # شکل قدیمی‌تر: avgcount و sum
ceph config get client.ceph-exporter exporter_prio_limit

۲۰-۳-۲ از ‏time_avg‏ به تأخیر#

شمارنده‌ی ‏add_time_avg‏ دو مقدار دارد: ‏sum‏ (مجموع ثانیه‌ها) و ‏avgcount‏ (تعداد). میانگین تأخیر در یک بازه، نسبت افزایش این دو است، نه نسبت مقادیر خام (که میانگین کل عمر ‏daemon‏ است):

avg_latency(window) = Δsum / Δavgcount
PromQL:  rate(ceph_osd_op_w_latency_sum[5m]) / rate(ceph_osd_op_w_latency_count[5m])

۲۰-۴ سیگنال‌های کلیدی#

۲۰-۵ طراحی قواعد هشدار#

قواعد زیر نمونه‌ی خود این کتاب‌اند و جایگزین ‏ceph-mixin‏ نیستند، بلکه الگوی افزودن قواعد محلی را نشان می‌دهند:

groups:
- name: ceph-local
  rules:
  - alert: CephWriteLatencyHigh
    expr: |
      ( rate(ceph_osd_op_w_latency_sum[5m]) / rate(ceph_osd_op_w_latency_count[5m]) ) > 0.05
    for: 15m
    labels: { severity: warning }
    annotations:
      summary: "تأخیر نوشتن {{ $labels.ceph_daemon }} بیش از ۵۰ میلی‌ثانیه"
      runbook: "https://wiki.example.internal/runbooks/ceph-slow-osd"
  - alert: CephPoolFillingFast
    expr: predict_linear(ceph_pool_percent_used[6h], 3 * 24 * 3600) > 0.85
    for: 1h
    labels: { severity: warning }
    annotations:
      summary: "pool {{ $labels.pool_id }} در سه روز آینده از ۸۵٪ می‌گذرد"

# Alertmanager: خاموش کردن هشدار OSD منفرد وقتی کل میزبان down است
inhibit_rules:
- source_matchers: [ alertname = "CephOSDHostDown" ]
  target_matchers: [ alertname = "CephOSDDown" ]
  equal: [ cluster ]

۲۰-۶ لایه‌ی پایین‌تر: از متغیر ‏atomic‏ تا سطر /‏metrics‏#

هر عدد روی داشبورد از یک متغیر ‏std::atomic<uint64_t>‏ در حافظه‌ی یک ‏daemon‏ شروع می‌شود. این بخش مسیر آن را تا ‏Prometheus‏ در سطح بایت و کد دنبال می‌کند تا بدانید هر عدد دقیقاً چه چیزی را اندازه می‌گیرد و کجا ممکن است دروغ بگوید.

۲۰-۶-۱ ساختار یک شمارنده#

‏perf_counter_data_any_d‏ در ‏src/common/perf_counters.h‏ برای هر شمارنده یک بایت نوع (‏bitmask‏)، یک اولویت و یک واحد نگه می‌دارد:

اولویت‌ها ‏PRIO_CRITICAL=10‏، ‏PRIO_INTERESTING=8‏، ‏PRIO_USEFUL=5‏، ‏PRIO_UNINTERESTING=2‏ و ‏PRIO_DEBUGONLY=0‏ هستند. این عدد تعیین می‌کند شمارنده اصلاً از ‏daemon‏ بیرون برود یا نه: ‏MgrClient‏ فقط شمارنده‌هایی را گزارش می‌کند که اولویت تنظیم‌شده‌شان ‏>= mgr_stats_threshold‏ (پیش‌فرض ۵) باشد. ‏ceph-exporter‏ هم همین کار را با ‏exporter_prio_limit=5‏ انجام می‌دهد. پس شمارنده‌ای که در ‏ceph daemon osd.3 perf dump‏ می‌بینید ولی در ‏Prometheus‏ نیست، احتمالاً اولویتی کمتر از ۵ دارد.

۲۰-۶-۲ میانگین بدون قفل#

‏tinc‏ برای یک شمارنده‌ی ‏LONGRUNAVG‏ سه کار را به این ترتیب انجام می‌دهد: ‏avgcount++‏، سپس ‏u64 += nsec‏ و در پایان ‏avgcount2++‏. خواننده (‏read_avg‏) برعکس عمل می‌کند:

pseudocode: read_avg (الگوی seqlock-مانند)
  repeat:
    c   = avgcount2        # شمارنده‌ی «پایان نوشتن»
    sum = u64
  until avgcount == c      # در این فاصله نوشتنی شروع نشده است
  return (sum, c)

اگر وسط خواندن یک ‏tinc‏ انجام شود، ‏avgcount‏ از ‏avgcount2‏ جلو می‌افتد و حلقه تکرار می‌شود. بنابراین جفت (‏sum, count‏) همیشه با هم سازگار است، بدون ‏mutex‏ در مسیر داغ ‏I/O‏. چون نویسنده‌های چندتایی (‏thread‏های شارد) هم‌زمان هستند، این تضمین «تقریباً» سازگار است و برای آمار کافی است، نه برای حسابداری دقیق.

مثال عددی#

فرض کنید دو نمونه به فاصله‌ی ۶۰ ثانیه از ‏osd.3‏ گرفته‌ایم:

‏IOPS‏ خواندن در این دقیقه ۳۰۰۰/۶۰=۵۰ است. ‏avgtime‏ از ۲.۴۱ به ۲.۳۳ رسیده و ظاهراً بهبود کمی نشان می‌دهد، در حالی که تأخیر واقعی این دقیقه ۱‏ms‏ بوده است. برعکسش هم ممکن است: یک دقیقه با تأخیر ۵۰‏ms‏، ‏avgtime‏ را فقط کمی بالا می‌برد. در ‏PromQL‏ معادل همین تفاضل این است:

rate(ceph_osd_op_r_latency_sum[1m]) / rate(ceph_osd_op_r_latency_count[1m])

۲۰-۶-۳ پروتکل ‏admin socket‏#

در ‏AdminSocket::do_accept‏ کد خطا روی سیم ارسال نمی‌شود. اگر فرمان شکست بخورد، پاسخ با رشته‌ی ‏ERROR: ‏ شروع می‌شود، پس ابزار خودکار باید همین پیشوند را بررسی کند. یک کلاینت حداقلی (نوشته‌ی این کتاب، فقط برای فهم پروتکل):

import socket, struct, json, sys
def asok(path, prefix):
    s = socket.socket(socket.AF_UNIX); s.connect(path)
    s.sendall(json.dumps({"prefix": prefix}).encode() + b"\0")
    n = struct.unpack(">I", s.recv(4, socket.MSG_WAITALL))[0]
    buf = b""
    while len(buf) < n: buf += s.recv(n - len(buf))
    s.close()
    if buf.startswith(b"ERROR: "): raise RuntimeError(buf[:200].decode())
    return json.loads(buf)
d = asok(sys.argv[1], "perf dump")
lat = d["osd"]["op_r_latency"]; print(lat["avgcount"], lat["sum"])

۲۰-۶-۴ دو مسیر رسیدن به ‏Prometheus‏#

دقت زمانی#

عدد ‏Prometheus‏ در بدترین حالت قدیمی‌تر از ‏scrape_interval‏ به‌علاوه‌ی دوره‌ی جمع‌آوری (۵ ثانیه) است. با ‏scrape‏ هر ۱۵ ثانیه، یک ‏spike‏ سه‌ثانیه‌ای ممکن است فقط به‌صورت افزایش کوچکی در ‏rate()‏ دیده شود. برای عیب‌یابی لحظه‌ای، مستقیم از ‏ceph daemon osd.N perf dump‏ یا ‏ceph tell osd.N dump_historic_ops‏ (فصل ۲۲) استفاده کنید، نه از داشبورد.

ceph daemon osd.3 perf schema | jq '.osd.op_r_latency'      # type، priority، units
ceph daemon osd.3 perf dump   | jq '.osd.op_r_latency'      # avgcount، sum، avgtime
ceph daemon osd.3 counter dump | jq 'keys' | head            # شمارنده‌های برچسب‌دار (نسخه‌های جدیدتر)
curl -s localhost:9926/metrics | grep -m3 ceph_osd_op_r_latency
ceph config get mgr mgr_stats_period

۲۰-۷ پایش با عدد: هیستوگرام، ‏cache‏ و سه قاعده‌ی هشدار#

این بخش پنج الگوریتم کوچک پشته‌ی پایش را با عدد بررسی می‌کند. دو الگوریتم درون خود ‏Ceph‏ هستند: هیستوگرام دوبعدی ‏perf counter‏ها و ‏cache‏ ماژول ‏prometheus‏ در ‏mgr‏. سه الگوریتم دیگر قواعد هشدار پیش‌فرض بسته‌ی ‏monitoring/ceph-mixin‏ هستند که ‏cephadm‏ همراه ‏Prometheus‏ مستقر می‌کند. همه‌ی ارجاع‌ها به شاخه‌ی ‏main‏ در نوامبر ۲۰۲۶ است. متن قواعد هشدار در نسخه‌های مختلف بارها تغییر کرده است، پس فایل ‏prometheus_alerts.yml‏ نسخه‌ی خودتان را با این متن مقایسه کنید. عددهای مثال با بازپیاده‌سازی پایتونی همین منطق حساب شده‌اند. در مورد ‏rate()‏ و ‏predict_linear()‏ در ‏Prometheus‏، پیاده‌سازی ما یک تقریب از منطق ‏Prometheus‏ است.

۲۰-۷-۱ هیستوگرام دوبعدی تأخیر و اندازه#

pseudocode
bucket(v, axis):
    if v < min: return 0                       # bucket صفر: کمتر از min
    q = (v − min) / quant
    LINEAR: return min(q + 1, buckets − 1)
    LOG2:   for i in 1 .. buckets−1: if q < 2^(i−1): return i
            return buckets − 1                 # bucket آخر: هر چیز بزرگ‌تر
محدوده‌ی bucket i در LOG2: [min + 2^(i−2)·quant ، min + 2^(i−1)·quant − 1]   (i ≥ 2)
hinc(latency_ns, bytes): counts[bucket_x(latency)][bucket_y(bytes)] += 1

‏OSD‏ دو هیستوگرام از این نوع دارد: ‏op_w_latency_in_bytes_histogram‏ و ‏op_r_latency_out_bytes_histogram‏. محور ‏x‏ تأخیر است. برچسب آن در کد «‏Latency‏ (usec)» است، اما مقدار ورودی ‏latency.to_nsec()‏ است و ‏quant‏ برابر ۱۰۰۰۰۰ نانوثانیه، یعنی ۱۰۰ میکروثانیه. محور ‏y‏ اندازه‌ی درخواست است با ‏quant‏ ‏۵۱۲ بایت. هر دو محور ‏LOG2‏ و ۳۲ ‏bucket‏ دارند.

مثال عددی. نوشتنی با تأخیر ۱.۵ ‏ms: q‏ = ۱۵۰۰۰۰۰ / ۱۰۰۰۰۰ = ۱۵. کوچک‌ترین ‏i‏ با ‏$15 < 2^{i-1}$‏ عدد ۵ است، پس ‏bucket 5‏ با محدوده‌ی ۸۰۰ تا ۱۶۰۰ میکروثانیه. اندازه‌ی ۴ ‏KiB: q‏ = ۴۰۹۶ / ۵۱۲ = ۸ و ‏i‏ = ۵، یعنی محدوده‌ی ۴۰۹۶ تا ۸۱۹۱ بایت. نوشتن ۴ ‏MiB‏ به ‏bucket 15‏ می‌رود. نوشتن ۶۴ ‏KiB‏ به ‏bucket 9‏ می‌رود. تأخیر ۱۵۰ µ‏s‏ در ‏bucket 2‏ (۱۰۰ تا ۲۰۰ µ‏s‏) و ۳۰ ‏ms‏ در ‏bucket 10‏ (۲۵.۶ تا ۵۱.۲ ‏ms‏) است. ‏bucket‏ آخر (۳۱) از ‏$2^{29} \times 100\,\mu\mathrm{s} \approx 53687$‏ ثانیه شروع می‌شود و در عمل هرگز پر نمی‌شود. کل هیستوگرام ۳۲ × ۳۲ = ۱۰۲۴ شمارنده‌ی ۶۴ بیتی، یعنی ۸ ‏KiB‏ برای هر ‏OSD‏ و هر جهت است.

ارزش این هیستوگرام در مقایسه با ‏op_w_latency‏ (که فقط میانگین است) این است که دُم توزیع را نشان می‌دهد. اگر میانگین تأخیر ۲ ‏ms‏ باشد، نمی‌دانیم همه‌ی درخواست‌ها ۲ ‏ms‏ هستند یا ۹۵ درصد ۱ ‏ms‏ و ۵ درصد ۲۰ ‏ms‏. هیستوگرام این را جدا می‌کند و سطر به سطر نشان می‌دهد کدام اندازه‌ی درخواست کند است. هیستوگرام از راه ‏admin socket‏ با ‏ceph daemon osd.N perf histogram dump‏ خوانده می‌شود. در کد ‏main‏، ماژول ‏prometheus‏ شمارنده‌های نوع ‏histogram‏ را صریحاً رد می‌کند (توضیح کد: «‏they are represented by long running avgs‏»). ‏ceph-exporter‏ هم شمارنده‌ها را از خروجی ‏counter dump‏ و ‏counter schema‏ می‌خواند که محل این هیستوگرام‌ها نیست. پس برای ‏p99‏ در ‏Prometheus‏ باید از ابزار جانبی یا از اسکریپتی استفاده کرد که ‏dump‏ را می‌خواند.

۲۰-۷-۲ ‏cache‏ ماژول ‏prometheus‏#

pseudocode
thread جمع‌آوری (اگر cache = true):
    loop: start = now ; data = collect() ; d = now − start
          collect_cache = data ; collect_time = d
          sleep(max(0, scrape_interval − d))            # اگر d > interval: هشدار در لاگ و بدون خواب
config: اگر stale_cache_strategy ∉ {fail, return}: strategy = fail   # پیش‌فرض گزینه «log» است
GET /metrics:
    if collect_cache خالی: 503
    if collect_time < scrape_interval: 200 با cache
    if strategy == return: 200 با cache کهنه (و پیام در لاگ)
    if strategy == fail: 503

دو نکته‌ی کمتر شناخته‌شده در این کد هست. اول، «کهنه بودن» بر اساس مدت آخرین جمع‌آوری سنجیده می‌شود، نه بر اساس سن ‏cache‏. اگر آخرین ‏collect()‏ ۱۷ ثانیه طول کشیده باشد و ‏scrape_interval‏ برابر ۱۵ ثانیه باشد، ‏cache‏ کهنه حساب می‌شود، حتی اگر همین یک ثانیه پیش به‌روز شده باشد. دوم، مقدار پیش‌فرض گزینه‌ی ‏stale_cache_strategy‏ در تعریف گزینه «‏log‏» است. این مقدار در فهرست مقادیر معتبر نیست و هنگام بارگذاری پیکربندی به ‏fail‏ تبدیل می‌شود. مستندات هم می‌گوید رفتار پیش‌فرض پاسخ ۵۰۳ است. پس عملاً پیش‌فرض ‏fail‏ است.

مثال عددی. با ‏scrape_interval‏ = ۱۵ ثانیه، فرض کنید مدت جمع‌آوری‌ها ۵، ۵، ۶، ۱۷، ۱۸، ۶ و ۵ ثانیه باشد (مثلاً هنگام ‏peering‏ گسترده). جمع‌آوری‌های ۱۷ و ۱۸ ثانیه‌ای بدون خواب پشت هم اجرا می‌شوند. ‏scrape‏های ‏Prometheus‏ که پس از پایان این دو جمع‌آوری و پیش از پایان جمع‌آوری ۶ ثانیه‌ای بعدی می‌رسند، در حالت ‏fail‏ پاسخ ۵۰۳ می‌گیرند. در شبیه‌سازی ما، دو ‏scrape‏ متوالی (در ثانیه‌ی ۷۰ و ۸۵) ۵۰۳ می‌شوند. ‏Prometheus‏ هشدار ‏up == 0‏ یا «‏target down‏» را برای ‏mgr‏ می‌بیند، در حالی که ‏mgr‏ سالم است و فقط کند است. در حالت ‏return‏ همان دو ‏scrape‏ داده‌ی کهنه می‌گیرند و هیچ شکافی در نمودارها دیده نمی‌شود. برای کلاسترهای بزرگ (مستندات عدد بیش از ۱۰۰۰ ‏OSD‏ را ذکر می‌کند)، یا ‏scrape_interval‏ ماژول را بالا ببرید و با ‏Prometheus‏ هماهنگ کنید، یا ‏strategy‏ را ‏return‏ بگذارید.

۲۰-۷-۳ قاعده‌ی ‏CephOSDFlapping‏#

pseudocode
expr: (rate(ceph_osd_up[5m]) × on(cluster, ceph_daemon) group_left(hostname) ceph_osd_metadata) × 60 > 1
rate روی نمونه‌ها: increase = Σ (v_i − v_{i−1} اگر v_i ≥ v_{i−1} ، وگرنه v_i)     # افت 1→0 «reset» است و 0 اضافه می‌کند
                   هر گذار 0→1 یک واحد افزایش است
                   increase برون‌یابی به لبه‌های پنجره ؛ تقسیم بر 300 ثانیه
×60 ⇒ تعداد «بالا آمدن» در دقیقه ؛ هشدار اگر بیش از 1 (بدون for:)

‏ceph_osd_up‏ یک ‏gauge‏ با مقدار ۰ یا ۱ است، اما قاعده ‏rate()‏ را روی آن به کار می‌برد که برای ‏counter‏ ساخته شده است. نتیجه کار می‌کند، چون ‏rate()‏ هر افت را ‏reset‏ تلقی می‌کند و هر صعود از ۰ به ۱ را یک واحد افزایش حساب می‌کند. پس ‏rate‏ × ۶۰ تقریباً تعداد دفعاتی است که ‏OSD‏ در هر دقیقه دوباره ‏up‏ شده است.

مثال عددی. ‏Prometheus‏ هر ۱۵ ثانیه نمونه می‌گیرد. ‏OSD‏ در فاصله‌ی ثانیه‌ی ۳۳۰ تا ۵۸۵ هفت بار ‏down‏ و دوباره ‏up‏ دیده می‌شود (هر بار در یک نمونه ۰ است). در ارزیابی ثانیه‌ی ۵۸۵، پنجره‌ی [۲۸۵، ۵۸۵] بیست نمونه و هفت افزایش دارد. برون‌یابی ‏Prometheus‏ آن را حدود ۷ × ۳۰۰ / ۲۸۵ ≈ ۷.۴ می‌کند، و ‏rate‏ × ۶۰ ≈ ۱.۲۶ > ۱ است. هشدار فوراً فعال می‌شود. دو محدودیت مهم دارد. اول، ‏OSD‏ی که بین دو نمونه ‏down‏ و ‏up‏ شود (کمتر از ۱۵ ثانیه) دیده نمی‌شود. دوم، شش ‏flap‏ در پنج دقیقه هنوز ممکن است زیر آستانه بماند. برای دید دقیق‌تر، ‏ceph osd stat‏ و لاگ ‏mon‏ (پیام‌های «‏wrongly marked me down‏») قابل اعتمادترند.

۲۰-۷-۴ قاعده‌ی ‏CephPGImbalance‏#

pseudocode
x_o = ceph_osd_numpg{o} (فقط اگر > 0) با برچسب device_class از ceph_osd_metadata
avg_c = میانگین x_o روی OSDهای همان (cluster, job, device_class)
هشدار اگر |x_o − avg_c| / avg_c > 0.30  به مدت 5 دقیقه (for: 5m)

مثال عددی. ده ‏OSD‏ در کلاس ‏hdd‏ به ترتیب ۹۲، ۹۵، ۹۸، ۱۰۰، ۱۰۱، ۱۰۳، ۱۰۴، ۱۰۶، ۱۱۰ و ۱۴۱ ‏PG‏ دارند. میانگین ۱۰۵ است و باند مجاز ۷۳.۵ تا ۱۳۶.۵. ‏osd.9‏ با ۱۴۱ ‏PG‏ حدود ۳۴.۳ درصد بالاتر از میانگین است و پس از پنج دقیقه هشدار می‌گیرد. ‏osd.0‏ با ۱۲.۴ درصد کمتر از میانگین در باند است. دو نکته: ‏OSD‏ با صفر ‏PG‏ (مثلاً تازه اضافه‌شده یا ‏out‏) با فیلتر ‏> 0‏ از محاسبه کنار می‌رود و خودش هشدار نمی‌گیرد. همچنین آستانه‌ی ۳۰ درصد بسیار گشاده‌تر از هدف ‏balancer‏ است. ‏balancer‏ در حالت ‏upmap‏ تلاش می‌کند انحراف هر ‏OSD‏ از هدف به حدود چند ‏PG‏ برسد (فصل ۱۹). پس اگر این هشدار فعال شد، معمولاً ‏balancer‏ خاموش است یا نمی‌تواند کار کند، مثلاً به دلیل وزن‌های نادرست ‏CRUSH‏ یا ‏OSD‏های تقریباً پر.

۲۰-۷-۵ قاعده‌ی ‏CephPoolGrowthWarning‏#

pseudocode
expr: (predict_linear(ceph_pool_percent_used[2d], 3600 × 24 × 5) × on(cluster, pool_id, instance) group_right() ceph_pool_metadata) ≥ 0.95
predict_linear: (a, b) = کمترین مربعات روی نمونه‌های 48 ساعت گذشته ، با t نسبت به زمان ارزیابی
                خروجی a + b × 432000                       # مقدار پیش‌بینی‌شده 5 روز بعد
هشدار اگر خروجی ≥ 0.95 (بدون for:)

مثال عددی. ‏pool‏ در دو روز گذشته از ۷۰ درصد به ۷۸ درصد رسیده است، یعنی شیب ۰.۰۴ در روز. نمونه‌ها هر ۱۰ دقیقه گرفته شده‌اند. بدون نویز، پیش‌بینی ۵ روز بعد ۰.۷۸ + ۵ × ۰.۰۴ = ۰.۹۸ است که از ۰.۹۵ بیشتر است و هشدار فعال می‌شود. با نویز مصنوعی (انحراف معیار ۰.۰۰۴) خروجی ۰.۹۸۷ شد. هشدار یعنی «با این روند، پنج روز دیگر ‏pool‏ پر است»، نه این‌که الان پر است. برعکس، اگر رشد ناگهانی در دو ساعت آخر رخ داده باشد، رگرسیون روی ۴۸ ساعت آن را رقیق می‌کند و هشدار دیر می‌آید. توجه کنید که ‏ceph_pool_percent_used‏ به ‏max_avail‏ وابسته است. ‏max_avail‏ با پرترین ‏OSD‏ زیر ‏CRUSH rule‏ آن ‏pool‏ محاسبه می‌شود. بنابراین عدم توازن داده، ‏percent_used‏ را بالا می‌برد و این هشدار را زودتر فعال می‌کند.

۲۰-۸ ‏mgmt-gateway‏: یک درِ ورودی#

در استقرارهای پیش از ‏Tentacle‏، ‏Dashboard‏، ‏Grafana‏، ‏Prometheus‏ و ‏Alertmanager‏ هر کدام پورت و گواهی جدا داشتند و کاربر باید به چند نشانی دسترسی داشت. ‏mgmt-gateway‏ (سرویس ‏cephadm‏ مبتنی بر ‏nginx‏) همه را پشت یک نقطه‌ی ورود با ‏TLS‏ قرار می‌دهد و با ‏oauth2-proxy‏ می‌تواند احراز هویت را به یک ‏IdP‏ بیرونی (‏OIDC‏) بسپارد.

ceph orch apply mgmt-gateway --placement="label:mgmt"
# با نشانی مجازی و احراز هویت (طبق مستندات mgmt-gateway)
ceph orch apply mgmt-gateway --virtual_ip 192.0.2.50 --enable-auth=true --placement="label:mgmt"
ceph orch apply oauth2-proxy -i oauth2-proxy.yaml
ceph orch ls | grep -E "mgmt-gateway|oauth2"

۲۰-۹ ‏log‏ و رویدادها#

• ‏log‏ کلاستر در ‏MON‏: ‏ceph log last 200‏، و پیگیری زنده با ‏ceph -w‏؛ کانال ‏cephadm‏ با ‏ceph -W cephadm‏.
• ‏log daemon‏ها در ‏cephadm‏ به ‏journald‏ می‌روند: ‏cephadm logs --name osd.3‏ یا ‏journalctl -u ceph-<fsid>@osd.3‏؛ برای نوشتن در فایل ‏ceph config set global log_to_file true‏.
• ‏crash‏ها با ماژول ‏crash‏ جمع می‌شوند و در هشدار ‏RECENT_CRASH‏ ظاهر می‌شوند؛ ‏ceph crash ls‏، ‏ceph crash info <id>‏، ‏ceph crash archive-all‏.
• ‏telemetry‏ (اختیاری و با رضایت): ارسال آمار ناشناس به پروژه؛ پیش‌نمایش با ‏ceph telemetry preview‏ (فصل ۹).

۲۰-۱۰ داشبوردها و ‏SLO‏#

داشبوردهای ‏ceph-mixin‏ (کلاستر، میزبان، ‏OSD‏، ‏pool‏، ‏RGW‏، ‏RBD‏، ‏CephFS‏) همراه ‏Grafana‏ مستقر می‌شوند. برای راهبری سرویس، علاوه بر آن‌ها چند نمای سطح سرویس بسازید:

۲۰-۱۱ تکمیلی و به‌روز#

• انتقال ‏perf counters‏ از ماژول ‏prometheus‏ به ‏ceph-exporter‏ (پیش‌فرض ‏exclude_perf_counters‏) مهم‌ترین تغییر معماری پایش از ۲۰۱۹ است؛ در آن سال‌ها پایش بیشتر بر ‏Calamari‏ و ابزارهای جانبی تکیه داشت که امروز جای خود را به ‏Dashboard‏ و پشته‌ی ‏Prometheus‏ داده‌اند.
• ‏mgmt-gateway‏ و ‏oauth2-proxy‏ در ‏Tentacle‏ آمده‌اند.
• قواعد سخت‌افزاری (منبع تغذیه، خنک‌کننده، ‏NVMe‏) و ‏NVMe-oF‏ به ‏ceph-mixin‏ افزوده شده‌اند.

۲۰-۱۲ تمرین عملی#

1. ۱. پشته‌ی پایش را با ‏cephadm‏ مستقر کنید و همه‌ی هدف‌ها را در صفحه‌ی ‏Targets‏ پرومتئوس سالم ببینید.
2. ۲. با ‏ceph daemon osd.N counter dump‏ و ‏curl‏ روی پورت ‏ceph-exporter‏، یک شمارنده را در هر دو شکل مقایسه کنید.
3. ۳. قاعده‌ی ‏CephWriteLatencyHigh‏ را اضافه کنید و با ‏tc netem‏ روی شبکه‌ی ‏cluster‏ آن را فعال کنید.
4. ۴. یک قاعده‌ی ‏inhibit‏ برای ‏CephOSDHostDown‏ و ‏CephOSDDown‏ بنویسید و با خاموش کردن یک میزبان آزمایش کنید.
5. ۵. ‏mgr‏ فعال را با ‏ceph mgr fail‏ جابه‌جا کنید و پیوستگی سری‌های زمانی را بررسی کنید.
6. ۶. ‏mgmt-gateway‏ را مستقر کنید و دسترسی مستقیم به پورت ‏Prometheus‏ را با فایروال ببندید.

۲۰-۱۳ پرسش‌های مرور#

1. ۱. چرا ‏perf counters‏ از ماژول ‏prometheus‏ به ‏ceph-exporter‏ منتقل شدند؟
2. ۲. چرا باید همه‌ی ‏mgr‏ها یا ‏service discovery‏ را برای ‏scrape‏ تعریف کرد؟
3. ۳. اولویت شمارنده و ‏exporter_prio_limit‏ چه رابطه‌ای دارند؟
4. ۴. میانگین تأخیر یک بازه از شمارنده‌ی ‏time_avg‏ چگونه محاسبه می‌شود؟
5. ۵. متریک ‏ceph_health_detail‏ چه کاربردی دارد؟
6. ۶. نقش ‏for‏ در قاعده‌ی هشدار چیست؟
7. ۷. ‏inhibit‏ در ‏Alertmanager‏ چه مشکلی را حل می‌کند؟
8. ۸. ‏mgmt-gateway‏ چه مزایایی دارد؟
9. ۹. چرا ‏Prometheus‏ نباید مستقیماً در معرض کاربران باشد؟
10. ۱۰. چند ‏SLI‏ مناسب برای سرویس ‏RBD‏ نام ببرید.

پاسخ این پرسش‌ها در پیوست ه: پاسخ پرسش‌ها آمده است. پاسخ پرسش‌های این فصل →

۲۰-۱۴ منابع این فصل#

• ‏Monitoring overview‏
  https://docs.ceph.com/en/latest/monitoring/
• ‏cephadm monitoring services‏
  https://docs.ceph.com/en/latest/cephadm/services/monitoring/
• ‏Prometheus manager module‏
  https://docs.ceph.com/en/latest/mgr/prometheus/
• ‏mgmt-gateway‏
  https://docs.ceph.com/en/latest/cephadm/services/mgmt-gateway/
• ‏oauth2-proxy‏
  https://docs.ceph.com/en/latest/cephadm/services/oauth2-proxy/
• ‏Ceph Dashboard‏
  https://docs.ceph.com/en/latest/mgr/dashboard/
• ‏Crash module‏
  https://docs.ceph.com/en/latest/mgr/crash/
• ‏ceph-mixin alerts‏
  https://github.com/ceph/ceph/blob/main/monitoring/ceph-mixin/prometheus_alerts.yml
• ‏Source: src/common/perf_counters.h‏
  https://github.com/ceph/ceph/blob/main/src/common/perf_counters.h
• ‏Source: src/common/options/ceph-exporter.yaml.in‏
  https://github.com/ceph/ceph/blob/main/src/common/options/ceph-exporter.yaml.in
• ‏Prometheus security model‏
  https://prometheus.io/docs/operating/security/