Exemplar - это возможность связать метрики, логи и трейсы. Например, это можно сделать на основе trace ID. Пример: у вас есть метрика (Prometheus) количества HTTP-запросов. И к каждому запросу, у которого код ответа 500, вы хотите прикрепить exemplar. За период между скрейпами у вас было 3 запроса с кодом 500. Тогда метрики будут иметь примерно следующий вид:
# HELP http_requests_total Total number of HTTP requests
# TYPE http_requests_total counter
http_requests_total{method="GET", code="500"} 3 # {trace_id="abc123"} 1620300000000
http_requests_total{method="GET", code="500"} 3 # {trace_id="def456"} 1620300005000
http_requests_total{method="GET", code="500"} 3 # {trace_id="ghi789"} 1620300010000
В этом случае при просмотре метрик, например, в Grafana и при правильной настройке всех необходимых data sources, вы сможете сразу из метрик просмотреть соответствующий спан трейсов и логи.
Также важно понимать, что возможности по хранению exemplars ограничены, и неправильно прикреплять их к каждому событию. При этом, логика добавления exemplars остаётся на ответственности разработчика (того, кто генерирует метрики).
Но при каких условиях S3 будет быстрее для запросов на чтение по сравнению с local storage?
Если мы сравниваем одну и туже систему, то ответ будет – никогда. Если сравниваем разные системы, то зависит от систем. Мое замечание заключалось в том, что если сравниваешь производительность двух систем и одна хранит данные на локальном SSD, а вторая хранит данные в S3 с letensy 1 сек, то вторая будет заведомо в проигрышной позиции.
Вы можете сказать сколько в среднем байт на точку данных требуется в вашей инсталляции? Я думаю, так будет проще рассуждать про сжатие.
У нас нет такой информации, мы никогда не замеряли это. И это не супер просто посчитать, так как нет данных по количеству точек в mimir.
В общем, что бы ответить на все эти вопросы, мы думаем сделать обширный тест, продолжительностью несколько недель, с замерами на разных этапах и красивыми картинками, и конечно же, опубликовать результаты.
Версии VM и Mimir были актуальными на момент бенчмарка. Вы тестировали оба решения или выбор был сделан только на основе статей и документации?
Да, вы правы, я упустил дату статьи.
На тот момент, когда мы принимали решение, Mimir еще не существовал, и мы выбирали между Victoria Metrics и Cortex. В процессе мы изучили документацию, провели различные тесты, включая нагрузочные, и изучили кодовую базу основных претендентов. При сопоставимых результатах по скорости ответа и записи, и потреблению ресурсов для нас решающим фактором стало отсутствие механизма решардирования данных в Victoria Metrics.
В статье достаточно много времени уделяется object storage. Но я не понимаю как использование S3 может в положительном ключе влиять на производительность по сравнению с более быстрыми и доступными локальными дисками?
Недостаточно, там не указаны значения для задержки для запросв и размера канала, хотя и говорится об использовании Google Cloud Storage. В случае с Mimir – S3 это ключевой компонент, аналогично дискам victoria metrics. Согласись, что есть разница в производительности при тестировании VM на SSD или HDD?
Вы имеете в виду 3.5TB были сжаты в 3TB? Если это так, то в VM можете ожидать 1TB согласно цифрам из бенчмарка.
Нет, смотрите, для обеспечения высокой доступности данных необходимо их хранить в нескольких копиях. В случае с VM данные записываются на несколько vmStorage, а в случае с Mimir - на несколько ingester. Важный момент заключается в том, что данные, записанные в несколько vmStorage, остаются там навсегда, тогда как ingester выгружает их в S3, после чего происходит дедубликация данных (три блока сливаются в один). Чтобы обеспечить высокую доступность данных, необходима репликация на уровне хранения в S3. Поскольку мы используем собственный S3, вопрос репликации остается актуальным для нас. В итоге, для хранения 3 ТБ метрик в S3 мы используем 3,5 ТБ дискового пространства с учетом трехкратной репликации.
Аналогично работает слияние и рекомпрессия данных в VictoriaMetrics. Данные могут сжиматься вплоть до 1 месяца.
Да, но есть нюансы. Как я писал выше, данные в VM хранятся на локальных дисках, и там архитектурно невозможен горизонтальный мердж, то есть объединение нескольких одинаковых блоков в один. Возможен только вертикальный мердж данных по времени.
Привет! Это отличная статья, и ребята проделали большую работу. Но всегда есть нюансы. Мы еще не проводили детальный анализ статьи, но есть пара моментов, которые делают ее не так однозначной:
Во-первых, они используют версию 2.2.0, хотя актуальная версия - 2.8.0. Версия 2.4 внесла существенные изменения, которые, по нашим замерам, сокращают потребление ресурсов на 30-40%.
В статье отсутствует информация об использовании S3, который является ключевым компонентом и сильно влияет на производительность.
В Mimir данные хранятся на дисках vmStorage, а в Mimir используется S3. Например, при использовании replication factor 3, в Mimir для хранения 3,5 Тб метрик требуется всего 3 Тб дискового пространства. Это основано на реальных данных нашего проекта, где мы используем Ceph S3 с replication factor 3.
В статье проводится бенчмарк в течение одних суток, но вряд ли Mimir и Victoriametrics используются для хранения данных такого маленького периода. Кроме того, учитывая многоуровневый merge данных в Mimir, реальное потребление места на данных за день и месяц может значительно отличаться.
Ох, на самом деле, сложный вопрос. Если уже заговорили о VM, то это действительно хорошее решение. Однако не стоит забывать о нюансах, которые важно понимать. Далее, стоит оценить, насколько существенны для вас эти особенности и сделать выбор.
Во-вторых, VM применяет собственный формат хранения данных, и на данный момент существует возможность перехода на VM, но обратной миграции нет.
В-третьих, VM формально шардирует данные, но фактически не поддерживает механизм решардирования. Другими словами, если у вас есть кластер из 3 vm-storage, вы не можете отключить один vm-storage и на его месте запустить новый, более мощный (а затем проделать то же самое с остальными), на новые vm-storage будут записываться только новые данные, а старые не перенесутся.
В-четвертых, в Mimir долгосрочное хранилище отделено (это S3), что делает систему более гибкой.
С учетом этих нюансов, мы сделали выбор в пользу Mimir.
Ох, на самом деле, сложный вопрос. Если уже заговорили о VM, то это действительно хорошее решение. Однако не стоит забывать о нюансах, которые важно понимать. Далее, стоит оценить, насколько существенны для вас эти особенности и сделать выбор.
Во-вторых, VM применяет собственный формат хранения данных, и на данный момент существует возможность перехода на VM, но обратной миграции нет.
В-третьих, VM формально шардирует данные, но фактически не поддерживает механизм решардирования. Другими словами, если у вас есть кластер из 3 vm-storage, вы не можете отключить один vm-storage и на его месте запустить новый, более мощный (а затем проделать то же самое с остальными), на новые vm-storage будут записываться только новые данные, а старые не перенесутся.
В-четвертых, в Mimir долгосрочное хранилище отделено (это S3), что делает систему более гибкой.
В итоге вам необходимо определить, насколько вы согласны с этими нюансами.
Нет. При включении remote_write, Prometheus продолжает работать как "обычный" Prometheus. При этом у Prometheus есть режим работы, который называется Prometheus agent mode, вот в этом режиме он работает так как вы описали. Подробнее про это можно почитать, например, тут: https://prometheus.io/blog/2021/11/16/agent/
Это не совсем относится к теме доклада, а так же с учетом ограниченности времени на доклад (и так пришлось сокращать его). Но я могу предложить пару видео, которые позволят познакомиться с интерфейсами продуктов, о которых я рассказывал. Grafana: https://youtu.be/QDV4KfDPs1E Prometheus: https://www.youtube.com/watch?v=VUQ6RudYh_w Mimir - не имеет собственного интерфейса.
Log Management, Application Performance Monitoring, Exception Tracking это и многое другое мы, конечно же, планируем добавить. Но, прежде чем начать работу над этим функционалом, нам нужен хороший фундамент. В нашем случае фундамент - это Storage и сейчас мы активно работаем над ним.
Подробней, про наши текущие планы, про Storage, почему он в первую очередь и что будет далее, мы рассказали в нашем докладе на DevOops. (Расшифровка его будет уже совсем скоро.)
Этот шаблон имеет детализацию уровня БД, то есть по данным можно понять, что происходит или происходило с базой данных в целом, при этом понять, что привело к этому нельзя. Допустим, у вас была нагрузка на вм с базой данных в 3 часа ночи, из данных этого шаблона, максимум можно локализовать в какой именно БД была нагрузка.
Это хорошо, но как правило не достаточно. Для полноценного мониторинга надо иметь возможность посмотреть какие именно запросы создают нагрузку, какую нагрузку они создают, а так же каких запросов было больше всего.
Не совсем так, если данный кейс приводит к инцидентам которые влияют на доступность сервиса(а это так потому, что он попал в постмортем), при этом его долго/сложно диагностировать(читай как уходит много времени на восстановление работы сервиса), то его не надо отправлять в тех долг.
Отказавшись от тестов, CI/CD вы не технический долг плодите, а ущерб бизнесу
Не всегда так, если мы говорим про запуск нового проекта есть кейсы, когда эти задачи могут быть отложены на более поздние этапы. И тут важно, что если мы откладываем это на следующие этапы, что это процесс не станет бесконечным.
«Продажа технического долга» — это продажа вероятной угрозы.
Далеко не всегда так, зачастую технический долг начинает приносит реальный ущерб и это один из поводов задуматься о том, что долги пора вернуть.
UPD: не разумнее ли «продавать» свой профессионализм, вместо технического долга?
Умение общаться с бизнесом на понятном языке, на мой взгляд, тоже относится к одной из граней профессионализма.
Использование методологии ITIL в качестве первоисточника знаний о SRE, скажем так, несколько странный подход. Может быть лучше прочитать SRE Book? Там SLA вводится так:
Понятие SLA появилось задолго до появления термина SRE и по этому давать определение не SRE вполне допустимо. Тем более, приведенное вам определение ни сколь не противоречит тому, что я привел.
SLA — это договор с внешними клиентами, который скорее всего предусматривает штрафные санкции.
SLO — это внутренний договор.
Насовсем так.
1. Смотрите, у вас есть микросервис А который зависит от 10 других. Допустим один из десяти является обязательным для микросервиса A и называется микросервис В. Так вот, если есть проблемы у микросервиса B, то это отразится и в показателях доступности микросервиса А, так как запросы к нему будут заканчиваться с ошибкой.
2. Зачастую строют графики не только по конкретным микросервисам, но и по проекту в целом.
3. При анализе работы используют еще и бизнесметрики. Например это может быть количество регистраций, количество бронирований или заказов.
4. Так же, за частую используют метрики полученные напрямую от устройства клиентов.
Приведенный вами пример, с математической точки зрения, верный и в целом не решен смысла. Но все не так линейно. И sli/slo это один из инструментов и на мой взгляд сильно переоцененный и работает он только в комплексе с большим количеством других инструментов и практик.
« Соглаше́ние об у́ровне предоставле́ния услу́ги (англ. Service Level Agreement, SLA) — термин методологии ITIL, обозначающий формальный договор между заказчиком (в рекомендациях ITIL заказчик и потребитель — разные понятия) услуги и её поставщиком, содержащий описание услуги, права и обязанности сторон и, самое главное, согласованный уровень качества предоставления данной услуги.»
Тут важно: согласованный уровень обслуживания. А санкции за не предоставления могут быть, а могут и не быть.
Если очень просто: SLA это договор с заказчиком, SLO ,SLI это внутренний договор. Как правило SLO и SLI более строгие, по отношению к SLA.
Не совсем так, у мобильной сети и у мобильного телефона меньше девяток и если повысить стабильность приложения с 99 на 99.9999% то пользователь скорее всего не заметит разницы, потому что мобильная и сам телефон работают не так стабильно.
Ну это достаточно утрированное произведение и в реальной жизни, вряд ли было бы так просто и быстро.
Но в целом, у меня в практике, да и у коллег, были кейсы где подобного рода предложения помогали развитию компании и карьерному росту:)
Exemplar - это возможность связать метрики, логи и трейсы. Например, это можно сделать на основе trace ID. Пример: у вас есть метрика (Prometheus) количества HTTP-запросов. И к каждому запросу, у которого код ответа 500, вы хотите прикрепить exemplar. За период между скрейпами у вас было 3 запроса с кодом 500. Тогда метрики будут иметь примерно следующий вид:
В этом случае при просмотре метрик, например, в Grafana и при правильной настройке всех необходимых data sources, вы сможете сразу из метрик просмотреть соответствующий спан трейсов и логи.
Также важно понимать, что возможности по хранению exemplars ограничены, и неправильно прикреплять их к каждому событию. При этом, логика добавления exemplars остаётся на ответственности разработчика (того, кто генерирует метрики).
Еще, можете почитать, например эту статью: https://vbehar.medium.com/using-prometheus-exemplars-to-jump-from-metrics-to-traces-in-grafana-249e721d4192
Если мы сравниваем одну и туже систему, то ответ будет – никогда. Если сравниваем разные системы, то зависит от систем. Мое замечание заключалось в том, что если сравниваешь производительность двух систем и одна хранит данные на локальном SSD, а вторая хранит данные в S3 с letensy 1 сек, то вторая будет заведомо в проигрышной позиции.
У нас нет такой информации, мы никогда не замеряли это. И это не супер просто посчитать, так как нет данных по количеству точек в mimir.
В общем, что бы ответить на все эти вопросы, мы думаем сделать обширный тест, продолжительностью несколько недель, с замерами на разных этапах и красивыми картинками, и конечно же, опубликовать результаты.
Да, вы правы, я упустил дату статьи.
На тот момент, когда мы принимали решение, Mimir еще не существовал, и мы выбирали между Victoria Metrics и Cortex. В процессе мы изучили документацию, провели различные тесты, включая нагрузочные, и изучили кодовую базу основных претендентов. При сопоставимых результатах по скорости ответа и записи, и потреблению ресурсов для нас решающим фактором стало отсутствие механизма решардирования данных в Victoria Metrics.
Недостаточно, там не указаны значения для задержки для запросв и размера канала, хотя и говорится об использовании Google Cloud Storage. В случае с Mimir – S3 это ключевой компонент, аналогично дискам victoria metrics. Согласись, что есть разница в производительности при тестировании VM на SSD или HDD?
Нет, смотрите, для обеспечения высокой доступности данных необходимо их хранить в нескольких копиях. В случае с VM данные записываются на несколько vmStorage, а в случае с Mimir - на несколько ingester. Важный момент заключается в том, что данные, записанные в несколько vmStorage, остаются там навсегда, тогда как ingester выгружает их в S3, после чего происходит дедубликация данных (три блока сливаются в один). Чтобы обеспечить высокую доступность данных, необходима репликация на уровне хранения в S3. Поскольку мы используем собственный S3, вопрос репликации остается актуальным для нас. В итоге, для хранения 3 ТБ метрик в S3 мы используем 3,5 ТБ дискового пространства с учетом трехкратной репликации.
Да, но есть нюансы. Как я писал выше, данные в VM хранятся на локальных дисках, и там архитектурно невозможен горизонтальный мердж, то есть объединение нескольких одинаковых блоков в один. Возможен только вертикальный мердж данных по времени.
* п3 В Vm данные хранятся на дисках vmStorage.
Привет! Это отличная статья, и ребята проделали большую работу. Но всегда есть нюансы. Мы еще не проводили детальный анализ статьи, но есть пара моментов, которые делают ее не так однозначной:
Во-первых, они используют версию 2.2.0, хотя актуальная версия - 2.8.0. Версия 2.4 внесла существенные изменения, которые, по нашим замерам, сокращают потребление ресурсов на 30-40%.
В статье отсутствует информация об использовании S3, который является ключевым компонентом и сильно влияет на производительность.
В Mimir данные хранятся на дисках vmStorage, а в Mimir используется S3. Например, при использовании replication factor 3, в Mimir для хранения 3,5 Тб метрик требуется всего 3 Тб дискового пространства. Это основано на реальных данных нашего проекта, где мы используем Ceph S3 с replication factor 3.
В статье проводится бенчмарк в течение одних суток, но вряд ли Mimir и Victoriametrics используются для хранения данных такого маленького периода. Кроме того, учитывая многоуровневый merge данных в Mimir, реальное потребление места на данных за день и месяц может значительно отличаться.
Ох, на самом деле, сложный вопрос. Если уже заговорили о VM, то это действительно хорошее решение. Однако не стоит забывать о нюансах, которые важно понимать. Далее, стоит оценить, насколько существенны для вас эти особенности и сделать выбор.
Во-первых, VM использует упрощенную модель хранения данных. Подробнее об этом можно прочитать здесь: https://www.robustperception.io/evaluating-performance-and-correctness/.
Во-вторых, VM применяет собственный формат хранения данных, и на данный момент существует возможность перехода на VM, но обратной миграции нет.
В-третьих, VM формально шардирует данные, но фактически не поддерживает механизм решардирования. Другими словами, если у вас есть кластер из 3 vm-storage, вы не можете отключить один vm-storage и на его месте запустить новый, более мощный (а затем проделать то же самое с остальными), на новые vm-storage будут записываться только новые данные, а старые не перенесутся.
В-четвертых, в Mimir долгосрочное хранилище отделено (это S3), что делает систему более гибкой.
С учетом этих нюансов, мы сделали выбор в пользу Mimir.
Ох, на самом деле, сложный вопрос. Если уже заговорили о VM, то это действительно хорошее решение. Однако не стоит забывать о нюансах, которые важно понимать. Далее, стоит оценить, насколько существенны для вас эти особенности и сделать выбор.
Во-первых, VM использует упрощенную модель хранения данных. Подробнее об этом можно прочитать здесь: https://www.robustperception.io/evaluating-performance-and-correctness/.
Во-вторых, VM применяет собственный формат хранения данных, и на данный момент существует возможность перехода на VM, но обратной миграции нет.
В-третьих, VM формально шардирует данные, но фактически не поддерживает механизм решардирования. Другими словами, если у вас есть кластер из 3 vm-storage, вы не можете отключить один vm-storage и на его месте запустить новый, более мощный (а затем проделать то же самое с остальными), на новые vm-storage будут записываться только новые данные, а старые не перенесутся.
В-четвертых, в Mimir долгосрочное хранилище отделено (это S3), что делает систему более гибкой.
В итоге вам необходимо определить, насколько вы согласны с этими нюансами.
Нет. При включении remote_write, Prometheus продолжает работать как "обычный" Prometheus. При этом у Prometheus есть режим работы, который называется Prometheus agent mode, вот в этом режиме он работает так как вы описали.
Подробнее про это можно почитать, например, тут: https://prometheus.io/blog/2021/11/16/agent/
Это не совсем относится к теме доклада, а так же с учетом ограниченности времени на доклад (и так пришлось сокращать его).
Но я могу предложить пару видео, которые позволят познакомиться с интерфейсами продуктов, о которых я рассказывал.
Grafana: https://youtu.be/QDV4KfDPs1E
Prometheus: https://www.youtube.com/watch?v=VUQ6RudYh_w
Mimir - не имеет собственного интерфейса.
А что бы вы хотели увидеть на скриншоте?
Да, полностью согласен. На самом деле, для использования SaaS много причин, но все они сводят: не хотим разбираться, а хотим взять готовое.
Log Management, Application Performance Monitoring, Exception Tracking это и многое другое мы, конечно же, планируем добавить. Но, прежде чем начать работу над этим функционалом, нам нужен хороший фундамент. В нашем случае фундамент - это Storage и сейчас мы активно работаем над ним.
Подробней, про наши текущие планы, про Storage, почему он в первую очередь и что будет далее, мы рассказали в нашем докладе на DevOops. (Расшифровка его будет уже совсем скоро.)
Этот шаблон имеет детализацию уровня БД, то есть по данным можно понять, что происходит или происходило с базой данных в целом, при этом понять, что привело к этому нельзя. Допустим, у вас была нагрузка на вм с базой данных в 3 часа ночи, из данных этого шаблона, максимум можно локализовать в какой именно БД была нагрузка.
Это хорошо, но как правило не достаточно. Для полноценного мониторинга надо иметь возможность посмотреть какие именно запросы создают нагрузку, какую нагрузку они создают, а так же каких запросов было больше всего.
Не всегда так, если мы говорим про запуск нового проекта есть кейсы, когда эти задачи могут быть отложены на более поздние этапы. И тут важно, что если мы откладываем это на следующие этапы, что это процесс не станет бесконечным.
Далеко не всегда так, зачастую технический долг начинает приносит реальный ущерб и это один из поводов задуматься о том, что долги пора вернуть.
Умение общаться с бизнесом на понятном языке, на мой взгляд, тоже относится к одной из граней профессионализма.
Понятие SLA появилось задолго до появления термина SRE и по этому давать определение не SRE вполне допустимо. Тем более, приведенное вам определение ни сколь не противоречит тому, что я привел.
SLA — это договор с внешними клиентами, который скорее всего предусматривает штрафные санкции.
SLO — это внутренний договор.
1. Смотрите, у вас есть микросервис А который зависит от 10 других. Допустим один из десяти является обязательным для микросервиса A и называется микросервис В. Так вот, если есть проблемы у микросервиса B, то это отразится и в показателях доступности микросервиса А, так как запросы к нему будут заканчиваться с ошибкой.
2. Зачастую строют графики не только по конкретным микросервисам, но и по проекту в целом.
3. При анализе работы используют еще и бизнесметрики. Например это может быть количество регистраций, количество бронирований или заказов.
4. Так же, за частую используют метрики полученные напрямую от устройства клиентов.
Приведенный вами пример, с математической точки зрения, верный и в целом не решен смысла. Но все не так линейно. И sli/slo это один из инструментов и на мой взгляд сильно переоцененный и работает он только в комплексе с большим количеством других инструментов и практик.
Позвольте не согласиться.
« Соглаше́ние об у́ровне предоставле́ния услу́ги (англ. Service Level Agreement, SLA) — термин методологии ITIL, обозначающий формальный договор между заказчиком (в рекомендациях ITIL заказчик и потребитель — разные понятия) услуги и её поставщиком, содержащий описание услуги, права и обязанности сторон и, самое главное, согласованный уровень качества предоставления данной услуги.»
Тут важно: согласованный уровень обслуживания. А санкции за не предоставления могут быть, а могут и не быть.
Если очень просто: SLA это договор с заказчиком, SLO ,SLI это внутренний договор. Как правило SLO и SLI более строгие, по отношению к SLA.
Не совсем так, у мобильной сети и у мобильного телефона меньше девяток и если повысить стабильность приложения с 99 на 99.9999% то пользователь скорее всего не заметит разницы, потому что мобильная и сам телефон работают не так стабильно.
Ну это достаточно утрированное произведение и в реальной жизни, вряд ли было бы так просто и быстро.
Но в целом, у меня в практике, да и у коллег, были кейсы где подобного рода предложения помогали развитию компании и карьерному росту:)