توی قسمت دوم مسیر Observability میریم سراغ استک ELK و بعد از معرفی‌ش چنتا از کامپوننت‌هاش رو هم بررسی می‌کنیم و احتمالا یه پست دیگه هم هفته بعد داریم ازش که بقیه کامپوننت‌هایی که میمونه رو بررسی کنیم.
خب یه مروری کنیم پست‌های قبلی رو:
توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.
استک ELK:
در واقع ELK سرنام سه تا ابزار Elasticsearch و Logstash و Kibana هست. که به ترتیب برای سرچ و آنالیز لاگ‌ها، جمع آوری دیتا از سورس های مختلف و پردازش اونها، و نهایتا نمایش دیتا به صورت چارت و گراف استفاده میشن که در ادامه هر کامپوننت این استک رو بیشتر بررسی می‌کنیم. مجموعه‌ی این ابزارها در کنار یه سری ابزار دیگه راه‌حلی رو برای Observability سیستم‌ها و سرویس‌ها حتی در ابعاد شرکت‌های خیلی بزرگ ارائه می‌دهد. این ابزارها بر پایه یک تکنولوژی هست و خیلی با هم به خوبی ادغام شدن. این استک به صورت کامل و جامع میتونه راه‌حلی به شما ارائه کنه که بتونید به خوبی تمام شهودی که نیاز دارید رو بدست بیارید. البته بگم خودم یوزرش نیستم و دلایل کافی هم برای این موضوع دارم. اما به شدت به سازمان‌های بزرگی که می‌خواهند یه راه حل جامع برای این کار داشته باشند توصیه می‌کنم. فقط دقت کنید که استک سنگین و گرونی هست برای همین باید توان تامین موارد مورد نیاز آن را داشته باشید.
کامپوننت‌های استک زیبا و بزرگ ELK:
Elasticsearch:
الستیک‌سرچ یک موتور جستجو و آنالیز قدرتمند برای انواع دیتای متنی، عددی، جغرافیایی و … به صورت توزیع شده هست و متن باز توسعه یافته. دیتای الستیک هم میتونه به صورت ساختارمند باشه و هم میتونه اصطلاحا بدون استراکچر باشه. الستیک بر پایه Apache Lucene ساخته شده و اولین بار سال ۲۰۱۰ منتشر شد. الستیک ابزار مرکزی استک ELK هست و به داشتن ویژگی‌هایی مثل REST API ساده، ذات دیستریبیوتد، سرعت بالا و قابلیت اسکیل پذیری بالا، معروف هست. به زبون دیگه قلب این استک است. امکان سرچ به صورت real-time و یا پیدا کردن الگوها و ترند و پترن‌ها از کنار هم قراردادن دیتا یا حتی استفاده از هوش مصنوعی برای این کار، از قابلیت‌های دیگه‌ی الستیک هست. این ابزار به صورت کلی هرجایی که نیاز باشه سرچ کنیم، توصیه میشه! یعنی بهترین گزینه‌ی ما برای پوشش نیاز سرچ میتونیم بگیم هست و واقعا تو این کار کامل هست.
همان‌طور که گفتیم به خوبی میتونیم این دیتابیس رو توزیع کنیم و براش راهکار وجود داره و نودهای الستیک می‌تونند هرکدوم یک role مشخص داشته باشند که در ادامه انواع اونها رو بررسی می‌کنیم:
Master Nodes:
معمولا توی الستیک همه‌ی نودها master-eligible هستن به صورت دیفالت. در هر لحظه فقط یک نود مستر باید توی کلاستر باشه که طی یک فرآیند اجماع و رای گیری که بین نودهای master-eligible انجام میشه، انتخاب میشه. نود مستر وظایفی مثل ساخت و حذف ایندکس‌ها، ترک کردن نودها و اختصاص دادن شاردها به اونها رو بر عهده داره. در ادامه مسیرمون با مفهوم ایندکس و شارد آشنا میشیم.
Data Nodes:
نودهای دیتا مسئول نگهداری دیتا و انجام عملیات مرتبط با دیتا هستن. مواردی مثل:
همه‌ی نودها به صورت دیفالت نقش دیتا نود رو دارند و برای کم کردن لود این نودها میتونید اونها رو کانفیگ کنید که فقط سرچ و اگریگیشن رو انجام بدن.
Coordinating Nodes:
این نودها در واقع کار لود بالانس رو به صورت هوشمند انجام میدن و درخواست‌ها رو به صورت مستقیم سمت نودهای دیتا و مستر میفرستن. این نودها کمک میکنن تا لود روی نود مستر یا یکی از نودهای دیتا بالا نره که نقش بسیار مهمی هست توی کلاستر های بزرگ. به نودهای کوردینیت بعضا client node هم میگن و به صورت دیفالت همه‌ی نودها این نقش رو هم دارند.
Ingest Nodes:
این نودها کمک میکنن تا پیش پردازش روی دیتا انجام بشه. داکیومنت‌ها قبل از اینکه تبدیل به ایندکس بشن نیاز به یک پردازشی دارند که کار نودهای ingest هست به همین دلیل به اونها نود transform هم میگن چون دیتا توی اونها از داکیومنت تبدیل میشه به ایندکس. بعضی سازمان ها از نودهای ingest به جای Logstash برای پایپ کردن و پردازش دیتا استفاده میکنن. به صورت دیفالت همه ی نود ها نقش ingest رو هم دارن.
Hot data Node:
نمیتونیم همه دیتای لاگ و … رو برای همیشه و با اهمیت یکسان بخواهیم نگه داریم کارمون خیلی سخت میشه. اینجا سر و کله مفهوم Tiering پیدا میشه، میاییم یه سری مرحله برای دیتامون تعریف می‌کنیم که به مرور با گذشت زمان دیتاهایی که دیگه ازشون زیاد استفاده نمی‌کنیم یا کمتر مورد استفاده هستند رو به سمت این ببریم که حذفشون کنیم یا روی نودهایی ذخیره کنیم که ارزونتر هستند، مشابه این مفهوم رو توی آبجکت استورج‌ها هم داریم. حالا هات دیتا نودها در واقع نودهایی هستن که دیتای ما رو که اخیرا ایجاد شده و بیشترین سرچ رو اون هست رو نگهداری میکنه. این نودها نیاز دارند که سرعت خواندن و نوشتن بالایی داشته باشند به همین علت استفاده از دیسک های SSD توی اونها متداول هست. معمولا نودهای هات ما نودهای گرون‌تری هستند که ظرفیت کمی دارند اما سرعت خیلی بالایی به ما می‌دهند.
Warm data Node:
توی Tier بعدی دیتا به نود warm منتقل میشه. دیتایی که توی نودهای هات ایندکس شده رو و معمولا مرتبط با هفته‌های اخیر هست، وارد نود وارم میشه و اینجا هم امکان آپدیت دیتا هست اما معمولا به دفعات کمتری نسبت به زمانی که در نود هات بود. یه جورایی دیتاهایی که کمتر از دیتاهای هات دیده می‌شند اینجا منتقل می‌شوند و نگهداری میشن. نودهای این tier ارزونتر از نودهای هات هستند و معمولا هاردهایی که دارند ارزونتر است و مثلا هاردهای SAS دارند. ظرفیتی بالاتر در عین حال سرعت کمتری که نسبت به ssdها دارند.
Cold data Node:
توی Tier بعدی که cold هست معمولا دیتایی قرار می‌گیره که دیگه به شکل معمول نیاز نداریم روی اون سرچ بزنیم، گرچه همچنان امکان اینکه سرچ رو انجام بدیم داریم. توی نودهای کولد معمولا از دیسک های با هزینه کمتر و ظرفیت بیشتر استفاده میشه. مثلا اینجا میریم سراغ دیسک‌های HDD که ظرفیت‌های خیلی بالایی در اختیار ما قرار می‌دهند ولی سرعتشون زیاد مطلوب نیست ماهم داریم دیتایی روی آنها قرار می‌دیم که انتظار داریم نسبت به دیتاهای دیگه کمتر سرچ بشه و سراغشون بریم.
Frozen data Node:
و نهایتا توی Tier بعدی که frozen هست دیگه بقیه طول عمر خودش رو سپری میکنه. معمولا دیتای توی این نودها به ندرت کوئری در موردشون هست.
این مدل ذخیره‌سازی و چرخه‌ی Tiering که براتون گفتم برای مواقعی هست که ما باید دیتاها رو برای مدت زیادی نگه داریم و عملا هیچ وقت قرار نیست اونها رو پاک کنیم و عمرشون همیشگی هست. این چرخه آنقدر کارا و خوبه که می‌تواند در انتهای عمر خود به سمت Tapeها برسه که ظرفیت‌های خیلی خیلی زیادی رو با سرعت کمی داریم و مثلا طول عمر دیتا روی آنها به بیش از ۳۰ سال ممکنه برسه. می‌بینید برای همه‌ی این مسیر راهکار وجود داره و به خوبی میتونیم با الستیک سرچ کامل آن را پوشش بدیم. الله اکبر
دوتا کانسپت اولیه هم توی الستیک داریم که خوبه باهاش آشنا باشید:
Index:
ایندکس‌های الستیک دسته بندی های لاجیکی از داکیومنت‌ها هستن که میتونیم اونها رو معادل table دیتابیس‌ها توی دنیای دیتابیس‌های رابطه‌ای بدونیم.
Documents:
داکیومنت‌ها توی الستیک سرچ آبجکت‌ها به فرمت JSON هستن که توی ایندکس‌های الستیک ذخیره میشن و میتونیم اونها رو واحد پایه‌ای استورج بدونیم. داکیومنت‌ها رو میشه معادل یک ردیف از جدول توی دنیای دیتابیس های رابطه ای دونست.
Logstash:
لاگ استش کامپوننتی هست که نقش صف رو توی کلاستر بازی میکنه و ورودی‌ها از سورس‌های مختلف اول سمت لاگ استش میان اونجا از یه سری فیلتر رد میشن و نهایتا خروجی لاگ استش به پلاگین‌های خروجی فرستاده میشه برای قرارگیری در کلاستر الستیک سرچ. خب حالا که فهمیدیم دیتا قرار هست توی لاگ استش parsing براش اتفاق بیافته، با دوتا فیلتر مرسوم هم آشنا بشیم: اولی dissect هست که دیتا رو بر اساس یه سری جداکننده یا دلیمیتر فیلتر میکنه و دومی هم grok هست که بر پایه regular expression ها کار میکند. به طور کلی گروک ابزار قدرتمند‌تری هست و میتونه دیتا متنوع‌تری رو هندل کنه اما به تبع آن ریسورس بیشتری رو هم استفاده میکنه و میتونه کندتر باشه مخصوصا اگه به خوبی کانفیگ و آپتیمایز نشه.
موقع ساخت یک کانفیگ گروک یه تعداد پترن استاندارد مشخص وجود داره که معمولا استفاده میشن در ادامه یه لیستی از اونها رو براتون میارم:
یه نمونه Grok پترن رو در ادامه قرار می‌دم که بتونیم باهاش ارتباط بهتری برقرار کنیم.
در ادامه یک خط از لاگ سرویس traefik رو می‌بینیم که می‌خواهیم اون رو با استفاده از grok بررسی و پارسش کنیم.
192.168.100.2 - - [16/Aug/2024:15:16:46 +0000] "GET /service/rest/v1/user-telemetry/events/rte/v2/kc?s=AP-YFGMCGUNNIFB-2-1723821391781-23826591&p=AP-YFGMCGUNNIFB-2 HTTP/1.0" 200 0 "-" "-" 7750 "repo@docker" "http://172.18.0.3:8081" 289ms
پترن استاندارد برای فیلتر آن به صورت زیر میشه.
%{IPV4:client_ip} - - \[%{HTTPDATE:timestamp}\] "%{WORD:method} %{URIPATHPARAM:request} HTTP/%{NUMBER:http_version}" %{NUMBER:status_code} %{NUMBER:bytes} "-" "-" %{NUMBER:request_time:int} "%{DATA:backend_name}" "%{URI:backend_url}" %{NUMBER:request_duration:int}ms
توضیح هر کدوم از قسمت‌های پترن مورد استفاده شده رو در ادامه میتونیم ببینیم.
%{IPV4:client_ip}: Matches the client IP address (192.168.100.2).-: Matches the hyphen (-) for both the ident and user fields, which are placeholders.%{HTTPDATE:timestamp}: Matches the timestamp ([16/Aug/2024:15:16:46 +0000]).%{WORD:method}: Matches the HTTP method (GET).%{URIPATHPARAM:request}: Matches the request path and query parameters (/service/rest/v1/user-telemetry/events/rte/v2/kc?s=AP-YFGMCGUNNIFB-2-1723821391781-23826591&p=AP-YFGMCGUNNIFB-2).%{NUMBER:http_version}: Matches the HTTP version (1.0).%{NUMBER:status_code}: Matches the HTTP status code (200).%{NUMBER:bytes}: Matches the size of the response in bytes (0)."-": Matches the referer and user-agent, which are placeholders.%{NUMBER:request_time:int}: Matches the request time in milliseconds (7750).%{DATA:backend_name}: Matches the backend name (repo@docker).%{URI:backend_url}: Matches the backend URL (http://172.18.0.3:8081).%{NUMBER:request_duration:int}ms: Matches the request duration in milliseconds (289ms).و در انتها هم کانفیگ لاگ‌استش ما برای تحلیل این لاگ به صورت زیر خواهد بود.
filter {
grok {
match => { "message" => "%{IPV4:client_ip} - - \[%{HTTPDATE:timestamp}\] \"%{WORD:method} %{URIPATHPARAM:request} HTTP/%{NUMBER:http_version}\" %{NUMBER:status_code} %{NUMBER:bytes} \"-\" \"-\" %{NUMBER:request_time:int} \"%{DATA:backend_name}\" \"%{URI:backend_url}\" %{NUMBER:request_duration:int}ms" }
}
}
همان طور که در مراحل بالا دیدید لاگی که می‌تونیست برای ما نامفهوم باشه و به صورت raw لاگ داخل الستیک سرچ ذخیره بشه الان به صورت کامل پارس شده و میتونیم روی هر کدوم از قسمت‌های آن سرچ کنیم. مثلا اون کلاینت‌هایی که استتوس کد ۳۰۰ یا ۴۰۰ دارن رو جدا کنیم و پیداشون کنیم.
این میشه یه آشنایی اولیه با استک ELK توی پست بعدی سعی می‌کنیم بقیه کامپوننت ها رو هم تکمیل کنیم و مسیر Observability رو ادامه بدیم و کنار هم یاد بگیریم.
مراقب خودتون باشید. 🌹🐳🌹
خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.
🫀 Follow DockerMe 🫀
🔔 Follow YouTube 🔔
📣 Follow Instagram 📣
🖇 Follow LinkedIn DockerMe🖇
🔎 Follow Linkedin Ahmad Rafiee 🔎
🕊 Follow Twitter 🕊
