[{"data":1,"prerenderedAt":403},["ShallowReactive",2],{"article-prometheus-grafana-observability-cloud-native":3,"related-article":29,"header-services":328},{"id":4,"title":5,"slug":-1,"excerpt":6,"content":7,"categoryId":8,"categorySlug":9,"categoryTitle":10,"categoryImage":11,"author":12,"publishedAt":15,"readTime":16,"image":17,"tags":18,"tagsFa":22,"views":4},0,"Prometheus و Grafana چیست؟ راهنمای کامل Observability در Cloud-Native","Prometheus و Grafana ستون‌های اصلی Observability هستند که متریک‌ها را جمع می‌کنند، تحلیل می‌کنند و به داشبوردهای عملیاتی و هشدارهای قابل‌اقدام تبدیل می‌کنند.","\u003Cp>در دنیای سنتی فناوری اطلاعات، مانیتورینگ اغلب به معنای بررسی روشن یا خاموش بودن سرور، میزان پر بودن دیسک، یا مقدار مصرف CPU بود. اما در جهان امروز، جایی که سیستم‌ها از ده‌ها یا صدها میکروسرویس، صف پیام، کلاسترهای Kubernetes، محیط‌های چندابری، و معماری‌های eventdriven تشکیل شده‌اند، چنین نگاه ساده‌ای دیگر کافی نیست.\u003C/p>\u003Cp>وقتی یک درخواست از سمت کاربر وارد سیستم می‌شود، ممکن است از API Gateway، سرویس احراز هویت، سرویس سفارش، صف Kafka، پایگاه‌داده، کش Redis، سرویس پرداخت، و حتی چندین سرویس خارجی عبور کند. در چنین ساختاری، اگر فقط بدانیم «سرویس بالا است یا پایین»، عملاً چیزی از رفتار واقعی سیستم نمی‌فهمیم. اینجاست که مفهوم Observability وارد می‌شود؛ مفهومی که هدف آن فقط «دیدن» نیست، بلکه درک عمیق رفتار سیستم از روی خروجی‌های آن است.\u003C/p>\u003Cp>مشاهده‌پذیری در عمل بر سه ستون اصلی استوار است: \u003Cstrong>Metrics\u003C/strong>،\u003Cstrong> Logs\u003C/strong> و \u003Cstrong>Traces\u003C/strong>. اما در میان این سه، متریک‌ها همچنان نقش ستون فقرات را دارند؛ زیرا سریع، ساخت‌یافته، قابل هشداردهی، و مناسب تحلیل‌های زمانی هستند. در همین نقطه است که دو ابزار متن‌باز و بسیار مهم از اکوسیستم CNCF یعنی Prometheus و Grafana به مرکز صحنه می‌آیند. Prometheus موتور جمع‌آوری و ذخیره‌سازی متریک است و Grafana لایه‌ی بصری‌سازی، تحلیل و داشبوردسازی را بر عهده دارد.\u003C/p>\u003Cblockquote>\u003Cp>این مقاله، فقط معرفی این دو ابزار نیست؛ بلکه یک کالبدشکافی عمیق از معماری داخلی، مدل داده، روش‌های جمع‌آوری، کوئری‌نویسی پیشرفته، طراحی داشبورد، alerting، مقیاس‌پذیری سازمانی، و الگوی استقرار آن‌ها در محیط‌های productionlevel و enterprisegrade است.\u003C/p>\u003C/blockquote>\u003Chr>\u003Ch3>۱. کالبدشکافی موتور Prometheus: فراتر از یک دیتابیس ساده\u003C/h3>\u003Cp>Prometheus فقط یک ابزار برای نمایش چند نمودار نیست. در واقع، Prometheus یک سیستم کامل متریک‌محور است که از چهار جزء کلیدی تشکیل می‌شود: جمع‌آوری داده، ذخیره‌سازی سری‌زمانی، زبان کوئری، و alerting. هر کدام از این لایه‌ها برای حل یک مسئله‌ی خاص در دنیای distributed systems طراحی شده‌اند.\u003C/p>\u003Cblockquote>\u003Cp>در رویکرد DevSecOps، مانیتورینگ و alerting نقش مهمی در شناسایی سریع تهدیدات دارند. ما در مقاله «\u003Ca href=\"https://new.dornadevops.com/blog/devops/devsecops-2026-security-in-ci-cd-cloud\">DevSecOps چیست ؟\u003C/a>» کامل به این رویکرد امنیت در دواپس اشاره کردیم .\u003C/p>\u003C/blockquote>\u003Cp>\u003Cstrong>الف) معماری Pull در برابر Push: فلسفه‌ای که مقیاس‌پذیری را ممکن کرد\u003C/strong>\u003C/p>\u003Cp>بسیاری از سیستم‌های مانیتورینگ سنتی بر پایه Push ساخته شده‌اند؛ یعنی Agentهای نصب‌شده روی سرورها، متریک‌ها را به‌صورت مداوم به سمت یک سرور مرکزی ارسال می‌کنند. این مدل در ظاهر ساده است، اما در مقیاس بزرگ مشکلات جدی ایجاد می‌کند: فشار ناگهانی روی شبکه، تجمع burstهای داده، وابستگی شدید به Agentها، و سختی در تشخیص اینکه آیا عدم دریافت داده ناشی از نبود بار کاری است یا از کار افتادن خود سیستم.\u003C/p>\u003Cp>Prometheus بر خلاف این رویکرد، از مدل PullBased Scraping استفاده می‌کند. یعنی Prometheus به‌صورت دوره‌ای، معمولاً هر ۱۵ ثانیه یا هر بازه‌ای که تعریف شده، خودش به مقصدهای از پیش مشخص‌شده مراجعه می‌کند و endpoint متریک، معمولاً `/metrics`، را scrape می‌کند. این طراحی چند مزیت مهم دارد:\u003C/p>\u003Cp>\u003Cstrong>1.\u003C/strong> \u003Cstrong>کنترل مرکزی بر چرخه جمع‌آوری\u003C/strong>\u003Cbr>  سرور Prometheus تصمیم می‌گیرد چه زمانی، از چه چیزی، و با چه تناوبی داده بخواند.\u003C/p>\u003Cp>\u003Cstrong>2.\u003C/strong> \u003Cstrong>کشف سریع خرابی\u003C/strong>\u003Cbr>  اگر scrape موفق نشود، خود این failure به یک سیگنال قابل تحلیل تبدیل می‌شود.\u003C/p>\u003Cp>\u003Cstrong>3.\u003C/strong> \u003Cstrong>سادگی معماری سمت سرویس\u003C/strong>\u003Cbr>  سرویس فقط باید endpoint متریک را expose کند؛ نه اینکه منطق ارسال، retry، batching، یا routing را در خود پیاده‌سازی کند.\u003C/p>\u003Cp>\u003Cstrong>4.\u003C/strong> \u003Cstrong>تناسب با service discovery پویا\u003C/strong>\u003Cbr>  در محیط‌هایی مثل Kubernetes، که Podها ممکن است در چند ثانیه ساخته یا نابود شوند، مدل Pull به‌همراه Service Discovery بسیار کارآمدتر از معماری‌های ثابت است.\u003C/p>\u003Cp>البته این مدل در سطح enterprise نیز به‌صورت گسترده قابل تنظیم است. می‌توان scrape intervalهای مختلف برای jobهای مختلف تعریف کرد، timeoutهای جداگانه گذاشت، relabeling انجام داد، و حتی هدف‌ها را از طریق Kubernetes API، Consul، EC2 SD، Azure SD، فایل‌های دینامیک، یا static configها دریافت کرد.\u003C/p>\u003Cp>\u003Cstrong>ب) موتور ذخیره‌سازی TSDB: قلب حافظه سری‌زمانی Prometheus\u003C/strong>\u003C/p>\u003Cp>Prometheus داده‌ها را در یک TimeSeries Database (TSDB) داخلی ذخیره می‌کند. هر سری زمانی در Prometheus بر اساس ترکیب سه جزء اصلی تعریف می‌شود:\u003C/p>\u003Cp>نام متریک ، مجموعه labelها ، timestamp و value\u003C/p>\u003Cp>برای مثال، متریک زیر:\u003C/p>\u003Cpre>\u003Ccode class=\"language-plaintext\">`http_requests_total{method=\"GET\", status=\"500\", instance=\"10.0.1.12:8080\"}`\u003C/code>\u003C/pre>\u003Cp>در ظاهر فقط یک عدد است، اما در واقع یک سری زمانی است که به شکل مداوم در طول زمان ثبت می‌شود. این مدل داده، اساس تمام تحلیل‌های بعدی را تشکیل می‌دهد.\u003C/p>\u003Cp>\u003Cstrong>ساختار ذخیره‌سازی داخلی\u003C/strong>\u003C/p>\u003Cp>TSDB پرومتئوس به‌صورت فایل‌محور و بسیار بهینه طراحی شده است. داده‌ها ابتدا در memory head block نگهداری می‌شوند، سپس با استفاده از WAL (WriteAhead Log) پایدار می‌شوند، و بعد از تکمیل شدن بلوک‌ها به دیسک منتقل می‌شوند. این مکانیزم چند مزیت مهم دارد:\u003C/p>\u003Cul>\u003Cli data-list-item-id=\"ede27039e90910dfdf443d96250a6d3c0\">جلوگیری از از دست رفتن داده در صورت crash ناگهانی\u003C/li>\u003Cli data-list-item-id=\"ec04f9633b1f3b9aa15ede4b4c51d07be\">بازیابی سریع پس از restart\u003C/li>\u003Cli data-list-item-id=\"efb923d523be228b8cbe556fe136280a0\">فشرده‌سازی ساختارمند داده‌ها\u003C/li>\u003Cli data-list-item-id=\"e467e65586ceacabf6374fe532f3123e8\">کاهش چشمگیر I/O بی‌مورد\u003C/li>\u003Cli data-list-item-id=\"e1b008974fee806686adad8e97001bf5e\">WAL و نقش آن در پایداری\u003C/li>\u003C/ul>\u003Cp>WriteAhead Log به Prometheus اجازه می‌دهد قبل از اینکه داده‌ها به ساختارهای اصلی TSDB نوشته شوند، نسخه‌ای از آن‌ها را در یک log appendonly ثبت کند. در صورت خاموشی ناگهانی، Prometheus می‌تواند از این log برای بازسازی وضعیت اخیر استفاده کند. این موضوع برای محیط‌های production حیاتی است، زیرا از نظر عملی، حتی چند دقیقه از دست رفتن متریک‌ها هم می‌تواند مانع تحلیل root cause شود.\u003C/p>\u003Ch3>بلوک‌ها، Compaction و Retention\u003C/h3>\u003Cp>Prometheus داده‌ها را به بلوک‌های زمانی تقسیم می‌کند و سپس آن‌ها را در فرآیند compaction فشرده می‌سازد. این کار هم بهره‌وری ذخیره‌سازی را بالا می‌برد و هم جست‌وجوی بازه‌های زمانی را سریع‌تر می‌کند.\u003C/p>\u003Cp>سیاست retention نیز تعیین می‌کند داده‌ها تا چه مدت در local storage نگهداری شوند. در نصب‌های کوچک ممکن است چند روز یا چند هفته کافی باشد، اما در محیط‌های enterprise معمولاً Prometheus فقط نقش local scraping layer را دارد و ذخیره‌سازی بلندمدت به لایه‌های بالاتری مثل Thanos، Cortex، Mimir یا remote storageها واگذار می‌شود.\u003C/p>\u003Cp>\u003Cstrong>چرا Prometheus برای متریک‌ها عالی است؟\u003C/strong>\u003C/p>\u003Cp>Prometheus برای متریک‌های عددی و سری‌زمانی طراحی شده، نه برای داده‌های transactionoriented یا relational. همین تخصص‌گرایی باعث شده در latency پایین، تحلیل سری‌زمانی، و مدل alerting، عملکرد فوق‌العاده‌ای داشته باشد. اما باید توجه داشت که این تخصص‌گرایی به این معناست که Prometheus برای همه نوع داده بهترین گزینه نیست؛ مثلاً برای جست‌وجوی متنی کامل، لاگ‌های خام، یا تراکنش‌های پیچیده، باید از ابزارهای مکمل استفاده شود.\u003C/p>\u003Cp>\u003Cstrong>ج) Service Discovery: کشف خودکار در جهانی که دائماً در حال تغییر است\u003C/strong>\u003C/p>\u003Cp>در معماری‌های سنتی، IP سرورها ثابت بود و ابزار مانیتورینگ با لیستی از hosts از پیش تعریف‌شده کار می‌کرد. اما در معماری CloudNative، چنین چیزی عملاً منسوخ شده است. Podها در Kubernetes می‌توانند هر لحظه recreate شوند، nodeها scale up/down شوند، و سرویس‌ها پشت load balancerها جابه‌جا شوند.\u003C/p>\u003Cp>Prometheus با Service Discovery این مشکل را حل می‌کند. او می‌تواند مقصدها را از منابع مختلف کشف کند، از جمله:\u003C/p>\u003Cul>\u003Cli data-list-item-id=\"e489dbd6981ff3c2bbb9c078e51230740\">Kubernetes API\u003Cbr>Consul\u003Cbr>AWS EC2\u003Cbr>Azure VM\u003Cbr>GCE\u003Cbr>فایل‌های dynamic target\u003Cbr>DNSbased discovery\u003C/li>\u003C/ul>\u003Cp>این یعنی Prometheus به‌جای تکیه بر IP ثابت، از هویت منطقی سرویس پیروی می‌کند. این موضوع در محیط‌های microservice و multitenant بسیار حیاتی است.\u003C/p>\u003Cp>\u003Cstrong>د) Relabeling: کنترل دقیق روی هدف‌ها و labels\u003C/strong>\u003C/p>\u003Cp>یکی از قابلیت‌های بسیار مهم و اغلب دست‌کم‌گرفته‌شده در Prometheus، relabeling است. Relabeling به شما اجازه می‌دهد labels را قبل از scrape، بعد از discovery، یا حتی بعد از ingestion تغییر دهید. \u003Cstrong>با relabeling می‌توان:\u003C/strong>\u003C/p>\u003Cp>مقصدهای ناخواسته را حذف کرد .\u003Cbr>labelهای استاندارد یا سفارشی اضافه کرد .\u003Cbr>namespace، cluster، team، environment یا region را به داده‌ها تزریق کرد .\u003Cbr>سری‌های زمانی پرهزینه و غیرضروری را drop کرد .\u003C/p>\u003Cp>در مقیاس بزرگ، relabeling تفاوت بین یک سیستم قابل مدیریت و یک سیستم انفجاری است.\u003C/p>\u003Cp>کشف خودکار Podها و سرویس‌ها در Kubernetes توسط Prometheus API.png👇\u003C/p>\u003Cfigure class=\"image\">\u003Cimg style=\"aspect-ratio:960/528;\" src=\"https://api.dornadevops.com/media/articles/posts/%DA%A9%D8%B4%D9%81%20%D8%AE%D9%88%D8%AF%DA%A9%D8%A7%D8%B1%20Pod%D9%87%D8%A7%20%D9%88%20%D8%B3%D8%B1%D9%88%DB%8C%D8%B3%D9%87%D8%A7%20%D8%AF%D8%B1%20Kubernetes%20%D8%AA%D9%88%D8%B3%D8%B7%20Prometheus%20API.png\" width=\"960\" height=\"528\">\u003C/figure>\u003Chr>\u003Ch3>۲. صادرات داده: ارتش Exporterها و ابزار دقیق (Instrumentation)\u003C/h3>\u003Cp>Prometheus ذاتاً برنامه‌ها را نمی‌فهمد؛ او فقط می‌داند چگونه به endpointهایی با فرمت استاندارد خودش مراجعه کند و داده بخواند. بنابراین برای اینکه سیستم‌ها با Prometheus صحبت کنند، باید متریک‌ها به شکلی ساخت‌یافته expose شوند. این کار از طریق Exporters و Instrumentation مستقیم انجام می‌شود.\u003C/p>\u003Cp>\u003Cstrong>۱. استفاده از Exporterهای استاندارد\u003C/strong>\u003C/p>\u003Cp>\u003Cstrong>Node Exporter\u003C/strong>\u003C/p>\u003Cp>Node Exporter یکی از بنیادی‌ترین اجزای اکوسیستم Prometheus است. این ابزار روی سرورهای لینوکسی اجرا می‌شود و مجموعه‌ای وسیع از متریک‌های سطح سیستم‌عامل و kernel را استخراج می‌کند، از جمله:\u003C/p>\u003Cp>1.1. مصرف CPU در حالت‌های مختلف\u003Cbr>1.2. load average\u003Cbr>1.3. وضعیت حافظه و swap\u003Cbr>1.4. وضعیت filesystem\u003Cbr>1.5. disk I/O\u003Cbr>1.6. throughput شبکه\u003Cbr>1.7. interruptها و context switchها\u003Cbr>1.8. filesystem mountها\u003Cbr>1.9. entropy و برخی متریک‌های خاص کرنل\u003C/p>\u003Cp>Node Exporter معمولاً به‌عنوان دید «\u003Cstrong>زیرساخت خام\u003C/strong>» به سیستم شناخته می‌شود. اگر application level همه‌چیز را سالم نشان دهد ولی node دچار saturation شده باشد، بدون Node Exporter تشخیص این مشکل دشوار خواهد بود.\u003C/p>\u003Cblockquote>\u003Cp>در پروژه‌های Dockerized، استفاده از ابزارهای مانیتورینگ مانند Prometheus ضروری است. ما مقاله ای آماده کردیم تحت عنوان «\u003Ca href=\"https://new.dornadevops.com/blog/docker/docker-mistakes-developers\">7 اشتباه مرگبار در داکرایز کردن پروژه ها\u003C/a>» با رعایت کردن این نکات دیگه اشتباهات مرسوم رو تکرار نکنید .\u003C/p>\u003C/blockquote>\u003Cp>\u003Cstrong>Blackbox Exporter\u003C/strong>\u003C/p>\u003Cp>Blackbox Exporter از بیرون به سرویس نگاه می‌کند، نه از داخل آن. این ابزار برای سنجش availability و رفتار خارجی سرویس طراحی شده است. از آن می‌توان برای موارد زیر استفاده کرد:\u003C/p>\u003Cp>1.1. HTTP probe\u003Cbr>1.2. HTTPS probe\u003Cbr>1.3. TCP probe\u003Cbr>1.4. ICMP ping\u003Cbr>1.5. DNS probe\u003Cbr>1.6. بررسی گواهی SSL/TLS\u003Cbr>1.7. ارزیابی redirectها\u003Cbr>1.8. بررسی زمان پاسخ واقعی از دید کاربر\u003C/p>\u003Cp>این نگاه خارجی برای تشخیص تفاوت بین «سرویس بالا است» و «سرویس از دید کاربر واقعاً قابل استفاده است» بسیار مهم است.\u003C/p>\u003Cp>\u003Cstrong>KubeStateMetrics\u003C/strong>\u003C/p>\u003Cp>KubeStateMetrics بر خلاف Node Exporter که وضعیت سیستم‌عامل را می‌سنجد، وضعیت اشیای Kubernetes را expose می‌کند. به‌عبارت دیگر، این ابزار state objectهای Kubernetes مانند Deployment، ReplicaSet، Pod، DaemonSet، Job، HPA و … را به متریک تبدیل می‌کند.\u003C/p>\u003Cp>این ابزار برای فهمیدن وضعیت منطقی کلاستر حیاتی است، چون گاهی node سالم است اما Deployment در وضعیت CrashLoopBackOff یا Pending قرار دارد. این دو سطح باید جداگانه مانیتور شوند.\u003C/p>\u003Cp>\u003Cstrong>سایر Exporterها\u003C/strong>\u003C/p>\u003Cp>\u003Cstrong>در اکوسیستم Prometheus exporterهای دیگری نیز وجود دارند، مانند:\u003C/strong>\u003C/p>\u003Cp>1.1. MySQL Exporter\u003Cbr>1.2. PostgreSQL Exporter\u003Cbr>1.3. Redis Exporter\u003Cbr>1.4. Nginx Exporter\u003Cbr>1.5. HAProxy Exporter\u003Cbr>1.6. RabbitMQ Exporter\u003Cbr>1.7. Kafka Exporter\u003Cbr>1.8. Elasticsearch Exporter\u003Cbr>1.9. Windows Exporter\u003C/p>\u003Cp>این تنوع باعث می‌شود تقریباً هر چیزی که endpoint متریک داشته باشد، قابل مانیتور باشد.\u003C/p>\u003Cp>\u003Cstrong>۲. Instrumentation مستقیم در کد برنامه\u003C/strong>\u003C/p>\u003Cp>گاهی exporter عمومی کافی نیست. در این حالت، تیم توسعه باید خود اپلیکیشن را instrument کند. Prometheus برای زبان‌های رایج، client libraryهای رسمی یا معتبر دارد؛ مانند Python، Go، Java، Node.js، Ruby، PHP، C و غیره.\u003C/p>\u003Cp>\u003Cstrong>سه نوع متریک اصلی در instrumentation\u003C/strong>\u003C/p>\u003Cp>Prometheus سه الگوی مهم برای متریک‌ها تعریف می‌کند:\u003C/p>\u003Cp>\u003Cstrong>Counter\u003C/strong>\u003Cbr>فقط افزایش پیدا می‌کند و برای شمارش رویدادها مناسب است.\u003Cbr>مثال: تعداد درخواست‌ها، تعداد خطاها، تعداد پرداخت‌ها.\u003C/p>\u003Cp>\u003Cstrong>Gauge\u003C/strong>\u003Cbr>می‌تواند بالا و پایین برود.\u003Cbr>مثال: تعداد کاربران آنلاین، مقدار حافظه مصرف‌شده، صف فعال.\u003C/p>\u003Cp>\u003Cstrong>Histogram\u003C/strong>\u003Cbr>برای توزیع مقادیر و محاسبه percentileها استفاده می‌شود.\u003Cbr>مثال: latency درخواست‌ها، زمان پاسخ دیتابیس، سایز payloadها.\u003C/p>\u003Cp>\u003Cstrong>Summary\u003C/strong>\u003Cbr>برای quantileهای محلی و محاسبات آماری درون‌سرویس استفاده می‌شود، هرچند در محیط‌های distributed باید با دقت استفاده شود.\u003C/p>\u003Cp>مثال کاربردی instrumentation\u003C/p>\u003Cp>فرض کنید در سرویس پرداخت، متریک زیر تعریف می‌شود:\u003C/p>\u003Cp>`payment_processing_seconds`\u003C/p>\u003Cp>هر بار که یک تراکنش کامل می‌شود، زمان پردازش ثبت می‌شود. حالا Prometheus می‌تواند تشخیص دهد که:\u003C/p>\u003Cp>latency نسخه جدید نسبت به نسخه قبلی افزایش یافته است\u003Cbr>درصد تراکنش‌های کند در ساعات اوج ترافیک بیشتر می‌شود\u003Cbr>یک dependency خاص، مانند بانک یا سرویس OTP، باعث کندی شده است\u003Cbr>در کدام region یا cluster مشکل بیشتر رخ می‌دهد\u003C/p>\u003Cp>این همان جایی است که telemetry از یک عدد ساده به یک ابزار تصمیم‌سازی تبدیل می‌شود.\u003C/p>\u003Cp>\u003Cstrong>۳. اصول طراحی متریک خوب\u003C/strong>\u003C/p>\u003Cp>یک metric خوب باید چند ویژگی داشته باشد:\u003C/p>\u003Cp>معنای روشن و پایدار داشته باشد\u003Cbr>با labelهای محدود اما مفید طراحی شود\u003Cbr>از cardinality انفجاری جلوگیری کند\u003Cbr>برای alerting و dashboarding قابل استفاده باشد\u003Cbr>با SLOها و business KPIها قابل اتصال باشد\u003C/p>\u003Cp>اشتباه رایج این است که توسعه‌دهندگان متریکی با labelهای بسیار زیاد می‌سازند، مثلاً `user_id` یا `request_id` را به‌عنوان label قرار می‌دهند. این کار باعث high cardinality می‌شود و می‌تواند بار سنگینی روی Prometheus ایجاد کند. در طراحی حرفه‌ای observability، cardinality یک موضوع بسیار جدی است.\u003C/p>\u003Cp>معماری Node Exporter جمع‌آوری متریک‌های سیستم‌عامل و ارائه به Prometheus.png👇\u003C/p>\u003Cfigure class=\"image\">\u003Cimg style=\"aspect-ratio:1024/487;\" src=\"https://api.dornadevops.com/media/articles/posts/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C%20Node%20Exporter%20%D8%AC%D9%85%D8%B9%D8%A2%D9%88%D8%B1%DB%8C%20%D9%85%D8%AA%D8%B1%DB%8C%DA%A9%D9%87%D8%A7%DB%8C%20%D8%B3%DB%8C%D8%B3%D8%AA%D9%85%D8%B9%D8%A7%D9%85%D9%84%20%D9%88%20%D8%A7%D8%B1%D8%A7%D8%A6%D9%87%20%D8%A8%D9%87%20Prometheus.png\" alt=\"معماری Node Exporter جمع‌آوری متریک‌های سیستم‌عامل و ارائه به Prometheus.png\" width=\"1024\" height=\"487\">\u003C/figure>\u003Chr>\u003Ch3>۳. جادوی تاریک PromQL: زبانی برای تحلیل زمان\u003C/h3>\u003Cp>اگر Prometheus قلب سیستم observability باشد، PromQL مغز تحلیلی آن است. PromQL فقط یک زبان کوئری نیست؛ یک زبان مدل‌سازی رفتار سری‌زمانی است. برخلاف SQL که روی جدول‌های relation کار می‌کند، PromQL روی data points در بازه‌های زمانی مشخص کار می‌کند.\u003C/p>\u003Cp>\u003Cstrong>الف) مفاهیم پایه در PromQL\u003C/strong>\u003C/p>\u003Cp>PromQL با نوع‌های مختلف selector و function کار می‌کند. مهم‌ترین مفاهیم آن عبارتند از:\u003C/p>\u003Cp>Instant vector\u003Cbr>Range vector\u003Cbr>Scalar\u003Cbr>String\u003C/p>\u003Cp>با این ابزارها، می‌توان رفتار گذشته را بررسی کرد، روندها را تشخیص داد، نرخ‌ها را محاسبه کرد، anomalyها را پیدا کرد، و alertهای دقیق ساخت.\u003C/p>\u003Cp>\u003Cstrong>ب) نرخ خطا و throughput\u003C/strong>\u003C/p>\u003Cp>یکی از مهم‌ترین استفاده‌های \u003Cstrong>PromQL \u003C/strong>محاسبه نرخ درخواست‌ها و خطاهاست. به‌جای شمردن raw counterها، باید از تابع `rate()` استفاده کرد تا نرخ تغییرات در یک بازه زمانی مشخص محاسبه شود.\u003C/p>\u003Cp>مثال:\u003C/p>\u003Cpre>\u003Ccode class=\"language-plaintext\">promql\r\nrate(http_requests_total{status=\"500\"}[5m])\u003C/code>\u003C/pre>\u003Cp>این کوئری به شما می‌گوید در پنج دقیقه اخیر، نرخ خطاهای ۵۰۰ چقدر بوده است. اما در عمل معمولاً از این کوئری در کنار نرخ کل درخواست‌ها استفاده می‌شود تا error ratio محاسبه شود.\u003C/p>\u003Cp>\u003Cstrong>ج) محاسبه درصد خطا\u003C/strong>\u003C/p>\u003Cpre>\u003Ccode class=\"language-plaintext\">promql\r\nsum(rate(http_requests_total{status=~\"5..\"}[5m])) \r\n/\r\nsum(rate(http_requests_total[5m]))\u003C/code>\u003C/pre>\u003Cp>این کوئری یکی از پایه‌ای‌ترین ابزارها برای SLI و error budget است. اگر سهم خطا از یک آستانه مشخص بالاتر برود، می‌توان alert فعال کرد یا rollout را متوقف نمود.\u003C/p>\u003Cp>\u003Cstrong>د) محاسبه latency و صدک‌ها\u003C/strong>\u003C/p>\u003Cp>یکی از پیچیده‌ترین و مهم‌ترین بخش‌های observability، تحلیل latency است. میانگین latency همیشه گمراه‌کننده است، چون چند request بسیار سریع می‌توانند یک spike شدید را پنهان کنند. به همین دلیل percentileها اهمیت دارند.\u003C/p>\u003Cp>برای histogramها، معمولاً از \u003Ccode>\u003Cstrong>`histogram_quantile()`\u003C/strong>\u003C/code> استفاده می‌شود:\u003C/p>\u003Cpre>\u003Ccode class=\"language-plaintext\">promql\r\nhistogram_quantile(0.99, rate(http_request_duration_seconds_bucket[10m]))\u003C/code>\u003C/pre>\u003Cp>این کوئری صدک ۹۹ام latency را بر اساس histogram bucketها محاسبه می‌کند. در محیط‌های enterprise، percentileها برای شناسایی tail latency، backlog، saturation، و رفتار کاربران در بار بالا ضروری هستند.\u003C/p>\u003Cp>\u003Cstrong>ه) تشخیص روند و پیش‌بینی\u003C/strong>\u003C/p>\u003Cp>Prometheus حتی می‌تواند برای پیش‌بینی روندهای آینده استفاده شود. تابع \u003Ccode>\u003Cstrong>`predict_linear()`\u003C/strong>\u003C/code> برای برآورد خطی آینده کاربرد دارد.\u003C/p>\u003Cp>مثال:\u003C/p>\u003Cpre>\u003Ccode class=\"language-plaintext\">promql\r\npredict_linear(node_filesystem_free_bytes[4h], 24  3600) < 0\u003C/code>\u003C/pre>\u003Cp>این کوئری بررسی می‌کند که آیا فضای دیسک طی ۲۴ ساعت آینده بر اساس روند ۴ ساعت گذشته به زیر صفر می‌رسد یا نه. چنین تحلیلی برای جلوگیری از outages ناشی از full disk بسیار ارزشمند است.\u003C/p>\u003Cp>\u003Cstrong>و) مقایسه بازه‌های زمانی\u003C/strong>\u003C/p>\u003Cp>PromQL امکان مقایسه متریک‌ها در زمان‌های مختلف را فراهم می‌کند. مثلاً می‌توان وضعیت امروز را با دیروز یا هفته گذشته مقایسه کرد. این موضوع برای شناسایی تغییرات پس از deploy، seasonality، یا چرخه‌های بار بسیار مهم است.\u003C/p>\u003Cp>\u003Cstrong>ز) تجمیع و grouping\u003C/strong>\u003C/p>\u003Cp>در محیط‌های distributed، یک متریک به‌تنهایی کافی نیست. باید داده‌ها را با \u003Cstrong>`sum by(...)`، `avg by(...)`، `max by(...)`\u003C/strong> و سایر عملگرها تجمیع کرد تا تصویر درست‌تری از رفتار سیستم به‌دست آید.\u003C/p>\u003Cp>مثلاً می‌توان latency را بر اساس سرویس، namespace، cluster، یا region تجزیه کرد و فهمید مشکل دقیقاً از کجا شروع شده است.\u003C/p>\u003Cp>\u003Cstrong>ح) PromQL در فضای تولید\u003C/strong>\u003C/p>\u003Cp>PromQL تنها برای نمایش نمودار نیست؛ برای alerting، SLO management، capacity planning، anomaly detection، و RCA هم استفاده می‌شود. همین ویژگی باعث شده یکی از مهم‌ترین مهارت‌ها برای SRE، DevOps و platform engineers باشد.\u003C/p>\u003Cp>داشبورد Grafana با کوئری_های PromQL برای تحلیل زمان_بندی و متریک_های سیستم👇\u003C/p>\u003Cfigure class=\"image\">\u003Cimg style=\"aspect-ratio:1280/720;\" src=\"https://api.dornadevops.com/media/articles/posts/%D8%AF%D8%A7%D8%B4%D8%A8%D9%88%D8%B1%D8%AF%20Grafana%20%D8%A8%D8%A7%20%DA%A9%D9%88%D8%A6%D8%B1%DB%8C_%D9%87%D8%A7%DB%8C%20PromQL%20%D8%A8%D8%B1%D8%A7%DB%8C%20%D8%AA%D8%AD%D9%84%DB%8C%D9%84%20%D8%B2%D9%85%D8%A7%D9%86_%D8%A8%D9%86%D8%AF%DB%8C%20%D9%88%20%D9%85%D8%AA%D8%B1%DB%8C%DA%A9_%D9%87%D8%A7%DB%8C%20%D8%B3%DB%8C%D8%B3%D8%AA%D9%85.png\" alt=\"داشبورد Grafana با کوئری_های PromQL برای تحلیل زمان_بندی و متریک_های سیستم.png\" width=\"1280\" height=\"720\">\u003C/figure>\u003Chr>\u003Ch3>۴. گرافانا (Grafana): از داشبوردهای خسته‌کننده تا اتاق جنگ (War Room)\u003C/h3>\u003Cp>اگر Prometheus موتور جمع‌آوری و تحلیل است، Grafana لایه‌ی دیدن، فهمیدن و تصمیم گرفتن است. Grafana فقط یک ابزار رسم نمودار نیست؛ یک پلتفرم observability visualization است که می‌تواند داده‌ها را از منابع مختلف بگیرد و در قالبی تعاملی، قابل‌فهم و سازمانی ارائه کند.\u003C/p>\u003Cp>\u003Cstrong>الف) داشبورد به‌عنوان محصول\u003C/strong>\u003C/p>\u003Cp>در سازمان‌های حرفه‌ای، داشبورد فقط یک صفحه نمودار نیست. داشبورد یک محصول داخلی است که برای نقش‌های مختلف طراحی می‌شود:\u003C/p>\u003Cp>dashboard برای SRE\u003Cbr>dashboard برای توسعه‌دهنده\u003Cbr>dashboard برای مدیر محصول\u003Cbr>dashboard برای مدیریت ارشد\u003Cbr>dashboard برای عملیات شبانه‌روزی\u003C/p>\u003Cp>هر گروه به سطح متفاوتی از اطلاعات نیاز دارد. Grafana این امکان را می‌دهد که همین لایه‌بندی را به‌خوبی پیاده‌سازی کنید.\u003C/p>\u003Cp>\u003Cstrong>ب) Templating و Variables: داشبوردهای پویا\u003C/strong>\u003C/p>\u003Cp>به‌جای ساختن ده‌ها یا صدها داشبورد تکراری، می‌توان از variables استفاده کرد. برای مثال:\u003C/p>\u003Cp>`$cluster`\u003Cbr>`$namespace`\u003Cbr>`$pod`\u003Cbr>`$service`\u003Cbr>`$instance`\u003Cbr>`$env`\u003C/p>\u003Cp>با این روش، یک داشبورد واحد می‌تواند برای هزاران target مختلف استفاده شود. این قابلیت در محیط‌های چندکلاستری و چندمحیطی مثل dev/stage/prod بسیار مهم است.\u003C/p>\u003Cp>\u003Cstrong>ج) Data Source Blending: تلفیق داده از چند منبع\u003C/strong>\u003C/p>\u003Cp>Grafana محدود به Prometheus نیست. شما می‌توانید در یک داشبورد، داده‌های زیر را کنار هم ببینید:\u003C/p>\u003Cp>metrics از Prometheus\u003Cbr>logs از Loki یا Elasticsearch\u003Cbr>traces از Tempo یا Jaeger\u003Cbr>داده‌های تحلیلی از PostgreSQL یا MySQL\u003Cbr>اطلاعات business از APIهای داخلی\u003C/p>\u003Cp>این ادغام باعث می‌شود تحلیل از «\u003Cstrong>فقط دیدن یک نمودار\u003C/strong>» به «فهمیدن کامل رخداد» تبدیل شود. مثلاً ممکن است latency بالا رفته باشد، لاگ‌ها نشان دهند errorهای timeout در افزایش‌اند، و traceها هم dependency خاصی را به‌عنوان bottleneck معرفی کنند.\u003C/p>\u003Cp>\u003Cstrong>د) Annotations: وصل کردن رخدادهای عملیاتی به نمودارها\u003C/strong>\u003C/p>\u003Cp>یکی از قابلیت‌های بسیار ارزشمند Grafana، Annotations است. این ویژگی به شما اجازه می‌دهد رخدادهای مهم را روی نمودار ثبت کنید:\u003C/p>\u003Cp>deploy نسخه جدید\u003Cbr>restart سرویس\u003Cbr>failover دیتابیس\u003Cbr>rotate شدن certificate\u003Cbr>افزایش ناگهانی traffic\u003Cbr>شروع campaign بازاریابی\u003Cbr>اعمال تغییر در feature flag\u003C/p>\u003Cp>وقتی روی نمودار یک spike می‌بینید، annotationها کمک می‌کنند بفهمید آن spike با چه رویدادی هم‌زمان بوده است. این قابلیت در تحلیل incident و postmortem بسیار مهم است.\u003C/p>\u003Cp>\u003Cstrong>ه) آژانگستن سازی داشبورد: از نمایش به تجربه\u003C/strong>\u003C/p>\u003Cp>Grafana فقط برای نمایش نیست؛ برای تجربه کاربر عملیاتی نیز طراحی شده است. شما می‌توانید:\u003C/p>\u003Cp>thresholds تعریف کنید\u003Cbr>رنگ‌های وضعیت را مشخص کنید\u003Cbr>drilldown بسازید\u003Cbr>لینک به دیگر داشبوردها اضافه کنید\u003Cbr>rowها و panelها را شرطی کنید\u003Cbr>repeat panel بر اساس variable داشته باشید\u003C/p>\u003Cp>در نتیجه، داشبورد دیگر یک صفحه‌ی ثابت نیست؛ بلکه یک محیط زنده و عملیاتی است.\u003C/p>\u003Cp>\u003Cstrong>و) War Room و Decision Support\u003C/strong>\u003C/p>\u003Cp>در incidentهای جدی، Grafana به اتاق جنگ تبدیل می‌شود. تیم عملیات، توسعه و زیرساخت همه یک داشبورد مشترک را نگاه می‌کنند. یک نگاه دقیق به panelها می‌تواند مشخص کند:\u003C/p>\u003Cp>آیا مشکل از CPU saturation است؟\u003Cbr>آیا memory leak رخ داده؟\u003Cbr>آیا network latency بالا رفته؟\u003Cbr>آیا تعداد درخواست‌های ۵xx بیشتر شده؟\u003Cbr>آیا یک rollout جدید در حال خراب کردن سیستم است؟\u003C/p>\u003Cp>در چنین لحظاتی، Grafana نقش یک ابزار تصمیم‌سازی بلادرنگ را بازی می‌کند.\u003C/p>\u003Cp>داشبورد Grafana با تم تیره و نمودارهای Gauge برای CPU و Load👇\u003C/p>\u003Cfigure class=\"image\">\u003Cimg style=\"aspect-ratio:1909/881;\" src=\"https://api.dornadevops.com/media/articles/posts/%D8%AF%D8%A7%D8%B4%D8%A8%D9%88%D8%B1%D8%AF%20Grafana%20%D8%A8%D8%A7%20%D8%AA%D9%85%20%D8%AA%DB%8C%D8%B1%D9%87%20%D9%88%20%D9%86%D9%85%D9%88%D8%AF%D8%A7%D8%B1%D9%87%D8%A7%DB%8C%20Gauge%20%D8%A8%D8%B1%D8%A7%DB%8C%20CPU%20%D9%88%20Load.png\" width=\"1909\" height=\"881\">\u003C/figure>\u003Chr>\u003Ch3>۵. مقیاس‌پذیری بی‌نهایت: غلبه بر محدودیت‌های پرومتئوس با Thanos\u003C/h3>\u003Cp>Prometheus در طراحی اولیه خود، به‌صورت singlenode TSDB ساخته شده است. این یعنی بسیار سریع، ساده، و قابل‌اعتماد است؛ اما در عین حال برای نگهداری بلندمدت و مقیاس جهانی، به تنهایی کافی نیست.\u003C/p>\u003Cp>اگر شما فقط یک Prometheus داشته باشید، چند مسئله مطرح می‌شود:\u003C/p>\u003Cp>در صورت خرابی سرور، data loss محتمل است\u003Cbr>retention محلی محدود است\u003Cbr>queryهای crosscluster دشوار می‌شوند\u003Cbr>aggregation جهانی در چند region سخت می‌شود\u003Cbr>longterm storage به صورت native در خود Prometheus ایده‌آل نیست\u003C/p>\u003Cp>برای حل این محدودیت‌ها، لایه‌هایی مانند Thanos، Cortex و در برخی سناریوها Grafana Mimir وارد می‌شوند.\u003C/p>\u003Cp>\u003Cstrong>الف) Thanos چیست؟\u003C/strong>\u003C/p>\u003Cp>Thanos یک لایه تکمیلی برای Prometheus است که قابلیت‌های زیر را فراهم می‌کند:\u003C/p>\u003Cp>HA برای Prometheus\u003Cbr>longterm storage\u003Cbr>query federation جهانی\u003Cbr>deduplication\u003Cbr>downsampling\u003Cbr>global aggregation\u003Cbr>اتصال به object storage\u003C/p>\u003Cp>Thanos معمولاً با معماری sidecar کنار هر Prometheus اجرا می‌شود و داده‌ها را به object storage مانند Amazon S3 یا فضای ذخیره‌سازی سازگار با S3 منتقل می‌کند.\u003C/p>\u003Cp>\u003Cstrong>ب) اجزای مهم Thanos\u003C/strong>\u003C/p>\u003Cp>\u003Cstrong>Sidecar\u003C/strong>\u003C/p>\u003Cp>کنار Prometheus اجرا می‌شود و بلوک‌ها را به object storage upload می‌کند. همچنین queryها را برای دسترسی به داده‌های محلی و بلندمدت پشتیبانی می‌کند.\u003C/p>\u003Cp>\u003Cstrong>Query\u003C/strong>\u003C/p>\u003Cp>لایه‌ای برای query سراسری است که می‌تواند چندین Prometheus را به‌صورت یکپارچه query کند.\u003C/p>\u003Cp>\u003Cstrong>Store Gateway\u003C/strong>\u003C/p>\u003Cp>بلوک‌های قدیمی‌تر را از object storage سرویس می‌کند.\u003C/p>\u003Cp>\u003Cstrong>Compactor\u003C/strong>\u003C/p>\u003Cp>وظیفه فشرده‌سازی، downsampling و نگهداری ساختاری داده‌های تاریخی را بر عهده دارد.\u003C/p>\u003Cp>\u003Cstrong>Ruler\u003C/strong>\u003C/p>\u003Cp>برای evaluation ruleها و alerting در معماری توزیع‌شده استفاده می‌شود.\u003C/p>\u003Cp>\u003Cstrong>ج) چرا Thanos در enterprise مهم است؟\u003C/strong>\u003C/p>\u003Cp>در سازمان‌های بزرگ، شما ممکن است چندین cluster در چند region، چند cloud provider، یا چند دیتاسنتر داشته باشید. بدون یک layer مانند Thanos، تحلیل crossenvironment بسیار سخت می‌شود. Thanos یک global view فراهم می‌کند، یعنی از دید تیم عملیات، کل زیرساخت به‌صورت یک سیستم واحد دیده می‌شود.\u003C/p>\u003Cp>این موضوع نه‌فقط برای مانیتورینگ، بلکه برای compliance، capacity planning، incident review و SLA governance نیز اهمیت دارد.\u003C/p>\u003Cp>\u003Cstrong>د) ذخیره‌سازی نامحدود و ارزان‌تر\u003C/strong>\u003C/p>\u003Cp>Object storage نسبت به local SSD برای نگهداری طولانی‌مدت ارزان‌تر و مناسب‌تر است. به این ترتیب، Prometheus می‌تواند در لایه local فقط داده‌های نزدیک و فوری را نگه دارد، در حالی که Thanos آرشیو بلندمدت را بر عهده می‌گیرد.\u003C/p>\u003Cp>معماری Thanos شامل Sidecar، Query، Store Gateway، Compactor و اتصال به Object Storage👇\u003C/p>\u003Cfigure class=\"image\">\u003Cimg style=\"aspect-ratio:2000/1352;\" src=\"https://api.dornadevops.com/media/articles/posts/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C%20Thanos%20%D8%B4%D8%A7%D9%85%D9%84%20Sidecar%D8%8C%20Query%D8%8C%20Store%20Gateway%D8%8C%20Compactor%20%D9%88%20%D8%A7%D8%AA%D8%B5%D8%A7%D9%84%20%D8%A8%D9%87%20Object%20Storage.png\" width=\"2000\" height=\"1352\">\u003C/figure>\u003Chr>\u003Ch3>۶. سیستم هشدار عصبی: Alertmanager در خط مقدم\u003C/h3>\u003Cp>Observability بدون alerting کامل نیست. اگر سیستم شما متوجه خطا شود اما هیچ هشدار مناسبی ارسال نکند، عملاً در لحظه بحران بی‌فایده خواهد بود. در اکوسیستم Prometheus، این نقش را Alertmanager ایفا می‌کند.\u003C/p>\u003Cp>Alertmanager فقط یک notifier ساده نیست؛ بلکه یک موتور مدیریت آلارم است که برای جلوگیری از انفجار هشدار، مسیریابی هوشمند، و کنترل نویز طراحی شده است.\u003C/p>\u003Cp>\u003Cstrong>الف) Grouping: جلوگیری از سیل هشدار\u003C/strong>\u003C/p>\u003Cp>وقتی یک dependency اصلی مثل database down شود، ممکن است ده‌ها یا صدها سرویس downstream هم شروع به خطا دادن کنند. اگر هر سرویس جداگانه alert بفرستد، تیم عملیات در چند ثانیه زیر حجم پیام دفن می‌شود.\u003C/p>\u003Cp>Alertmanager با grouping هشدارهای مرتبط را در یک دسته جمع می‌کند تا فقط یک alert معنادار به تیم برسد. این کار باعث کاهش چشمگیر alert fatigue می‌شود.\u003C/p>\u003Cp>\u003Cstrong>ب) Inhibition: اولویت دادن به علت اصلی\u003C/strong>\u003C/p>\u003Cp>گاهی یک alert علت اصلی است و بقیه فقط نشانه‌های ثانویه آن هستند. مثلاً اگر node فیزیکی down شده باشد، alertهای مربوط به podها یا کانتینرهای داخل آن node عملاً تکراری‌اند. Alertmanager می‌تواند آن‌ها را inhibit کند تا فقط alert اصلی نمایش داده شود.\u003C/p>\u003Cp>\u003Cstrong>ج) Routing: رساندن هشدار به تیم مناسب\u003C/strong>\u003C/p>\u003Cp>تمام alertها یکسان نیستند. برخی باید به تیم توسعه برسند، برخی به تیم زیرساخت، برخی به oncall، و برخی باید فوری به مدیر شیفت یا کانال incident منتقل شوند. Alertmanager با route tree این تفکیک را انجام می‌دهد.\u003C/p>\u003Cp>به‌طور مثال:\u003C/p>\u003Cp>Warning → Slack یا Teams\u003Cbr>Critical → PagerDuty یا تماس تلفنی\u003Cbr>Infrastructure issue → تیم platform\u003Cbr>Application bug → تیم development\u003Cbr>Security anomaly → تیم SOC\u003C/p>\u003Cp>\u003Cstrong>د) Silencing و Maintenance Window\u003C/strong>\u003C/p>\u003Cp>در محیط عملیاتی، گاهی لازم است هشدارها موقتاً خاموش شوند؛ مثلاً هنگام maintenance، migration، deploy، یا تست بار. Alertmanager این امکان را فراهم می‌کند که alertها را silence کنید تا نویز غیرضروری ایجاد نشود.\u003C/p>\u003Cp>\u003Cstrong>ه) Alert Design اصولی\u003C/strong>\u003C/p>\u003Cp>هشدار خوب باید:\u003C/p>\u003Cp>روی symptom یا SLO حساس باشد، نه فقط روی علت‌های سطح پایین\u003Cbr>دقیق و قابل‌اقدام باشد\u003Cbr>نویز کم داشته باشد\u003Cbr>ownership مشخص داشته باشد\u003Cbr>severity واقعی داشته باشد\u003Cbr>تاریخچه و context کافی ارائه دهد\u003C/p>\u003Cp>یک alert بد، تیم را خسته می‌کند. یک alert خوب، زمان واکنش را نجات می‌دهد.\u003C/p>\u003Cp>معماری Alertmanager Grouping، Deduplication، Silencing و Routing به کانال‌های اطلاع‌رسانی👇\u003C/p>\u003Cfigure class=\"image\">\u003Cimg style=\"aspect-ratio:871/599;\" src=\"https://api.dornadevops.com/media/articles/posts/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C%20Alertmanager%20Grouping%D8%8C%20Deduplication%D8%8C%20Silencing%20%D9%88%20Routing%20%D8%A8%D9%87%20%DA%A9%D8%A7%D9%86%D8%A7%D9%84%D9%87%D8%A7%DB%8C%20%D8%A7%D8%B7%D9%84%D8%A7%D8%B9%D8%B1%D8%B3%D8%A7%D9%86%DB%8C.png\" alt=\"معماری Alertmanager Grouping، Deduplication، Silencing و Routing به کانال‌های اطلاع‌رسانی.png\" width=\"871\" height=\"599\">\u003C/figure>\u003Chr>\u003Ch3>۷. الگوهای استقرار حرفه‌ای در Kubernetes و CloudNative\u003C/h3>\u003Cp>استفاده از Prometheus و Grafana در محیط‌های production صرفاً نصب ساده یک سرویس نیست. برای اینکه این استک به‌خوبی کار کند، باید طراحی معماری آن نیز درست باشد.\u003C/p>\u003Cp>\u003Cstrong>الف) Single Prometheus برای شروع، ولی نه برای همیشه\u003C/strong>\u003C/p>\u003Cp>برای محیط‌های کوچک و متوسط، یک Prometheus می‌تواند کافی باشد. اما به‌محض افزایش تعداد targetها، cardinality، و نیازهای retention، باید به سمت معماری‌های توزیع‌شده رفت.\u003C/p>\u003Cp>\u003Cstrong>ب) Prometheus Operator\u003C/strong>\u003C/p>\u003Cp>در Kubernetes، یکی از بهترین روش‌ها برای مدیریت Prometheus استفاده از Prometheus Operator است. این operator باعث می‌شود اشیای Kubernetesnative مانند:\u003C/p>\u003Cp>ServiceMonitor\u003Cbr>PodMonitor\u003Cbr>PrometheusRule\u003Cbr>Alertmanager\u003Cbr>ThanosRuler\u003C/p>\u003Cp>به‌صورت declarative مدیریت شوند.\u003C/p>\u003Cp>این الگو هم عملیات را ساده‌تر می‌کند و هم با GitOps و Infrastructure as Code سازگارتر است.\u003C/p>\u003Cp>\u003Cstrong>ج) Namespacebased Monitoring\u003C/strong>\u003C/p>\u003Cp>در کلاسترهای بزرگ، معمولاً متریک‌ها بر اساس namespace، team، environment و tenant سازمان‌دهی می‌شوند. این کار باعث می‌شود هر تیم دید مستقل اما استانداردی به سرویس‌های خود داشته باشد.\u003C/p>\u003Cp>\u003Cstrong>د) Scrape Strategy و Load Control\u003C/strong>\u003C/p>\u003Cp>در مقیاس بالا باید حتماً به موارد زیر توجه کرد:\u003C/p>\u003Cp>scrape interval\u003Cbr>scrape timeout\u003Cbr>number of targets\u003Cbr>series cardinality\u003Cbr>relabeling rules\u003Cbr>metric drop strategy\u003Cbr>remote write load\u003Cbr>resource requests/limits\u003C/p>\u003Cp>Prometheus برای performance مناسب، به CPU، RAM، و especially I/O مناسب نیاز دارد. TSDB یک workload نوشتن مداوم و خواندن تحلیلی دارد و همین موضوع آن را به سیستمی حساس به storage performance تبدیل می‌کند.\u003C/p>\u003Cp>\u003Cstrong>ه) High Availability\u003C/strong>\u003C/p>\u003Cp>برای HA، معمولاً چند instance از Prometheus در کنار هم اجرا می‌شوند. داده‌ها به‌صورت duplicate scrape می‌شوند و سیستم‌های بالادستی مانند Thanos deduplication را انجام می‌دهند. این الگو باعث می‌شود خرابی یک instance به معنای از دست رفتن observability نباشد.\u003C/p>\u003Cp>معماری Prometheus Operator با ServiceMonitor و PodMonitor در Kubernetes👇\u003C/p>\u003Cfigure class=\"image\">\u003Cimg style=\"aspect-ratio:600/374;\" src=\"https://api.dornadevops.com/media/articles/posts/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C%20Prometheus%20Operator%20%D8%A8%D8%A7%20ServiceMonitor%20%D9%88%20PodMonitor%20%D8%AF%D8%B1%20Kubernetes.png\" width=\"600\" height=\"374\">\u003C/figure>\u003Chr>\u003Ch3>۸. از متریک تا تصمیم تجاری: چرا این استک فقط ابزار فنی نیست؟\u003C/h3>\u003Cp>یکی از اشتباهات رایج این است که Prometheus و Grafana را فقط ابزار DevOps بدانیم. در واقع، این استک اگر درست استفاده شود، به‌طور مستقیم بر تصمیم‌های کسب‌وکار اثر می‌گذارد.\u003C/p>\u003Cp>\u003Cstrong>الف) اتصال observability به SLO و SLA\u003C/strong>\u003C/p>\u003Cp>با Prometheus می‌توان دقیقاً سنجید:\u003C/p>\u003Cp>چند درصد درخواست‌ها موفق بوده‌اند\u003Cbr>latency واقعی کاربران چقدر است\u003Cbr>نرخ خطا در چه بازه‌ای از بودجه خطا عبور کرده\u003Cbr>کدام سرویس بیشترین ریسک را برای SLA ایجاد می‌کند\u003C/p>\u003Cp>\u003Cstrong>ب) ظرفیت‌سنجی و Planning\u003C/strong>\u003C/p>\u003Cp>اگر متریک‌های CPU، RAM، disk, network, queue depth, connection pool و request rate را به‌صورت تاریخی داشته باشید، می‌توانید:\u003C/p>\u003Cp>growth trend را تشخیص دهید\u003Cbr>زمان لازم برای scale را پیش‌بینی کنید\u003Cbr>هزینه زیرساخت را تخمین بزنید\u003Cbr>bottleneckهای آینده را قبل از رخ دادن شناسایی کنید\u003C/p>\u003Cp>\u003Cstrong>ج) تحلیل اثر Releaseها\u003C/strong>\u003C/p>\u003Cp>با annotation و مقایسه نسخه‌ها، می‌توان فهمید یک release جدید چه اثری روی latency، error rate یا resource consumption داشته است. این یعنی observability مستقیماً به کیفیت delivery و reliability مربوط است.\u003C/p>\u003Cp>\u003Cstrong>د) پشتیبانی از فرهنگ Postmortem\u003C/strong>\u003C/p>\u003Cp>بعد از هر incident، متریک‌ها و داشبوردها بهترین منبع برای بازسازی حقیقت هستند. از روی آن‌ها می‌توان فهمید:\u003C/p>\u003Cp>چه زمانی مشکل شروع شد\u003Cbr>کدام dependency نخستین سیگنال را داد\u003Cbr>چه تغییری باعث تشدید بحران شد\u003Cbr>در چه لحظه‌ای تیم باید مداخله می‌کرد\u003C/p>\u003Cp>داشبورد SLO در Grafana نمایش Error Budget Burn Rate و وضعیت SLA👇\u003C/p>\u003Cfigure class=\"image\">\u003Cimg style=\"aspect-ratio:1382/938;\" src=\"https://api.dornadevops.com/media/articles/posts/%D8%AF%D8%A7%D8%B4%D8%A8%D9%88%D8%B1%D8%AF%20SLO%20%D8%AF%D8%B1%20Grafana%20%D9%86%D9%85%D8%A7%DB%8C%D8%B4%20Error%20Budget%20Burn%20Rate%20%D9%88%20%D9%88%D8%B6%D8%B9%DB%8C%D8%AA%20SLA.png\" alt=\"داشبورد SLO در Grafana نمایش Error Budget Burn Rate و وضعیت SLA.png\" width=\"1382\" height=\"938\">\u003C/figure>\u003Chr>\u003Ch3>\u003Cstrong>نتیجه‌گیری & Call To Action\u003C/strong>\u003C/h3>\u003Cul>\u003Cli data-list-item-id=\"e5bee4f81819292aa63c0c79460df0f20\">در سال ۲۰۲۶، استک Prometheus و Grafana دیگر یک گزینه تزئینی یا صرفاً فنی نیست؛ این دو ابزار به بخشی از زیرساخت حیاتی سازمان تبدیل شده‌اند. در معماری‌های مدرن، failure نه یک رویداد استثنایی، بلکه بخشی از واقعیت سیستم‌های پیچیده است. تفاوت سازمان‌های موفق و ناموفق در این است که آیا می‌توانند failure را سریع ببینند، تحلیل کنند، و از آن یاد بگیرند یا نه.\u003C/li>\u003Cli data-list-item-id=\"e68de30fa63faa64a23344226106650b9\">Prometheus به شما قدرت می‌دهد که سیستم را با زبان متریک‌های دقیق، پایدار و سری‌زمانی ببینید. Grafana این داده‌ها را به دانش عملیاتی تبدیل می‌کند. Thanos آن را به مقیاس enterprise می‌رساند. Alertmanager آن را به action تبدیل می‌کند. و در کنار هم، این stack یک برج مراقبت تمام‌عیار برای دنیای cloudnative می‌سازد.\u003C/li>\u003Cli data-list-item-id=\"ee5f68e281ef79c62a4dad2840be8ecde\">زیرساخت ابری ایده‌آل برای چنین معماری‌ای باید از storage سریع، I/O پایدار، منابع RAM کافی، و شبکه کم‌تاخیر برخوردار باشد. اگر متریک‌ها قلب observability باشند، storage و compute مناسب رگ‌های حیاتی آن هستند. یک Prometheus کند یا یک Grafana ناپایدار، می‌تواند خود به منبع مشکل تبدیل شود.\u003C/li>\u003Cli data-list-item-id=\"ec65663a2e4ee0e382993e5181244d1da\">در نهایت، observability فقط دیدن نمودار نیست؛ فهمیدن رفتار سیستم پیش از تبدیل شدن آن به بحران است. و همین تفاوت است که Prometheus و Grafana را از ابزارهای ساده monitoring به ستون‌های اصلی reliability engineering تبدیل می‌کند.\u003C/li>\u003C/ul>\u003Cblockquote>\u003Cp>اگر می‌خواهید یک قدم جلوتر از رقبا باشید، باید امروز اقدام کنید.😁\u003Cbr>زیرساخت خود را بهینه کنید،\u003Cstrong> مانیتورینگ خود را حرفه ای و به روز کنید ،\u003C/strong> \u003Cstrong>Prometheus و Grafana ابزاریست که انتظار مانیتورینگ شمارا میکشد.\u003C/strong>\u003C/p>\u003C/blockquote>",5,"devops","دواپس","https://api.dornadevops.com/media/articles/category/images/devops.png",{"name":13,"avatar":14,"firstName":15,"lastName":15},"الیاس پوررجب","👤","",22,"https://api.dornadevops.com/media/articles/images/prometheus-grafana-observability-cloud-native-2026.jpg.png",[19,20,21],"Monitoring","Grafana","Prometheus",[23,25,27],{"name":24,"name_en":19},"مانیتورینگ",{"name":26,"name_en":20},"گرافانا",{"name":28,"name_en":21},"پرومتئوس",{"articles":30,"count":32,"next":327,"previous":327},[31,44,55,69,79,89,103,113,123,133,139,152,165,178,188,198,207,216,224,233,245,253,262,270,279,287,298,308,318],{"id":32,"title":33,"slug":34,"excerpt":35,"content":35,"categoryId":8,"categorySlug":9,"categoryTitle":10,"categoryImage":11,"author":36,"publishedAt":39,"readTime":40,"image":41,"tags":42,"tagsFa":43,"views":4},29,"طراحی سیستم‌های Highly Available چیست؟ راهنمای کامل معماری‌های در دسترس‌پذیر","highly-available-system-design-guide-2026","طراحی سیستم‌های Highly Available یعنی ساخت معماری‌هایی که در برابر خرابی‌های روزمره، outage و failover مقاوم باشند. در این مقاله HA را عمیق بررسی می‌کنیم.",{"name":13,"avatar":14,"firstName":37,"lastName":38},"الیاس","پوررجب","1405-02-26",20,"https://api.dornadevops.com/media/articles/images/highly-available-system-design-2026.jpg.png",[],[],{"id":45,"title":46,"slug":47,"excerpt":48,"content":48,"categoryId":8,"categorySlug":9,"categoryTitle":10,"categoryImage":11,"author":49,"publishedAt":50,"readTime":51,"image":52,"tags":53,"tagsFa":54,"views":4},28,"SRE چیست؟ راهنمای کامل Site Reliability Engineering در سیستم‌های مدرن","sre-site-reliability-engineering-guide-2026","SRE یا Site Reliability Engineering رویکردی مهندسی برای ساخت و نگهداری سیستم‌های قابل‌اعتماد، مقیاس‌پذیر و پایدار است. در این مقاله SRE را کامل بررسی می‌کنیم.",{"name":13,"avatar":14,"firstName":37,"lastName":38},"1405-02-25",18,"https://api.dornadevops.com/media/articles/images/sre-site-reliability-engineering-2026.jpg.png",[],[],{"id":56,"title":57,"slug":58,"excerpt":59,"content":59,"categoryId":60,"categorySlug":61,"categoryTitle":62,"categoryImage":63,"author":64,"publishedAt":50,"readTime":65,"image":66,"tags":67,"tagsFa":68,"views":4},27,"SLA چیست؟ راهنمای کامل Service Level Agreement در خدمات ابری","what-is-sla-cloud-service-level-agreement-2026","SLA یا Service Level Agreement قرارداد سطح خدمت در cloud است که uptime، service credit، scope و مسئولیت‌ها را مشخص می‌کند. در این مقاله SLA را کامل بررسی می‌کنیم.",8,"security","امنیت","https://api.dornadevops.com/media/articles/category/images/security.jpeg",{"name":13,"avatar":14,"firstName":37,"lastName":38},15,"https://api.dornadevops.com/media/articles/images/sla-cloud-service-level-agreement-2026.jpg.png",[],[],{"id":70,"title":71,"slug":72,"excerpt":73,"content":73,"categoryId":60,"categorySlug":61,"categoryTitle":62,"categoryImage":63,"author":74,"publishedAt":75,"readTime":40,"image":76,"tags":77,"tagsFa":78,"views":4},26,"Network Firewall چیست؟ معرفی کامل فایروال شبکه و بهترین فایروال‌های جهان در ۲۰۲۶","what-is-network-firewall-best-firewalls-2026","Network Firewall لایه‌ای کلیدی برای کنترل ترافیک بین شبکه‌های قابل‌اعتماد و غیرقابل‌اعتماد است. در این مقاله، فایروال شبکه را عمیق بررسی می‌کنیم و بهترین گزینه‌های جهان را معرفی می‌کنیم.",{"name":13,"avatar":14,"firstName":37,"lastName":38},"1405-02-24","https://api.dornadevops.com/media/articles/images/network-firewall-best-firewalls-2026.jpg.png",[],[],{"id":80,"title":81,"slug":82,"excerpt":83,"content":83,"categoryId":60,"categorySlug":61,"categoryTitle":62,"categoryImage":63,"author":84,"publishedAt":75,"readTime":85,"image":86,"tags":87,"tagsFa":88,"views":4},25,"WAF چیست؟ معرفی کامل Web Application Firewall و بهترین WAFهای جهان","what-is-waf-best-waf-2026","WAF یا Web Application Firewall لایه‌ای امنیتی برای محافظت از وب‌اپلیکیشن‌ها در برابر حملات HTTP و HTTPS است. در این مقاله، WAF را کامل بررسی می‌کنیم و بهترین WAFهای جهان را معرفی می‌کنیم.",{"name":13,"avatar":14,"firstName":37,"lastName":38},17,"https://api.dornadevops.com/media/articles/images/what-is-waf-web-application-firewall-best-waf-2026.jpg.png",[],[],{"id":90,"title":91,"slug":92,"excerpt":93,"content":93,"categoryId":94,"categorySlug":95,"categoryTitle":96,"categoryImage":97,"author":98,"publishedAt":75,"readTime":99,"image":100,"tags":101,"tagsFa":102,"views":4},24,"گارد قرمز چیست؟ راهکار حرفه‌ای برای انسداد درخواست‌های خارجی وردپرس و افزایش سرعت پیشخوان","red-guard-wordpress-external-requests","افزونه گارد قرمز برای انسداد درخواست‌های خارجی وردپرس و افزایش سرعت پیشخوان سایت",9,"wordpress","وردپرس","https://api.dornadevops.com/media/articles/category/images/wordpress.jpeg",{"name":13,"avatar":14,"firstName":37,"lastName":38},12,"https://api.dornadevops.com/media/articles/images/red-guard-wordpress-external-requests-2026.jpg.png",[],[],{"id":104,"title":105,"slug":106,"excerpt":107,"content":107,"categoryId":8,"categorySlug":9,"categoryTitle":10,"categoryImage":11,"author":108,"publishedAt":75,"readTime":109,"image":110,"tags":111,"tagsFa":112,"views":4},23,"GitLab چیست؟ ستون فقرات DevOps و CI/CD مدرن برای تیم‌های ایرانی","gitlab-devops-ci-cd-platform-iran","GitLab یک پلتفرم کامل DevOps برای مدیریت repository، CI/CD، Container Registry و Platform Engineering است که با زیرساخت داخلی، سرعت و پایداری بیشتری برای تیم‌های ایرانی فراهم می‌کند.",{"name":13,"avatar":14,"firstName":37,"lastName":38},14,"https://api.dornadevops.com/media/articles/images/gitlab-devops-platform-cloudnative-ci-cd-iran.jpg.png",[],[],{"id":16,"title":114,"slug":115,"excerpt":116,"content":116,"categoryId":8,"categorySlug":9,"categoryTitle":10,"categoryImage":11,"author":117,"publishedAt":118,"readTime":119,"image":120,"tags":121,"tagsFa":122,"views":4},"آینده DevOps در عصر هوش مصنوعی ۲۰۲۶","future-of-devops-ai-agentic-2026","آینده DevOps به سمت AI-Native Delivery، agentic workflows، observability هوشمند و عملیات نیمه‌خودمختار مبتنی بر AI و Platform Engineering حرکت می‌کند.",{"name":13,"avatar":14,"firstName":37,"lastName":38},"1405-02-22",16,"https://api.dornadevops.com/media/articles/images/future-devops-ai-agentic-cloud-native-2026.jpg.png",[],[],{"id":124,"title":125,"slug":126,"excerpt":127,"content":127,"categoryId":60,"categorySlug":61,"categoryTitle":62,"categoryImage":63,"author":128,"publishedAt":129,"readTime":51,"image":130,"tags":131,"tagsFa":132,"views":4},21,"OS Hardening چیست؟ راهنمای جامع امن‌سازی سیستم‌عامل در ۲۰۲۶","os-hardening-guide-2026","OS Hardening مجموعه‌ای از تکنیک‌های چندلایه برای کاهش سطح حمله، محدودسازی دسترسی‌ها و مقاوم‌سازی سیستم‌عامل در برابر نفوذ است.",{"name":13,"avatar":14,"firstName":37,"lastName":38},"1405-02-18","https://api.dornadevops.com/media/articles/images/os-hardening-linux-security-cloud-native-2026.jpg.png",[],[],{"id":40,"title":5,"slug":134,"excerpt":6,"content":6,"categoryId":8,"categorySlug":9,"categoryTitle":10,"categoryImage":11,"author":135,"publishedAt":136,"readTime":16,"image":17,"tags":137,"tagsFa":138,"views":4},"prometheus-grafana-observability-cloud-native",{"name":13,"avatar":14,"firstName":37,"lastName":38},"1405-02-16",[],[],{"id":140,"title":141,"slug":142,"excerpt":143,"content":143,"categoryId":144,"categorySlug":145,"categoryTitle":146,"categoryImage":147,"author":148,"publishedAt":136,"readTime":40,"image":149,"tags":150,"tagsFa":151,"views":4},19,"cPanel چیست؟ راهنمای کامل مدیریت سرور و هاست","cpanel-server-hosting-management-guide","cPanel همه‌چیز مدیریت هاست و سرور لینوکسی را در یک داشبورد ساده و قدرتمند جمع می‌کند؛ از سایت و ایمیل تا امنیت و اتوماسیون.",6,"cpanel","سیپنل","https://api.dornadevops.com/media/articles/category/images/cpanel.png",{"name":13,"avatar":14,"firstName":37,"lastName":38},"https://api.dornadevops.com/media/articles/images/cpanel-hosting-control-panel-dashboard-2026_vzAoNcZ.jpg.png",[],[],{"id":51,"title":153,"slug":154,"excerpt":155,"content":155,"categoryId":156,"categorySlug":157,"categoryTitle":158,"categoryImage":159,"author":160,"publishedAt":161,"readTime":85,"image":162,"tags":163,"tagsFa":164,"views":4},"DefectDojo چیست؟ راهنمای کامل مدیریت آسیب‌پذیری در DevSecOps","defectdojo-vulnerability-management-devsecops","DefectDojo گزارش‌های امنیتی پراکنده را به یک مرکز فرماندهی واحد تبدیل می‌کند تا آسیب‌پذیری‌ها سریع‌تر، دقیق‌تر و قابل‌ردیابی‌تر مدیریت شوند.",7,"devsecops","DevSecOps","https://api.dornadevops.com/media/articles/category/images/devsecops.jpeg",{"name":13,"avatar":14,"firstName":37,"lastName":38},"1405-02-13","https://api.dornadevops.com/media/articles/images/defectdojo-vulnerability-management-devsecops-2026.jpg.png",[],[],{"id":85,"title":166,"slug":167,"excerpt":168,"content":168,"categoryId":60,"categorySlug":61,"categoryTitle":62,"categoryImage":63,"author":169,"publishedAt":173,"readTime":174,"image":175,"tags":176,"tagsFa":177,"views":4},"آسیب‌پذیری بسیار مهم در cPanel – هشدار امنیتی درباره CVE‑2026‑41940","cpanel-cve-2026-41940-security-alert","با انتشار آسیب‌پذیری CVE‑2026‑41940 برای cPanel، سرورهایی که هنوز روی نسخه‌های قدیمی‌تر از آخرین نسخه امن هستند در معرض تهدید جدی قرار گرفته‌اند. این آسیب‌پذیری می‌تواند امنیت کامل سرویس را به خطر بیندازد.",{"name":170,"avatar":14,"firstName":171,"lastName":172},"درنا ادمین","درنا","ادمین","1405-02-12",1,"https://api.dornadevops.com/media/articles/images/cpanel-vuln.png",[],[],{"id":119,"title":179,"slug":180,"excerpt":181,"content":181,"categoryId":156,"categorySlug":157,"categoryTitle":158,"categoryImage":159,"author":182,"publishedAt":183,"readTime":184,"image":185,"tags":186,"tagsFa":187,"views":4},"GitLeaks چیست؟ ابزار شناسایی Secrets در Git","what-is-gitleaks-sast-secret-detection","GitLeaks ابزار متن‌باز برای شناسایی رمزها و API Keyهای لو رفته در Git است که قبل از انتشار، جلوی نشت اطلاعات حساس را می‌گیرد.",{"name":13,"avatar":14,"firstName":37,"lastName":38},"1405-02-09",11,"https://api.dornadevops.com/media/articles/images/gitleaks-git-secrets-scanner-security.jpg.png",[],[],{"id":65,"title":189,"slug":190,"excerpt":191,"content":191,"categoryId":156,"categorySlug":157,"categoryTitle":158,"categoryImage":159,"author":192,"publishedAt":193,"readTime":194,"image":195,"tags":196,"tagsFa":197,"views":4},"Semgrep چیست؟ ابزار سریع SAST برای امنیت کد و DevSecOps","semgrep-sast-devsecops","ابزار Semgrep با اسکن سریع کد، باگ‌ها، آسیب‌پذیری‌ها و secrets را قبل از اجرا پیدا می‌کند و امنیت را وارد جریان توسعه می‌کند.",{"name":13,"avatar":14,"firstName":37,"lastName":38},"1405-02-07",10,"https://api.dornadevops.com/media/articles/images/semgrep-sast-code-security-devsecops.jpg.png",[],[],{"id":109,"title":199,"slug":200,"excerpt":201,"content":201,"categoryId":156,"categorySlug":157,"categoryTitle":158,"categoryImage":159,"author":202,"publishedAt":203,"readTime":40,"image":204,"tags":205,"tagsFa":206,"views":4},"DevSecOps در ۲۰۲۶؛ تزریق امنیت به CI/CD و کلود","devsecops-2026-security-in-ci-cd-cloud","چطور امنیت را از ابتدا وارد CI/CD و زیرساخت ابری کنیم بدون اینکه سرعت توسعه قربانی شود؟",{"name":13,"avatar":14,"firstName":37,"lastName":38},"1405-02-02","https://api.dornadevops.com/media/articles/images/devsecops-security-ci-cd-cloud-2026_hnouteW.png",[],[],{"id":208,"title":209,"slug":210,"excerpt":211,"content":211,"categoryId":8,"categorySlug":9,"categoryTitle":10,"categoryImage":11,"author":212,"publishedAt":203,"readTime":51,"image":213,"tags":214,"tagsFa":215,"views":4},13,"CI/CD در ۲۰۲۶؛ از صفر تا دیپلوی بدون قطعی","ci-cd-2026-zero-downtime-deployment","از پایه تا حرفه‌ای یاد بگیرید چطور بدون قطعی روی سرور ابری دیپلوی کنید.",{"name":13,"avatar":14,"firstName":37,"lastName":38},"https://api.dornadevops.com/media/articles/images/ci-cd-zero-downtime-cloud-deployment.png",[],[],{"id":99,"title":217,"slug":218,"excerpt":219,"content":219,"categoryId":8,"categorySlug":9,"categoryTitle":10,"categoryImage":11,"author":220,"publishedAt":203,"readTime":119,"image":221,"tags":222,"tagsFa":223,"views":4},"ابزارهای DevOps در ۲۰۲۶؛ معرفی کامل و کاربردی","devops-tools-2026-complete-guide","بهترین ابزارهای DevOps را بشناسید و بفهمید هرکدام دقیقاً کجا استفاده می‌شوند.",{"name":13,"avatar":14,"firstName":37,"lastName":38},"https://api.dornadevops.com/media/articles/images/devops-tools-list-2026-cloud.png",[],[],{"id":184,"title":225,"slug":226,"excerpt":227,"content":227,"categoryId":8,"categorySlug":9,"categoryTitle":10,"categoryImage":11,"author":228,"publishedAt":229,"readTime":51,"image":230,"tags":231,"tagsFa":232,"views":4},"DevOps چیست؟ راهنمای کامل از صفر تا حرفه‌ای (۲۰۲۶)","what-is-devops-complete-guide-2026","از تعریف تا ابزارها و مسیر یادگیری DevOps را یک‌جا و حرفه‌ای یاد بگیرید.",{"name":13,"avatar":14,"firstName":37,"lastName":38},"1405-02-01","https://api.dornadevops.com/media/articles/images/what-is-devops-cloud-architecture-2026.png",[],[],{"id":194,"title":234,"slug":235,"excerpt":236,"content":236,"categoryId":237,"categorySlug":238,"categoryTitle":239,"categoryImage":240,"author":241,"publishedAt":229,"readTime":194,"image":242,"tags":243,"tagsFa":244,"views":4},"تغییر دامنه در DirectAdmin؛ سریع و بدون دردسر","change-domain-directadmin-guide","دامنه سایت را در DirectAdmin بدون خطا و از دست رفتن اطلاعات تغییر دهید.",4,"directadmin","دایرکت ادمین","https://api.dornadevops.com/media/articles/category/images/directadmin.jpg",{"name":13,"avatar":14,"firstName":37,"lastName":38},"https://api.dornadevops.com/media/articles/images/directadmin-change-domain-tutorial.jpg",[],[],{"id":94,"title":246,"slug":247,"excerpt":248,"content":248,"categoryId":237,"categorySlug":238,"categoryTitle":239,"categoryImage":240,"author":249,"publishedAt":229,"readTime":194,"image":250,"tags":251,"tagsFa":252,"views":4},"نصب SSL رایگان در DirectAdmin؛ امن‌سازی فوری سایت","install-free-ssl-directadmin","در چند دقیقه SSL رایگان نصب کنید و امنیت سایت را تضمین کنید.",{"name":13,"avatar":14,"firstName":37,"lastName":38},"https://api.dornadevops.com/media/articles/images/directadmin-free-ssl-install.jpg",[],[],{"id":60,"title":254,"slug":255,"excerpt":256,"content":256,"categoryId":237,"categorySlug":238,"categoryTitle":239,"categoryImage":240,"author":257,"publishedAt":258,"readTime":184,"image":259,"tags":260,"tagsFa":261,"views":4},"ساخت DNS اختصاصی برای دامنه؛ راهنمای کامل","create-custom-dns-domain-guide","یاد بگیرید DNS اختصاصی بسازید و کنترل کامل دامنه را در دست بگیرید.",{"name":13,"avatar":14,"firstName":37,"lastName":38},"1405-01-31","https://api.dornadevops.com/media/articles/images/custom-dns-setup-domain.jpg",[],[],{"id":156,"title":263,"slug":264,"excerpt":265,"content":265,"categoryId":237,"categorySlug":238,"categoryTitle":239,"categoryImage":240,"author":266,"publishedAt":258,"readTime":119,"image":267,"tags":268,"tagsFa":269,"views":4},"آموزش کامل و قدم‌ به‌ قدم بازگردانی بکاپ در دایرکت ادمین","restore-backup-directadmin-guide","چطور در کمترین زمان سایت را از بکاپ برگردانیم؟",{"name":13,"avatar":14,"firstName":37,"lastName":38},"https://api.dornadevops.com/media/articles/images/directadmin-backup-restore.jpg",[],[],{"id":144,"title":271,"slug":272,"excerpt":273,"content":273,"categoryId":237,"categorySlug":238,"categoryTitle":239,"categoryImage":240,"author":274,"publishedAt":275,"readTime":99,"image":276,"tags":277,"tagsFa":278,"views":4},"تغییر دامنه در وردپرس؛ قدم‌به‌قدم و بدون خطا","change-domain-wordpress-step-by-step","تغییر نام، بدون تغییر سرنوشت ، دامنه وردپرس را بدون خراب شدن سایت تغییر دهید.",{"name":13,"avatar":14,"firstName":37,"lastName":38},"1405-01-30","https://api.dornadevops.com/media/articles/images/wordpress-domain-change-guide.jpg",[],[],{"id":8,"title":280,"slug":281,"excerpt":282,"content":282,"categoryId":237,"categorySlug":238,"categoryTitle":239,"categoryImage":240,"author":283,"publishedAt":275,"readTime":99,"image":284,"tags":285,"tagsFa":286,"views":4},"بکاپ‌گیری حرفه‌ای در DirectAdmin (Admin Level)","directadmin-admin-backup-guide","چطور از کل سرور بکاپ بگیریم و در بحران نجاتش دهیم؟",{"name":13,"avatar":14,"firstName":37,"lastName":38},"https://api.dornadevops.com/media/articles/images/directadmin-admin-level-backup.jpg",[],[],{"id":237,"title":288,"slug":289,"excerpt":290,"content":290,"categoryId":174,"categorySlug":291,"categoryTitle":292,"categoryImage":293,"author":294,"publishedAt":275,"readTime":208,"image":295,"tags":296,"tagsFa":297,"views":4},"Portainer چیست؟ مدیریت حرفه‌ای Docker و Kubernetes","what-is-portainer-docker-management","Docker و Kubernetes را بدون دردسر و گرافیکی مدیریت کنید.","docker","داکر","https://api.dornadevops.com/media/articles/category/images/Screenshot_from_2026-03-06_15-05-14.png",{"name":13,"avatar":14,"firstName":37,"lastName":38},"https://api.dornadevops.com/media/articles/images/portainer-docker-kubernetes-ui.png",[],[],{"id":299,"title":300,"slug":301,"excerpt":302,"content":302,"categoryId":174,"categorySlug":291,"categoryTitle":292,"categoryImage":293,"author":303,"publishedAt":304,"readTime":194,"image":305,"tags":306,"tagsFa":307,"views":4},3,"۷ اشتباه مرگبار در Docker که باید همین امروز اصلاح کنید","docker-mistakes-developers","اشتباهاتی که پروژه‌ات را نابود می‌کنند و چطور ازشان جلوگیری کنی.",{"name":13,"avatar":14,"firstName":37,"lastName":38},"1405-01-29","https://api.dornadevops.com/media/articles/images/docker-common-mistakes.png",[],[],{"id":309,"title":310,"slug":311,"excerpt":312,"content":312,"categoryId":237,"categorySlug":238,"categoryTitle":239,"categoryImage":240,"author":313,"publishedAt":314,"readTime":194,"image":315,"tags":316,"tagsFa":317,"views":4},2,"بکاپ‌گیری در DirectAdmin؛ آموزش کامل و ساده(بیمه عمر سایت شما!)","directadmin-backup-complete-guide","با چند کلیک از سایتت بکاپ بگیر و خیالت را راحت کن.",{"name":13,"avatar":14,"firstName":37,"lastName":38},"1404-12-15","https://api.dornadevops.com/media/articles/images/directadmin-backup-guide.jpg",[],[],{"id":174,"title":319,"slug":320,"excerpt":321,"content":321,"categoryId":174,"categorySlug":291,"categoryTitle":292,"categoryImage":293,"author":322,"publishedAt":323,"readTime":174,"image":324,"tags":325,"tagsFa":326,"views":4},"نصب Docker بدون تحریم","install-docker-in-iran","نصب آفلاین Docker مخصوص سرورهای داخل ایران",{"name":170,"avatar":14,"firstName":171,"lastName":172},"1404-11-30","https://api.dornadevops.com/media/articles/images/install-docker-iran.png",[],[],null,[329,339,347,356,364,372,380,388,396],{"id":194,"name":330,"name_en":331,"image":332,"description":333,"slug":331,"headline":334,"tagline":335,"hidden":336,"group_type":337,"sort_order":338},"پشتیبانی و خدمات دواپس","devops-support","https://api.dornadevops.com/media/service_group_images/devops.png","\u003Cp>خدمات پشتیبانی ماهانه DevOps برای راه‌اندازی، نگهداری و عیب‌یابی زیرساخت‌های استقرار و مانیتورینگ ارائه می‌شود. این سرویس شامل پیاده‌سازی CI/CD، داکرایز کردن پروژه‌ها، راه‌اندازی مانیتورینگ، مدیریت لاگ و بهینه‌سازی فرایندهای استقرار است. هر پلن شامل تعداد ساعت مشخصی پشتیبانی است و در صورت مصرف بیشتر، ساعات مازاد به‌صورت جداگانه محاسبه خواهد شد.\u003C/p>","پشتیبانی و خدمات DevOps","راه‌اندازی، نگهداری و بهینه‌سازی زیرساخت DevOps برای استقرار سریع‌تر و پایدارتر",false,"F",91,{"id":174,"name":340,"name_en":341,"image":342,"description":343,"slug":341,"headline":344,"tagline":345,"hidden":336,"group_type":337,"sort_order":346},"پشتیبانی و مدیریت سرور لینوکسی","support","https://api.dornadevops.com/media/service_group_images/support.png","\u003Cp>خدمات پشتیبانی ماهانه برای مدیریت، عیب‌یابی و نگهداری سرورهای لینوکسی ارائه می‌شود. هر پلن شامل تعداد ساعت مشخصی پشتیبانی است و در صورت مصرف بیشتر، ساعات مازاد به‌صورت جداگانه محاسبه خواهد شد.\u003C/p>","پشتیبانی تخصصی سرور، متناسب با نیاز کسب‌وکار شما","از رفع خطاهای زیرساختی تا مدیریت روزمره سرور، با پلن‌های ماهانه و شفاف",90,{"id":309,"name":348,"name_en":349,"image":350,"description":351,"slug":349,"headline":352,"tagline":353,"hidden":336,"group_type":354,"sort_order":355},"لایسنس نرم‌افزارهای مدیریت سرور","license","https://api.dornadevops.com/media/service_group_images/license.png","\u003Cp>در این بخش می‌توانید لایسنس‌های موردنیاز برای مدیریت، امنیت، مجازی‌سازی و بهینه‌سازی سرور را به‌صورت ماهانه تهیه یا تمدید کنید. تمامی لایسنس‌ها با هدف افزایش کارایی، امنیت و سهولت مدیریت سرور ارائه می‌شوند.\u003C/p>","لایسنس‌های ضروری برای مدیریت حرفه‌ای سرور","از کنترل‌پنل و وب‌سرور تا امنیت و مجازی‌سازی، همه‌چیز برای یک زیرساخت کامل","S",80,{"id":8,"name":357,"name_en":358,"image":359,"description":360,"slug":358,"headline":361,"tagline":362,"hidden":336,"group_type":337,"sort_order":363},"سرور مجازی ایران با منابع اختصاصی","iran-vm","https://api.dornadevops.com/media/service_group_images/servers.png","\u003Cp>سرور مجازی ایران برای کسب‌وکارهایی مناسب است که به منابع اختصاصی‌تر، کنترل بیشتر و عملکرد پایدارتر نسبت به هاست اشتراکی نیاز دارند. این سرویس با پلن‌های متنوع و IP اختصاصی ارائه می‌شود.\u003C/p>","قدرت بیشتر، کنترل کامل‌تر، میزبانی در ایران","از پروژه‌های در حال رشد تا سرویس‌های حرفه‌ای، با منابع اختصاصی و دسترسی پایدار",70,{"id":237,"name":365,"name_en":366,"image":367,"description":368,"slug":366,"headline":369,"tagline":370,"hidden":336,"group_type":337,"sort_order":371},"هاست لینوکس ایران برای میزبانی سایت","linux-host","https://api.dornadevops.com/media/service_group_images/hosts.png","\u003Cp>هاست لینوکس ایران برای میزبانی سایت‌های شرکتی، فروشگاهی و شخصی با منابع متنوع، پهنای باند نامحدود و امکان استفاده از کنترل‌پنل‌های محبوب ارائه می‌شود. این سرویس برای راه‌اندازی سریع و پایدار وب‌سایت در داخل ایران مناسب است.\u003C/p>","میزبانی لینوکسی سریع و پایدار در ایران","انتخابی مناسب برای سایت‌های ایرانی با دسترسی بهتر، منابع متنوع و مدیریت آسان",63,{"id":60,"name":373,"name_en":374,"image":375,"description":376,"slug":374,"headline":377,"tagline":378,"hidden":336,"group_type":337,"sort_order":379},"هاست ایمیل حرفه‌ای","email","https://api.dornadevops.com/media/service_group_images/email.png","\u003Cp>سرویس ایمیل برای راه‌اندازی و مدیریت ایمیل سازمانی با تنظیمات بهینه و کاهش ریسک اسپم‌شدن ارائه می‌شود. این سرویس دارای پنل تحت وب، امکان ساخت حساب‌های متعدد و بکاپ هفتگی است.\u003C/p>","ایمیل سازمانی پایدار و حرفه‌ای برای کسب‌وکار شما","ارسال و دریافت مطمئن ایمیل با تنظیمات بهینه، پنل تحت وب و پشتیبانی مداوم",62,{"id":94,"name":381,"name_en":382,"image":383,"description":384,"slug":382,"headline":385,"tagline":386,"hidden":336,"group_type":337,"sort_order":387},"هاست لینوکس خارج با کیفیت بین‌المللی","linux-host-eu","https://api.dornadevops.com/media/service_group_images/hosts_6NC0r8y.png","\u003Cp>هاست لینوکس خارج برای سایت‌هایی مناسب است که به میزبانی با کیفیت بالا در خارج از کشور نیاز دارند. این سرویس با فضای مناسب، پهنای باند نامحدود، SSL و امکان استفاده از کنترل‌پنل‌های محبوب ارائه می‌شود.\u003C/p>","میزبانی لینوکسی خارج، مناسب پروژه‌های حرفه‌ای‌تر","کیفیت بالا، منابع مناسب و انتخابی مطمئن برای وب‌سایت‌های بین‌المللی یا خاص",61,{"id":299,"name":389,"name_en":390,"image":391,"description":392,"slug":390,"headline":393,"tagline":394,"hidden":336,"group_type":337,"sort_order":395},"فضای بکاپ و نگهداری نسخه پشتیبان","backup","https://api.dornadevops.com/media/service_group_images/backups.png","\u003Cp>هاست بکاپ مناسب ذخیره‌سازی امن فایل‌های پشتیبان سایت و سرور است و با فضای متنوع، ترافیک نامحدود و دسترسی FTP/SFTP ارائه می‌شود. این سرویس برای نگهداری نسخه‌های پشتیبان منظم و دسترسی سریع طراحی شده است\u003C/p>","فضایی مطمئن برای نگهداری بکاپ‌های مهم شما","ذخیره‌سازی سریع، ترافیک نامحدود و دسترسی امن برای مدیریت بهتر نسخه‌های پشتیبان",50,{"id":156,"name":397,"name_en":398,"image":399,"description":400,"slug":398,"headline":401,"tagline":402,"hidden":336,"group_type":337,"sort_order":4},"خدمات مانیتورینگ","monitoring","https://api.dornadevops.com/media/service_group_images/monitoring.png","\u003Cp>این سرویس برای پایش وضعیت دسترس‌پذیری و سلامت سرویس‌ها طراحی شده و با گزارش‌گیری، عیب‌یابی و اطلاع‌رسانی از طریق ایمیل و تلگرام، به شما در شناسایی سریع اختلال‌ها کمک می‌کند.\u003C/p>","همیشه از وضعیت سرویس‌های خود باخبر باشید","پایش لحظه‌ای آپتایم، گزارش دقیق و اطلاع‌رسانی سریع در زمان بروز اختلال",1779615404741]