0

راهنمای عملی مانیتورینگ Kubernetes با Applications Manager؛ از Cluster و Node تا Pod، Probe، Resource Limit، Storage، APM و Root Cause در محیط‌های K8s.

شرکت مدانت
شرکت مدانت
[ مجری تخصصی پیاده‌سازی چارچوب ITIL و تحول دیجیتال ]
مانیتورینگ Kubernetes با Applications Manager؛ از Node و Pod تا Root Cause

فرض کنید سرویس Checkout یک فروشگاه سازمانی ناگهان کند شده است. تیم زیرساخت می‌گوید همه Nodeهای Kubernetes در وضعیت Ready هستند، تیم توسعه می‌گوید Deployment بدون خطا انجام شده و Dashboard هم نشان می‌دهد بیشتر Podها Running هستند. با این حال کاربران هنوز با تأخیر و Timeout روبه‌رو هستند.

در چنین سناریویی، نگاه کردن به یک Metric مثل CPU کل کلاستر کافی نیست. ممکن است چند Pod در Restart Loop باشند، بخشی از Replicaها Ready نشده باشند، یک Node با Memory Pressure درگیر باشد، Persistent Volume کند شده باشد یا سرویس داخل Container سالم به نظر برسد اما Transactionهای واقعی در لایه Application تأخیر داشته باشند.

مانیتورینگ Kubernetes با Applications Manager زمانی ارزش پیدا می‌کند که این لایه‌ها در یک زنجیره قابل‌تحلیل کنار هم دیده شوند: Cluster، Control Plane، Node، Namespace، Deployment، ReplicaSet، Pod، Container، Storage و در نهایت Application. هدف صرفاً داشتن نمودار بیشتر نیست؛ هدف این است که وقتی سرویس کند یا ناپایدار می‌شود، تیم عملیات بتواند سریع‌تر بفهمد مشکل از کدام لایه شروع شده و چه چیزی تحت تأثیر قرار گرفته است.

در صفحه ManageEngine Applications Manager مدانت می‌توانید قابلیت‌های کلی APM، مانیتورینگ سرور، Cloud، Database و Container را ببینید. این نوشتار روی یک Intent مشخص‌تر تمرکز دارد: طراحی مانیتورینگ عملی Kubernetes و تبدیل داده‌های K8s به Root Cause قابل‌اقدام.

چرا مانیتورینگ Kubernetes با مانیتورینگ یک سرور معمولی فرق دارد؟

در معماری سنتی، ممکن است یک Application روی یک یا چند Server ثابت اجرا شود و تیم عملیات همان Hostها را برای مدت طولانی بشناسد. در Kubernetes این فرض خیلی زود از بین می‌رود. Podها موقت‌اند، Replicaها کم و زیاد می‌شوند، Scheduler محل اجرای Workload را تغییر می‌دهد و یک Deployment می‌تواند ظرف چند دقیقه چندین Container جدید بسازد یا حذف کند.

به همین دلیل سؤال «کدام Server مشکل دارد؟» دیگر کافی نیست. سؤال‌های مهم‌تر این‌ها هستند:

  • کدام Cluster یا Namespace تحت تأثیر است؟
  • آیا تعداد Replicaهای آماده با مقدار Desired برابر است؟
  • آیا Podها Pending، Failed یا در Restart Loop هستند؟
  • آیا Node ظرفیت CPU و Memory کافی دارد؟
  • آیا Resource Request و Limit درست تعریف شده‌اند؟
  • آیا Persistent Volume یا PVC عامل تأخیر است؟
  • آیا سرویس به Podهایی Traffic می‌فرستد که واقعاً Ready هستند؟
  • آیا مشکل در Infrastructure است یا در کد و Transaction داخل Application؟

مستندات رسمی ManageEngine برای Kubernetes Monitor اعلام می‌کنند که Applications Manager می‌تواند اجزایی مانند Node، Namespace، Deployment، ReplicaSet، Pod و Container را کشف کند و رابطه بین آن‌ها را برای تحلیل بهتر نمایش دهد.

اولین اصل: Cluster Health را از Application Health جدا کنید

یکی از خطاهای رایج این است که سبز بودن Cluster با سالم بودن Application یکی در نظر گرفته شود. ممکن است Kubernetes از نظر Control Plane و Nodeها سالم باشد اما یک سرویس خاص برای کاربران کند یا غیرقابل استفاده باشد.

برای همین بهتر است Dashboard عملیاتی دو سؤال مستقل را جواب بدهد:

  1. آیا خود Kubernetes سالم و دارای ظرفیت کافی است؟
  2. آیا Applicationهایی که روی Kubernetes اجرا می‌شوند واقعاً Performance و Availability مطلوب دارند؟

Applications Manager این دو نگاه را می‌تواند کنار هم قرار دهد: Metrics مربوط به K8s برای لایه Orchestration و Infrastructure، و APM/Tracing برای لایه Application. اگر از OpenTelemetry هم استفاده می‌کنید، مقاله OpenTelemetry در Applications Manager؛ رهگیری Microservice بدون Vendor Lock-in ادامه طبیعی همین معماری است.

چه لایه‌هایی را در Kubernetes باید مانیتور کنیم؟

لایه سیگنال‌های مهم نمونه مشکل
Cluster / Control Plane API Server، Scheduler، Controller، etcd، سلامت کلی کندی Scheduling یا اختلال Control Plane
Node CPU، Memory، Disk، Network، Status Memory Pressure یا Node NotReady
Deployment / Replica Desired، Available، Updated Replica کم بودن Replica آماده پس از Release
Pod Status، Restart Count، CPU/Memory، Probe CrashLoopBackOff، Pending یا NotReady
Container CPU، Memory، Status، Start Time، Image OOM، مصرف غیرعادی یا Restart
Storage PV/PVC Status، Capacity، Request، Access Mode پر شدن Volume یا PVC نامناسب
Service Mesh Latency، Error، Traffic Flow، mTLS خطای ارتباط Service-to-Service
Application Transaction، Trace، Error Rate، JVM/.NET Metrics کندی یک API یا Query بدون مشکل زیرساختی

این جدول یک نکته مهم را نشان می‌دهد: مانیتورینگ Kubernetes نباید فقط به Container CPU و Memory محدود شود. هر لایه می‌تواند علت یا اثر اختلال باشد.

Node Monitoring؛ ظرفیت کلاستر از همین‌جا شروع می‌شود

Nodeها ظرفیت واقعی اجرای Workload را فراهم می‌کنند. اگر Scheduler نتواند Pod جدید را روی هیچ Node مناسبی قرار دهد، حتی سالم بودن Deployment Definition هم کمکی نمی‌کند.

در Applications Manager باید حداقل این موارد برای Nodeها زیر نظر باشند:

  • Node Status و Availability
  • CPU Usage و ظرفیت CPU
  • Memory Usage و Memory Pressure
  • Network Traffic
  • تعداد و توزیع Podها روی Nodeها
  • میزان تخصیص Resource نسبت به ظرفیت

مستندات رسمی ManageEngine به‌طور مشخص روی CPU و Memory Nodeهای Worker و Master، تخصیص Pod و کافی بودن ظرفیت Nodeها تأکید می‌کنند. این دید برای جلوگیری از Overprovisioning و Underprovisioning هم مهم است.

Resource Request و Limit؛ Metricهایی که فقط تزئینی نیستند

در Kubernetes، Resource Request و Resource Limit مستقیماً روی Scheduling و رفتار Container اثر دارند. Kubernetes از Request برای تصمیم‌گیری درباره محل قرار گرفتن Pod استفاده می‌کند و Limit سقف مصرف Resource را مشخص می‌کند.

اگر Request بیش از حد بالا باشد، Pod ممکن است با وجود ظرفیت ظاهری کلاستر Pending بماند. اگر Request خیلی پایین باشد، Scheduler ممکن است Workload زیادی روی یک Node قرار دهد. اگر Memory Limit نامتناسب باشد، Container می‌تواند با فشار حافظه و Restart مواجه شود.

Applications Manager امکان مشاهده Resource Request و Limit در کنار مصرف واقعی Pod و Container را فراهم می‌کند. این مقایسه برای Right-sizing بسیار مفیدتر از مشاهده مصرف خام است.

مثال ساده برای Right-sizing

فرض کنید یک Container معمولاً بین 300 تا 450MiB حافظه مصرف می‌کند، اما Request آن 2GiB تعریف شده است. اگر ده‌ها Replica با همین الگو داشته باشید، Scheduler ظرفیت بسیار بیشتری از مصرف واقعی رزرو می‌کند. برعکس، اگر Limit نزدیک مصرف عادی باشد، یک Spike کوتاه می‌تواند به Restart یا اختلال منجر شود.

هدف این نیست که Request و Limit را صرفاً پایین بیاوریم؛ هدف این است که تفاوت بین «ظرفیت رزروشده»، «مصرف واقعی» و «رفتار Peak» قابل اندازه‌گیری باشد.

Pod Monitoring؛ Running همیشه به معنی سالم نیست

Pod می‌تواند Running باشد ولی Ready نباشد. همین تفاوت برای Troubleshooting حیاتی است. اگر فقط Status کلی را ببینید، ممکن است مشکل واقعی در Probe یا Dependency داخلی Application پنهان بماند.

برای Podها این سیگنال‌ها مهم‌اند:

  • Pod Status
  • Restart Count
  • CPU و Memory
  • Desired در برابر Available Pod
  • Readiness/Liveness/Startup Probe
  • Container Status
  • Namespace و Deployment مرتبط

مستندات رسمی Kubernetes توضیح می‌دهند که Readiness Probe تعیین می‌کند Pod آماده دریافت Traffic هست یا نه. در صورت Failure، Pod از Endpointهای سرویس خارج می‌شود. Liveness Probe برای تشخیص Container ناسالم و Restart آن استفاده می‌شود و Startup Probe می‌تواند جلوی اجرای زودهنگام Liveness و Readiness روی Applicationهای کند در Startup را بگیرد.

Restart Count را فقط یک عدد نبینید

یک Restart منفرد ممکن است حاصل Deploy یا Recovery طبیعی باشد، اما رشد مستمر Restart Count باید با Context بررسی شود. علت می‌تواند از Crash برنامه و OOM تا Probe اشتباه یا مشکل Node متفاوت باشد.

الگوی بهتر این است:

  1. Restart Count را تشخیص دهید.
  2. زمان Restart را با تغییرات Deployment مقایسه کنید.
  3. مصرف Memory/CPU قبل از Restart را بررسی کنید.
  4. Probe Failureها را بررسی کنید.
  5. Node میزبان را از نظر Pressure یا Failure بررسی کنید.
  6. اگر Infrastructure سالم است، وارد Trace و Application Error شوید.

این مسیر از «Pod ری‌استارت شده» به یک Root Cause قابل‌اقدام نزدیک‌تر است.

Deployment و Replica؛ Release سالم فقط یعنی Image Pull موفق نیست

بعد از یک Release جدید، بهتر است وضعیت Deployment فقط با Successful شدن Pipeline سنجیده نشود. KPIهای عملیاتی مانند Desired Replica، Updated Replica و Available Replica باید با هم مقایسه شوند.

فرض کنید Desired Replica برابر 12 است اما Available Replica برای چند دقیقه روی 8 می‌ماند. این وضعیت می‌تواند Capacity، Probe، Image، Config یا Dependency Problem را نشان دهد. اگر هم‌زمان Latency سرویس بالا برود، ارتباط بین Release و Impact بسیار محتمل‌تر می‌شود.

Applications Manager می‌تواند Deployment و Service Details را در Context کلاستر نمایش دهد تا بررسی فقط روی Podهای منفرد متوقف نشود.

Persistent Volume و PVC؛ بخشی که در Root Cause زیاد فراموش می‌شود

Applicationهای Stateful به Storage وابسته‌اند. حتی اگر Pod و Node سالم باشند، کندی یا ناسازگاری Storage می‌تواند Response Time را بالا ببرد یا Pod را در وضعیت نامطلوب نگه دارد.

طبق راهنمای فعلی ManageEngine، Kubernetes Monitor می‌تواند اطلاعاتی مانند وضعیت PV و PVC، Storage Class، Access Mode، Capacity و PVC Request را نمایش دهد.

برای سرویس‌های Database، Queue، Registry یا هر Workload Stateful بهتر است Storage Alert جداگانه داشته باشید؛ چون پر شدن Volume یا PVC نامناسب معمولاً قبل از Down شدن کامل سرویس نشانه‌هایی ایجاد می‌کند.

Control Plane را فقط در زمان بحران نگاه نکنید

API Server، Scheduler، Controller و etcd از اجزای کلیدی Control Plane هستند. اگر Scheduling کند شود یا API Server با مشکل مواجه باشد، اثر آن ممکن است ابتدا در Pending شدن Podها یا کندی عملیات Deployment دیده شود.

ManageEngine در مستندات Kubernetes Monitoring امکان مشاهده وضعیت اجزای Master و Node از جمله API Server، etcd، Scheduler و Controller را مطرح می‌کند. برای تیم Platform این داده‌ها باید بخشی از Baseline عادی باشند، نه فقط اطلاعاتی که بعد از Incident بررسی می‌شوند.

Prometheus را دور نریزید؛ Context را یکپارچه کنید

خیلی از تیم‌های Kubernetes از قبل Prometheus دارند. مهاجرت به یک ابزار Enterprise نباید الزاماً به معنی حذف همه اجزای فعلی باشد. مستندات فعلی Applications Manager از استفاده از Prometheus Metrics و Scrape Configuration موجود برای مانیتورینگ یکپارچه‌تر صحبت می‌کنند.

این رویکرد کمک می‌کند تیم Platform داده‌های Kubernetes-native را حفظ کند و در عین حال آن‌ها را کنار Server، Database، Cloud و Application Monitoring ببیند. ارزش اصلی در کاهش Tool Sprawl و افزایش Correlation است، نه صرفاً جایگزینی یک Dashboard با Dashboard دیگر.

اگر Istio دارید، Service Mesh را هم وارد مانیتورینگ کنید

در معماری Microservice، مشکل ممکن است نه در Node باشد و نه در کد سرویس مقصد؛ بلکه در مسیر ارتباط Service-to-Service، Latency، Error یا Policy مربوط به Service Mesh رخ دهد.

Applications Manager برای Istio نیز قابلیت مانیتورینگ ارائه می‌کند و طبق مستندات فعلی می‌تواند Traffic Flow، Latency، Error Rate، Resource Utilization و اطلاعات مرتبط با mTLS را در این لایه بررسی کند.

برای محیط‌هایی که Sidecar و Envoy بخش اصلی مسیر Request هستند، نادیده گرفتن Service Mesh می‌تواند Blind Spot مهمی ایجاد کند.

از Kubernetes Metric تا Transaction؛ جایی که APM مهم می‌شود

فرض کنید Node سالم است، Pod Ready است و Restart هم نداریم، اما API پرداخت هنوز کند است. در این نقطه Kubernetes Monitoring به تنهایی Root Cause را تضمین نمی‌کند.

ممکن است یک Query پایگاه‌داده کند شده باشد، Garbage Collection افزایش یافته باشد، یک Service downstream پاسخ دیر بدهد یا کد جدید مسیر Transaction را سنگین کرده باشد.

Applications Manager می‌تواند Kubernetes Monitoring را با APM و Distributed Tracing ترکیب کند. برای تیم‌هایی که Microservice دارند، این ترکیب اجازه می‌دهد از یک Container یا Deployment پرمسئله به Trace و Transaction مرتبط برسند. مقاله OpenTelemetry در Applications Manager جزئیات این مسیر را توضیح می‌دهد.

سناریوی Root Cause؛ چرا Checkout کند شده است؟

یک سناریوی فرضی را قدم‌به‌قدم بررسی کنیم. کاربران می‌گویند Checkout کند شده است.

مرحله مشاهده برداشت عملیاتی
1 Cluster Up است اختلال کامل Control Plane نداریم
2 Deployment: Desired=12، Available=8 ظرفیت واقعی سرویس کاهش یافته
3 4 Pod در Pending مسئله Scheduling یا Resource محتمل است
4 Nodeها CPU آزاد دارند اما Memory Allocated بالاست Request/Capacity باید بررسی شود
5 Podهای موجود Latency بالا دارند Traffic روی Replicaهای کمتر متمرکز شده
6 Trace نشان می‌دهد Database Call هم کند شده یک Bottleneck دوم نیز وجود دارد

در این سناریو، اگر فقط Application Latency را ببینیم، ممکن است Database را تنها مقصر بدانیم. اگر فقط Kubernetes را ببینیم، ممکن است کاهش Replica را تنها علت بدانیم. Correlation بین دو لایه تصویر واقعی‌تری می‌دهد.

EKS، GKE و AKS؛ Managed Kubernetes هم نیاز به مانیتورینگ دارد

Managed بودن Kubernetes به این معنی نیست که تمام Workload، Pod، Deployment، Resource Allocation و Application Performance خودکار سالم می‌ماند. Cloud Provider بخشی از Control Plane را مدیریت می‌کند، اما تیم شما همچنان مسئول سلامت Workload و تجربه سرویس است.

Applications Manager در مستندات فعلی از AWS EKS، Google Kubernetes Engine و Microsoft Azure Kubernetes Service در کنار Kubernetes استاندارد پشتیبانی می‌کند. برای سازمان Hybrid، مزیت مهم این است که چند Cluster در Cloudهای مختلف می‌توانند در یک نگاه عملیاتی واحد دیده شوند.

Alert را بر اساس Symptom طراحی نکنید؛ بر اساس Action طراحی کنید

اگر برای هر Spike کوتاه CPU یک Critical Alert بسازید، خیلی زود Alert Fatigue ایجاد می‌شود. Alert خوب باید به Action مشخص منتهی شود.

برای Kubernetes می‌توان Severity را بر اساس نوع Signal تفکیک کرد:

  • Warning: افزایش Restart، کاهش Headroom یا نزدیک شدن Resource به Limit.
  • Trouble: Pending Pod پایدار، Replica Gap یا PVC Problem.
  • Critical: Service Impact، Node NotReady گسترده، Deployment Availability پایین یا Failure در Business Transaction.

همچنین بهتر است Alarmها با Dependency Context ترکیب شوند. یک Pod مشکل‌دار در محیط Dev با Pod مشابه در سرویس پرداخت Production ارزش عملیاتی یکسان ندارد.

Monitoring را به Incident Management وصل کنید

وقتی Alert به Impact واقعی تبدیل می‌شود، باید از Dashboard مانیتورینگ وارد فرآیند Incident شود. این اتصال باعث می‌شود Ownership، SLA، Escalation و Timeline مشخص باشند.

برای دید گسترده‌تر درباره اتصال ITOM به ITSM، مقاله ITOM + ITSM؛ رویکرد یکپارچه برای مدیریت حوادث می‌تواند مکمل این موضوع باشد. همچنین برای مفاهیم Incident، Problem و Change می‌توانید مجموعه ITIL برای همه در ServiceDeskPlus.ir را دنبال کنید.

مدل عملیاتی بهتر این است: Applications Manager اختلال را Detect کند، تیم عملیات Root Cause را بررسی کند و اگر Impact تأیید شد، Incident با Context فنی کافی وارد Service Desk شود.

چه Dashboardهایی برای تیم‌های مختلف بسازیم؟

یک Dashboard واحد برای همه نقش‌ها معمولاً نتیجه خوبی نمی‌دهد.

برای تیم Platform

  • Cluster Health
  • Node Capacity
  • Pending/Failed Pods
  • Restart Rate
  • PV/PVC
  • Control Plane

برای تیم Application

  • Deployment Availability
  • Application Latency
  • Error Rate
  • Transaction/Trace
  • Pod/Container مرتبط با Release

برای NOC

  • Service Availability
  • Critical Alert
  • Business Service Impact
  • Top Resource Saturation
  • Incidentهای باز مرتبط

Role-based Dashboard کمک می‌کند هر تیم Signal مناسب خودش را ببیند و در عین حال منبع داده مشترک باقی بماند.

KPIهای مفید برای Kubernetes Monitoring

KPI هدف
Pod Availability اندازه‌گیری آماده بودن واقعی Workload
Restart Rate کشف Crash، OOM یا Probe Problem
Replica Gap فاصله Desired تا Available
Node Saturation کشف کمبود ظرفیت یا Allocation نامتناسب
Pending Pod Duration تشخیص Scheduling Problem
Application P95/P99 Latency سنجش تجربه سرویس فراتر از Average
Error Rate اندازه‌گیری Failure واقعی Application
MTTD زمان تا کشف اختلال
MTTR زمان تا بازیابی سرویس

هدف این KPIها تولید گزارش بیشتر نیست؛ هدف این است که تیم بفهمد آیا مانیتورینگ واقعاً Detection و Recovery را بهتر کرده است یا نه.

اشتباه‌های رایج در مانیتورینگ Kubernetes

  • فقط Node CPU و Memory را مانیتور کردن.
  • Running را معادل Ready دانستن.
  • Restart Count را بدون Timeline و Context بررسی کردن.
  • Resource Request و Limit را از Dashboard حذف کردن.
  • Persistent Volume را فقط هنگام پر شدن بررسی کردن.
  • Control Plane را فقط بعد از Incident نگاه کردن.
  • Metricهای Kubernetes را از APM و Trace جدا نگه داشتن.
  • Alertهای یکسان برای Dev و Production ساختن.
  • نادیده گرفتن Service Mesh در معماری Istio.
  • ساخت Dashboard بدون Owner و Runbook.

لایسنس Applications Manager را با تعداد Metric اشتباه نگیرید

مدل عمومی Licensing در Applications Manager بر پایه Monitor است، نه تعداد Performance Metric. در مستندات رسمی ManageEngine، یک Monitor یک Application، Server، Service یا URL مشخص است و Metricهایی مانند CPU Usage و Response Time به‌عنوان Attribute همان Monitor محاسبه می‌شوند.

از نسخه‌های جدید، Monitorها به Basic و Standard دسته‌بندی شده‌اند و طبق FAQ رسمی، Standard Monitorها با نسبت 1:1 در Licensed Monitor محاسبه می‌شوند؛ Heartbeat Monitor مدل شمارش متفاوتی دارد. برای طراحی Kubernetes Monitoring بهتر است Sizing را از روی Licensed Monitorهای واقعی در Scope انجام دهید، نه بر اساس تعداد Metricها یا یک تخمین ساده از تعداد Podها.

برای انتخاب Edition، تعداد Monitor و مدل Annual/Perpetual می‌توانید از استعلام لایسنس محصولات ManageEngine مدانت استفاده کنید. اگر معماری چندسایتی یا حجم Monitoring بالا دارید، Enterprise Edition به‌دلیل Distributed Monitoring و Scale بالاتر باید جداگانه ارزیابی شود.

Checklist پیشنهادی قبل از Rollout

  • Clusterها و Namespaceهای Production را اولویت‌بندی کنید.
  • Business Serviceهای مهم را به Workloadهای Kubernetes Map کنید.
  • Node Capacity و Resource Allocation را Baseline بگیرید.
  • Deployment و Replica Gap را Alert کنید.
  • Restart Rate و Pending Pod Duration را اندازه بگیرید.
  • Readiness، Liveness و Startup Probe را با تیم توسعه بازبینی کنید.
  • PV/PVC و Storage Capacity را وارد Monitoring کنید.
  • در صورت استفاده از Istio، Service Mesh Metrics را اضافه کنید.
  • برای Microserviceها APM یا OpenTelemetry را به K8s Monitoring متصل کنید.
  • Alertهای Production را به Runbook و Incident Process وصل کنید.
  • Role-based Dashboard برای Platform، Application و NOC بسازید.
  • بعد از Pilot، MTTD، MTTR و False Positive Rate را مقایسه کنید.

نکات کلیدی

  • سلامت Kubernetes با سلامت Application یک مفهوم نیست؛ هر دو باید مستقل و مرتبط مانیتور شوند.
  • Node، Deployment، Pod، Container، Storage و Control Plane باید در یک Context واحد دیده شوند.
  • Resource Request و Limit بخش مهم Capacity و Scheduling هستند و نباید از تحلیل حذف شوند.
  • Running بودن Pod تضمین نمی‌کند که Ready و قابل سرویس‌دهی باشد.
  • Restart Loop بدون بررسی Probe، Memory، Node و Deployment Timeline اطلاعات کافی نمی‌دهد.
  • برای Microserviceها، Correlation بین Kubernetes و Distributed Trace مسیر Root Cause را کوتاه‌تر می‌کند.
  • Applications Manager از Kubernetes استاندارد و سرویس‌های Managed مانند EKS، GKE و AKS پشتیبانی می‌کند.
  • مدل Licensing عمومی Applications Manager بر Monitor است، نه تعداد Metric.

سخن پایانی

مانیتورینگ Kubernetes زمانی بالغ می‌شود که تیم عملیات بتواند از یک نشانه ساده مثل «Checkout کند شده» به یک مسیر قابل دفاع برسد: کدام Deployment؟ کدام Replica؟ کدام Pod؟ کدام Node؟ کدام Resource Constraint؟ و در نهایت کدام Transaction یا Dependency داخل Application؟

ManageEngine Applications Manager می‌تواند لایه‌های Kubernetes را از Cluster و Node تا Pod، Container، Persistent Volume و Service Mesh در کنار APM و Distributed Tracing قرار دهد. این ترکیب برای سازمانی که می‌خواهد Tool Sprawl را کم کند و Root Cause را سریع‌تر پیدا کند، از داشتن یک Dashboard جداگانه برای هر لایه ارزش بیشتری دارد.

اگر قصد دارید Kubernetes، EKS، GKE یا AKS را در کنار Application، Database، Server و Cloud Monitoring وارد یک معماری یکپارچه کنید، درخواست دمو و مشاوره مدانت نقطه مناسبی برای بررسی Scope، Edition، Sizing لایسنس و طراحی استقرار است. مدانت خدمات لایسنس، پیاده‌سازی، آموزش، Integration و پشتیبانی Applications Manager و سایر محصولات ManageEngine را ارائه می‌کند.

منابع

مطالب مرتبط جهت افزایش سطح دانش شما:

دیدگاه شما

دیدگاه مرتبط و محترمانه بنویسید.