در چشمانداز مدرن توسعه برنامه، قابلیت مشاهده (Observability) تنها یک کالای لوکس نیست، بلکه ضرورتی است. در حالی که متریکها و ردیابیها بینشهای ارزشمندی درباره عملکرد سیستم ارائه میدهند، لاگها زمینه جزئی و زمانی مورد نیاز برای عیبیابی مسائل پیچیده را فراهم میکنند. با این حال، دادههای خام لاگ اغلب ساختارمند نیستند، حجیم هستند و پرسوجو در آنها دشوار است. اینجاست که ترکیب گرافانا و گرافانا لوکی درخشش میکند.
این راهنما شما را در معماری مجموعه ابزار (Stack) گرافانا لوکی قدم به قدم پیش میبرد و نشان میدهد که چگونه میتوان لاگها را به طور موثر تجسم کرد. ما بر الگوهای متوسط تا پیشرفته، از جمله تجزیه لاگ، فیلتر کردن بر اساس برچسبها و ساخت داشبوردهای عملیاتی تمرکز خواهیم کرد.
درک معماری لوکی
قبل از ورود به جزئیات پیکربندی، درک این نکته حیاتی است که چرا لوکی از مجموعه ابزار ELK (الستیکسرچ، لاگشات، کوبانا) متمایز است. برخلاف الاستیکسرچ که تمام محتوای لاگها را نمایهسازی میکند، لوکی از روشی مشابه پرمتهئوس استفاده میکند. این سیستم تنها متادیتا (برچسبها) را نمایهسازی کرده و خطوط لاگ واقعی را در قطعات (Chunks) ذخیره میکند. این تصمیم معماری منجر به هزینههای زیرساختی به مراتب کمتر و عملکرد پرسوجوی سریعتر برای بیشتر موارد استفاده میشود.
اجزای اصلی عبارتند از:
- لوکی (Loki): خود سیستم تجمیع لاگ.
- پرموتیل (Promtail): عاملی که روی میزبانها یا خوشههای شما اجرا میشود، لاگها را دنبال کرده و آنها را به لوکی ارسال میکند.
- گرافانا (Grafana): لایه تجسم که برای نمایش دادهها از لوکی پرسوجو میکند.
پیکربندی پرموتیل برای دادههای ساختارمند
یکی از بزرگترین چالشها در تجسم لاگ، مدیریت متنهای ساختارمند نیست. برای قابل پرسوجو کردن لاگها در گرافانا، باید آنها را با برچسبها غنی کرده و در صورت امکان، آنها را به فرمتهای ساختارمند مانند JSON تجزیه کنید.
در زیر یک مثال عملی از پیکربندی برای یک فایل `promtail.yaml` آورده شده است. این پیکربندی نشان میدهد که چگونه میتوان لاگهای کوبرنِتِس را هدف قرار داد، برچسبهای خاص را استخراج کرد و پیکربندیهای JSON را از خروجی استاندارد (stdout) برنامه تجزیه نمود.
server:
http_listen_port: 9080
grpc_listen_port: 0
positions:
filename: /tmp/positions.yaml
clients:
- url: http://loki:3100/loki/api/v1/push
scrape_configs:
- job_name: kubernetes-pods
kubernetes_sd_configs:
- role: pod
# Relabeling to extract metadata
relabel_configs:
- source_labels: [__meta_kubernetes_pod_label_app]
target_label: app
- source_labels: [__meta_kubernetes_namespace]
target_label: namespace
# Parsing JSON logs for better visualization
pipeline_stages:
- json:
expressions:
level: level
message: msg
trace_id: traceID
با استخراج `level` (سطح)، `message` (پیام) و `trace_id` به فیلدها، گرافانا میتواند آنها را به عنوان ستونها یا فیلترهای خاص رندر کند که این امر تجربه کاربری را برای توسعهدهندگانی که در حال عیبیابی مشکلات هستند، به شدت بهبود میبخشد.
نوشتن پرسوجوهای لاگ کارآمد
پس از اینکه لاگهای شما به لوکی جریان یافتند، باید بدانید چگونه به طور کارآمد از آنها پرسوجو کنید. لوکی از سینتکس LogQL استفاده میکند که انتخابگرهای جریان (Stream selectors) را با پردازشگرهای جریان لاگ ترکیب میکند.
یک پرسوجوی ساده به این شکل است:
{app="frontend", namespace="production"}
این دستور تمام لاگهای برنامه فرانتاند را در نامفضای تولید (Production) برمیگرداند. برای مفیدتر کردن این دادهها، باید پردازشگرهای جریان لاگ را به هم متصل کنید. برای مثال، برای فیلتر کردن خطاهای بحرانی:
{app="frontend", namespace="production"} |~ "ERROR"
عملگر `|~` از تطبیق با عبارت منظم (Regular Expression) استفاده میکند. برای فیلتر کردن پیچیدهتر، میتوانید فیلدهایی را که در مرحله قبل تجزیه شدهاند، استخراج کنید:
{app="frontend", namespace="production"} | json | level="error"
درک این خطوط لوله به شما امکان میدهد داشبوردهای پویایی ایجاد کنید که کاربران میتوانند به راحتی بین لاگهای هشدار و خطا جابجا شوند.
ساخت داشبوردهای عملیاتی
تجسم، مرحله نهایی است. در گرافانا، میتوانید یک داشبورد ایجاد کرده و یک پنل "Logs" اضافه کنید. قدرت واقعی در پیوند دادن متریکها به لاگها نهفته است. با پیکربندی لینکهای پنل، میتوانید روی یک قله در متریک استفاده از CPU کلیک کرده و بلافاصله با استفاده از تفسیر متغیرها، به لاگهای خطای مربوطه نفوذ کنید.
برای مثال، اگر پنلی دارید که تأخیر بالای درخواست را نشان میدهد، میتوانید لینکی اضافه کنید که به طور خودکار لاگها را بر اساس همان بازه زمانی و برچسب سرویس فیلتر کند و زمینهای فوری برای ناهنجاریها فراهم آورد.
نتیجهگیری
تجسم لاگها با گرافانا و لوکی، جریانهای متنی آشفته را به داراییهای ساختارمند و قابل پرسوجو تبدیل میکند. با بهرهگیری از برچسبگذاری مناسب، تجزیه JSON و پرسوجوهای LogQL کارآمد، توسعهدهندگان و متخصصان SRE میتوانند زمان متوسط برای رفع مشکل (MTTR) را به طور قابل توجهی کاهش دهند. اگرچه راهاندازی اولیه نیازمند توجه به جزئیات است، اما مزایای بلندمدت آن در زمینه صرفهجویی در هزینهها و کارایی عملیاتی، آن را به انتخابی مستحکم برای استراتژیهای قابلیت مشاهده مدرن تبدیل میکند. با پیادهسازی لاگنویسی ساختارمند در برنامههای خود شروع کنید و ببینید که روند عیبیابی شما از آتشنشانی واکنشی به تحلیل پیشدستانه تکامل مییابد.