Англійська для розробників VictoriaMetrics

VictoriaMetrics - це швидка, економічна база даних часових рядів, яка в основному сумісна з Prometheus, побудована для обробки проблем масштабу і кардинальності, які роблять довгострокове зберігання Prometheus дорогим. Його словник сильно перетинається з більш широкою екосистемою Prometheus, але декілька термінів - кардиналість, пониження семплювання, віддалений запис - постійно з’являються в обговореннях про ємність і вартість. Вот англiйська, яка потрiбна твоїй командi.

---

Вживання метрики

** Віддалений запис ** — протокол, який Prometheus (або будь- який сумісний агент) використовує для пересилання скасованих метрик до сервера довгострокового зберігання, на зразок VictoriaMetrics, замість того, щоб Prometheus зберігав їх локально назавжди.

• “Ми вказали віддалений запис Prometheus на кластер VictoriaMetrics, тому на локальному диску потрібно зберігати лише декілька годин буфера, а не місяці історії.” *

** Призначення скану ** — кінцева точка, яка виставляє метричні дані у форматі, сумісному з Prometheus, який сканер обробляє за певним інтервалом для збору точок даних. “Нова служба не з’ являлася на панелях управління, тому що ми забувають зареєструвати її як мету скрепу — кінцева точка метрики існувала, але нічого з неї не витягувалося.”

** Часові рядки ** — послідовність точок даних з часовими штампами, які мають спільну назву і набір міток, фундаментальну одиницю зберігання і запиту VictoriaMetrics. “Кожна унікальна комбінація міток створює новий часовий ряд — це та деталь, яка перетворює невинно виглядаючу метрику на проблему кардиналізації.”

---

Запит за допомогою MetricsQL

MetricsQL

** MetricsQL ** — це мова запиту VictoriaMetrics — надмножина PromQL з додатковими функціями і синтаксисом, тому більшість існуючих запитів Prometheus працюватимуть без змін.

“Ми не мусили переписувати правила попереджень для міграції — MetricsQL є зворотньо сумісним з PromQL, який ми вже мали.”

Функції і функціональні групи

Функції, такі як rate() і агрегаційні оператори, такі як sum by (...), використовуються для перетворення сирих лічильників в значущі швидкості за секунду або груповані підсумки.

“На панелі показувалися скасування первинних лічильників як піки — обгортання запиту в rate() згладило це і дало нам фактичний тренд запитів за секунду.”

---

Кардинальність і вартість

** Кардинальність ** — кількість унікальних часових рядків, які створює метрика, залежно від кількості існуючих комбінацій різних значень міток; висока кардинальність є найбільшим чинником, що впливає на вартість зберігання і запиту у системах часових рядків.

“Додавши user_id як мітку, ми помножили нашу кардинальність на кількість активних користувачів за одну ніч — ми повернули її і перенесли цю деталь в журнали замість цього.”

** Зменшення вибірки ** — зменшення роздільної здатності старих даних (зберігання середніх значення за годину замість точок за секунду) для зменшення вартості зберігання, зберігаючи при цьому видимість довгострокових тенденцій.

“Після 30 днів ми зменшуємо вибірку до п’ятихвилинної роздільності — нікому не потрібна гранулярність другого рівня для графіка, що охоплює останні шість місяців.”

** Період зберігання ** — термін зберігання необроблених або зменшених даних перед їх вилученням, налаштований відповідно до кожного випадку використання, щоб збалансувати вартість зберігання з тим, наскільки далеко назад вам слід повертатися для розслідування подій.

• “Ми встановили 13- місячний період зберігання, щоб завжди мати можливість порівняти цей місяць з тим же місяцем минулого року, не платячи за зберігання кожної точки даних другого рівня так довго.” *

---

Керування кластером

** vmagent ** — легкий агент скребінгу і віддаленого запису VictoriaMetrics, який часто використовується як замінник скриптування Prometheus, коли вам не потрібне локальне зберігання Prometheus.

“Ми замінили Prometheus на vmagent на краєвих вузлах — він має набагато менший слід у пам’ яті, оскільки йому не потрібно нічого зберігати локально.”

** Режим кластерів (vminsert/vmstorage/vmselect) ** — горизонтально масштабований режим розгортання, де вживання, зберігання і запит розділені на окремі, незалежно масштабовані компоненти.

“Ми досі працюємо на одному вузлі VictoriaMetrics — кластерний режим буде в плані, як тільки обсяг поглинання перевищить те, що може обробляти один екземпляр.”

---

Виступав за команду «Вікторія»

Situation	Phrase
Justifying the migration from raw Prometheus	”Long-term storage and cardinality management were becoming a real cost center — VictoriaMetrics compresses far better and our existing PromQL queries still work.”
Explaining a cost spike	”That new label pushed cardinality way up — we’re generating a new time series per unique value, and that’s what’s driving the storage bill.”
Describing a retention decision	”We downsample after 30 days and drop raw data after a year — that keeps recent debugging detailed while controlling long-term storage cost.”
Discussing scaling	”Once single-node ingestion becomes the bottleneck, cluster mode lets us scale ingestion and querying independently.”

Поширені помилки

• Якщо ви додасте мітки високої кардиналізації (ІД користувача, ІД запиту) до метрик без урахування кожного унікального значення, буде створено новий збережений часовий рядок.
• Використання « Prometheus », коли запит використовує розширення MetricsQL — варто позначити у перегляді коду, оскільки це впливає на переносимість назад до простого Prometheus.
• Плутанина ** зберігання ** (як довго зберігаються дані) з ** пониженням вибірки ** (при якій роздільності вони зберігаються) — команда може знизити вибірку без скорочення зберігання, або навпаки.

Практичні вправи

1. Поясніть, у двох реченнях, чому висока кардиналість є проблемою вартості, а не просто проблемою швидкодії запиту.
2. Напишіть короткий опис PR для додавання правила зменшення вибірки, яке зменшує роздільну здатність після 30 днів.
3. Створити повідомлення, яке обґрунтовує перехід з локального сховища Prometheus на віддалений запис VictoriaMetrics, зосередившись на збереженні і вартості.

Зв’язані ресурси

• Англійська для розробників TigerBeetle
• Англійська для розробників, що моніторять Checkly
• Англійською мовою для розробників Bugsnag Error Tracking

Наприклад, англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська

Вивчення професійної англійської, особливо в технічній області VictoriaMetrics, може відчувати себе як розшифровку самої складної системи. Це не просто знати слова; це розуміння * як * ці слова використовуються в конкретних контекстах і розпізнавання тонких відмінностей у тоні, що можуть значно вплинути на спілкування. Для не-рідних носіїв, це може бути особливо складним - немовлені правила перегляду коду, обговорення Slack і описи PR часто сильно покладаються на встановлені конвенції, побудовані навколо рідної англійської мови.

Однією з поширених перешкод є конструктивне оформлення зворотнього зв’язку. Простое “Это не работает” кажется тупым и бесполезным. Замість цього, розгляньте такі фрази: «Я помітив потенційну проблему з продуктивністю запиту; чи можемо ми дослідити оптимізацію його для кардинальності? Можливо, зменшення обсягу агрегації зменшить навантаження на програму. » Або, якщо ви переглядаєте код, « Логіка тут виглядає здоровою, але я хотів би дізнатися про читабельність цього розділу — чи можна додати коментар, який пояснює намір поліпшити підтримку? » Сфокусування на * впливі * — як щось впливає на продуктивність, масштабованість або ясність — це ключ. Аналогічно, коли ви описуєте зміни у запиті на завантаження, не пишіть просто « Виправлено помилку ». Замість цього пишіть « Цей запит на завантаження розв’ язує проблему, про яку було повідомлено, з періодичною втратою даних; я реалізував механізм повторних спроб і додав журналювання для спостереження за частотою помилок. »

Іншою областю, що вимагає ретельної уваги, є використання точної термінології. Хоча «зниження вибірки» може здатися простим, його наслідки - зменшення роздільної здатності для історичних даних - можуть бути нюансовані при обговоренні політики зберігання або продуктивності запиту. Аналогічно, розуміння різниці між «віддаленим записом» (надіслання даних метрики до VictoriaMetrics) і «запитами MetricsQL» (аналіз цих даних) є фундаментальним. Не припускайте, що всі поділять ваші інтуїтивні знання; чітке визначення термінів, особливо під час обговорення проектування інфраструктури, є цінною практикою.

Нарешті, пам’ятайте, що активне слухання відіграє вирішальну роль. Якщо ви не впевнені в чомусь, запитайте про пояснення. Питання «Чи можете ви розібратися, що ви маєте на увазі під «оптимальною кардиналістю» в цьому контексті?» демонструє залучення і зменшує ризик неправильного тлумачення. Не бійтеся визнати, коли ви не до кінця розумієте - це набагато краще, ніж діяти на основі припущень.

vm query -d my_metrics --query "sum(http_requests{status_code=200}) by {job}"

Ця проста команда, виконана за допомогою CLI VictoriaMetrics, демонструє типовий сценарій: запит на агреговані метричні дані (HTTP- запити з кодом стану 200), згруповані за job. Вивід — який ви потім обговорюватимете у команді — ймовірно, буде включати розгляд кардинальності (кількості унікальних завдань), правил зберігання (як довго зберігаються історичні дані) і, можливо, зменшення вибірки, якщо запит повертає забагато даних.