‏از تست نویسی مهم تر داشتن متریک لازم و کافی در همه جای کد هست، تا میتونید نقاط مهم کدی که مینویسید رو در لحظه متر کنید، نوشتن متریک رو همون لحظه که کد پروداکشن مینویسید اضافه کنید و به تعویقش نندازید.

@gocasts

#observability

لایو ورکشاپ اول RahBia
برگشتیم برای پارت دوم ...
🔥🔥🔥
🔗لینک

نمونه‌برداری و کاهش چشمگیر هزینه‌ها در Tracing بدون از دست دادن Visibility

قبل اینکه بریم سراغ sampling توضیح کوتاهی درباره trace و span بخونیم:
یک trace رو می‌تونیم به‌عنوان نماینده‌ ی یک کار کامل تو سیستم در نظر بگیریم. مثلا وقتی کاربر درخواست ثبت سبد خرید میده، این عملیات به‌صورت کامل یک Trace حساب می‌شه.

هر Span یک بخش کوچک از اون Trace هست. مثلاً برای ثبت سبد خرید، ممکنه چند سرویس درگیر بشن (مثل بررسی موجودی، محاسبه‌ی تخفیف، ثبت در پایگاه داده و ...) که هر کدوم از این مراحل می‌تونه یک Span جدا باشه. در نهایت، این Spanها کنار هم قرار می‌گیرن و یک کار کامل یعنی trace رو تشکیل می‌دن.

پس با استفاده از traces (یا همون ردپاها)، می‌تونید با دقت بررسی کنید یک درخواست از کجا شروع شده، به کدوم سرویس‌ها رفته، و حتی در هر فانکشن یا لایه چقدر زمان برده تا پردازش بشه.
می‌تونید اطلاعات اضافی (Attributes) یا رویدادهایی که اتفاق افتاده رو هم به هر Span اضافه کنید. در کل، Trace ابزار فوق‌العاده‌ای برای تحلیل دقیق و عمیق رفتار سیستمتونه.

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

نمونه برداری یعنی چی؟

نمونه برداری یعنی تصمیم بگیریم کدوم Traceها نگه‌داری (Sampled) بشه و کدوم رو حذف کنیم (Not Sampled).
هدف اینه که با یه درصد کوچیک و حساب‌شده از داده‌ها، تصویری واضح از وضعیت سیستم داشته باشیم.

مثلا اگه شما هزار تا Trace در ثانیه تولید می‌کنید، نگه داشتن ۱۰۰٪ اونا هم پرهزینه‌ست و هم اغلب غیرضروری. توی این شرایط، یه نرخ Sampling حتی در حد ۱٪ هم می‌تونه نماینده خوبی از رفتار کلی سیستم باشه.

چه زمانی باید از Sampling استفاده کنیم؟

* وقتی تعداد زیادی Trace در ثانیه تولید می‌کنید (مثلا بیشتر از ۱۰۰۰ تا)
* وقتی بیشتر ترافیک شما سالم و بدون خطاست
* وقتی بتونید با قواعد خاصی (مثل خطا داشتن یا latency زیاد) تصمیم بگیرید که چه Traceهایی مهم‌ترن
* وقتی بودجه محدودی برای observability دارید

همچنین ما دو نوع نمونه برداری داریم:

1. Head Sampling

اینجوریه که تو لحظه ای که یک تریس ایجاد میشه، براساس ID و بدون درنظر گرفتن محتوا تصمیم‌گیری میکنه که این تریس سمپل هستش یا نه.
مزیتش اینه ساده و سریعه، ولی نمی‌تونه مثلا تشخیص بده که آیا داخل اون Trace خطا بوده یا نه.
مثال استفادش مثلا میگیم پنجاه درصد کل درخواست هارو نگه دار.

2. Tail Sampling

نمونه برداری بعد از اینکه کل Trace جمع‌آوری شد. می‌تونه براساس شرایطی مثل داشتن خطا، زیاد بودن latency، یا حتی اطلاعات مربوط به یک سرویس خاص تصمیم بگیره. خیلی قدرتمنده ولی نسب به head sampling منابع و هزینه بیشتری میخواد.

مثال tail sampling:
– هر Trace که error داشته باشه رو حتما نگه دار
– اگه latency بالای ۳ ثانیه بود، نگه دار
– تریس هایی که از سرویس جدیدمون شروع می‌شن رو بیشتر نگه دار

گاهی ترکیب Head و Tail Sampling بهترین راهه

مثلا ممکنه یه سیستم خیلی پرحجم اول با Head Sampling فقط ۱۰٪ داده‌ها رو رد کنه، بعد اون ۱۰٪ رو بیاره داخل یه سیستم Tail Sampling تا براساس هوشمندی بیشتر تصمیم بگیره چی رو نگه داره.

پیاده سازی عملی:
ما تو پروژه اپن سورس و مدرن Quick-Connect از opentelemetry برای جمع آوری تریس ها استفاده کردیم و از head sampling هم برای نمونه برداری استفاده کردیم که توی کانفیگ میتونید مشخص کنید به چه صورت باشه.
اگه 0 تنظیم کنید هیچی تریس نمیکنه و اگه 1 تنظیم کنیم صد درصد تریس میکنه.
برای اینکه مشخص کنید ده درصد باشه میتونید روی 0.1 تنظیمش کنید.

https://github.com/syntaxfa/quick-connect/tree/main/adapter/observability/traceotela


#trace #sampling #opentelemetry #observability

@Syntax_fa

🔵 عنوان مقاله
Observe Live SQL Queries in Go with DTrace

🟢 خلاصه مقاله:
این مطلب از Golang Weekly نشان می‌دهد چطور با استفاده از DTrace بدون تغییر کد و توقف سرویس، کوئری‌های SQL را در برنامه‌های Go به‌صورت زنده مشاهده کنیم. نویسنده با معرفی کوتاهی از DTrace به‌عنوان یک ابزار ردیابی پویا و کم‌سربار، قدم‌به‌قدم نحوه راه‌اندازی روی سیستم‌عامل‌های پشتیبانی‌شده، اتصال به پردازه در حال اجرا و نوشتن اسکریپت‌های ساده برای دیدن متن کوئری، زمان اجرا و الگوهای فراوانی را توضیح می‌دهد؛ همراه با فیلترگذاری برای محدود کردن خروجی به سرویس/کاربر/درایور موردنظر و نکاتی برای حفظ سربار کم.

کاربرد این روش، عیب‌یابی سریع مسائلی مثل کوئری‌های کند، الگوهای N+1، شاخص‌های مفقود و ORM پرحرف در شرایط واقعی تولید است. این رویکرد مکمل لاگ‌ها و APM است و امکان تشخیص فوری و تأیید سریع اصلاحات را می‌دهد. در بخش ملاحظات، به تفاوت پشتیبانی پلتفرم‌ها (مثل FreeBSD و برخی نسخه‌های macOS؛ و پیشنهاد eBPF روی Linux)، نیاز به دسترسی‌های بالا، حساسیت داده‌های متنی کوئری و ضرورت سنجش سربار در محیط staging اشاره می‌شود.

#Go #DTrace #SQL #Observability #Performance #GolangWeekly #eBPF #Database

🟣لینک مقاله:
https://golangweekly.com/link/174425/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Fibratus: Windows Kernel Exploration and Observability Tool

🟢 خلاصه مقاله:
فایبراتوس یک ابزار کاوش و Observability برای کرنل Windows است که اکنون بر «تشخیص، محافظت و شکار ترفندهای مهاجم» تمرکز دارد. این ابزار رویدادهای سیستمی مانند file I/O و درخواست‌های شبکه را جمع‌آوری می‌کند و با اسکن حافظه، تصویری دقیق از رفتار برنامه‌ها ارائه می‌دهد. چنین دیدی به تیم‌های امنیتی کمک می‌کند الگوهای مشکوک را شناسایی کنند، هشدارهای مهم را اولویت بدهند و در شکار تهدیدها و رسیدگی به رخدادها سریع‌تر عمل کنند. فایبراتوس همچنین برای توسعه‌دهندگان و تیم‌های IT که به درک عمیق‌تر از رفتار برنامه‌ها روی Windows نیاز دارند مفید است و از طریق مخزن GitHub در دسترس است.

#Fibratus #Windows #Kernel #Observability #ThreatHunting #Security #MemoryScanning

🟣لینک مقاله:
https://golangweekly.com/link/174657/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Flight Recorder in Go 1.25

🟢 خلاصه مقاله:
Flight Recorder در Go 1.25 ابزاری تشخیصی است که به‌صورت پیوسته ردیابی اجرای برنامه را ضبط می‌کند و چند ثانیه‌ی اخیر را در یک بافر چرخشی نگه می‌دارد. مزیت اصلی این است که پس از وقوع مشکل، می‌توان همان پنجره زمانیِ مرتبط را ذخیره و تحلیل کرد، بدون نیاز به فعال‌بودنِ دائمیِ ردیابی سنگین. این قابلیت برای عیب‌یابی مسائل گذرا در محیط production—مثل افزایش مقطعی تاخیر، بن‌بست‌ها، رقابت بر سر قفل‌ها یا تعاملات GC—با سربار کم مفید است و زمان رسیدن به ریشه مشکل را کاهش می‌دهد. همچنین می‌توان بخش ضبط‌شده را صادر کرد و در ابزارهای آشنای ردیابی Go بررسی نمود تا اتفاقات منتهی به رخداد به‌روشنی دیده شود.

#Go #Go125 #FlightRecorder #Tracing #Diagnostics #Observability #ProductionDebugging #Profiling

🟣لینک مقاله:
https://golangweekly.com/link/175049/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
celebrates its tenth anniversary with a look

🟢 خلاصه مقاله:
این مقاله دهمین سالگرد یک ابزار زیرساختی متن‌باز مبتنی بر Go را جشن می‌گیرد و نشان می‌دهد چگونه از یک ابزار کوچک به مولفه‌ای بالغ و شناخته‌شده در تیم‌های DevOps و SRE تبدیل شده است؛ با بهبودهای کارایی و پایداری، معماری افزونه‌پذیر، API/CLI پایدار و تمرکز جدی بر امنیت و زنجیره تأمین. اکوسیستم آن با جامعه‌ای پویا، مستندات بهتر، نسخه‌بندی معنادار، سازگاری عقب‌رو و یکپارچگی گسترده با فضای ابری، CI/CD و ابزارهای مشاهده‌پذیری رشد کرده است. در ادامه، نقشه‌راه بر بهبود تجربه کاربری، غنی‌تر شدن API/SDK، تقویت policy-as-code، مدیریت بهتر وضعیت و دریفت، و اتوماسیون ایمن‌تر در مقیاس تأکید می‌کند.

#Go #Infrastructure #DevOps #OpenSource #Cloud #Automation #Security #Observability

🟣لینک مقاله:
https://golangweekly.com/link/175053/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
AWS Lambda for Go 1.50

🟢 خلاصه مقاله:
این مقاله اعلام می‌کند که AWS Lambda از Go 1.50 پشتیبانی می‌کند و مجموعه‌ای از نمونه‌ها و ابزارها برای ساخت سرویس‌های Serverless ارائه می‌دهد. محورها شامل استفاده از کتابخانه aws-lambda-go، ادغام با رویدادهای Amazon API Gateway، Amazon S3، Amazon DynamoDB و AWS Step Functions، و مشاهده‌پذیری از طریق Amazon CloudWatch و AWS Lambda Powertools for Go است. برای استقرار و اتوماسیون، از AWS SAM، AWS CDK و Serverless Framework استفاده می‌شود؛ تست محلی با AWS SAM CLI و شبیه‌ساز رابط زمان‌اجرا ممکن است، و استقرار هم به‌صورت zip و هم Container Image پشتیبانی می‌شود. نکات عملی شامل ساخت باینری‌های کوچک برای linux/amd64 یا linux/arm64، بهره‌گیری از Lambda Layers، بهینه‌سازی سرداستارت با مقداردهی اولیه سراسری و Provisioned Concurrency، تنظیم بهینه حافظه/CPU، انتخاب arm64 برای کارایی-به‌ازای-هزینه، و مدیریت امن رازها با AWS Secrets Manager یا AWS Systems Manager Parameter Store است؛ همچنین برای مهاجرت از نسخه‌های قبلی Go بر بررسی وابستگی‌ها و تنظیم پرچم‌های ساخت تأکید می‌شود.

#AWS #AWSLambda #Go #Serverless #Cloud #DevOps #InfrastructureAsCode #Observability

🟣لینک مقاله:
https://golangweekly.com/link/175649/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Livecore: A Low-Pause Core File Dumper for Linux Processes

🟢 خلاصه مقاله:
این مقاله Livecore را معرفی می‌کند؛ ابزاری برای گرفتن core file از فرایندهای در حال اجرای Linux با وقفه بسیار کم. این ابزار که در یک جلسه «vibe coding» توسط Brad Fitzpatrick (عضو پیشین تیم Go) ساخته شده، امکان ساخت آنی و کم‌اختلال snapshot از حافظه و وضعیت اجرای فرایند را فراهم می‌کند تا بدون متوقف کردن سرویس، داده‌های لازم برای عیب‌یابی به‌دست آید. به‌جای تکیه بر crash یا توقف کامل فرایند، Livecore با بهره‌گیری از goref و قابلیت‌های Linux تلاش می‌کند تصویری دقیق و با سربار اندک تهیه کند و برای بررسی با ابزارهای post-mortem به کار رود. نتیجه، ابزاری عملی برای تیم‌های توسعه و SRE است که به observability کم‌اختلال—به‌ویژه در سرویس‌های Go روی Linux—نیاز دارند.

#Livecore #Linux #CoreDump #Debugging #Go #Observability #BradFitzpatrick #goref

🟣لینک مقاله:
https://golangweekly.com/link/176630/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy