Grafana: تابش نور به خوشه های Kubernetes

خالق Grafana، Torkel Ödegaard، سفر پروژه منبع باز را دنبال می‌کند تا به توسعه‌دهندگان کمک کند تا آنچه را که در داخل زیرساخت‌های ابری توزیع‌شده می‌گذرد تجسم کنند.

در سال ۲۰۱۴، زمانی که موج کانتینرها، Kubernetes، و محاسبات توزیع شده در صنعت فناوری رخنه کرده بود، Torkel Ödegaard به عنوان یک مهندس پلتفرم در eBay سوئد کار می کرد. مانند سایر پیشگامان devops، اودگارد با فاکتور شکل جدید میکروسرویس ها و کانتینرها دست و پنجه نرم می کرد و در تلاش بود تا از عملیات شیب دار Kubernetes و منحنی یادگیری عیب یابی صعود کند.

اودگارد به‌عنوان مهندسی که تلاش می‌کند تحویل مستمر را هم برای توسعه‌دهندگان ایمن و آسان کند، به روشی برای تجسم وضعیت تولید سیستم Kubernetes و رفتار کاربران نیاز داشت. متأسفانه، کتاب بازی خاصی برای نحوه استخراج، تجمیع و تجسم داده های تله متری از این سیستم ها وجود نداشت. جستجوی اودگارد در نهایت او را به ابزار نظارتی نوپایی به نام Graphite و ابزار دیگری به نام Kibana رساند که تجربه ایجاد تجسم‌ها را ساده می‌کند.

“با Graphite می‌توانید با تلاش بسیار کمی معیارهایی را از برنامه خود ارسال کنید که رفتارهای داخلی آن را شرح دهد، و برای من، به عنوان یک توسعه‌دهنده، این قدرت را به شما می‌دهد که در واقع بینش واقعی را در مورد آنچه برنامه‌ها و سرویس‌ها انجام می‌دهند و رفتار می‌کنند، ببینم. اودگارد به InfoWorld گفت، و تاثیر تغییر کد یا استقرار جدید چه بود. “از نظر بصری بسیار هیجان‌انگیز و ارزشمند بود و باعث شد که ما نسبت به نحوه رفتار آنها احساس اعتماد بیشتری کنیم.”

چیزی که اودگارد را بر آن داشت تا پروژه جانبی خود را شروع کند این بود که علیرغم قدرت گرافیت، استفاده از آن بسیار دشوار بود. این امر مستلزم یادگیری یک زبان پرس و جو پیچیده و فرآیندهای سخت برای ساختن فریمورک ها بود. اما اودگارد متوجه شد که اگر بتوانید قدرت نظارت گرافیت را با سهولت Kibana ترکیب کنید، می‌توانید تجسم‌های سیستم‌های توزیع‌شده را برای توسعه‌دهندگان در دسترس‌تر و مفیدتر کنید.

و اینگونه بود که چشم انداز گرافانا متولد شد. امروزه Grafana و سایر ابزارهای مشاهده پذیری نه جای خالی در چشم انداز نظارت را پر می کنند، بلکه شکافی را پر می کنند که ابزارهای نظارت بر شبکه و سیستم های سنتی هرگز پیش بینی نمی کردند.

سیستم عامل ابری

دهه‌های اخیر شاهد دو جهش عمده در تکامل زیرساخت‌ها بوده‌ایم. اول، ما از سرورهای کوچک «مقیاس‌شده» به ناوگان «مقیاس‌شده» سرورهای لینوکس کالایی که در مراکز داده اجرا می‌شوند، رفتیم. سپس ما یک جهش دیگر به سطوح حتی بالاتر انتزاع انجام دادیم و به زیرساخت خود به عنوان انبوهی از منابع ابری نزدیک شدیم که از طریق API قابل دسترسی هستند.

در طول این تکامل سیستم‌های توزیع‌شده که توسط تجمیع‌ها، انتزاع‌ها و اتوماسیون هدایت می‌شود، قیاس «سیستم عامل» مکرراً فراخوانی شده است. Sun Microsystems شعار “شبکه کامپیوتر است را داشت. Matei Zaharia از UC Berkeley AMPLab، خالق Apache Spark، یکی از خالقان Apache Mesos، و اکنون CTO و یکی از بنیانگذاران Databricks، گفت: «مرکز داده به یک سیستم عامل نیاز دارد.” و امروزه، Kubernetes به طور فزاینده ای به عنوان “سیستم عامل ابری نامیده می شود. .”

سیستم‌عامل نامیدن Kubernetes باعث می‌شود عده‌ای مخالفت کنند و به سرعت به تفاوت‌های بین سیستم‌عامل Kubernetes و واقعی اشاره می‌کنند.

اما قیاس معقول است. لازم نیست به لپ تاپ خود بگویید که در هنگام راه اندازی یک برنامه، کدام هسته را روشن کند. لازم نیست هر بار که درخواست API انجام می شود به سرور خود بگویید از کدام منابع استفاده کند. این فرآیندها از طریق سیستم عامل های ابتدایی خودکار می شوند. به طور مشابه، Kubernetes (و اکوسیستم نرم‌افزار زیرساختی ابر بومی در مدار خود) انتزاعی‌هایی شبیه به سیستم عامل ارائه می‌کند که سیستم‌های توزیع‌شده را با پوشاندن عملیات سطح پایین از کاربر ممکن می‌سازد.

طرف دیگر این همه انتزاع و اتوماسیون فوق‌العاده این است که درک آنچه در زیر کاپوت Kubernetes و سیستم‌های توزیع‌شده می‌گذرد، مستلزم هماهنگی زیادی است که به کاربر بازمی‌گردد. Kubernetes هرگز با یک رابط کاربری گرافیکی زیبا که به طور خودکار معیارهای عملکرد سیستم را جمع‌آوری می‌کند، عرضه نشد، و ابزارهای نظارت سنتی هرگز برای جمع‌آوری تمام داده‌های تله‌متری که توسط این سیستم‌های بسیار پیچیده منتشر می‌شوند، طراحی نشدند.

از صفر به ۲۰ میلیون کاربر در ۱۰ سال

ایجاد داشبورد و تجسم تداعی‌های رایجی است که توسعه‌دهندگان زمانی که به Grafana فکر می‌کنند، ترسیم می‌کنند. قدرت آن به عنوان یک ابزار تجسم و توانایی آن برای کار با تقریباً هر نوع داده، آن را به یک پروژه بسیار محبوب پروژه منبع باز تبدیل کرده است. ، بسیار فراتر از محاسبات توزیع شده و موارد استفاده بومی ابری.

علاقه‌مندان از تجسم گرافانا برای همه چیز از تجسم فعالیت‌های کلونی زنبور عسل در داخل کندو گرفته تا ردیابی ردپای کربن در تحقیقات علمی استفاده می‌کنند. گرافانا در مرکز کنترل اسپیس ایکس برای پرتاب فالکون ۹ در سال ۲۰۱۵ مورد استفاده قرار گرفت و سپس دوباره توسط آژانس اکتشافات هوافضای ژاپن در فرود خود روی ماه استفاده شد. این یک فناوری است که به معنای واقعی کلمه در هر جایی که موارد استفاده از تجسم را پیدا کنید وجود دارد.

اما داستان واقعی تأثیر Grafana بر دامنه مشاهده‌پذیری است که قبل از ورود آن توسط پایگاه‌های داده پشتیبان اختصاصی و زبان‌های پرس‌وجو تعریف شده بود که کاربران را در پیشنهادات فروشنده خاص قفل می‌کرد، هزینه‌های عمده تعویض برای فروشندگان برای مهاجرت به کاربران دیگر، و باغ های دیواری از منابع داده پشتیبانی شده.

اودگارد بیشتر موفقیت اولیه Grafana را به سیستم پلاگینی که در روزهای اولیه خود ایجاد کرد نسبت می دهد. بعد از اینکه او شخصا InfluxDB و Elasticsearch برای Grafana، اعضای انجمن با Prometheus و < ادغام شدند a href="https://github.com/opentsdb" rel="nofollow">OpenTSDB، موجی از افزونه های انجمن را به Grafana راه اندازی می کند. امروزه این پروژه از بیش از ۱۶۰ منبع داده خارجی پشتیبانی می کند – چیزی که آن را رویکرد “چادر بزرگ” برای مشاهده پذیری می نامد.

پروژه Grafana به کار با سایر پروژه‌های منبع باز مانند OpenTelemetry ادامه می‌دهد تا مدل‌های معنایی استاندارد ساده را برای همه انواع داده‌های تله‌متری ارائه کند و «ستون‌های» داده‌های تله‌متری مشاهده‌پذیری را متحد کند (لاگ، متریک، ردیابی، پروفایل). جامعه Grafana با فلسفه “داده های خودت” مرتبط است که همچنان به جذب اتصالات و ادغام با هر پایگاه داده ممکن و نوع داده تله متری ادامه می دهد.

آینده گرافانا: تجسم های جدید و منابع تله متری

اودگارد می‌گوید که قابلیت‌های تجسم گرافانا تمرکز شخصی بزرگی برای تکامل پروژه بوده است. اودگارد گفت: «سفر طولانی‌ای برای ایجاد معماری جدید React وجود دارد که در آن توسعه‌دهندگان شخص ثالث می‌توانند برنامه‌های داشبورد مانند در Grafana بسازند.

اما فراتر از غنی‌سازی روش‌هایی که اشخاص ثالث می‌توانند تصویرسازی‌هایی را در بالای این معماری برنامه ایجاد کنند، خود داشبوردها از نظر هوشمندی تقویت می‌شوند.

اودگارد گفت: «یک روند بزرگ این است که ایجاد داشبورد در نهایت باید منسوخ شود. توسعه‌دهندگان نباید آنها را به صورت دستی بسازند، آنها باید به اندازه کافی هوشمند باشند تا بر اساس انواع داده‌ها، روابط تیمی و سایر معیارها به‌طور خودکار تولید کنند. با دانستن زبان پرس و جو، کتابخانه های شناسایی شده، زبان های برنامه نویسی که با آنها می نویسید و موارد دیگر. ما در تلاش هستیم تا تجربه را بسیار پویاتر، قابل استفاده مجدد و ترکیب کنیم.”