🥇 یوازې نوی ریلیک نه دی: ډیټاډګ او اتاتوس ته یوه کتنه

د SRE/DevOps انجینرانو په چاپیریال کې، دا به هیڅوک حیران نه کړي چې یوه ورځ یو پیرودونکی (یا د څارنې سیسټم) راښکاره کیږي او راپور ورکوي چې "هر څه ورک شوي": سایټ کار نه کوي، تادیات نه تیریږي، ژوند خرابیږي. ... مهمه نده چې تاسو په داسې حالت کې څومره مرسته کول غواړئ، دا د ساده او د پوهیدو وړ وسیلې پرته دا کار کول خورا ستونزمن کیدی شي. ډیری وختونه ستونزه پخپله د غوښتنلیک کوډ کې پټه ده؛ تاسو یوازې د دې ځایی کولو ته اړتیا لرئ.

او په غم او خوښۍ کې…

دا داسې پیښ شوي چې موږ د نوي ریلیک سره اوږده او ژوره مینه درلوده. دا د غوښتنلیک فعالیت نظارت کولو لپاره عالي وسیله وه او پاتې ده ، او تاسو ته اجازه درکوي د مایکرو سرویس جوړښت وسیله کړئ (د دې اجنټ په کارولو سره) او نور ډیر څه. او هرڅه خورا ښه کیدی شي که چیرې دا د خدماتو قیمتونو پالیسي کې بدلونونو لپاره نه وي: دا د لګښت د 2013 کال څخه 3+ ځله وده وکړه. سربیره پردې ، د تیر کال راهیسې ، د آزموینې حساب ترلاسه کول د شخصي مدیر سره اړیکې ته اړتیا لري ، کوم چې احتمالي پیرودونکي ته د محصول وړاندې کول ستونزمن کوي.

عادي حالت: نوي ریلیک ته "دایمي اساس" ته اړتیا نشته؛ دوی دا یوازې هغه وخت یادوي کله چې ستونزې پیل شي. مګر تاسو لاهم اړتیا لرئ په منظم ډول تادیه وکړئ (په هره میاشت کې په هر سرور کې 140 USD)، او په اتوماتيک ډول د کلاوډ زیربنا اندازه کول خورا لوی دي. که څه هم دلته د تادیې په توګه-تو-ګو اختیار شتون لري، د نوي ریلیک فعالول به تاسو ته د غوښتنلیک بیا پیلولو ته اړتیا ولري، کوم چې ممکن د هغه ستونزمن حالت له لاسه ورکړي چې دا ټول پیل شوي. ډیر وخت دمخه ، نیو ریلیک د تعرفې نوی پلان معرفي کړ - ویښ، - کوم چې په لومړي نظر کې د مسلکي لپاره د مناسب بدیل په څیر ښکاري ... مګر د نږدې ازموینې وروسته معلومه شوه چې ځینې مهمې دندې ورکې دي (په ځانګړې توګه، دا نلري کلیدي لیږدونه, د کراس غوښتنلیک تعقیب, توزیع شوي تعقیب).

د پایلې په توګه، موږ د ارزانه بدیل په لټه کې فکر کولو پیل وکړ، او زموږ انتخاب په دوو خدماتو کې راوتلی: ډیټاډګ او اتاتوس. ولې پر دوی؟

د سیالانو په اړه

اجازه راکړئ سمدلاسه ووایم چې په بازار کې نور حلونه شتون لري. موږ حتی د خلاصې سرچینې اختیارونه په پام کې نیولي، مګر هر پیرودونکی د ځان کوربه شوي حلونو کوربه کولو وړیا ظرفیت نلري ... - سربیره پردې، دوی اضافي ساتنې ته اړتیا لري. هغه جوړه چې موږ غوره کړې وه تر ټولو نږدې وه زموږ اړتیاوې:

د PHP غوښتنلیکونو لپاره جوړ شوی او پرمختللی ملاتړ (زموږ د پیرودونکو سټیک خورا متنوع دی ، مګر دا د نوي ریلیک لپاره د بدیل لټون په شرایطو کې روښانه مشر دی)؛
ارزانه لګښت (په هره میاشت کې له 100 USD څخه لږ کوربه)؛
اتوماتیک وسایل؛
د Kubernetes سره یوځای کول؛
د نوي ریلیک انٹرفیس سره ورته والی د پام وړ پلس دی (ځکه چې زموږ انجینران دې ته عادت شوي).

له همدې امله، د انتخاب په لومړني پړاو کې، موږ ډیری نور مشهور حلونه له منځه یوړل، او په ځانګړې توګه:

Tideways، AppDynamics او Dynatrace - د لګښت لپاره؛
Stackify د روسیې په فدراسیون کې بند شوی او ډیر لږ معلومات ښیې.

د مقالې پاتې برخه په داسې ډول جوړه شوې چې د پوښتنې حلونه به لومړی په لنډ ډول وړاندې شي، وروسته به زه د نوي ریلیک سره زموږ د عادي تعامل او په نورو خدماتو کې د ورته عملیاتو ترسره کولو تجربه / تاثیراتو په اړه وغږیږم.

د ټاکل شویو سیالیو وړاندې کول

په نوې اړیکه، شاید هرڅوک اوریدلی وي؟ دا خدمت د 10 څخه ډیر کاله دمخه په 2008 کې خپل پرمختګ پیل کړ. موږ دا له 2012 راهیسې په فعاله توګه کاروو او په PHP، روبي او پایتون کې د واقعیا لوی شمیر غوښتنلیکونو مدغم کولو کې کومه ستونزه نلرو، او موږ د C# او Go سره د ادغام تجربه هم درلوده. د خدماتو لیکوالان د څارنې غوښتنلیکونو لپاره حلونه لري، زیربناوې، د مایکرو سرویس زیربنا تعقیب، د کاروونکي وسیلو لپاره مناسب غوښتنلیکونه رامینځته کړي، او نور ډیر څه.

په هرصورت، نوی ریلیک اجنټ د ملکیت پروتوکولونو پرمخ ځي او د OpenTracing ملاتړ نه کوي. پرمختللي وسایل په ځانګړي ډول د نوي ریلیک لپاره ترمیم ته اړتیا لري. په نهایت کې ، د کوبرنیټس ملاتړ لاهم تجربه لري.

په 2010 کې یې پراختیا پیل کړه ډاټاډګ د کبرنیټس چاپیریال کې د کارولو شرایطو کې دقیقا د نوي ریلیک څخه د پام وړ خورا په زړه پوري ښکاري. په ځانګړې توګه، دا د NGINX Ingress، log collection، statsd او OpenTracing پروتوکولونو سره ادغام ملاتړ کوي، کوم چې تاسو ته اجازه درکوي د کاروونکي غوښتنه تعقیب کړئ له هغه وخته چې دا د بشپړیدو سره وصل وي، او همدارنګه د دې غوښتنې لپاره لاګونه ومومئ (دواړه د ویب سرور اړخ کې. او د مصرف کوونکو په اړه).

کله چې د Datadog کاروئ، موږ ورسره مخ شو چې دا ځینې وختونه د مایکرو سرویس نقشه په غلط ډول رامینځته کوي، او ځینې تخنیکي نیمګړتیاوې. د مثال په توګه، دا د خدماتو ډول غلط پیژندل شوی (د کیچ کولو خدمت لپاره د جینګو غلط کول) او د مشهور پریډیس کتابتون په کارولو سره د پی ایچ پی غوښتنلیک کې د 500 غلطیو لامل شوی.

اتاتوس - تر ټولو ځوان وسیله؛ خدمت په 2014 کې پیل شو. د دې د بازار موندنې بودیجه په ښکاره ډول د لیست شوي سیالیو څخه ټیټه ده، یادونه خورا لږ عام دي. په هرصورت، دا وسیله پخپله د نوي ریلیک سره ورته ده، نه یوازې په خپلو وړتیاوو (APM، د براوزر څارنه، او نور)، بلکې په ظاهري بڼه هم.

یو مهم نیمګړتیا دا ده چې دا یوازې د Node.js او PHP ملاتړ کوي. له بلې خوا، دا د Datadog په پرتله د پام وړ ښه پلي کیږي. د وروستي برعکس، اتاتوس غوښتنلیکونو ته اړتیا نلري چې تعدیلات وکړي یا کوډ ته اضافي لیبلونه اضافه کړي.

موږ څنګه د نوي ریلیک سره کار کوو

اوس راځئ چې معلومه کړو چې څنګه موږ عموما نوي ریلیک کاروو. راځئ چې ووایو موږ یوه ستونزه لرو چې حل ته اړتیا لري:

دا په ګراف کې لیدل اسانه دي ټوټه ټوټه - راځئ چې دا تحلیل کړو. په نوي ریلیک کې، ویب لیږد سمدلاسه د ویب غوښتنلیک لپاره غوره کیږي، ټولې برخې د فعالیت په ګراف کې ښودل شوي، د غلطۍ کچه، د غوښتنې نرخ پینلونه شتون لري ... هغه څه چې خورا مهم دي دا دي چې تاسو مستقیم له دې پینلونو څخه د مختلفو ترمنځ حرکت کولی شئ. د غوښتنلیک برخې (د مثال په توګه، په MySQL باندې کلیک کول به د ډیټابیس برخې ته لاړ شي).

ځکه چې په لاندې مثال کې موږ په فعالیت کې زیاتوالی ګورو پی ایچ پیپه دې چارټ کلیک وکړئ او په اتوماتيک ډول لاړ شئ راکړې ورکړې:

د معاملو لیست، کوم چې په اصل کې د MVC ماډل څخه کنټرولرونه دي، مخکې له دې ترتیب شوي ډیری وخت مصرفوي، کوم چې خورا اسانه دی: موږ سمدلاسه وګورو چې غوښتنلیک څه کوي. دلته د اوږدو پوښتنو مثالونه دي چې په اتوماتيک ډول د نوي ریلیک لخوا راټول شوي. د ترتیب کولو بدلولو سره، دا موندل اسانه دي:

ترټولو ډیر بار شوي غوښتنلیک کنټرولر؛
ډیری وخت غوښتل شوي کنټرولر؛
تر ټولو ورو کنټرولر.

سربیره پردې ، تاسو کولی شئ هره معامله پراخه کړئ او وګورئ چې غوښتنلیک د کوډ اجرا کولو په وخت کې څه کوي:

په نهایت کې ، غوښتنلیک د اوږدو غوښتنو نښو مثالونه ذخیره کوي (هغه چې له 2 ثانیو څخه ډیر وخت نیسي). دلته د اوږدې معاملې لپاره پینل دی:

دا لیدل کیدی شي چې دوه میتودونه ډیر وخت نیسي، او په ورته وخت کې کله چې غوښتنه ترسره شوې وي، د هغې URI او ډومین هم ښودل شوي. ډیری وختونه دا په لاګونو کې د غوښتنې موندلو کې مرسته کوي. ورتګ ... ورته توضیحات تعقیب کړئ، تاسو کولی شئ وګورئ چې دا میتودونه له کوم ځای څخه ویل کیږي:

او په د ډیټابیس پوښتنې - ډیټابیسونو ته د پوښتنو ارزونه وکړئ چې د غوښتنلیک د چلولو پرمهال اجرا شوي:

د دې پوهې سره وسله وال، موږ کولی شو ارزونه وکړو چې ولې غوښتنلیک ورو دی او د پراختیا کونکي سره کار کوي ترڅو د ستونزې حل کولو لپاره ستراتیژۍ سره راشي. په واقعیت کې، نوی ریلیک تل یو روښانه انځور نه ورکوي، مګر دا د تحقیقاتو ویکتور غوره کولو کې مرسته کوي:

اوږد PDO::Construct موږ د pgpoll عجیب فعالیت ته لاره هواره کړه؛
د وخت په تیریدو سره بې ثباتي Memcache::Get وړاندیز وکړ چې مجازی ماشین په غلط ډول ترتیب شوی و؛
د ټیمپلیټ پروسس کولو لپاره په شکمن ډول ډیر شوی وخت د دې لامل شوی چې د نیسټ شوي لوپ د شیانو ذخیره کې د 500 اوتارونو شتون چیک کړي؛
وغيره…

دا هم پیښیږي چې د کوډ اجرا کولو پرځای ، د بهرني ډیټا ذخیره کولو پورې اړوند یو څه په اصلي سکرین کې وده کوي - او دا مهمه نده چې دا به څه وي: Redis یا PostgreSQL - دا ټول په ټب کې پټ دي Databases.

تاسو کولی شئ د څیړنې او ترتیب پوښتنو لپاره یو ځانګړی اساس وټاکئ - ورته ورته چې دا څنګه په معاملو کې ترسره کیږي. او د غوښتنې ټب ته په تګ سره ، تاسو کولی شئ وګورئ چې دا غوښتنه په هر غوښتنلیک کنټرولر کې څو ځله پیښیږي ، او دا هم اټکل کړئ چې څو ځله ورته ویل کیږي. دا خورا آرام دی:

ټب ورته معلومات لري بهرني خدمتونه، کوم چې بهرني HTTP خدماتو ته غوښتنې پټوي ، لکه د شیانو ذخیره کولو ته لاسرسی ، سینټري ته د پیښو لیږل ، یا ورته نور. د ټب مینځپانګه په بشپړ ډول ډیټابیس ته ورته ده:

سیالي کوونکي: فرصتونه او تاثیرات

اوس ترټولو په زړه پورې شی د نوي ریلیک وړتیاوې پرتله کول د هغه څه سره چې سیالي یې وړاندیز کوي. له بده مرغه، موږ نشو کولی ټول درې وسیلې د یو غوښتنلیک په یوه نسخه کې ازموینه وکړو چې په تولید کې روان دي. په هرصورت، موږ هڅه وکړه چې شرایط / تشکیلات پرتله کړو چې د امکان تر حده ورته وو.

1.Datadog

ډیټاډګ موږ ته د خدماتو دیوال سره د پینل سره ښه راغلاست ووایی:

دا هڅه کوي غوښتنلیکونه اجزاو / مایکرو خدماتو ته مات کړي، نو د مثال په توګه د جینګو غوښتنلیک موږ به د PostgreSQL سره 2 اړیکې وګورو (defaultdb и postgres)، همدارنګه سیلري، ریډیس. د ډیټاډګ سره کار کول تاسو ته اړتیا لري چې د MVC اصولو لږترلږه پوهه ولرئ: تاسو اړتیا لرئ پوه شئ چې د کارونکي غوښتنې عموما له کوم ځای څخه راځي. دا معمولا مرسته کوي د خدماتو نقشه:

په لاره کې، په نوي ریلیک کې ورته یو څه شتون لري:

... او د دوی نقشه، زما په اند، ساده او روښانه شوې ده: دا د یو غوښتنلیک اجزا نه ښیې (کوم چې دا به خورا مفصل کړي، لکه د ډیټاډګ په قضیه کې)، مګر یوازې ځانګړي خدمتونه یا مایکرو خدمات.

راځئ چې ډیټاډګ ته راستون شو: د خدماتو نقشې څخه موږ ګورو چې د کارونکي غوښتنې جینګو ته راځي. راځئ چې د جینګو خدمت ته لاړ شو او په پای کې وګورو چې موږ څه تمه درلوده:

له بده مرغه، دلته د ډیفالټ په واسطه هیڅ ګراف شتون نلري د ویب لیږد وخت، د هغه څه په څیر چې موږ په اصلي نوي ریلیک پینل کې ګورو. په هرصورت، دا د مهال ویش په ځای کې تنظیم کیدی شي د مصرف شوي وخت سلنه. دا د بدلولو لپاره کافي ده د ډول له مخې د هرې غوښتنې اوسط وخت... او اوس پیژندل شوی ګراف موږ ته ګوري!

ولې ډیټاډګ یو مختلف چارټ غوره کړی زموږ لپاره یو راز دی. یو بل مایوسونکی شی دا دی چې سیسټم د کارونکي انتخاب نه یادوي (د دواړو سیالانو برعکس)، او له همدې امله یوازینۍ حل د دودیز پینلونو رامینځته کول دي.

مګر زه په ډیټاډګ کې د دې وړتیا څخه خوښ وم چې له دې ګرافونو څخه د اړوند سرورونو میټریکونو ته واړوم ، لاګونه ولولئ او د ویب سرور هینډلرونو (ګونیکورن) باندې بار ارزونه وکړئ. هرڅه نږدې ورته دي لکه په نوي ریلیک کې ... او حتی یو څه نور (لاګ)!

د ګرافونو لاندې لیږدونه په بشپړ ډول د نوي ریلیک سره ورته دي:

په Datadog کې، لیږدونه ویل کیږي سرچینې. تاسو کولی شئ کنټرولرونه د غوښتنو شمیر له مخې ترتیب کړئ، د اوسط ځواب وخت په واسطه، او د ټاکل شوي مودې لپاره مصرف شوي اعظمي وخت سره.

تاسو کولی شئ سرچینه پراخه کړئ او هرڅه وګورئ چې موږ دمخه په نوي ریلیک کې لیدلي دي:

د سرچینې په اړه احصایې شتون لري، د داخلي تلیفونونو عمومي لیست، او د غوښتنو مثالونه چې د ځواب کوډ لخوا ترتیب کیدی شي ... په هرصورت، زموږ انجنیرانو واقعیا دا ترتیب خوښ کړ.

په ډیټاډګ کې هره بیلګه سرچینه پرانیستل کیدی شي او مطالعه کیدی شي:

د غوښتنې پیرامیټرې، په هره برخه کې د مصرف شوي وخت لنډیز چارټ، او د آبشار چارټ چې د تلیفونونو ترتیب ښیې وړاندې کیږي. تاسو کولی شئ د آبشار چارټ د ونې لید ته هم لاړ شئ:

او ترټولو په زړه پوری شی د کوربه توب لیدل دي په کوم کې چې غوښتنه اجرا شوې او د غوښتنې لاګونه لیدل.

عالي ادغام!

تاسو شاید حیران شئ چې ټبونه چیرته دي Databases и بهرني خدمتونهلکه څنګه چې په نوي ریلیک کې. دلته هیڅ هم شتون نلري: له هغه وخته چې ډیټاډګ غوښتنلیک په اجزاو کې ماتوي ، نو PostgreSQL به په پام کې ونیول شي یو جلا خدمت، او د بهرنیو خدماتو پرځای دا د لټون ارزښت لري aws.storage (دا به د هر بل بهرني خدمت لپاره ورته وي چې غوښتنلیک یې لاسرسی کولی شي).

دلته یو مثال دی postgres:

په اصل کې هرڅه شتون لري چې موږ یې غوښتل:

تاسو کولی شئ وګورئ چې د کوم "خدمت" غوښتنه له کوم ځای څخه راغلې.

دا به غلط نه وي چې تاسو ته یادونه وکړئ چې ډیټاډګ په بشپړ ډول د NGINX انګریس سره مدغم کیږي او تاسو ته اجازه درکوي د پای څخه تر پای پورې تعقیب ترسره کړئ له هغه وخته چې غوښتنه کلسټر ته راشي ، او تاسو ته اجازه درکوي د سټیټ میټریک ترلاسه کړئ ، لاګ راټول کړئ او کوربه میټریکونه .

د ډیټاډګ یو لوی پلس د دې قیمت دی وده کوي د زیربنا څارنې څخه، APM، د ننوتلو مدیریت او مصنوعي ازموینې، د بیلګې په توګه. تاسو کولی شئ خپل پلان په نرمۍ سره وټاکئ.

2.Atatus

د اتاتوس ټیم ادعا کوي چې د دوی خدمت "د نوي ریلیک په څیر دی، مګر غوره." راځئ وګورو چې ایا دا واقعیا داسې ده.

اصلي پینل ورته ښکاري، مګر دا ممکنه نه وه چې په غوښتنلیک کې کارول شوي Redis او memcached مشخص کړي.

APM ټول لیږدونه د ډیفالټ له مخې غوره کوي، که څه هم معمولا یوازې ویب لیږد ته اړتیا وي. د Datadog په څیر، د اصلي پینل څخه مطلوب خدمت ته د تګ کولو کومه لاره نشته. سربیره پردې، لیږدونه د غلطیو وروسته لیست شوي، کوم چې د APM لپاره خورا منطقي نه ښکاري.

په اتاتوس معاملو کې، هر څه د امکان تر حده د نوي ریلیک سره ورته دي. منفي اړخ دا دی چې د هر کنټرولر لپاره متحرکات سمدلاسه نه لیدل کیږي. تاسو باید دا د کنټرولر میز کې وګورئ، په ترتیب سره ډیری وخت مصرف شوی:

د کنټرولر معمول لیست په ټب کې شتون لري پيژندګلو:

په ځینو لارو کې، دا میز د ډیټاډګ یادونه کوي او زه دا په نوي ریلیک کې د ورته ورته څخه غوره خوښوم.

تاسو کولی شئ هره معامله پراخه کړئ او وګورئ چې غوښتنلیک څه کوي:

پینل د ډیټاډګ ډیر یادونه هم کوي: یو شمیر غوښتنې شتون لري ، د تلیفونونو عمومي عکس. پورتنۍ پینل د تېروتنې ټب چمتو کوي د HTTP ناکامۍ او د ورو پوښتنو مثالونه د ناستې نښې:

که تاسو یو لیږد ته لاړ شئ، تاسو کولی شئ د ټریس مثال وګورئ، تاسو کولی شئ ډیټابیس ته د غوښتنو لیست ترلاسه کړئ او د غوښتنې سرلیکونه وګورئ. هرڅه د نوي ریلیک سره ورته دي:

په عموم کې، اتاتوس د مفصلو نښو څخه خوښ دی - پرته له دې چې د یادونې بلاک ته د تلیفونونو عادي نوي ریلیک ګلینګ کړي:

په هرصورت، دا یو فلټر نلري چې (د نوي ریلیک په څیر) به د الټرا ګړندي غوښتنې (<5ms) قطع کړي. له بلې خوا، ما د وروستي لیږد ځواب (بریالیتوب یا تېروتنه) ښودل خوښ کړل.

پینل Databases به تاسو سره د بهرنیو ډیټابیسونو غوښتنې مطالعه کولو کې مرسته وکړي چې غوښتنلیک یې رامینځته کوي. اجازه راکړئ تاسو ته یادونه وکړم چې اتاتوس یوازې PostgreSQL او MySQL موندلي، که څه هم Redis او memcached هم په پروژه کې ښکیل دي.

غوښتنې د معمول معیارونو سره سم ترتیب شوي: د ځواب فریکونسۍ، د اوسط غبرګون وخت، او داسې نور. زه غواړم د خورا ورو پوښتنو سره ټب هم ذکر کړم - دا خورا اسانه دی. برسېره پردې، د PostgreSQL لپاره پدې ټب کې ډاټا د تمدید ډاټا سره سمون لري pg_stat_statements - عالي پایله!

ټب بهرنۍ غوښتنې په بشپړه توګه د ډیټابیس سره ورته.

موندنو

دواړه وړاندې شوي وسیلې د APM رول کې ښه ترسره شوي. هر یو کولی شي اړین لږترلږه وړاندیز وکړي. زموږ تاثرات په لنډ ډول په لاندې ډول بیان کیدی شي:

ډاټاډګ

پرو:

د مناسب تعرفې مهالویش (APM د هر کوربه 31 USD لګښت لري)؛
د Python سره ښه کار وکړ؛
د OpenTracing سره د ادغام امکان
د Kubernetes سره یوځای کول؛
د NGINX Ingress سره یوځای کول.

ضمیمه:

یوازینی APM چې د ماډل غلطۍ (predis) له امله غوښتنلیک د نه شتون لامل شوی؛
کمزوری پی ایچ پی اتوماتیک وسیله؛
د خدماتو او د دوی هدف یو څه عجیب تعریف.

اتاتوس