Тезисы

Уже много было докладов про то, как разные компании переезжают на Prometheus, и мы не исключение. Мы в Lamoda тоже успешно применяем Prometheus для целей мониторинга, наверное, как и все, складываем в него миллионы различных метрик и чувствуем себя хорошо. Prometheus достаточно успешно справляется с очень большой write-нагрузкой, а что же с read? Мне так же хочется затронуть тему read-нагрузки и поделиться с вами в том числе и нашим не самым удачным опытом использования Prometheus.

Начать стоит с того, что же из себя представляет tsdb в самом простом случае и выработать требования. Поговорим о том, что такое ts и какие проблемы необходимо решить при построении такой db. Как можно с ними работать с точки зрения дисковой подсистемы, особенно когда у вас миллионы метрик. Как можно оптимизировать место, необходимое под хранение - delta encoding, double-delta encoding и т.д.

Перед тем, как выбрать ту или иную технологию, хорошо бы определиться с задачей, которую нам необходимо решать, знать, как технология работает внутри, как влиять на ее производительность и подстраивать под свои нужды. Про это и поговорим на примере трех решений, которые в последнее время завоевали популярность в качестве tsdb - это Prometheus, Influxdb, Gorilla. Постараюсь рассказать, как мы их анализировали и делали выбор и почему выбрали Prometheus.

Во второй части доклада расскажу про наш опыт работы с Prometheus, так как мы попытались использовать его не только для целей мониторинга, и что из этого вышло и почему. Дополнительно расскажу про некоторые особенности Prometheus (rushed mode, throttling), на которые стоит обратить внимание.