WIUNIX ACADEMY

آموزش مانیتورینگ با Prometheus، Grafana و Docker Compose

صفحهٔ 5 از 6؛ مراحل قبلی و پیش‌نیازها را پیش از ادامه مرور کن.

آموزش متناسب با محیط تو

کجا اجرا می‌کنی؟

سیستم‌عامل و نسخه را انتخاب کن تا مراحل، دستورها و راه‌حل‌ها برای همان محیط نمایش داده شوند.

Ubuntu 26.10بررسی‌شده با مستندات رسمی · 2026-10-20

آموزش متناسب با مقادیر تو

تنظیمات این آموزش

مقادیر نمونه را برای محیط خودت تنظیم کن؛ متن و دستورهای مرتبط با هم تغییر می‌کنند. رمز، کلید خصوصی و توکن وارد نکن. مقادیر فقط در همین زبانه نگهداری می‌شوند و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شوند. پیش از اجرا، DNS، گواهی‌ها و سیاست شبکهٔ واقعی را بررسی کن.

آی‌پی، دامنه یا پورت مثال‌ها با محیط تو فرق دارد؟ دکمهٔ زیر را باز کن، مقادیر را تغییر بده و «اعمال در آموزش» را بزن؛ سپس دستورهای به‌روز‌شده را کپی کن.

تنظیم مقادیر برای محیط من11 مقدار قابل‌تغییر

قدم بعدی

فهرست تارگت را اتمیک عوض کنید

فقط label عمومی محیط را در فهرست تغییر دهید. file discovery پوشه را بدون restart پرومتئوس دوباره می‌خواند. label تازه سری تازه می‌سازد و سری قبلی تا پایان retention در تاریخچه می‌ماند؛ شناسهٔ نامحدود کاربر یا URL درخواست را label نکنید. برای YAML اصلی، ابتدا اعتبارسنجی و سپس کانتینر سرویس را recreate کنید؛ ذخیرهٔ اتمیک ویرایشگر روی فایل bindشده ممکن است inode قدیمی را داخل کانتینر نگه دارد. API مدیریتی و web lifecycle فعال نشده‌اند.

سرور اختصاصی لینوکس؛ پوستهٔ Bash

sudo tee '/srv/academy-monitor/config/targets/services.json.new' >/dev/null <<'JSON'
[{"targets":["grafana:3000"],"labels":{"service":"grafana","stack":"academy-monitor","stage":"lab"}}]
JSON
sudo python3 -m json.tool '/srv/academy-monitor/config/targets/services.json.new' >/dev/null
sudo chmod 0644 '/srv/academy-monitor/config/targets/services.json.new'
sudo mv '/srv/academy-monitor/config/targets/services.json.new' '/srv/academy-monitor/config/targets/services.json'
sleep 45
curl --fail --show-error -G http://127.0.0.1:19090/api/v1/query --data-urlencode 'query=up{stage="lab"}'

از کجا بدانم درست انجام شد؟

سری stage=lab بدون restart پرومتئوس موجود است و up=1 دارد.

قدم بعدی

لایهٔ خراب را مشخص کنید

برای permission denied، mount و مالک عددی را مقایسه کنید و پوشهٔ نامرتبط را chown نکنید. اگر به‌جای فایل، پوشه دیده می‌شود، منبع bind از ابتدا موجود نبوده است. برای خطای DNS تارگت، عضویت شبکه و نام سرویس را تطبیق دهید؛ curl موفق میزبان، دسترسی داخل کانتینر را ثابت نمی‌کند. اگر پس از تغییر secret ورود ناموفق است، مقداردهی اولیه فقط یک‌بار انجام می‌شود. OOMKilled یا حلقهٔ restart به بررسی حافظه و تعداد سری نیاز دارد. لاگ را محلی بخوانید؛ exporter واقعی ممکن است label حساس داشته باشد. محیط فرایند و فایل رمز را چاپ نکنید.

سرور اختصاصی لینوکس؛ پوستهٔ Bash

sudo docker compose -f '/srv/academy-monitor/compose.yaml' ps -a
sudo docker compose -f '/srv/academy-monitor/compose.yaml' logs --tail=80 prometheus grafana
sudo docker inspect --format '{{.Name}} user={{.Config.User}} oom={{.State.OOMKilled}} restarts={{.RestartCount}}' $(sudo docker compose -f '/srv/academy-monitor/compose.yaml' ps -aq)
sudo stat -c '%u:%g %a %n' '/srv/academy-monitor/prometheus-data' '/srv/academy-monitor/grafana-data' '/srv/academy-monitor/secrets/grafana-admin'
sudo docker network inspect 'academy-monitor_monitor'
df -h '/srv/academy-monitor'

از کجا بدانم درست انجام شد؟

پیش از تغییر، علت مشخص در mount، مالکیت، DNS، ورود یا منابع پیدا می‌شود.

retention جای بکاپ را نمی‌گیرد

با رسیدن زودترِ زمان یا حجم، بلوک‌های قدیمی پرومتئوس حذف می‌شوند. پسوند GB در این flag واحد دودویی دارد؛ سقف برای بلوک‌هاست و همهٔ WAL و head را شامل نمی‌شود و پاک‌سازی هم فوری نیست. حدود ۱۵ تا ۲۰ درصد فضای اضافه بر بودجهٔ بلوک‌ها و سهم جداگانه برای سایر داده‌ها بگذارید؛ نرخ دریافت و اوج compaction واقعی را اندازه بگیرید. سقف حافظه ممکن است TSDB در حال رشد را OOM کند. دیسک، cardinality، مدت scrape، خطا و restart را پایش کنید. دیسک محلی و میزبان نقطهٔ خرابی‌اند؛ retention، restart و کانتینر دوم HA یا بکاپ خارج میزبان نمی‌سازند.

قدم بعدی

بکاپ سازگار را با توقف بگیرید

این مرحله وقفهٔ مانیتورینگ و UI ایجاد می‌کند. پیش از کپی TSDB و SQLite گرافانا، هر دو سرویس تمیز متوقف می‌شوند. آرشیو شامل رمز اولیه، دیتابیس و sessionها، تنظیمات و pin ایمیج است؛ فقط root بخواند، با سامانهٔ بکاپ مصوب رمزنگاری شود و بدون نمایش رمز به خارج میزبان برود. trap حتی در خطای کپی، استک اصلی را برمی‌گرداند. کپی معمولی SQLite زنده یا فقط بلوک‌های پرومتئوس بکاپ کامل نیست. نام ثابت آرشیو بازنویسی را رد می‌کند؛ پیش از تکرار، نسخهٔ قبلی را از روند نگهداری معمول خود منتقل کنید.

سرور اختصاصی لینوکس؛ پوستهٔ Bash

sudo bash -eu <<'BACKUP'
archive='/srv/academy-monitor-backups/compose-stack.tar'
[[ ! -e "$archive" ]]
docker compose -f '/srv/academy-monitor/compose.yaml' stop -t 60
trap 'docker compose -f "/srv/academy-monitor/compose.yaml" start' EXIT
[[ -z "$(docker compose -f '/srv/academy-monitor/compose.yaml' ps --status running -q)" ]]
umask 077
tar --numeric-owner -cpf "$archive" -C '/srv/academy-monitor' .
cd '/srv/academy-monitor-backups'
sha256sum compose-stack.tar > compose-stack.tar.sha256
sha256sum -c compose-stack.tar.sha256
BACKUP

از کجا بدانم درست انجام شد؟

آرشیو و هش با مجوز خصوصی موجودند؛ سرویس اصلی برگشته و probe آمادگی دوباره موفق است.

قدم بعدی

بازیابی همان میزبان را بدون پاک‌کردن داده تمرین کنید

فقط آرشیو قابل اعتماد خودتان را استفاده کنید. هش را بررسی کنید، سپس فقط کانتینر و شبکهٔ همین پروژه را متوقف و حذف کنید؛ volume و ایمیج حذف نمی‌شوند. کل پوشهٔ فعلی کنار گذاشته می‌شود و آرشیو در پوشهٔ خالیِ همان مسیر اصلی با مالک عددی باز می‌شود. چون bindها مطلق‌اند، جابه‌جایی سادهٔ پوشهٔ بازیابی کافی نیست. پوشهٔ قبلی برای برگشت باقی می‌ماند و برای هر دو کپی فضای کافی لازم است. در میزبان جایگزین، داکر پشتیبانی‌شده، مسیر و مالکیت و secret اصلی را بازسازی و شبکه و پورت را دوباره بررسی کنید؛ قبل از اجرا همان digestها را دریافت کنید. بازیابی آفلاین آرشیو ایمیج تأییدشده هم می‌خواهد. دو نسخه با نام پروژه و شبکهٔ یکسان را هم‌زمان اجرا نکنید.

سرور اختصاصی لینوکس؛ پوستهٔ Bash

sudo bash -eu <<'RESTORE'
cd '/srv/academy-monitor-backups'
sha256sum -c compose-stack.tar.sha256
[[ ! -e '/srv/academy-monitor.before-restore' ]]
docker compose -f '/srv/academy-monitor/compose.yaml' down --timeout 60
mv '/srv/academy-monitor' '/srv/academy-monitor.before-restore'
install -d -m 0755 '/srv/academy-monitor'
tar --numeric-owner -xpf '/srv/academy-monitor-backups/compose-stack.tar' -C '/srv/academy-monitor'
docker compose -f '/srv/academy-monitor/compose.yaml' config --quiet
docker compose -f '/srv/academy-monitor/compose.yaml' up -d
RESTORE

از کجا بدانم درست انجام شد؟

مسیرهای مطلق و مالکیت برگشته‌اند؛ تا تأیید نهایی پوشهٔ قبلی را نگه دارید.

تاریخچه و هویت بازیابی‌شده را تأیید کنید

probeهای آمادگی و تارگت بخش سوم را تکرار کنید. با حساب پیش از بکاپ وارد مرورگر شوید و داشبورد و تاریخچهٔ قبل از بکاپ را ببینید. کاربر، تنظیم شخصی و secret واقعی دیتاسورس را بدون افشا بررسی کنید. تطبیق بایت آرشیو و پوشه فقط هنگام توقف سرویس معنی دارد؛ دیتابیس فعال طبیعی است که تغییر کند. زمان بازیابی و دادهٔ قابل ازدست‌رفتن را در محیط خود اندازه بگیرید. هش سالم، موفقیت restore را ثابت نمی‌کند. در شکست، پنل بعدی به نسخهٔ قبلی برمی‌گردد و پوشهٔ ناموفق برای بررسی می‌ماند.

همهٔ آموزش‌های آکادمی ↗