مشاهده‌پذیری API چیست؟

مشاهده‌پذیری API میزان درک‌پذیر بودن وضعیت داخلی یک API از طریق سیگنال‌هایی است که تولید می‌کند.

برای آن‌که یک API مشاهده‌پذیر باشد، باید با شنونده‌های رویداد، ایجنت‌ها یا کتابخانه‌ها instrument شود؛ ابزارهایی که به تیم‌ها امکان می‌دهند به‌صورت غیرفعال، متریک‌ها، رویدادها، لاگ‌ها و تریس‌های API را جمع‌آوری کنند. این داده‌های تله‌متری سپس می‌توانند برای ایجاد هشدارهایی استفاده شوند که تیم‌ها را از بروز مشکلات نگران‌کننده مطلع می‌کنند، و همچنین می‌توان آن‌ها را بصری‌سازی کرد یا برای تحلیل‌های بیشتر به یک ابزار APM ارسال نمود. بنابراین مشاهده‌پذیری API نقشی حیاتی در کمک به تیم‌ها برای پایش عملکرد API، عیب‌یابی مشکلات، درک الگوهای مصرف و شناسایی فرصت‌های بهینه‌سازی ایفا می‌کند.

در ادامه، بررسی می‌کنیم مشاهده‌پذیری API چگونه از مدل توسعه API-first پشتیبانی می‌کند و تفاوت آن با پایش API چیست. سپس چهار ستون اصلی مشاهده‌پذیری API را مرور می‌کنیم و برخی موارد استفاده رایج از این داده‌های تله‌متری را بررسی خواهیم کرد. در نهایت، به برخی قابلیت‌های پلتفرم Postman API اشاره می‌کنیم که به تیم‌ها کمک می‌کند مشاهده‌پذیری تمام APIهای موجود در پورتفوی خود را بهبود دهند.

مشاهده‌پذیری API در دنیای API-first چه نقشی دارد؟

امروزه بسیاری از تیم‌ها برنامه‌های خود را به‌صورت مجموعه‌ای از سرویس‌های داخلی و خارجی طراحی و پیاده‌سازی می‌کنند که از طریق API ارائه می‌شوند. این رویکرد که با نام API-first شناخته می‌شود، باعث گسترش گسترده میکروسرویس‌هایی با مدیریت مستقل شده است که از طریق API با یکدیگر ارتباط برقرار می‌کنند. معماری‌های مبتنی بر میکروسرویس بسیار مقیاس‌پذیر هستند، اما ماهیت توزیع‌شده آن‌ها مشاهده‌پذیری را دشوار می‌کند. برای مثال، یک تغییر به‌ظاهر کوچک در یک میکروسرویس می‌تواند پیامدهای مهمی برای میکروسرویس دیگری که با آن تعامل دارد ایجاد کند، اما بدون دید کامل نسبت به کل سیستم، عیب‌یابی چنین مشکلاتی بسیار دشوار خواهد بود.

علاوه بر کمک به پیاده‌سازی معماری‌های مبتنی بر میکروسرویس، رویکرد API-first باعث افزایش تعداد APIهایی شده است که به‌عنوان محصولات قابل فروش به مصرف‌کنندگان شخص ثالث ارائه می‌شوند. در این مدل، تولیدکنندگان API مسئول پایبندی به توافق‌نامه‌های سطح خدمت (SLA) در زمینه دسترس‌پذیری، عملکرد و امنیت هستند و بروز هرگونه مشکل می‌تواند اعتماد مشتریان را تضعیف کرده و به ریزش منجر شود.

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

تفاوت مشاهده‌پذیری API و پایش API چیست؟

مشاهده‌پذیری API و پایش API مفاهیمی نزدیک به هم هستند، اما یکسان نیستند. پایش API فرآیند جمع‌آوری، بصری‌سازی و ارسال هشدار بر اساس متریک‌های از پیش تعریف‌شده است تا اطمینان حاصل شود یک API انتظارات مشخصی را برآورده می‌کند. مشاهده‌پذیری API از پایش API پشتیبانی می‌کند، اما دامنه آن بسیار بازتر است. مشاهده‌پذیری نه‌تنها داده‌هایی غنی از زمینه در اختیار تیم‌ها قرار می‌دهد که امکان عیب‌یابی مشکلات پیش‌بینی‌نشده را فراهم می‌کند، بلکه تحلیل‌های اکتشافی (ad-hoc) و پیچیده‌ای را ممکن می‌سازد که می‌توانند راهنمای تصمیم‌های کلان کسب‌وکار باشند.

چهار ستون اصلی مشاهده‌پذیری API کدام‌اند؟

همان‌طور که گفته شد، یک API مشاهده‌پذیر داده‌های تله‌متری تولید می‌کند که به توسعه‌دهندگان، مهندسان قابلیت اطمینان سایت (SRE) و مهندسان DevOps کمک می‌کند وضعیت داخلی آن را بهتر درک کنند. چهار نوع اصلی داده تله‌متری شامل متریک‌ها، رویدادها، لاگ‌ها و تریس‌ها هستند که در مجموع به‌عنوان «چهار ستون» مشاهده‌پذیری API شناخته می‌شوند. هیچ‌یک از این داده‌ها به‌تنهایی تصویر کاملی ارائه نمی‌دهد، اما تحلیل هم‌زمان آن‌ها می‌تواند نمای جامعی از سلامت، عملکرد و نحوه استفاده از API ترسیم کند.

متریک‌ها (Metrics)

متریک یک اندازه‌گیری از یک مقدار در بازه‌های زمانی مشخص است، مانند هر دقیقه یا هر ساعت. انواع مختلفی از متریک‌ها وجود دارد که می‌توانند ابعاد متفاوتی از سلامت API را روشن کنند. برای مثال، متریک‌های کاری مانند throughput و latency نشان می‌دهند API با چه کارایی‌ای درخواست‌ها را پردازش می‌کند، در حالی که متریک‌های منابع مانند مصرف CPU و حافظه برای سنجش میزان اشباع API استفاده می‌شوند. این متریک‌ها نه‌تنها به شناسایی مشکلات فوری کمک می‌کنند، بلکه در بلندمدت نیز می‌توان از آن‌ها برای یافتن فرصت‌های بهینه‌سازی استفاده کرد.

رویدادها (Events)

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

لاگ‌ها (Logs)

در حالی که رویدادها فعالیت‌های مهم اما نسبتاً کم‌تکرار را ثبت می‌کنند، لاگ‌ها جزئیات تمام اقداماتی را که در یک سیستم رخ می‌دهد ثبت می‌کنند. لاگ‌ها بسیار ریزدانه‌تر از رویدادها هستند؛ به‌طوری‌که یک رویداد واحد معمولاً با تعداد زیادی لاگ مرتبط است. برای مثال، تمام مراحل یک انتشار کد، از merge شاخه کاری گرفته تا شروع build و اجرای هر تست CI، احتمالاً در لاگ‌های جداگانه ثبت می‌شوند.

یک لاگ معمولی API شامل متد و URL درخواست، زمان ثبت، کد وضعیت HTTP، زمان پاسخ و آدرس IP فراخواننده است. این اطلاعات به تیم‌ها کمک می‌کند مشکلات مربوط به endpointها و متدهای خاص را عیب‌یابی کنند و همچنین می‌تواند برای بررسی فعالیت‌های مشکوک یا حملات امنیتی مورد استفاده قرار گیرد.

تریس‌ها (Traces)

تریس رکوردی از مسیر کامل یک درخواست در یک سیستم توزیع‌شده است. هر تریس حداقل شامل یک span است که نمایانگر یک گام از مسیر درخواست است. هر span شامل داده‌هایی درباره آن گام است، مانند مدت‌زمان اجرا و این که آیا خطایی رخ داده یا نه. تریس‌ها و spanهای تشکیل‌دهنده آن‌ها معمولاً در قالب نمودار flame یا نقشه سرویس بصری‌سازی می‌شوند که به تیم‌ها کمک می‌کند الگوهای ترافیک و روابط وابستگی را بهتر درک کنند. تریس‌ها همچنین به تیم‌ها کمک می‌کنند مؤلفه‌ای را که مسئول افزایش تأخیر کلی است شناسایی کنند و در فرآیند عیب‌یابی با لاگ‌ها و رویدادها هم‌بسته شوند.

مشاهده‌پذیری API از چه موارد استفاده‌ای پشتیبانی می‌کند؟

بسیاری از تیم‌ها از داده‌های تله‌متری API برای اطمینان از این که تأخیر و نرخ خطای API با اهداف سطح خدمت (SLO) مطابقت دارد استفاده می‌کنند. با این حال، مشاهده‌پذیری API امکان انواع پیچیده‌تری از پایش و تحلیل را نیز فراهم می‌کند. برای مثال، داده‌های تله‌متری API می‌توانند به تیم‌ها کمک کنند:

برنامه‌ریزی برای منسوخ‌سازی API

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

شناسایی شکاف‌ها در پوشش تست API

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

تشخیص انحراف‌های سطح تولید نسبت به خط مبنا

معمول است که تیم‌ها پیش از انتشار API در محیط تولید، آن را در یک محیط staging مستقر کنند. محیط staging به‌گونه‌ای طراحی می‌شود که تا حد ممکن شبیه محیط تولید باشد تا تیم‌ها بتوانند یک خط مبنا از عملکرد مورد انتظار API در دنیای واقعی تعریف کنند. پس از رسیدن API به تولید، تیم‌ها می‌توانند داده‌های سطح تولید را به‌طور مداوم با این خط مبنا مقایسه کنند تا هرگونه انحراف غیرمنتظره را به‌محض وقوع شناسایی کنند.