ساخت داشبورد یکپارچه فروش، سرور و شبکه با Grafana و وصلک
چگونه فروش، سفارش، موجودی، سلامت سرورها، روترهای MikroTik و وضعیت کانکتورها را در یک داشبورد Grafana جمع کنیم؟ این راهنما معماری، اتصال OAuth و طراحی هشدارها را توضیح می‌دهد.
داشبورد مدیریتی زمانی ارزشمند است که فقط چند نمودار زیبا نباشد؛ باید در چند ثانیه نشان دهد کسب‌وکار چه وضعیتی دارد، چه چیزی از محدوده طبیعی خارج شده و کدام موضوع نیازمند اقدام است. ترکیب Grafana، Prometheus و وصلک می‌تواند داده فنی و عملیاتی را در یک صفحه واحد جمع کند.
Prometheus تاریخچه و متریک زیرساخت را نگه می‌دارد، وصلک داده زنده ابزارهای کسب‌وکار را به‌شکل کنترل‌شده ارائه می‌کند و Grafana همه آن‌ها را نمایش و روی شرایط مهم هشدار ایجاد می‌کند.
چرا Grafana برای این سناریو مناسب است؟
Grafana می‌تواند چند Data Source را در یک داشبورد ترکیب کند. متریک‌های زمان‌محور مانند CPU، RAM، فضای دیسک و نرخ درخواست از Prometheus می‌آیند؛ داده‌های کسب‌وکار مانند سفارش‌های فعال یا وضعیت یک اتصال می‌توانند از API مانیتورینگ وصلک خوانده شوند.
این جداسازی مهم است. Grafana پایگاه داده اصلی فروشگاه یا سیستم مانیتورینگ نیست و وصلک نیز نباید تاریخچه‌ای را که منبع آن نگهداری نکرده، جعل یا Backfill کند.
معماری پیشنهادی
- Node Exporter یا Exporter مناسب، متریک سرورها را جمع می‌کند.
- Prometheus متریک‌های زمان‌محور را Scrape و ذخیره می‌کند.
- Exporter یا API روتر، داده MikroTik و لینک‌های اینترنت را ارائه می‌دهد.
- فروشگاه و سرویس‌های کسب‌وکار از طریق کانکتورهای وصلک متصل‌اند.
- Grafana با Data Source پرومتئوس، متریک زیرساخت را می‌خواند.
- Grafana با Infinity و OAuth Client Credentials، داده‌های خواندنی منتخب را از وصلک می‌گیرد.
- Grafana Alerting روی Queryهای عددی شرط می‌گذارد و اعلان را به Contact Point می‌فرستد.
وصلک چه داده‌ای به Grafana می‌دهد؟
اتصال Grafana در وصلک یک اتصال سروربه‌سرور و فقط‌خواندنی است. هنگام ساخت Client، عضو منابع مجاز را انتخاب می‌کند و Grafana فقط ابزارهای خواندنی همان Connectionها را می‌بیند. ابزار نوشتنی، مخرب یا نیازمند تأیید انسانی در دسترس مانیتورینگ پس‌زمینه نیست.
API اختصاصی Grafana در وصلک Endpointهایی برای بررسی سلامت Credential، فهرست منابع، فهرست ابزارهای مجاز، متریک اجرای ابزارها و اجرای Query خواندنی دارد.
راه‌اندازی اتصال Grafana به وصلک
- در پنل وصلک به Connect → Grafana بروید.
- نام اتصال، منابع مجاز و تاریخ انقضا را انتخاب کنید.
- Client ID و Client Secret را ایجاد کنید و Secret یک‌بارنمایش‌داده‌شده را امن نگه دارید.
- در Grafana افزونه رسمی Infinity را نصب کنید.
- یک Infinity Data Source با OAuth 2.0 Client Credentials بسازید.
- Base URL و Token URL وصلک را وارد کنید و Scope را monitoring:read قرار دهید.
- Custom Health Check را فعال و Save & test را اجرا کنید.
- Starter Dashboard را Import و Queryهای موردنیاز خود را جایگزین کنید.
تنظیمات اصلی Data Source
- Base URL: https://api.vaslak.com/api/v1/grafana
- Token URL: https://api.vaslak.com/api/v1/grafana/oauth/token
- Scope: monitoring:read
- Auth style: Client Secret در Header یا Basic
- Allowed host: https://api.vaslak.com
- Parser برای Query و Alert: Backend / JSONata
توکن‌های Client Credentials کوتاه‌عمرند و Grafana به‌صورت خودکار توکن جدید می‌گیرد. Client Secret را داخل URL، Query String، عنوان پنل یا فایل عمومی قرار ندهید.
راهنمای کامل اتصال Grafana به وصلک
Prometheus در این معماری چه می‌کند؟
Prometheus برای متریک‌هایی طراحی شده که باید در طول زمان ذخیره و با PromQL تحلیل شوند. Grafana Data Source پرومتئوس به‌صورت داخلی از Metrics، Alerting، Annotation و Recording Rules پشتیبانی می‌کند.
مستندات رسمی Prometheus Data Source در Grafana
چه داده‌هایی را از Prometheus بگیریم؟
- CPU Usage و Load Average هر سرور
- RAM و Swap
- فضای آزاد و درصد مصرف Disk
- نرخ ورودی و خروجی شبکه
- Latency و Packet Loss لینک‌ها
- تعداد پاسخ‌های 5xx و زمان پاسخ سرویس
- وضعیت Up/Down هدف‌های Scrape
- متریک روتر، Interface و پهنای باند در صورت وجود Exporter
چه داده‌هایی را از وصلک بگیریم؟
- تعداد سفارش‌های امروز و مبلغ فروش جاری
- آخرین سفارش همراه وضعیت و مبلغ
- سفارش‌های ارسال‌نشده یا معوق طبق Query منبع
- کالاهای کم‌موجودی
- تعداد کاربران یا بازدیدهای قابل دریافت از اتصال‌های مجاز
- وضعیت Connectionها و ابزارهای منتخب
- آمار تعداد اجرا، خطا و میانگین Latency ابزارهای وصلک
نکته مهم درباره تاریخچه داده کسب‌وکار
Endpoint Timeseries وصلک تاریخچه اجرای ابزارهای مجاز را گزارش می‌کند؛ تاریخچه فروش یا CPU را اختراع نمی‌کند. اگر نمودار چندماهه فروش لازم دارید، داده باید از منبعی که تاریخچه را نگه می‌دارد خوانده شود یا با یک Collector کنترل‌شده در پایگاه زمان‌محور ذخیره گردد.
برای KPI لحظه‌ای، Query مستقیم به فروشگاه یا حسابداری مناسب است. برای Trend طولانی‌مدت و Alert پایدار، بهتر است داده عددی در یک منبع زمان‌محور مانند Prometheus-compatible backend ثبت شود.
طراحی یک صفحه ۱۶:۹
برای مانیتور دیواری، صفحه باید بدون Scroll و با سلسله‌مراتب روشن طراحی شود. عددهای نیازمند اقدام در بالا، شاخص‌های فنی در مرکز و جزئیات تشخیصی در پایین قرار بگیرند.
- ردیف اول: فروش امروز، تعداد سفارش، آخرین سفارش، سفارش معوق و کاربران آنلاین.
- ردیف دوم: Gaugeهای CPU، RAM، Disk و Load برای سرورها.
- ردیف سوم: وضعیت روترها، اینترنت، Packet Loss و Latency.
- ردیف چهارم: سلامت کانکتورها، خطاهای پرداخت و هشدارهای فعال.
Gauge را کجا استفاده کنیم؟
Gauge برای عددی مناسب است که محدوده قابل‌فهم دارد؛ مانند درصد CPU، RAM یا Disk. برای روند فروش و تعداد سفارش، Time Series یا Stat همراه Sparkline اطلاعات بهتری می‌دهد. استفاده بیش از حد از Gauge صفحه را شلوغ می‌کند.
نمونه Queryهای Prometheus
برای CPU می‌توان نرخ زمان غیر Idle را محاسبه کرد. برای Disk، درصد فضای قابل استفاده و برای سرویس، نرخ خطا یا Latency صدک‌دار مناسب است. Labelها باید طوری طراحی شوند که نام سرور، محیط و سرویس به‌وضوح قابل فیلتر باشند.
اگر یک Expression سنگین در چند پنل و Alert تکرار می‌شود، Recording Rule می‌تواند آن را از قبل محاسبه کند؛ البته Backend مقصد باید امکان ذخیره نتیجه را پشتیبانی کند.
طراحی هشدارهای کاربردی
- فضای دیسک کمتر از ۱۵ درصد برای بیش از ۱۰ دقیقه.
- CPU بالاتر از آستانه همراه با Load غیرعادی، نه یک جهش چندثانیه‌ای.
- Packet Loss یا Latency اینترنت بیشتر از محدوده پایه.
- سرویس فروشگاه یا API در چند ارزیابی متوالی Down باشد.
- سفارش معوق بعد از پایان بازه ارسال وجود داشته باشد.
- پرداخت موفق بدون سفارش متناظر پیدا شود.
- Connection حیاتی وصلک غیرفعال یا خطادار شود.
هر Alert باید Owner، شدت، Runbook و شرط پایان داشته باشد. هشدار مبهمی مانند «فروش کم شد» بدون تعریف Baseline و بازه مقایسه، بیشتر نویز ایجاد می‌کند تا اقدام.
راهنمای رسمی Grafana Alerting با Prometheus
اعلان‌ها را چگونه ارسال کنیم؟
Grafana Alerting شرط را ارزیابی می‌کند و Notification Policy تعیین می‌کند هشدار به کدام Contact Point برود. ایمیل، پیام‌رسان یا Webhook باید بر اساس شدت و ساعات کاری مسیردهی شوند.
برای هشدار عملیاتی، متن باید شامل سرویس، مقدار فعلی، آستانه، زمان شروع و لینک مستقیم به Dashboard باشد. پیام «Server is down» بدون مشخص‌کردن نام و Context کافی نیست.
امنیت داشبورد
- برای Grafana یک Client مستقل و فقط‌خواندنی بسازید.
- فقط Connectionهایی را انتخاب کنید که کاربران Dashboard باید ببینند.
- Secret را در Secret Store یا Provisioning امن نگه دارید.
- دسترسی Query در Grafana را با Role کنترل کنید.
- Client قدیمی را Revoke و Secret مشکوک را Rotate کنید.
- Refresh کوتاه و Queryهای لازم را انتخاب کنید تا سهمیه و منبع مقصد تحت فشار قرار نگیرد.
خطاهای رایج
- نمایش عدد صفر به‌جای داده ناموجود؛ Null باید از صفر واقعی جدا باشد.
- استفاده از Frontend Parser برای Alert؛ Alert زمان‌بندی‌شده به Backend Parsing نیاز دارد.
- Polling بسیار سریع روی API فروشگاه.
- دادن دسترسی همه Connectionها به یک Data Source عمومی.
- مخلوط‌کردن Time Zone و بازه روز بدون توجه به ساعت تهران.
- ساخت پنل زیاد بدون اولویت عملیاتی.
Starter Dashboard و فایل Provisioning
وصلک یک Starter Dashboard و نمونه Provisioning برای شروع ارائه می‌کند. این فایل‌ها نقطه شروع‌اند و باید Source ID، ابزار و ساختار داده واقعی سازمان خود را روی آن‌ها تنظیم کنید.
دریافت نمونه Provisioning Data Source
جمع‌بندی
داشبورد یکپارچه زمانی قابل اتکاست که مرز داده‌ها روشن باشد: Prometheus برای متریک تاریخی، وصلک برای Query کنترل‌شده ابزارهای کسب‌وکار و Grafana برای نمایش و Alert. با این معماری می‌توان وضعیت فروش، سفارش، سرور، شبکه و اتصال‌ها را بدون دادن دسترسی نوشتنی به سیستم مانیتورینگ در یک صفحه دید.
داشبورد خوب فقط وضعیت را نشان نمی‌دهد؛ به‌وضوح مشخص می‌کند چه اتفاقی افتاده، چقدر مهم است و قدم بعدی چیست.
مطالب مرتبط
امنیت اتصال هوش مصنوعی به ابزارهای کسب‌وکار
