سرور مجازی NVMe

نظارت بر برنامه Node.js با برنامه‌های Prometheus و GrafanaMonitoring همچنان بخش مهمی از دنیای میکروسرویس است. چالش‌های مرتبط با ریزسرویس‌های نظارت معمولاً مختص اکوسیستم شما هستند و خرابی‌ها اغلب محتاطانه هستند – خرابی یک ماژول کوچک می‌تواند برای مدتی مورد توجه قرار نگیرد. اگر به یک برنامه سنتی یکپارچه نگاه کنیم، نصب شده به عنوان …

JavaScript (JS)برنامه نویسی

توسط مهران در دی ۲۶, ۱۴۰۲

سرفصلهای مطلب

زمان لازم برای مطالعه: 10 دقیقه

برنامه های کاربردی نظارت

نظارت بر برنامه‌های کاربردی همچنان بخش مهمی از برنامه است دنیای میکروسرویس. چالش‌های مرتبط با ریزسرویس‌های نظارت معمولاً مختص اکوسیستم شما هستند و خرابی‌ها اغلب محتاطانه هستند – خرابی یک ماژول کوچک می‌تواند برای مدتی مورد توجه قرار نگیرد.

اگر به یک برنامه یکپارچه سنتی تر، نصب شده به عنوان یک کتابخانه یا سرویس منفرد نگاه کنیم – خرابی ها معمولاً واضح تر هستند زیرا ماژول های آن به عنوان سرویس های مستقل اجرا نمی شوند.

در طول توسعه، نظارت اغلب در ابتدا مورد توجه قرار نمی گیرد، زیرا معمولاً موارد ضروری تری وجود دارد که باید به آنها توجه کرد. اگرچه، به محض استقرار، به خصوص اگر ترافیک برنامه شروع به افزایش کند – نظارت بر تنگناها و سلامت سیستم برای چرخش سریع در صورت شکست کاری ضروری است.

خرابی سیستم بهترین حالت برای نظارت بر برنامه های شما است. سیستم‌های توزیع‌شده پیچیده، و همچنین یکپارچه‌های عمومی، ممکن است در حالت تخریبی عمل کنند که بر عملکرد تأثیر می‌گذارد. این حالت های تخریب شده اغلب منجر به شکست های نهایی می شود. نظارت بر رفتار برنامه‌ها می‌تواند اپراتورها را از وضعیت تخریب شده قبل از وقوع خرابی کامل آگاه کند.

در این راهنما به بررسی خواهیم پرداخت پرومتئوس و گرافانا برای نظارت بر یک برنامه Node.js. ما از یک کتابخانه Node.js برای ارسال معیارهای مفید به Prometheus استفاده خواهیم کرد، که سپس آنها را برای تجسم داده ها به Grafana صادر می کند.

Prometheus – محصولی با ذهنیت DevOps

پرومتئوس یک سیستم مانیتورینگ منبع باز و عضوی از بنیاد محاسبات بومی ابری. در ابتدا به عنوان یک راه حل نظارت داخلی برای ایجاد شد SoundCloud، اما اکنون توسط یک توسعه دهنده و کاربر نگهداری می شود انجمن.

ویژگی های پرومتئوس

برخی از ویژگی های کلیدی پرومتئوس عبارتند از:

Prometheus معیارها را از سرور یا دستگاه با کشیدن نقاط پایانی متریک آنها روی HTTP در یک بازه زمانی از پیش تعریف شده جمع آوری می کند.
آ مدل داده سری زمانی چند بعدی. به عبارت ساده‌تر – داده‌های سری زمانی را برای ویژگی‌ها/متریک‌های مختلف (ابعاد) نگه می‌دارد.
این یک زبان پرس و جو عملکردی اختصاصی را ارائه می دهد که به عنوان شناخته می شود PromQL (زبان پرس و جو Prometheus). PromQL را می توان برای انتخاب و تجمیع داده ها استفاده کرد.
Pushgateway – یک حافظه پنهان معیارها، که برای ذخیره معیارهای کارهای دسته‌ای ایجاد شده است که عمر کوتاه آن معمولاً غیرقابل اعتماد یا غیرممکن کردن آن‌ها در فواصل زمانی منظم بر روی HTTP است.
یک رابط کاربری وب برای اجرای عبارات PromQL و تجسم نتایج در یک جدول یا نمودار در طول زمان.
همچنین ویژگی های هشدار برای ارسال هشدار به یک را فراهم می کند مدیر هشدار روی مطابق با یک قانون تعریف شده و ارسال اعلان ها از طریق ایمیل یا سایر سیستم عامل ها.
جامعه تعداد زیادی شخص ثالث را حفظ می کند صادرکنندگان و ادغام کنندگان که به کشیدن معیارها کمک می کند.

نمودار معماری

اعتبار: Prometheus.io

معرفی کردن پروم-مشتری

پرومتئوس می دود روی سرور خودش برای اتصال برنامه خود به سرور Prometheus، باید از a صادر کننده معیارها، و معیارها را در معرض دید قرار دهید تا پرومتئوس بتواند آنها را از طریق HTTP بکشد.

ما تکیه خواهیم کرد روی را پروم-مشتری کتابخانه به export معیارهای برنامه ما از صادرات داده های مورد نیاز برای تولید هیستوگرام، خلاصه، سنج و شمارنده پشتیبانی می کند.

در حال نصب پروم-مشتری

ساده ترین راه برای نصب prom-client ماژول از طریق npm:

$ npm install prom-client

افشای معیارهای پیش‌فرض Prometheus با پروم-مشتری

تیم پرومتئوس مجموعه ای از توصیه شده متریک برای پیگیری، که prom-client در نتیجه شامل به عنوان معیارهای پیش فرض، که از طریق مشتری قابل دریافت است collectDefaultMetrics().

اینها، در میان سایر معیارها، اندازه حافظه مجازی، تعداد توصیفگرهای فایل باز، کل زمان صرف شده CPU و غیره هستند:

const client = require('prom-client');

// Create a Registry to register the metrics
const register = new client.Registry();
client.collectDefaultMetrics({register});

ما معیارهای جمع آوری شده در a را پیگیری می کنیم Registry – بنابراین هنگام جمع‌آوری معیارهای پیش‌فرض از مشتری، از آن عبور می‌کنیم Registry نمونه، مثال. همچنین می‌توانید گزینه‌های سفارشی‌سازی دیگر را در collectDefaultMetrics() زنگ زدن:

const client = require('prom-client');

// Create a Registry to register the metrics
const register = new client.Registry();

client.collectDefaultMetrics({
    app: 'node-application-monitoring-app',
    prefix: 'node_',
    timeout: 10000,
    gcDurationBuckets: (0.001, 0.01, 0.1, 1, 2, 5),
    register
});

در اینجا، ما نام برنامه خود را اضافه کرده ایم، a prefix برای معیارهای سهولت ناوبری، الف timeout پارامتری برای تعیین زمان درخواست مهلت زمانی و همچنین الف gcDurationBuckets که تعیین می کند سطل ها چقدر باید برای آن باشند هیستوگرام جمع آوری زباله.

جمع آوری سایر معیارها از همین الگو پیروی می کند – ما آنها را از طریق client و سپس آنها را در رجیستری ثبت کنید. بیشتر روی این بعدا

هنگامی که معیارها در رجیستر قرار گرفتند، می توانیم آنها را برگردانیم از جانب ثبت نام روی نقطه پایانی که پرومتئوس از آن خارج خواهد شد. بیایید یک سرور HTTP ایجاد کنیم و a را در معرض نمایش قرار دهیم /metrics نقطه پایانی که مقدار را برمی گرداند metrics() از register هنگام ضربه زدن:

const client = require('prom-client');
const express = require('express');
const app = express();

// Create a registry and pull default metrics
// ...

app.get('/metrics', async (req, res) => {
    res.setHeader('Content-Type', register.contentType);
    res.send(await register.metrics());
});

app.listen(8080, () => console.log('Server is running روی http://localhost:8080, metrics are exposed روی http://localhost:8080/metrics'));

ما از Express.js برای نمایش یک نقطه پایانی در پورت استفاده کرده‌ایم 8080، که هنگام ضربه زدن با a GET درخواست معیارها را از رجیستری برمی گرداند. از آنجا که metrics() برمی گرداند a Promise، ما استفاده کرده ایم async/await نحو برای بازیابی نتایج.

اگر با Express.js آشنایی ندارید – راهنمای ما برای ساختن API REST با Node.js و Express را بخوانید.

بیایید جلو برویم و a را بفرستیم curl درخواست به این نقطه پایانی:

$ curl -GET localhost:8080/metrics

# HELP node_process_cpu_user_seconds_total Total user CPU time spent in seconds.
# TYPE node_process_cpu_user_seconds_total counter
node_process_cpu_user_seconds_total 0.019943

# HELP node_process_cpu_system_seconds_total Total system CPU time spent in seconds.
# TYPE node_process_cpu_system_seconds_total counter
node_process_cpu_system_seconds_total 0.006524

# HELP node_process_cpu_seconds_total Total user and system CPU time spent in seconds.
# TYPE node_process_cpu_seconds_total counter
node_process_cpu_seconds_total 0.026467

# HELP node_process_start_time_seconds Start time of the process since unix epoch in seconds.
...

معیارها عبارتند از a دسته از معیارهای مفید، که هر کدام از طریق نظرات توضیح داده شده است. اگرچه، بازگشت به بیانیه از مقدمه – در بسیاری از موارد، نیازهای نظارتی شما ممکن است مختص اکوسیستم باشد. خوشبختانه، شما انعطاف کاملی دارید تا معیارهای سفارشی خود را نیز به نمایش بگذارید.

افشای معیارهای سفارشی با پروم-مشتری

اگرچه افشای معیارهای پیش‌فرض نقطه شروع خوبی برای درک چارچوب و همچنین برنامه شما است – در برخی مواقع، ما نیاز به تعریف معیارهای سفارشی برای استفاده از یک چشم شاهین در چند جریان درخواست خواهیم داشت.

بیایید معیاری ایجاد کنیم که مدت زمان درخواست HTTP را پیگیری کند. برای شبیه سازی یک عملیات سنگین روی یک نقطه پایانی خاص، ما یک عملیات ساختگی ایجاد می کنیم که 3-6 ثانیه طول می کشد تا یک پاسخ را بازگرداند. ما یک هیستوگرام از زمان های پاسخ و توزیعی که آنها دارند را تجسم خواهیم کرد. ما همچنین مسیرها و کدهای بازگشت آنها را در نظر خواهیم گرفت.

برای ثبت و پیگیری معیارهایی مانند این – ما یک معیار جدید ایجاد خواهیم کرد Histogram و استفاده کنید startTimer() روش شروع تایمر نوع بازگشت از startTimer() متد تابع دیگری است که می توانید به آن فراخوانی کنید رعایت کنید (ورود) معیارهای ثبت شده و پایان دادن به تایمر، برچسب هایی را که می خواهید معیارهای هیستوگرام را با آنها مرتبط کنید، بگذرانید.

شما می توانید به صورت دستی observe() مقادیر، با این حال، فراخوانی روش بازگشتی ساده تر و تمیزتر است.

بیایید ابتدا پیش برویم و یک سفارشی ایجاد کنیم Histogram برای این:

// Create a custom histogram metric
const httpRequestTimer = new client.Histogram({
  name: 'http_request_duration_seconds',
  help: 'Duration of HTTP requests in seconds',
  labelNames: ('method', 'route', 'code'),
  buckets: (0.1, 0.3, 0.5, 0.7, 1, 3, 5, 7, 10) // 0.1 to 10 seconds
});

// Register the histogram
register.registerMetric(httpRequestTimer);

توجه داشته باشید: را buckets صرفاً برچسب هایی برای هیستوگرام ما هستند و به طول درخواست ها اشاره می کنند. اگر درخواستی کمتر از 0.1 ثانیه برای اجرا، متعلق به 0.1 سطل

هر بار که بخواهیم برخی از درخواست ها را زمان بندی کنیم و توزیع آنها را ثبت کنیم، به این نمونه اشاره خواهیم کرد. اجازه دهید aa delay handler را نیز تعریف کنیم، که پاسخ را به تاخیر می اندازد و در نتیجه یک عملیات سنگین را شبیه سازی می کند:

// Mock slow endpoint, waiting between 3 and 6 seconds to return a response
const createDelayHandler = async (req, res) => {
  if ((Math.floor(Math.random() * 100)) === 0) {
    throw new Error('Internal Error')
  }
  // Generate number between 3-6, then delay by a factor of 1000 (miliseconds)
  const delaySeconds = Math.floor(Math.random() * (6 - 3)) + 3
  await new Promise(res => setTimeout(res, delaySeconds * 1000))
  res.end('Slow url accessed!');
};

در نهایت، ما می توانیم خود را تعریف کنیم /metrics و /slow نقاط پایانی، که یکی از آنها از کنترل کننده تاخیر برای به تاخیر انداختن پاسخ ها استفاده می کند. هر یک از اینها با ما زمان بندی می شود httpRequestTimer به عنوان مثال، و ثبت نام شده است:

// Prometheus metrics route
app.get('/metrics', async (req, res) => {
  // Start the HTTP request timer, saving a reference to the returned method
  const end = httpRequestTimer.startTimer();
  // Save reference to the path so we can record it when ending the timer
  const route = req.route.path;
    
  res.setHeader('Content-Type', register.contentType);
  res.send(await register.metrics());

  // End timer and add labels
  end({ route, code: res.statusCode, method: req.method });
});

// 
app.get('/slow', async (req, res) => {
  const end = httpRequestTimer.startTimer();
  const route = req.route.path;
  await createDelayHandler(req, res);
  end({ route, code: res.statusCode, method: req.method });
});

// Start the Express server and listen to a port
app.listen(8080, () => {
  console.log('Server is running روی http://localhost:8080, metrics are exposed روی http://localhost:8080/metrics')
});

در حال حاضر، هر بار که ما یک درخواست را به /slow نقطه پایانی یا /metrics نقطه پایانی – مدت زمان درخواست ثبت شده و به رجیستری Prometheus اضافه می شود. اتفاقا ما هم در معرض گذاشتن این معیارها روی را /metrics نقطه پایانی بیایید یک را بفرستیم GET درخواست به /slow و سپس مشاهده کنید /metrics از نو:

$ curl -GET localhost:8080/slow
Slow url accessed!

$ curl -GET localhost:8080/metrics
# HELP http_request_duration_seconds Duration of HTTP requests in seconds
# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{le="0.1",route="/metrics",code="200",method="GET"} 1
http_request_duration_seconds_bucket{le="0.3",route="/metrics",code="200",method="GET"} 1
http_request_duration_seconds_bucket{le="0.5",route="/metrics",code="200",method="GET"} 1
http_request_duration_seconds_bucket{le="0.7",route="/metrics",code="200",method="GET"} 1
http_request_duration_seconds_bucket{le="1",route="/metrics",code="200",method="GET"} 1
http_request_duration_seconds_bucket{le="3",route="/metrics",code="200",method="GET"} 1
http_request_duration_seconds_bucket{le="5",route="/metrics",code="200",method="GET"} 1
http_request_duration_seconds_bucket{le="7",route="/metrics",code="200",method="GET"} 1
http_request_duration_seconds_bucket{le="10",route="/metrics",code="200",method="GET"} 1
http_request_duration_seconds_bucket{le="+Inf",route="/metrics",code="200",method="GET"} 1
http_request_duration_seconds_sum{route="/metrics",code="200",method="GET"} 0.0042126
http_request_duration_seconds_count{route="/metrics",code="200",method="GET"} 1
http_request_duration_seconds_bucket{le="0.1",route="/slow",code="200",method="GET"} 0
http_request_duration_seconds_bucket{le="0.3",route="/slow",code="200",method="GET"} 0
http_request_duration_seconds_bucket{le="0.5",route="/slow",code="200",method="GET"} 0
http_request_duration_seconds_bucket{le="0.7",route="/slow",code="200",method="GET"} 0
http_request_duration_seconds_bucket{le="1",route="/slow",code="200",method="GET"} 0
http_request_duration_seconds_bucket{le="3",route="/slow",code="200",method="GET"} 0
http_request_duration_seconds_bucket{le="5",route="/slow",code="200",method="GET"} 0
http_request_duration_seconds_bucket{le="7",route="/slow",code="200",method="GET"} 1
http_request_duration_seconds_bucket{le="10",route="/slow",code="200",method="GET"} 1
http_request_duration_seconds_bucket{le="+Inf",route="/slow",code="200",method="GET"} 1
http_request_duration_seconds_sum{route="/slow",code="200",method="GET"} 5.0022148
http_request_duration_seconds_count{route="/slow",code="200",method="GET"} 1

هیستوگرام دارای چندین سطل است و ردیابی آن را حفظ می کند route، code و method ما برای دسترسی به یک نقطه پایانی استفاده کرده ایم. طول کشید 0.0042126 ثانیه برای دسترسی /metrics، اما فوق العاده 5.0022148 برای دسترسی به /slow نقطه پایانی در حال حاضر، حتی اگر این یک گزارش بسیار کوچک است، پیگیری یک درخواست تنها به دو نقطه پایانی – خیلی آسان نیست روی چشمها. انسان ها در هضم حجم عظیمی از اطلاعات مانند این عالی نیستند – بنابراین بهتر است در عوض به تجسم این داده ها مراجعه کنید.

برای انجام این کار، استفاده خواهیم کرد گرافانا برای مصرف معیارها از /metrics نقطه پایانی و آنها را تجسم کنید. گرافانا، بسیار شبیه پرومتئوس، می دود روی سرور خود را، و یک راه آسان برای بالا بردن هر دوی آنها در کنار برنامه Node.js ما از طریق a Docker Compose Cluster.

تنظیم خوشه Docker Compose

بیایید با ایجاد یک شروع کنیم docker-compose.yml فایلی که از آن استفاده می کنیم تا به داکر اطلاع دهیم که چگونه راه اندازی شود و پورت های مربوطه را برای سرور Node.js، سرور Prometheus و سرور Grafana در معرض دید قرار دهد. از آنجایی که Prometheus و Grafana به عنوان تصاویر Docker در دسترس هستند، می‌توانیم مستقیماً تصاویر آنها را از Docker Hub بیرون بکشیم:

version: '2.1'
networks:
  monitoring:
    driver: bridge
volumes:
    prometheus_data: {}
    grafana_data: {}
services:
  prometheus:
    image: prom/prometheus:v2.20.1
    container_name: prometheus
    volumes:
      - ./prometheus:/etc/prometheus
      - prometheus_data:/prometheus
    ports:
      - 9090:9090
    expose:
      - 9090
    networks:
      - monitoring
  grafana:
    image: grafana/grafana:7.1.5
    container_name: grafana
    volumes:
      - grafana_data:/var/lib/grafana
      - ./grafana/provisioning:/etc/grafana/provisioning
    environment:
      - GF_AUTH_DISABLE_LOGIN_FORM=true
      - GF_AUTH_ANONYMOUS_ENABLED=true
      - GF_AUTH_ANONYMOUS_ORG_ROLE=Admin
    ports:
      - 3000:3000
    expose:
      - 3000
    networks:
      - monitoring
  node-application-monitoring-app:
    build:
      context: node-application-monitoring-app
    ports:
      - 8080:8080
    expose:
      - 8080
    networks:
      - monitoring

برنامه Node در حال نمایش است روی بندر 8080، گرافانا در معرض دید قرار می گیرد روی 3000 و پرومتئوس افشا می شود روی 9090. از طرف دیگر، می توانید ما را شبیه سازی کنید GitHub مخزن:

$ git clone https://github.com/rasanegar/node-prometheus-grafana.git

همچنین اگر مطمئن نیستید که کدام فایل های پیکربندی قرار است در کدام دایرکتوری ها قرار گیرند، می توانید به مخزن مراجعه کنید.

همه کانتینرهای docker را می توان به طور همزمان با استفاده از docker-compose فرمان به عنوان یک پیش نیاز، چه بخواهید host این خوشه روی یک ماشین ویندوز، مک یا لینوکس، موتور داکر و Docker Compose نیاز به نصب دارند.

پس از نصب می توانید دستور زیر را در پروژه اجرا کنید root فهرست راهنما:

$ docker-compose up -d

پس از اجرای این دستور، سه برنامه در پس‌زمینه اجرا می‌شوند – یک سرور Node.js، یک رابط وب و سرور Prometheus و همچنین رابط کاربری Grafana.

پیکربندی Prometheus برای Scrape Metrics

پرومتئوس نقطه پایانی مربوطه را در بازه‌های زمانی مشخص می‌خراشد. برای دانستن زمان خراشیدن، و همچنین جایی که، ما باید یک فایل پیکربندی ایجاد کنیم – prometheus.yml:

global:
  scrape_interval: 5s
scrape_configs:
  - job_name: "node-application-monitoring-app"
    static_configs:
      - targets: ("docker.host:8080")

توجه داشته باشید: docker.host باید با نام میزبان واقعی سرور Node.js که در آن پیکربندی شده است جایگزین شود docker-compose فایل YAML.

در اینجا، ما برنامه‌ریزی کرده‌ایم که معیارها را هر 5 ثانیه یکبار خراش دهد. تنظیم جهانی به طور پیش فرض 15 ثانیه است، بنابراین ما آن را کمی بیشتر کرده ایم. نام شغل برای راحتی ما و شناسایی برنامه ای است که در حال نگهداری آن هستیم روی. در نهایت، /metrics نقطه پایانی هدف چیزی است که پرومتئوس به آن نگاه خواهد کرد روی.

پیکربندی داده ها Source برای گرافانا

در حالی که ما در حال پیکربندی Prometheus هستیم – اجازه دهید a نیز ایجاد کنیم منبع اطلاعات برای گرافانا همانطور که قبلا ذکر شد، و همانطور که بیشتر توضیح داده خواهد شد – داده ها را از یک منبع داده می پذیرد و آن را تجسم می کند. البته، این منابع داده باید با برخی از پروتکل ها و استانداردها مطابقت داشته باشند.

را datasources.yml فایل پیکربندی همه منابع داده Grafana را در خود جای داده است. ما فقط یکی داریم – سرور Prometheus ما، در معرض روی بندر 9090:

apiVersion: 1

datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    orgId: 1
    url: http://docker.prometheus.host:9090
    basicAuth: false
    isDefault: true
    editable: true

توجه داشته باشید: docker.prometheus.host قرار است با نام میزبان واقعی Prometheus که در پیکربندی شده است جایگزین شود docker-compose فایل YAML.

شبیه سازی ترافیک درجه تولید

در نهایت، اگر مقداری ترافیک مصنوعی ایجاد کنیم، مشاهده نتایج آسان‌تر خواهد بود روی برنامه. شما به سادگی می توانید صفحات را چندین بار بارگیری مجدد کنید یا درخواست های زیادی ارسال کنید، اما از آنجایی که انجام این کار به صورت دستی زمان بر است – می توانید از هر یک از موارد استفاده کنید. ابزارهای مختلف مانند ApacheBench، Ali، API Bench و غیره.

برنامه Node.js ما از این استفاده خواهد کرد پروم-مشتری برای ورود به سیستم و ارسال آنها به سرور Prometheus. تنها چیزی که باقی می ماند این است که از Grafana برای تجسم آنها استفاده کنید.

Grafana – یک داشبورد با تنظیم آسان

گرافانا یک پلت فرم تحلیلی است که برای نظارت و تجسم انواع معیارها استفاده می شود. این به شما امکان می‌دهد پرس و جوهای سفارشی را برای منابع داده خود اضافه کنید، تجسم کنید، هشدار دهید روی و معیارهای خود را بدون توجه به جایی که ذخیره می شوند درک کنید. می توانید داشبوردهایی ایجاد کنید، کاوش کنید و با تیم خود به اشتراک بگذارید و فرهنگ داده محور را تقویت کنید.

Grafana داده ها را از منابع داده های مختلف جمع آوری می کند و Prometheus تنها یکی از آنهاست.

داشبوردهای مانیتورینگ گرافانا

چند داشبورد خارج از جعبه بسته بندی شده اند تا یک نمای کلی از آنچه در حال انجام است ارائه دهند روی. را داشبورد برنامه NodeJS معیارهای پیش فرض را جمع آوری می کند و آنها را تجسم می کند:

را معیارهای برنامه سطح بالا داشبورد معیارهای سطح بالا را برای برنامه Node.js با استفاده از معیارهای پیش‌فرض مانند میزان خطا، استفاده از CPU، استفاده از حافظه و غیره نشان می‌دهد:

را داشبورد جریان را درخواست کنید معیارهای جریان درخواست را با استفاده از API هایی که در برنامه Node.js ایجاد کرده ایم نشان می دهد. یعنی، اینجا جایی است که Histogram ما ایجاد کرده ایم تا بدرخشد:

نمودار استفاده از حافظه

به‌جای داشبوردهای خارج از جعبه، می‌توانید تجمیع‌هایی را نیز برای محاسبه معیارهای مختلف ایجاد کنید. به عنوان مثال، ما می توانیم میزان مصرف حافظه را در طول زمان از طریق:

avg(node_nodejs_external_memory_bytes / 1024) by (route)

نمودار هیستوگرام درخواست در ثانیه

یا، می‌توانیم نموداری را رسم کنیم که درخواست‌ها را در هر ثانیه نمایش می‌دهد (در فواصل زمانی ۲ دقیقه)، با استفاده از داده‌های جمع‌آورنده داده خودمان:

sum(rate(http_request_duration_seconds_count(2m)))

نتیجه

Prometheus و Grafana ابزارهای منبع باز قدرتمندی برای نظارت بر برنامه ها هستند. با یک جامعه فعال و تعداد زیادی کتابخانه مشتری و ادغام، تعداد کمی از کدها بینش بسیار منظم و تمیزی را در مورد سیستم ارائه می دهند.

(برچسب‌ها برای ترجمه)# جاوا اسکریپت

منتشر شده در 1403-01-16 01:28:04

امتیاز شما به این مطلب