راهاندازی یک خط لوله پایه برای تحلیل لاگ
تیم متابیس
انتخاب ابزارها برای تمیز کردن، تجزیه و ساختاردهی داده لاگ میتواند طاقتفرسا (و گران) باشد. اما وقتی تازه شروع میکنید، میتوانید با یک راهاندازی ساده برای تحلیل موردی با یک ابزار BI مانند Metabase از آن خلاص شوید. در اینجا چند روش بهترین برای راهاندازی یک خط لوله پایه برای تحلیل لاگ وجود دارد.
استفاده از یک ابزار اتصال داده به عنوان میانبر برای ورود
ابزارهایی مانند Airbyte میتوانند به سرعت به پایگاه داده شما متصل شوند و لاگها را برای شما ساختاردهی کنند. منبع لاگ خود را انتخاب کنید، مانند AWS CloudTrail، و آن را به یک پایگاه داده، مانند Snowflake (یک راهحل نسبتاً آسان، مقیاسپذیر، با هزینه معقول)، یا AWS Aurora Serverless Postgres (یک راهحل آسان، تا حدودی مقیاسپذیر، کمهزینه) متصل کنید.
ابزارهای ETL دیگر، مانند Fivetran یا Stitch، به روشی مشابه کار میکنند. آنها از یک اتصالدهنده برای انتقال داده لاگ از یک منبع، مانند CloudTrail، به پایگاه داده شما استفاده میکنند. همچنین میتوانید از یک ابزار ETL استفاده کنید و مدلسازی داده را به صورت همزمان انجام دهید تا برخی از کارهای سنگینتر را برای شما انجام دهد.
استفاده از یک ارائهدهنده ابری واحد برای نگه داشتن همه چیز تحت یک سقف
Google Cloud Logging با BigQuery متصل میشود تا بتوانید به طور خودکار لاگها را مستقیماً به انبار داده خود وارد کنید. AWS گزینههای لاگ متعددی دارد، مانند CloudTrail یا CloudWatch، که میتوانید به یکی از گزینههای پایگاه داده آنها، مانند Postgres for RDS متصل کنید. Azure Monitor نیز قابلیتهای لاگ و ذخیرهسازی دارد.
مورد استفاده پیشرفته: تخلیه لاگها از چندین سرویس AWS به یک سطل S3 و پرسوجوی آنها با Athena
اگر کمی تجربه با سرویسهای ابری، مانند AWS دارید، میتوانید از یک مجموعه کامل از سرویسهای ابری برای گرفتن لاگها از چندین سرویس مختلف و فشار دادن آنها به یک مکان مرکزی برای آمادهسازی برای تحلیل استفاده کنید.
به عنوان مثال، لاگهای سرور وب یا برنامه را از نمونههای EC2 خود به یک سطل S3، همراه با لاگهای CloudTrail خود فشار دهید. سطل S3 خود را به یک ابزار پرسوجو، مانند Athena، متصل کنید تا بتوانید چند جدول ایجاد کنید برای استفاده در تحلیل. پس از داشتن جداول، میتوانید به ابزار تحلیل خود متصل شوید و یک داشبورد عیبیابی ایجاد کنید، مانند یکی که رویدادهای EC2 را به حوادث CloudTrail برای تحلیل علت ریشه نقشهبرداری میکند.
در اینجا برخی از گزینههای لاگ AWS دیگر وجود دارد که میتوانید با S3 و Athena استفاده کنید:
- CloudWatch: ذخیره لاگهای برنامه، سیستم یا سفارشی
- RDS: ذخیره لاگهای خطا، پرسوجوی کند یا تراکنش
- Lambda: ذخیره لاگهای lambda که شامل جزئیات اجرا، پیامهای خطا و عبارات لاگ سفارشی هستند
- Elastic Load Balancer (ELB): ذخیره لاگهای ELB که شامل آدرس IP مشتری، زمان درخواست و کد وضعیت پاسخ هستند
اگر میخواهید یک قدم جلوتر بروید، میتوانید Athena را به dbt متصل کنید و نحوه نوشتن تبدیلهای داده خود در SQL را یاد بگیرید. dbt کنترل نسخه، استقرار و تست را بدون نیاز به اجرای ابزارهای فردی ساده میکند. با این حال، ما فقط این راهاندازی را توصیه میکنیم اگر با مدلسازی داده و ابزارهای توسعهدهنده آشنا هستید.
بارگذاری دستهای لاگها برای کارایی
باید لاگهای خود را به صورت دستهای مستقیماً به انبار داده خود، یا یک گزینه ذخیرهسازی مانند S3، بارگذاری کنید تا از تأخیر و مصرف منابع جلوگیری کنید. بیشتر سرویسهای ابری یک سرویس دستهای ارائه میدهند جایی که میتوانید کارها را برنامهریزی و صفبندی کنید. توجه داشته باشید اگر برای یک پایگاه داده یا ذخیره لاگ پول میپردازید، ابتدا قیمت بارگذاری دستهای را دوباره بررسی کنید زیرا برخی سرویسهای ابری به ازای هر بارگذاری دستهای شارژ میکنند.
استفاده از یک کتابخانه کلاینت پایگاه داده یا اتصالدهنده برای ورود
نداشتن دسترسی به یک ابزار اتصالدهنده مشکل نیست، اما ممکن است کار توسعه بیشتری نیاز داشته باشد. استفاده از یک کتابخانه کلاینت پایگاه داده یا درایور موجود میتواند به شما کمک کند تا لاگها را مستقیماً در زمان لاگ به ذخیرهسازی / انبار داده وارد کنید.
به عنوان مثال، Postgres درایور دارد، و MySQL اتصالدهنده دارد. از یکی از اینها برای اتصال به پایگاه داده خود بدون نیاز به اختراع مجدد چرخ استفاده کنید.
مطمئن شوید که لاگهای شما شامل timestamp، منبع، پیام و سطح لاگ هستند
چهار منطقه وجود دارد که ما توصیه میکنیم به فایلهای لاگ خود اضافه کنید تا تحلیل لاگ روانتر شود:
- Timestampها: ایجاد یک دنباله از رویدادها آسانتر خواهد شد. Timestampها به ویژه مهم هستند اگر از یک ابزار تحلیل برای ایجاد داشبورد برای نظارت بر عملکرد، یا حسابرسی و انطباق استفاده میکنید.
- منبع: مانند سرویسی که لاگ را ایجاد کرده است، اما همچنین کدام مکان/فایل/زیرسرویس لاگها از آن میآیند. میتوانید از فیلد سرویس برای عیبیابی، یا فقط برای سنجش اینکه کدام منابع به هر سرویس اختصاص داده شدهاند استفاده کنید.
- پیام لاگ: پیامها را واضح و مختصر نگه دارید تا بتوانید هر رویداد را درک کنید. کلمات کلیدی را دوباره استفاده کنید تا فیلتر کردن و یافتن آنچه در طول تحلیل متنی نیاز دارید آسانتر شود.
- سطح لاگ: میتوانید روی سطوحی مانند
ALERTوCRITICALفیلتر کنید تا به پایین آن برسید که کدام لاگ نیاز به بررسی و پاسخ فوری دارد.
روشهای بهترین و ایدههای اضافی برای تحلیل لاگ
اگر هدف شما تحلیل لاگ در زمان واقعی، یا تحلیل پیشرفته یا مکرر لاگ است، ابزارهای خاص لاگ تمایل دارند که مناسبتر باشند. اگر تیم شما قبلاً از یک پشته ELK استفاده میکند، یک ابزار مانند Grafana میتواند مناسب باشد.
در اینجا چند منبع اضافی وجود دارد که میتوانید برای تصمیمگیری هنگام ساخت یک خط لوله لاگ در مقیاس کوچک استفاده کنید:
