سلام به همه! در او آخرین مقاله من در مورد سازماندهی یک سیستم نظارت مدولار برای معماری میکروسرویس نوشتم. هیچ چیز ثابت نمی ماند، پروژه ما دائما در حال رشد است، و همچنین تعداد معیارهای ذخیره شده نیز افزایش می یابد. چگونه انتقال از Graphite + Whisper به Graphite + ClickHouse را در شرایط بار بالا سازماندهی کردیم، در مورد انتظارات از آن و نتایج مهاجرت تحت برش بخوانید.

قبل از اینکه به شما بگویم که چگونه انتقال معیارهای ذخیره سازی در Graphite + Whisper به Graphite + ClickHouse را سازماندهی کردیم، می خواهم اطلاعاتی در مورد دلایل اتخاذ چنین تصمیمی و در مورد معایب Whisper که برای مدت طولانی با آن زندگی می کردیم ارائه دهم.

مشکلات گرافیت + Whisper

1. بار زیاد روی زیرسیستم دیسک

در زمان انتقال، تقریباً 1.5 میلیون متریک در دقیقه به سمت ما رفت. با این جریان، استفاده از دیسک در سرورها 30٪ بود. به طور کلی، کاملاً قابل قبول بود - همه چیز با ثبات کار می کرد، به سرعت نوشته می شد، به سرعت خوانده می شد ... تا اینکه یکی از تیم های توسعه ویژگی جدیدی را ارائه کرد و شروع به ارسال 10 میلیون متریک در دقیقه برای ما کرد. پس از آن بود که زیرسیستم دیسک سخت تر شد و ما شاهد استفاده 100 درصدی بودیم. مشکل به سرعت حل شد، اما رسوب باقی ماند.

2. عدم تکرار و سازگاری

به احتمال زیاد، مانند همه کسانی که از Graphite + Whisper استفاده می کنند / استفاده می کنند، ما همان جریان معیارها را به طور همزمان روی چندین سرور Graphite ریختیم تا بتوانیم تحمل خطا را ایجاد کنیم. و هیچ مشکل خاصی با این وجود نداشت - تا لحظه ای که یکی از سرورها به دلایلی سقوط نکرد. گاهی اوقات ما موفق می شدیم سرور سقوط کرده را با سرعت کافی بالا بیاوریم، و کربن-c-relay موفق شد آن را با معیارهایی از حافظه پنهان خود پر کند، و گاهی اوقات نه. و سپس سوراخی در متریک وجود داشت که ما آن را با rsync پوشاندیم. روش کاملا طولانی بود. تنها با این واقعیت که این اتفاق بسیار نادر رخ می دهد نجات یافته است. ما همچنین به صورت دوره‌ای مجموعه‌ای تصادفی از معیارها را برداشتیم و آنها را با سایر موارد مشابه در گره‌های همسایه خوشه مقایسه کردیم. در حدود 5 درصد موارد، چندین مقدار متفاوت بود که ما را خیلی خوشحال نکرد.

3. فضای زیادی اشغال شده است

از آنجایی که ما در Graphite نه تنها زیرساخت، بلکه معیارهای تجاری را نیز می نویسیم (و اکنون نیز معیارهایی از Kubernetes)، اغلب اوقات وضعیتی را دریافت می کنیم که در آن فقط چند مقدار در متریک وجود دارد و فایل .wsp با استفاده از آن ایجاد می شود. کل دوره نگهداری را در نظر می گیرد و مقدار فضای از پیش تخصیص داده شده را اشغال می کند که ~ 2 مگابایت داشتیم. این مشکل با این واقعیت تشدید می شود که در طول زمان تعداد زیادی از این فایل ها وجود دارد و هنگام ساختن گزارش ها بر روی آنها، خواندن نقاط خالی زمان و منابع زیادی را می گیرد.

می خواهم فوراً متذکر شوم که مشکلاتی که در بالا توضیح داده شد را می توان با روش های مختلف و با درجات مختلف کارایی برطرف کرد، اما هرچه داده های بیشتری دریافت کنید، بیشتر تشدید می شوند.

داشتن تمام موارد فوق (با در نظر گرفتن موارد قبلی مقاله) و همچنین افزایش مداوم تعداد معیارهای دریافتی، تمایل به انتقال تمام معیارها به فاصله ذخیره سازی 30 ثانیه. (در صورت لزوم تا 10 ثانیه)، تصمیم گرفتیم Graphite+ClickHouse را به عنوان جایگزینی امیدوارکننده برای Whisper امتحان کنیم.

Graphite+ClickHouse. انتظارات

با بازدید از چندین ملاقات از بچه ها از Yandex، خواندن چند مقاله در Habré، پس از بررسی مستندات و یافتن اجزای معقول برای بستن ClickHouse به Graphite، تصمیم گرفتیم اقدام کنیم!

می خواهید موارد زیر را دریافت کنید:

کاهش استفاده از سیستم فرعی دیسک از 30٪ به 5٪.
کاهش فضای اشغال شده از 1 ترابایت به 100 گیگابایت؛
قادر به دریافت 100 میلیون متریک در دقیقه به سرور باشد.
تکرار داده ها و تحمل خطا خارج از جعبه؛
یک سال روی این پروژه ننشینید و برای مدتی عاقلانه انتقال را انجام دهید.
سوئیچ بدون خرابی

خیلی جاه طلب است، درست است؟

Graphite+ClickHouse. اجزاء

برای دریافت داده ها از طریق پروتکل Graphite و سپس نوشتن آنها در ClickHouse، من انتخاب کردم کربن-کلیک خانه (گلانگ).

آخرین نسخه ClickHouse نسخه پایدار 1.1.54253 به عنوان پایگاه داده برای ذخیره سری های زمانی انتخاب شد. هنگام کار با آن، مشکلاتی وجود داشت: کوهی از خطاها به سیاهههای مربوط ریخته شد و کاملاً مشخص نبود که با آنها چه باید کرد. در بحث با رومن لومونوسوف (نویسنده carbon-clickhouse، graphite-clickhouse و موارد دیگر) قدیمی تر انتخاب شد انتشار 1.1.54236. خطاها ناپدید شدند - همه چیز با صدای بلند شروع به کار کرد.

برای خواندن داده ها از ClickHouse انتخاب شد گرافیت-کلیک خانه (گلانگ). به عنوان یک API برای گرافیت - کربناپی (گلانگ). برای سازماندهی تکرار بین جداول، از ClickHouse استفاده شد نگهبان باغ وحش. برای معیارهای مسیریابی، ما محبوب خود را ترک کردیم کربن سی رله (C) (مقاله قبلی را ببینید).

Graphite+ClickHouse. ساختار جدول

"گرافیت" پایگاه داده ای است که ما برای نظارت بر جداول ایجاد کرده ایم.

"graphite.metrics" جدولی با موتور ReplicatedReplacingMergeTree است (تکثیر شده جایگزینی MergeTree). این جدول نام معیارها و مسیرهای رسیدن به آنها را ذخیره می کند.

CREATE TABLE graphite.metrics ( Date Date, Level UInt32, Path String, Deleted UInt8, Version UInt32 ) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.metrics', ‘r1’, Date, (Level, Path), 8192, Version);

"graphite.data" جدولی با موتور ReplicateGraphiteMergeTree است (تکثیر شده GraphiteMergeTree). این جدول مقادیر متریک را ذخیره می کند.

CREATE TABLE graphite.data ( Path String, Value Float64, Time UInt32, Date Date, Timestamp UInt32 ) ENGINE = ReplicatedGraphiteMergeTree('/clickhouse/tables/replicator/graphite.data', 'r1', Date, (Path, Time), 8192, 'graphite_rollup')

"graphite.date_metrics" یک جدول پر مشروط با موتور ReplicatedReplacingMergeTree است. این جدول شامل نام تمام معیارهایی است که در طول روز با آنها مواجه شده اند. دلایل ایجاد در بخش توضیح داده شده است "چالش ها و مسائل" در پایان این مقاله

CREATE MATERIALIZED VIEW graphite.date_metrics ( Path String,  Level UInt32,  Date Date) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.date_metrics', 'r1', Date, (Level, Path, Date), 8192) AS SELECT toUInt32(length(splitByChar('.', Path))) AS Level, Date, Path FROM graphite.data

"graphite.data_stat" یک جدول شرطی با موتور ReplicatedAggregatingMergeTree است (تکثیر شده Aggregating MergeTree). این جدول تعداد معیارهای ورودی را که به 4 سطح تودرتو تقسیم می شود، ثبت می کند.

CREATE MATERIALIZED VIEW graphite.data_stat ( Date Date,  Prefix String,  Timestamp UInt32,  Count AggregateFunction(count)) ENGINE = ReplicatedAggregatingMergeTree('/clickhouse/tables/replicator/graphite.data_stat', 'r1', Date, (Timestamp, Prefix), 8192) AS SELECT toStartOfMonth(now()) AS Date, replaceRegexpOne(Path, '^([^.]+.[^.]+.[^.]+).*$', '1') AS Prefix, toUInt32(toStartOfMinute(toDateTime(Timestamp))) AS Timestamp, countState() AS Count FROM graphite.data  GROUP BY Timestamp, Prefix

Graphite+ClickHouse. طرح تعامل اجزا

Graphite+ClickHouse. مهاجرت داده ها

همانطور که از انتظارات از این پروژه به یاد داریم، انتقال به ClickHouse باید بدون خرابی باشد، به ترتیب، ما مجبور شدیم به نحوی کل سیستم نظارتی خود را به فضای ذخیره سازی جدید تا حد امکان شفاف برای کاربران خود تغییر دهیم.
ما این کار را انجام دادیم.

قانونی به رله کربن-c اضافه شد تا یک جریان اضافی از معیارها به خانه کلیکی کربن یکی از سرورهای درگیر در تکثیر جداول ClickHouse ارسال شود.
ما یک اسکریپت پایتون کوچک نوشتیم که با استفاده از کتابخانه whisper-dump، تمام فایل‌های wsp. را از فضای ذخیره‌سازی ما می‌خواند و این داده‌ها را به خانه کلیکی کربن که در بالا در 24 رشته توضیح داده شد ارسال می‌کرد. تعداد مقادیر متریک پذیرفته شده در خانه کلیکی کربن به 125 میلیون در دقیقه رسید و ClickHouse حتی عرق نکرد.
ما یک DataSource جداگانه در Grafana ایجاد کردیم تا توابع مورد استفاده در داشبوردهای موجود را اشکال زدایی کنیم. فهرستی از ویژگی‌هایی را که ما استفاده کردیم، اما در carbonapi پیاده‌سازی نشدند، نشان داد. ما این توابع را به پایان رساندیم و روابط عمومی را برای نویسندگان carbonapi ارسال کردیم (با تشکر ویژه از آنها).
برای تغییر بار خواندن در تنظیمات متعادل کننده، نقاط پایانی را از graphite-api (واسط API برای Graphite+Whisper) به carbonapi تغییر دادیم.

Graphite+ClickHouse. نتایج

استفاده از زیرسیستم دیسک را از 30٪ به 1٪ کاهش داد.
میزان فضای اشغال شده را از 1 ترابایت به 300 گیگابایت کاهش داد.
ما توانایی دریافت 125 میلیون متریک در دقیقه برای هر سرور را داریم (پیک در زمان مهاجرت).
تمام معیارها را به یک فاصله ذخیره سازی سی و دوم منتقل کرد.
تکرار داده های دریافتی و تحمل خطا.
تغییر بدون توقف؛
برای همه چیز حدود 7 هفته طول کشید.

Graphite+ClickHouse. چالش ها و مسائل

در مورد ما، برخی از دام ها وجود داشت. در اینجا چیزی است که ما پس از انتقال با آن مواجه شدیم.

ClickHouse همیشه پیکربندی‌ها را دوباره بازخوانی نمی‌کند، گاهی اوقات نیاز به بارگیری مجدد دارد. برای مثال، در مورد توصیف خوشه zookeeper در پیکربندی ClickHouse، تا زمانی که کلیک‌هاوس-سرور راه‌اندازی مجدد نشده بود، اعمال نشد.
هیچ درخواست ClickHouse بزرگی وجود نداشت، بنابراین در graphite-clickhouse ما، رشته اتصال ClickHouse به شکل زیر است:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
ClickHouse اغلب نسخه‌های جدیدی از نسخه‌های پایدار را منتشر می‌کند، ممکن است شگفت‌انگیز باشد: مراقب باشید.
ظروف ایجاد شده به صورت پویا در kubernetes تعداد زیادی معیار را با طول عمر کوتاه و تصادفی ارسال می کنند. با توجه به این معیارها نقاط زیادی وجود ندارد و هیچ مشکلی در مکان وجود ندارد. اما هنگام ساخت پرس و جوها، ClickHouse تعداد زیادی از این معیارها را از جدول "متریک" جمع آوری می کند. در 90٪ موارد، هیچ داده ای برای آنها در خارج از پنجره (24 ساعت) وجود ندارد. اما زمان صرف شده برای جستجوی این داده ها در جدول 'داده ها' صرف می شود و در نهایت به یک بازه زمانی بستگی دارد. برای حل این مشکل، ما شروع به حفظ یک نمای جداگانه با اطلاعاتی در مورد معیارهایی کردیم که در طول روز با آن مواجه می شدیم. بنابراین، هنگام ساختن گزارش‌ها (نمودارها) روی کانتینرهایی که به صورت پویا ایجاد شده‌اند، ما فقط معیارهایی را که در پنجره مشخص شده با آن مواجه شده‌اند، نظرسنجی می‌کنیم، و نه برای کل زمان، که تولید گزارش‌ها در آنها را بسیار تسریع می‌کند. برای راه حل فوق جمع آوری شد گرافیت-کلیک خانه (چنگال)، که شامل اجرای کار با جدول date_metrics می باشد.

Graphite+ClickHouse. برچسب ها

از زمان رسمی شدن نسخه 1.1.0 Graphite برچسب های پشتیبانی. و ما فعالانه به این فکر می کنیم که چه کاری و چگونه برای حمایت از این ابتکار در پشته گرافیت+کلیک هاوس انجام دهیم.

Graphite+ClickHouse. آشکارساز ناهنجاری

بر اساس زیرساختی که در بالا توضیح داده شد، ما یک نمونه اولیه آشکارساز ناهنجاری را پیاده سازی کرده ایم و کار می کند! اما در مورد او - در مقاله بعدی.

مشترک شوید، فلش بالا را فشار دهید و خوشحال باشید!

منبع: www.habr.com

ذخیره سازی متریک: چگونه از Graphite+Whisper به Graphite+ClickHouse منتقل شدیم