Sentry Performance برای وردپرس (WordPress) یک راهکار پایش عملکرد در سطح کد است که با نصب SDK رسمی Sentry روی سایت، خطاها، تراکنش‌های کند، کوئری‌های سنگین و رفتار کاربران واقعی را در لحظه ثبت و تحلیل می‌کند. برخلاف ابزارهای سنتی که فقط خطاها را لاگ می‌کنند، Sentry Performance با تمرکز بر Performance Monitoring و Distributed Tracing به توسعه‌دهنده نشان می‌دهد که کدام بخش از کد، کدام کوئری دیتابیس یا کدام درخواست HTTP، بیشترین زمان را مصرف می‌کند. در سایت‌های وردپرسی، این ابزار می‌تواند کشف کند که کدام افزونه در حال کند کردن سایت است، کدام هوک زمان پاسخ را افزایش می‌دهد و کدام درخواست API خارجی باعث timeout می‌شود. ترکیب Sentry با APMهای سنتی و ابزارهای پروفایلینگ PHP، یک لایه پایش دقیق و مکمل می‌سازد. در این نوشتار، معماری Sentry، نحوه نصب و پیکربندی آن در وردپرس، الگوهای Tracing، تحلیل داده‌ها و نکات پیشرفته بررسی می‌شود.

Sentry Performance برای وردپرس یکی از آن ابزارهایی است که پس از راه‌اندازی، دیدگاه کاملاً متفاوتی از سایت به توسعه‌دهنده می‌دهد. تا قبل از نصب، بسیاری از مشکلات عملکردی حدس و گمان هستند. پس از نصب، هر کوئری کند، هر درخواست HTTP خارجی و هر هوک زمان‌بر، قابل مشاهده می‌شود. در پروژه‌هایی که با سایت‌های پربازدید و افزونه‌های متعدد کار می‌کنند، این ابزار تفاوت بین عیب‌یابی مبتنی بر حدس و عیب‌یابی مبتنی بر داده را می‌سازد.

Sentry چیست و چه تفاوتی با ابزارهای سنتی دارد؟

Sentry یک پلتفرم متن‌باز برای پایش خطا (Error Monitoring) و عملکرد (Performance Monitoring) است که در سال ۲۰۰۸ میلادی به‌عنوان یک پروژه جانبی آغاز شد و امروز به یک اکوسیستم کامل تبدیل شده است. این پلتفرم از زبان‌ها و فریم‌ورک‌های متعددی پشتیبانی می‌کند: PHP، JavaScript، Python، Ruby، Java، Go، Rust، .NET و بسیاری دیگر.

تفاوت بنیادین Sentry با ابزارهای سنتی لاگ‌گیری در سه محور اصلی خلاصه می‌شود:

  • زمینه (Context): Sentry نه فقط خطا، بلکه اطلاعات زمینه‌ای مانند کاربر، نسخه، URL، مرورگر، سرور و stack trace کامل را ثبت می‌کند.
  • عملکرد (Performance): Sentry فقط خطاها را رصد نمی‌کند، بلکه زمان پاسخ درخواست‌ها، کوئری‌های دیتابیس و درخواست‌های HTTP را نیز اندازه‌گیری می‌کند.
  • تحلیل (Analytics): Sentry داده‌ها را گروه‌بندی، اولویت‌بندی و روند‌یابی می‌کند و به تیم اجازه می‌دهد بر مشکلات مهم تمرکز کند.

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

Sentry یک ابزار لاگ‌گیری نیست، یک ابزار درک سیستم است. تفاوت آن در این است که به شما نشان می‌دهد چرا یک مشکل رخ می‌دهد، نه فقط اینکه رخ داده است.

برای مطالعه بیشتر درباره ابزارهای توسعه وردپرس، مقاله بهترین ابزارهای توسعه وب را ببینید.

Sentry Performance در مقابل APM سنتی

ابزارهای APM (Application Performance Monitoring) سنتی مانند New Relic، Datadog و Dynatrace سال‌هاست در صنعت نرم‌افزار استفاده می‌شوند. Sentry Performance در برخی جنبه‌ها مشابه و در برخی جنبه‌ها متفاوت است:

ویژگیSentry PerformanceAPM سنتی
تمرکز اصلیخطا + عملکردعملکرد + زیرساخت
هزینهمتن‌باز + پلن‌های مقرون‌به‌صرفهمعمولاً گران
راه‌اندازیساده با SDKنیازمند عامل (Agent)
Distributed Tracingبلهبله
پایش زیرساختمحدودکامل
پایش خطای فرانت‌اندعالیمعمولاً ضعیف
مناسب برایتیم‌های محصول و توسعهتیم‌های SRE و زیرساخت

در پروژه‌های وردپرسی، Sentry معمولاً انتخاب اول است، زیرا راه‌اندازی آن ساده‌تر است و تمرکز آن بر خطا و عملکرد کد، دقیقاً همان چیزی است که تیم توسعه به آن نیاز دارد. APMهای سنتی برای پایش سرور و زیرساخت مفیدند، اما در سطح کد، Sentry بینش عمیق‌تری ارائه می‌دهد.

برای مطالعه بیشتر درباره عملکرد سرور، مقاله مانیتورینگ سرور دقیقاً چگونه انجام می‌شود؟ را ببینید.

معماری Sentry و اجزای اصلی

برای استفاده مؤثر از Sentry، درک معماری آن ضروری است. Sentry از چند جزء اصلی تشکیل شده که هرکدام نقش مشخصی دارند.

Sentry SDK و نقش آن در وردپرس

Sentry SDK یک کتابخانه سبک است که در اپلیکیشن نصب می‌شود و رویدادها را به سرور Sentry ارسال می‌کند. در وردپرس، دو SDK اصلی استفاده می‌شوند:

  • sentry/sentry (PHP SDK): برای ثبت خطاها و تراکنش‌های سمت سرور.
  • @sentry/browser (JavaScript SDK): برای ثبت خطاها و تراکنش‌های سمت مرورگر.

هر SDK شامل یک DSN (Data Source Name) است که آدرس سرور Sentry و کلید پروژه را مشخص می‌کند. DSN به‌صورت زیر است:

https://public_key@o123456.ingest.sentry.io/1234567

DSN در کد پیکربندی می‌شود و SDK از آن برای ارسال رویدادها استفاده می‌کند.

Traces و Spans در Distributed Tracing

Distributed Tracing مفهوم مرکزی Sentry Performance است. در این مدل:

  • Transaction: یک واحد کار بزرگ (مانند یک درخواست HTTP کامل) را نشان می‌دهد.
  • Span: یک عملیات کوچک‌تر درون transaction (مانند یک کوئری SQL یا یک فراخوانی HTTP) را نشان می‌دهد.
  • Trace: مجموعه‌ای از transactionها که با یک شناسه (trace ID) به هم مرتبط‌اند.

در وردپرس، یک transaction می‌تواند یک بارگذاری صفحه باشد و spanها شامل کوئری‌های دیتابیس، درخواست‌های HTTP خارجی، اجرای هوک‌ها و رندر قالب هستند. این ساختار سلسله‌مراتبی، امکان شناسایی دقیق گلوگاه‌ها را فراهم می‌کند.

Transaction: GET /wp-admin/
├── Span: bootstrap (50ms)
├── Span: plugin_loaded (200ms)
├── Span: init (300ms)
│   ├── Span: SQL query (10ms)
│   ├── Span: HTTP request to external API (1500ms) ← گلوگاه
│   └── Span: SQL query (5ms)
└── Span: render (150ms)

در این مثال، درخواست HTTP خارجی با ۱۵۰۰ میلی‌ثانیه، گلوگاه اصلی است. بدون Distributed Tracing، شناسایی این گلوگاه تقریباً غیرممکن است.

Sample Rate و مدیریت حجم داده

ارسال همه تراکنش‌ها به Sentry می‌تواند هزینه بالا و حجم داده زیاد ایجاد کند. برای مدیریت این موضوع، Sentry از Sample Rate استفاده می‌کند:

$traces_sample_rate = 0.1; // 10% از تراکنش‌ها

مقدار 0.1 یعنی ۱۰٪ از تراکنش‌ها به Sentry ارسال می‌شوند. این رویکرد، حجم داده را کنترل می‌کند و در عین حال امکان تحلیل آماری را فراهم می‌کند. در سایت‌های پرترافیک، مقدار ۰.۰۱ تا ۰.۱ معمولاً کافی است.

نکته مهم: Sample Rate روی خطاها اعمال نمی‌شود. خطاها همیشه ثبت می‌شوند. Sample Rate فقط روی تراکنش‌های عملکردی اعمال می‌شود.

نصب و پیکربندی Sentry در وردپرس

نصب Sentry در وردپرس چند روش دارد که هرکدام مزایا و محدودیت‌های خاص خود را دارند.

استفاده از Sentry PHP SDK

روش توصیه‌شده، نصب SDK از طریق Composer است:

composer require sentry/sentry

سپس در فایل wp-config.php یا یک MU-Plugin، پیکربندی انجام می‌شود:

require_once __DIR__ . '/vendor/autoload.php';

\Sentry\init([
    'dsn' => 'https://public_key@o123456.ingest.sentry.io/1234567',
    'traces_sample_rate' => 0.1,
    'profiles_sample_rate' => 0.1,
    'environment' => defined('WP_ENVIRONMENT_TYPE') ? WP_ENVIRONMENT_TYPE : 'production',
    'release' => 'my-site@' . get_option('my_site_version', '1.0.0'),
    'before_send' => function(\Sentry\Event $event, $hint) {
        // فیلتر کردن رویدادهای غیرضروری
        return $event;
    },
]);

این پیکربندی چند نکته کلیدی را نشان می‌دهد:

  • traces_sample_rate: نرخ نمونه‌گیری برای تراکنش‌ها.
  • profiles_sample_rate: نرخ نمونه‌گیری برای پروفایلینگ (در پلن‌های بالاتر).
  • environment: تفکیک محیط‌ها (development، staging، production).
  • release: نسخه‌بندی برای ردیابی تغییرات.
  • before_send: فیلتر کردن رویدادها قبل از ارسال.

برای مطالعه بیشتر درباره Composer، مقاله Composer برای مدیریت وابستگی وردپرس را ببینید.

افزونه رسمی Sentry برای وردپرس

افزونه wp-sentry-integration یک راه‌حل آماده است که SDK را در وردپرس ادغام می‌کند:

wp plugin install wp-sentry-integration --activate

پس از نصب، DSN را در wp-config.php تعریف کنید:

define('WP_SENTRY_PHP_DSN', 'https://public_key@o123456.ingest.sentry.io/1234567');
define('WP_SENTRY_BROWSER_DSN', 'https://public_key@o123456.ingest.sentry.io/7654321');
define('WP_SENTRY_ENV', 'production');
define('WP_SENTRY_TRACES_SAMPLE_RATE', 0.1);
define('WP_SENTRY_ERROR_TYPES', E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED);

این افزونه مزایای متعددی دارد: راه‌اندازی ساده، پشتیبانی از JavaScript، ادغام با هوک‌های وردپرس و امکان فیلتر رویدادها.

Sentry JavaScript برای فرانت‌اند

برای پایش خطاها و عملکرد سمت مرورگر، باید Sentry JavaScript نیز نصب شود:

add_action('wp_enqueue_scripts', function() {
    wp_enqueue_script(
        'sentry-browser',
        'https://browser.sentry-cdn.com/7.x.x/bundle.tracing.min.js',
        array(),
        null,
        true
    );
    
    wp_add_inline_script('sentry-browser', "
        Sentry.init({
            dsn: 'https://public_key@o123456.ingest.sentry.io/7654321',
            tracesSampleRate: 0.1,
            environment: 'production',
            release: 'my-site@1.0.0'
        });
    ");
});

این کد، SDK مرورگر را بارگذاری می‌کند و تراکنش‌های فرانت‌اند را نیز پایش می‌کند. این داده‌ها در Sentry با داده‌های سرور ادغام می‌شوند و یک تصویر کامل از عملکرد سایت ارائه می‌دهند.

پایش عملکرد در Sentry

بخش اصلی Sentry Performance، پایش تراکنش‌ها و spanهاست. در وردپرس، این پایش در چند سطح انجام می‌شود.

Transactions و اندازه‌گیری زمان پاسخ

هر درخواست HTTP به وردپرس می‌تواند به‌عنوان یک transaction ثبت شود. برای پیکربندی، می‌توان از hook init استفاده کرد:

add_action('init', function() {
    if (!function_exists('\Sentry\startTransaction')) {
        return;
    }
    
    $transaction = \Sentry\startTransaction([
        'name' => $_SERVER['REQUEST_URI'] ?? 'unknown',
        'op' => 'http.server',
        'description' => $_SERVER['REQUEST_METHOD'] . ' ' . ($_SERVER['REQUEST_URI'] ?? '/'),
    ]);
    
    \Sentry\SentrySdk::getCurrentHub()->setSpan($transaction);
});

add_action('shutdown', function() {
    $transaction = \Sentry\SentrySdk::getCurrentHub()->getSpan();
    if ($transaction !== null) {
        $transaction->finish();
    }
}, 999);

این کد، هر درخواست HTTP را به‌عنوان یک transaction ثبت می‌کند و زمان پاسخ کامل را اندازه‌گیری می‌کند. داده‌ها در داشبورد Sentry با جزئیات قابل مشاهده هستند.

Spans و شناسایی کوئری‌های کند MySQL

شناسایی کوئری‌های کند دیتابیس یکی از پرکاربردترین کاربردهای Sentry در وردپرس است. برای ثبت خودکار کوئری‌ها، از فیلتر query وردپرس استفاده می‌شود:

add_filter('query', function($query) {
    if (!function_exists('\Sentry\startSpan')) {
        return $query;
    }
    
    $span = \Sentry\startSpan([
        'op' => 'db.sql.query',
        'description' => substr($query, 0, 200),
    ]);
    
    if ($span !== null) {
        $span->finish();
    }
    
    return $query;
});

این کد هر کوئری SQL را به‌عنوان یک span ثبت می‌کند. در داشبورد Sentry می‌توان کندترین کوئری‌ها را شناسایی کرد و سپس با EXPLAIN تحلیل عمیق‌تری انجام داد.

برای مطالعه بیشتر درباره بهینه‌سازی کوئری، مقاله بهینه سازی کوئری های MySQL را ببینید.

پایش درخواست‌های HTTP خارجی

درخواست‌های HTTP به سرویس‌های خارجی (مانند درگاه پرداخت، APIهای تحلیلی یا سرویس‌های ایمیل) اغلب گلوگاه‌های پنهان هستند. Sentry می‌تواند این درخواست‌ها را با فیلتر http_response ردیابی کند:

add_filter('http_response', function($response, $args, $url) {
    if (!function_exists('\Sentry\startSpan')) {
        return $response;
    }
    
    $span = \Sentry\startSpan([
        'op' => 'http.client',
        'description' => $url,
    ]);
    
    if ($span !== null) {
        $span->setData([
            'http.url' => $url,
            'http.method' => $args['method'] ?? 'GET',
            'http.status_code' => wp_remote_retrieve_response_code($response),
        ]);
        $span->finish();
    }
    
    return $response;
}, 10, 3);

این کد هر درخواست HTTP خروجی را ثبت می‌کند. اگر سرویس خارجی کند باشد یا timeout داشته باشد، در داشبورد Sentry قابل مشاهده است.

پایش عملکرد هوک‌های وردپرس

هوک‌های وردپرس می‌توانند زمان‌بر باشند، به‌ویژه اگر افزونه‌ای callback سنگینی ثبت کرده باشد. برای پایش هوک‌های کلیدی:

add_action('plugins_loaded', function() {
    if (!function_exists('\Sentry\startSpan')) {
        return;
    }
    $span = \Sentry\startSpan(['op' => 'wp.hook', 'description' => 'plugins_loaded']);
    register_shutdown_function(function() use ($span) {
        if ($span !== null) {
            $span->finish();
        }
    });
});

add_action('init', function() {
    if (!function_exists('\Sentry\startSpan')) {
        return;
    }
    $span = \Sentry\startSpan(['op' => 'wp.hook', 'description' => 'init']);
    // اجرای هوک‌های وابسته
    $span->finish();
});

این کد زمان اجرای هوک‌های کلیدی را ثبت می‌کند. با تحلیل این داده‌ها، می‌توان فهمید که کدام افزونه یا کدام callback، عامل کندی است.

پایش خطا و Exceptionها

علاوه بر پایش عملکرد، Sentry خطاها و Exceptionها را نیز ثبت می‌کند. این قابلیت در وردپرس به‌ویژه برای شناسایی خطاهای پنهان مفید است.

ثبت خطاهای PHP

Sentry SDK خطاهای PHP را به‌طور خودکار ثبت می‌کند. برای فعال‌سازی:

\Sentry\init([
    'dsn' => '...',
    'error_types' => E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED,
]);

پارامتر error_types تعیین می‌کند که کدام انواع خطا ثبت شوند. خطاهای E_DEPRECATED معمولاً در محیط تولید نادیده گرفته می‌شوند تا نویز کاهش یابد.

ثبت خطاهای JavaScript

Sentry JavaScript خطاهای مرورگر را ثبت می‌کند. این خطاها با داده‌های سرور در یک trace ادغام می‌شوند و امکان تحلیل کامل‌تری فراهم می‌کنند. برای مطالعه بیشتر درباره خطاهای جاوااسکریپت، مقاله چگونه خطاهای جاوااسکریپت را در کنسول مرورگر پیدا کنیم؟ را ببینید.

گروه‌بندی و اولویت‌بندی خطاها

یکی از قابلیت‌های کلیدی Sentry، گروه‌بندی هوشمند خطاهاست. خطاهای مشابه به‌صورت خودکار گروه‌بندی می‌شوند و به‌عنوان یک issue نمایش داده می‌شوند. معیارهای اولویت‌بندی:

  • تعداد رخداد (Frequency)
  • تعداد کاربران تحت تأثیر (Users Affected)
  • زمان اولین و آخرین رخداد
  • محیط (production، staging، development)
  • نسخه (Release)

این گروه‌بندی به تیم اجازه می‌دهد بر مهم‌ترین مشکلات تمرکز کند، نه بر پرتکرارترین خطاها.

Release Tracking و مدیریت نسخه

Sentry از مفهوم Release پشتیبانی می‌کند که برای ردیابی تغییرات بین نسخه‌ها حیاتی است. با پیکربندی Release:

  • می‌توان فهمید که یک خطا از کدام نسخه شروع شده.
  • می‌توان روند رفع خطا در نسخه‌های مختلف را دید.
  • می‌توان به‌طور خودکار کاربران را از نسخه‌های آسیب‌پذیر مطلع کرد.
\Sentry\init([
    'dsn' => '...',
    'release' => 'my-site@' . MY_SITE_VERSION,
]);

نکته مهم: برای ثبت source mapها و امکان خواندن خطاهای JavaScript با کد اصلی، باید Source Maps را در زمان build آپلود کرد:

sentry-cli releases files my-site@1.0.0 upload-sourcemaps ./dist

این کار تضمین می‌کند که stack traceها با کد اصلی (و نه کد فشرده‌شده) نمایش داده شوند.

User Feedback و تجربه کاربران

Sentry قابلیت جمع‌آوری بازخورد کاربران را نیز دارد. وقتی خطایی رخ می‌دهد، Sentry می‌تواند یک فرم بازخورد نمایش دهد تا کاربر توضیح دهد چه اتفاقی افتاده:

Sentry.init({
    dsn: '...',
    beforeSend(event) {
        if (event.exception) {
            Sentry.showReportDialog({ eventId: event.event_id });
        }
        return event;
    }
});

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

ترکیب Sentry با WP-CLI و Cron

Sentry در محیط‌های خط فرمان نیز کار می‌کند. برای ثبت خطاهای WP-CLI و Cron:

// در فایل wp-config.php یا MU-Plugin
if (defined('WP_CLI') && WP_CLI) {
    \Sentry\init([
        'dsn' => '...',
        'environment' => 'cli',
    ]);
}

// برای Cron
if (defined('DOING_CRON') && DOING_CRON) {
    \Sentry\init([
        'dsn' => '...',
        'environment' => 'cron',
    ]);
}

این پیکربندی، خطاهای WP-CLI و Cron را با برچسب محیطی مناسب ثبت می‌کند و امکان تفکیک آن‌ها از خطاهای وب را فراهم می‌کند. برای مطالعه بیشتر درباره WP-CLI، مقاله WP-CLI و مدیریت وردپرس از خط فرمان را ببینید.

Sentry خودمیزبان در مقابل SaaS

Sentry دو مدل استقرار دارد:

ویژگیSentry SaaSSentry خودمیزبان
راه‌اندازیفوریچند ساعت تا چند روز
هزینهمبتنی بر حجم رویدادهزینه زیرساخت
حریم خصوصیداده روی سرور Sentryداده روی سرور شما
نگهداریتوسط Sentryتوسط تیم شما
مقیاس‌پذیریبالاوابسته به زیرساخت
مناسب برایاکثر پروژه‌هاپروژه‌های با داده حساس

برای پروژه‌های وردپرسی معمولی، SaaS انتخاب منطقی‌تری است. اما اگر پروژه شما داده حساس دارد (مانند اطلاعات کاربران یا داده‌های مالی)، استقرار خودمیزبان می‌تواند انتخاب بهتری باشد.

نصب Sentry خودمیزبان با Docker Compose انجام می‌شود:

git clone https://github.com/getsentry/self-hosted.git
cd self-hosted
./install.sh
docker-compose up -d

پس از راه‌اندازی، داشبورد Sentry روی http://localhost:9000 در دسترس است. برای مطالعه بیشتر درباره Docker، مقاله تجربه کار با Docker در توسعه پروژه‌ها را ببینید.

ملاحظات امنیتی و حریم خصوصی

ارسال داده به Sentry نیازمند رعایت نکات امنیتی و حریم خصوصی است:

  • فیلتر کردن داده حساس: هرگز رمز عبور، توکن یا اطلاعات کارت بانکی را به Sentry ارسال نکنید.
  • پیکربندی scrubber: از قابلیت before_send برای حذف داده‌های حساس استفاده کنید.
  • رعایت GDPR: اگر سایت کاربران اروپایی دارد، باید قوانین GDPR را رعایت کنید.
  • گمنام‌سازی IP: Sentry به‌طور پیش‌فرض IP را ذخیره می‌کند. می‌توانید آن را در before_send حذف کنید.
  • تعیین Data Retention: در پلن SaaS، مدت نگهداری داده را تنظیم کنید.
\Sentry\init([
    'dsn' => '...',
    'before_send' => function(\Sentry\Event $event) {
        // حذف IP
        $event->setUser(null);
        
        // حذف داده‌های حساس از request
        $request = $event->getRequest();
        if (isset($request['cookies'])) {
            unset($request['cookies']);
        }
        if (isset($request['data']['password'])) {
            unset($request['data']['password']);
        }
        $event->setRequest($request);
        
        return $event;
    },
]);

برای مطالعه بیشتر درباره حریم خصوصی، مقاله چرا انطباق با GDPR در پروژه وردپرس حیاتی است؟ را ببینید.

Sentry ابزاری قدرتمند است، اما با قدرت، مسئولیت می‌آید. داده‌ای که ارسال می‌کنید، می‌تواند حاوی اطلاعات حساس باشد. پیکربندی scrubber بخش جدایی‌ناپذیر پیاده‌سازی است.

سربار عملکردی Sentry

هر ابزار پایش، یک سربار عملکردی دارد. Sentry به‌عنوان یک SDK سبک، سربار آن معمولاً ناچیز است، اما در سایت‌های پرترافیک باید مدیریت شود:

  • حجم SDK: PHP SDK حدود ۲ مگابایت است. JavaScript SDK در نسخه فشرده حدود ۳۰ کیلوبایت.
  • زمان پردازش: هر رویداد نیازمند پردازش و ارسال است که چند میلی‌ثانیه زمان می‌برد.
  • ارسال غیرهمزمان: Sentry SDK از ارسال غیرهمزمان استفاده می‌کند تا تجربه کاربر تحت تأثیر قرار نگیرد.
  • Sample Rate: با کاهش Sample Rate، حجم ارسال کاهش می‌یابد.
  • Buffering: SDK می‌تواند رویدادها را بافر کند و به‌صورت دسته‌ای ارسال کند.

برای بهینه‌سازی:

  • Sample Rate را بر اساس ترافیک سایت تنظیم کنید (۰.۰۱ تا ۰.۱).
  • خطاهای کم‌اهمیت را فیلتر کنید.
  • از traces_sample_rate به‌جای traces_sample_rate = 1.0 استفاده کنید.
  • در محیط توسعه، Sentry را غیرفعال یا با Sample Rate پایین‌تر اجرا کنید.

برای مطالعه بیشتر درباره بهینه‌سازی سرعت، مقاله بهینه‌سازی سرعت سایت چیست و چرا مهم است؟ را ببینید.

اشتباهات رایج در پیاده‌سازی Sentry

در پروژه‌های متعدد، اشتباهات تکراری در پیاده‌سازی Sentry دیده می‌شود:

  1. Sample Rate برابر ۱.۰ در تولید: این کار هزینه بالا و حجم داده زیاد ایجاد می‌کند.
  2. ارسال داده حساس: عدم پیکربندی scrubber می‌تواند به نقض حریم خصوصی منجر شود.
  3. نادیده گرفتن محیط: تفکیک نکردن محیط‌ها باعث می‌شود خطاهای توسعه با خطاهای تولید مخلوط شوند.
  4. عدم استفاده از Release: بدون Release، ردیابی تغییرات بین نسخه‌ها غیرممکن است.
  5. نادیده گرفتن Source Maps: خطاهای JavaScript در Sentry با کد فشرده نمایش داده می‌شوند.
  6. فیلتر نکردن خطاهای پرتکرار: خطاهای بی‌اهمیت می‌توانند خطاهای مهم را پنهان کنند.
  7. عدم تست SDK: عدم تست در محیط staging می‌تواند به مشکلات در تولید منجر شود.
  8. نصب SDK به‌صورت سراسری: نصب در MU-Plugin توصیه می‌شود، نه در functions.php قالب.
  9. نادیده گرفتن سربار: نصب Sentry بدون در نظر گرفتن تأثیر آن بر عملکرد.
  10. عدم مستندسازی: تیم‌های جدید نمی‌دانند Sentry در کجا پیکربندی شده و چگونه استفاده شود.

برای مطالعه بیشتر درباره خطاهای وردپرس، مقاله خطاهای رایج وردپرس و رفع مرحله‌به‌مرحله آنها را ببینید.

پرسش‌های پرتکرار درباره Sentry Performance

در این بخش، به پرسش‌های متداول درباره Sentry پاسخ داده می‌شود. این ساختار برای بهینه‌سازی محتوا برای موتورهای پاسخگو (Answer Engines) نیز مفید است.

Sentry Performance چیست و چه کاربردی در وردپرس دارد؟

Sentry Performance یک ابزار پایش خطا و عملکرد است که در وردپرس برای شناسایی خطاهای پنهان، ردیابی کوئری‌های کند، پایش درخواست‌های HTTP خارجی و تحلیل عملکرد هوک‌ها استفاده می‌شود. این ابزار به توسعه‌دهنده نشان می‌دهد که کدام بخش از کد عامل کندی یا خطاست.

تفاوت Sentry با ابزارهای لاگ‌گیری سنتی چیست؟

Sentry نه فقط خطاها را ثبت می‌کند، بلکه زمینه (Context)، کاربر، مرورگر، نسخه و stack trace کامل را نیز ذخیره می‌کند. همچنین قابلیت Performance Monitoring و Distributed Tracing دارد که ابزارهای سنتی فاقد آن هستند.

آیا Sentry بر سرعت سایت اثر می‌گذارد؟

سربار Sentry ناچیز است (چند میلی‌ثانیه در هر درخواست). با تنظیم Sample Rate مناسب و پیکربندی بهینه، تأثیر آن بر تجربه کاربر قابل چشم‌پوشی است.

چگونه Sentry را در وردپرس نصب کنیم؟

سه روش اصلی: استفاده از Composer برای نصب SDK، نصب افزونه wp-sentry-integration، یا ادغام دستی SDK در یک MU-Plugin. روش افزونه ساده‌تر است، اما Composer کنترل بیشتری می‌دهد.

Sample Rate چیست و چگونه تنظیم می‌شود؟

Sample Rate نرخ نمونه‌گیری تراکنش‌هاست. مقدار ۰.۱ یعنی ۱۰٪ از تراکنش‌ها به Sentry ارسال می‌شوند. برای سایت‌های پرترافیک، مقدار ۰.۰۱ تا ۰.۱ مناسب است. خطاها همیشه ثبت می‌شوند.

آیا Sentry می‌تواند کوئری‌های کند MySQL را شناسایی کند؟

بله. با فیلتر query وردپرس، هر کوئری SQL به‌عنوان یک span ثبت می‌شود. در داشبورد Sentry می‌توان کندترین کوئری‌ها را شناسایی کرد.

Sentry چه تفاوتی با New Relic دارد؟

Sentry بر خطا و عملکرد کد تمرکز دارد و راه‌اندازی آن ساده‌تر است. New Relic بر پایش زیرساخت و سرور تمرکز دارد و برای تیم‌های SRE مناسب‌تر است. این دو مکمل یکدیگرند.

آیا Sentry از وردپرس چندسایتی (Multisite) پشتیبانی می‌کند؟

بله. اما پیکربندی آن نیازمند دقت است. برای هر سایت می‌توان از یک پروژه جداگانه یا tagهای متمایز استفاده کرد.

چگونه داده‌های حساس را از Sentry فیلتر کنیم؟

با استفاده از callback before_send. در این callback می‌توان داده‌های حساس مانند رمز عبور، توکن و IP را حذف کرد.

آیا Sentry برای سایت‌های کوچک مناسب است؟

بله. پلن رایگان Sentry برای سایت‌های کوچک و متوسط کافی است. حتی برای سایت‌های شخصی، Sentry می‌تواند خطاهای پنهان را آشکار کند.

چگونه Sentry را با CI/CD ادغام کنیم؟

با استفاده از sentry-cli می‌توان Releaseها را در pipeline CI ثبت کرد و Source Mapها را آپلود کرد. این کار به ردیابی دقیق خطاها بین نسخه‌ها کمک می‌کند.

آیا Sentry از PHP 8 پشتیبانی می‌کند؟

بله. نسخه‌های جدید SDK با PHP 8 و 8.1 کاملاً سازگارند. برای PHP نسخه‌های قدیمی‌تر، از نسخه‌های مناسب SDK استفاده کنید.

هزینه Sentry چقدر است؟

پلن رایگان Sentry تا ۵۰۰۰ رویداد در ماه را پشتیبانی می‌کند. پلن‌های پرداختی بر اساس حجم رویداد و ویژگی‌ها قیمت‌گذاری می‌شوند. برای اکثر پروژه‌های وردپرسی، پلن رایگان یا پلن‌های ابتدایی کافی است.

نکات پیشرفته برای مهندسان ارشد

برای مهندسان ارشد و تیم‌های DevOps، Sentry فراتر از یک ابزار خطاگیری است. در این بخش، به نکات پیشرفته‌ای می‌پردازیم که در پروژه‌های بزرگ حیاتی می‌شوند.

Distributed Tracing در معماری چندسرویسی

در معماری‌های Microservices یا Serverless، Distributed Tracing حیاتی است. Sentry از پروتکل sentry-trace و baggage برای انتقال context بین سرویس‌ها استفاده می‌کند:

// سرویس A
$traceId = \Sentry\SentrySdk::getCurrentHub()->getSpan()->getTraceId();
$http->request($url, [
    'headers' => [
        'sentry-trace' => $traceId,
    ],
]);

این context در سرویس B قابل استخراج است:

// سرویس B
$traceId = $_SERVER['HTTP_SENTRY_TRACE'] ?? null;
if ($traceId) {
    $transaction = \Sentry\continueTrace($traceId, $baggage);
}

این رویکرد، امکان ردیابی یک درخواست از فرانت‌اند تا بک‌اند و سرویس‌های جانبی را فراهم می‌کند.

Profiling با Sentry

Sentry Profiling یک قابلیت پیشرفته است که نه فقط زمان اجرا، بلکه نحوه توزیع زمان بین توابع را نشان می‌دهد:

\Sentry\init([
    'dsn' => '...',
    'profiles_sample_rate' => 0.1,
    'traces_sample_rate' => 0.1,
]);

با فعال‌سازی Profiling، Sentry یک flame graph از اجرای کد تولید می‌کند که نشان می‌دهد کدام توابع بیشترین زمان را مصرف می‌کنند. این داده‌ها برای بهینه‌سازی کد حیاتی هستند.

Alerting و هشداردهی هوشمند

Sentry امکان تعریف alert rules را فراهم می‌کند:

  • Issue Alerts: هشدار برای خطاهای جدید یا با نرخ بالا.
  • Metric Alerts: هشدار برای معیارهای عملکردی (مانند P95 زمان پاسخ).
  • Anomaly Detection: هشدار برای رفتار غیرمعمول.

این هشدارها از طریق Slack، Email، PagerDuty و Webhook قابل ارسال هستند. برای مطالعه بیشتر درباره اتوماسیون، مقاله نقد Zapier: ابزار اتوماسیون بدون کد چه محدودیت‌هایی دارد؟ را ببینید.

Custom Instrumentation برای هوک‌های وردپرس

برای هوک‌های سفارشی، می‌توان از instrumentation دقیق استفاده کرد:

function my_wrapped_hook($callback, $priority = 10, $accepted_args = 1) {
    return function(...$args) use ($callback) {
        $span = \Sentry\startSpan([
            'op' => 'wp.hook.custom',
            'description' => 'my_custom_hook',
        ]);
        
        try {
            return $callback(...$args);
        } finally {
            if ($span !== null) {
                $span->finish();
            }
        }
    };
}

add_action('my_custom_hook', my_wrapped_hook('my_callback'), 10, 1);

این الگو، هر callback را با اندازه‌گیری زمان اجرا احاطه می‌کند و داده‌های دقیق‌تری فراهم می‌آورد.

تحلیل داده‌های Sentry با SQL

در پلن‌های تجاری Sentry، می‌توان به داده‌ها با SQL دسترسی داشت:

SELECT
    transaction,
    COUNT(*) AS count,
    AVG(duration) AS avg_duration,
    QUANTILE(0.95)(duration) AS p95_duration
FROM transactions
WHERE environment = 'production'
GROUP BY transaction
ORDER BY p95_duration DESC
LIMIT 20;

این کوئری، کندترین تراکنش‌ها را بر اساس P95 نشان می‌دهد. P95 معیار دقیق‌تری از میانگین است، زیرا تحت تأثیر outliers قرار نمی‌گیرد.

مقایسه Sentry با OpenTelemetry

OpenTelemetry یک استاندارد باز برای observability است که توسط CNCF پشتیبانی می‌شود. Sentry از OpenTelemetry پشتیبانی می‌کند و می‌تواند به‌عنوان backend برای داده‌های OTel استفاده شود. تفاوت‌ها:

ویژگیSentry SDKOpenTelemetry
راه‌اندازیسادهپیچیده‌تر
استاندارداختصاصیاستاندارد باز
پشتیبانیکامل توسط Sentryوابسته به backend
مناسب برایپروژه‌های وردپرسیسیستم‌های پیچیده

برای پروژه‌های وردپرسی، Sentry SDK انتخاب منطقی‌تری است. اما در سیستم‌های توزیع‌شده بزرگ، OpenTelemetry می‌تواند انعطاف‌پذیری بیشتری فراهم کند.

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

هزینه Sentry بر اساس حجم رویداد است. در پروژه‌های بزرگ، مدیریت هزینه حیاتی است:

  • Sample Rate پویا: نرخ نمونه‌گیری را بر اساس نوع تراکنش تنظیم کنید.
  • Filtering: رویدادهای غیرضروری را فیلتر کنید.
  • Rate Limiting: محدودیت نرخ ارسال برای جلوگیری از سیل رویداد.
  • Data Retention: مدت نگهداری داده را کاهش دهید.
  • Self-Hosted: در حجم بالا، self-hosted می‌تواند ارزان‌تر باشد.
\Sentry\init([
    'dsn' => '...',
    'traces_sample_rate' => function(\Sentry\TransactionContext $context) {
        // نرخ نمونه‌گیری پویا
        if (strpos($context->getName(), '/wp-admin/') === 0) {
            return 0.01; // ۱٪ برای ادمین
        }
        return 0.1; // ۱۰٪ برای بقیه
    },
]);

نکات کلیدی برای پایداری بلندمدت

در پایان، چند نکته کلیدی که در پیاده‌سازی Sentry باید در خاطر بماند:

  • Sample Rate را بر اساس ترافیک تنظیم کنید: نه بیشتر، نه کمتر.
  • محیط‌ها را تفکیک کنید: development، staging و production باید جداگانه باشند.
  • Release Tracking را فعال کنید: بدون آن، ردیابی تغییرات غیرممکن است.
  • Data Scrubbing را جدی بگیرید: حریم خصوصی کاربران اولویت است.
  • خطاهای پرتکرار را فیلتر کنید: تا خطاهای مهم پنهان نشوند.
  • Source Maps را آپلود کنید: برای خوانایی خطاهای JavaScript.
  • Alerting را پیکربندی کنید: تا از مشکلات بحرانی باخبر شوید.
  • هزینه را پایش کنید: به‌ویژه در پلن‌های SaaS.
  • با WP-CLI و Cron ادغام کنید: برای پوشش کامل.
  • تیم را آموزش دهید: تا همه بتوانند از داده‌ها استفاده کنند.

اگر در پروژه‌های خود از Sentry استفاده کرده‌اید، جالب است بدانم کدام قابلیت آن بیشترین تأثیر را در عیب‌یابی داشته است. تجربه خودتان را در دیدگاه‌ها بنویسید؛ به‌خصوص اگر راه‌حل خلاقانه‌ای برای ترکیب Sentry با سایر ابزارها پیدا کرده‌اید که می‌تواند برای دیگران مفید باشد.