Представляю текстовую версию моего недавнего разговора с коллегами из Data Egret — компании, которая специализируется на поддержке PostgreSQL. Я пообщался с Ильей Космодемьянским (CEO) и Алексеем Лесовским (senior DBA). Обсудили, как мониторить PostgreSQL, какие бывают ошибки при выборе и настройке систем мониторинга, кто такие DBA и какие soft skills для них важны, а также затронули более хардкорные темы. Пост объемный, но он того стоит. Илья: Всем привет. Меня зовут Илья Космодемьянский. Я CEO компании Data Egret и один из ее основателей. Мы занимаемся поддержкой баз данных PostgreSQL. Нам часто приходится решать вопросы вроде «Что произошло?», «Кто бросил валенок на пульт?» и т. п. Клиентов у нас много, базы огромные. Без нормального мониторинга мы бы, конечно, всё это не осилили. Поэтому тема сегодняшнего разговора — мониторинг. Мои собеседники — это коллега Алексей Лесовский, большой специалист по Postgres, и Владимир Гурьянов, который занимается разработкой системы мониторинга Okmeter. Система много чего умеет мониторить, в том числе Postgres. Владимир: Я буду сегодня выступать не как эксперт, а скорее как ведущий. Коллеги, расскажите, чем вы занимаетесь. Илья: Мы поддерживаем всё, что касается базы данных Postgres. Мы давно работаем на российском и зарубежном рынках. У некоторых компаний есть администраторы баз данных — DBA (database administrator). Мы можем такого DBA заменить или дополнить. То есть следим за тем, чтобы базы данных в компании были под присмотром, все рутинные задачи решены, траблшутинг оттраблшучен. Чем мы отличаемся от обычного DBA? У большинства администраторов в Data Egret гораздо больше опыта эксплуатации самых разных баз, больше сложных ситуаций, с которыми приходилось сталкиваться. Как правило, стрессовые штуки встречаются нам гораздо раньше: мы раньше нащупываем баги, раньше встреваем в какие-то проблемы. Владимир: Я в свое время достаточно долго работал инженером. Знаю, что во всех компаниях есть база данных (БД), но не у всех есть выделенные DBA. Поддержкой БД занимаются там обычно инженеры эксплуатации или разработчики. В какой момент у компании появляется необходимость в выделенном DBA, когда они к вам приходят? Кто вообще ваши клиенты? Илья: У нас очень разные клиенты. Отсутствие у них выделенного DBA может быть связано с кучей разных особенностей. Например, компания еще не доросла до этого, и БД проще поручить сисадмину. Иногда просто нет регулярных задач для DBA. Многое зависит от того, какая специфика бизнеса, как разработан бэкенд, как он ходит в базу и т. д. Среди наших клиентов и маленькие, и большие компании. Есть большие компании, у которых целый отдел опытных DBA, но поскольку они постоянно работают с плюс-минус одним проектом, им бывает нужна внешняя экспертиза — помочь разобраться с чем-то специфическим, какой-то подземный стук диагностировать.  Бывает, что для небольшой компании мы периодически выступаем в роли DBA, потому что постоянно он им не нужен. Владимир: Мне раньше казалось, что DBA — это такие специалисты, которых очень сложно найти. При этом в последние несколько лет большинство компаний осознали, что все они — ИТ-компании: что магазин одежды, что ритейл, что ресторан. Существенно вырос спрос на ИТ-специалистов. И это очень заметно по разработчикам, по DevOps-инженерам. А как обстоят дела с DBA? Илья: Точно так же... Кстати, мы ищем DBA. Если кто интересуется, обязательно пишите. (Смеется.)  Дело в том, что DBA исторически был не очень популярной профессией. Многие разработчики считают, что это какая-то скучная старперская штука. Почему-то это не популярно. Прикольнее быть каким-нибудь разработчиком Haskell, стоять на переднем крае технологий. Поэтому дефицит DBA был всегда. Это довольно дорогие специалисты, с вредным характером. DBA знает себе цену, он разбирается, куда пойти работать, хочет много денег, приятного графика. К тому же, сейчас появились две тенденции. Во-первых, количество БД растет — в связи с любовью к миросервисам, со всеми этими подходами, которые приносят много пользы бизнесу. Из-за этого масса всяческих издержек. Когда у тебя, скажем, 20 баз, начинаются гораздо более интересные истории, чем когда у тебя одна большая база, за которой могут следить двое DBA. То есть микросервисы тоже влияют на рост спроса. Во-вторых, многие компании считают, что им не нужен целый DBA, что хорошо бы иметь отдел на подхвате, который в случае чего может прийти на помощь. Владимир: Как вообще попадают в эту профессию? Можно ли перейти откуда-то? И с чего стоит начать? Илья: На эту тему можно долго рассуждать. Я когда-то даже специальный доклад делал, чтобы рассказать, с чего начать, какие книжки читать. Но сейчас я могу точно сказать: было бы желание.  Один из профилей людей, которых мы обычно ищем, это уверенный пользователь Linux. Тот, кто не боится командной строки, не боится читать документацию. Это программа-минимум. И я бы сказал, что при должной въедливости остальному научим.  Дальше мы начинаем рассуждать о том, что нужно иметь какое-то представление о математической логике, о базах данных, о том, что такое транзакция. Но, по моему опыту, этому можно научиться по ходу дела. Владимир: Сейчас ИТ-рынок активно развивается. Каждый день появляются сотни новых технологий и направлений. Насколько это влияет на БД? Или это все еще такой укромный, консервативный уголок, где рост не столь стремительный и бурный?  Илья: Рост, конечно, не столь бурный и стремительный, как много где. Но при этом понятно, что БД — это не уголок. БД — это такая штуковина, которая есть практически в любой компании. Она находится в центре ИТ-инфраструктуры, хочешь ты этого или нет. Все системы с ней взаимодействуют. Если, условно говоря, активно развивается Java, сообщество придумывает какие-то новые технологии, появляются какие-то принципиально новые языки, то неминуемо уголок DBA перестает быть уютным. Потому что эти новые языки и технологии должны взаимодействовать с базой. И DBA нужно вникать, что там происходит — на уровне решения проблем, которые вызывает конкретное приложение, написанное на конкретном языке. Могу по своему опыту сказать, что мне приходилось работать с языками, на которых я в жизни ничего не мог написать. Потому что когда я что-то кодил, их еще не было или они еще не набрали популярность. Но все эти технологии надо учить, разбираться в них. На самом деле здесь зеркальная ситуация. Если ты работаешь с БД, у тебя с одной стороны консерватизм, а с другой — постоянно происходит накопление новых знаний. Потому что все эти новые знания в базу ломятся, их периодически надо траблшутить. Это очень расширяет кругозор. Владимир: Я прекрасно понимаю, о чем ты говоришь. Вроде бы Linux остался тот же самый, а языков и технологий появилось такое количество… Но перейдем к мониторингу. Мониторинг — такая же важная штука для БД, как и для любой другой системы в ИТ-ландшафте? Илья: Иногда даже еще более важная.  Владимир: А насколько принципиально отличается мониторинг БД от мониторинга того же Linux? Илья: Linux долгое время был немного вещью в себе в плане диагностики. Такие технологии, как eBPF, стали появляться относительно недавно. Долгое время средства диагностики были довольно куцые: какой-нибудь мониторинг ввода-вывода в виде iostat и примерно всё. Что касается БД, то здесь всегда было нужно разобраться с тем, что происходит с запросом, почему именно он тормозит, где узкие места, какой тренд в нагрузке, трассировка, сэмплинг и т. д. То есть базы начали тщательно мониторить немножко раньше, это базам имманентно. Владимир: А бывает так, что к вам кто-нибудь приходит с просьбой о помощи и оказывается, что у них совсем нет системы мониторинга? Илья: Бывает, конечно, но очень редко. Обычно с мониторингом такая же ситуация, как с бэкапами: часто люди снимают бэкапы, а восстановление с них не тестируют. Это такая массовая большая беда.  С мониторингом бывает так, что он вроде как есть, но в реальном траблшутинге задействован редко. Снимаются какие-то метрики, которые при возникновении проблем просто не помогают. Еще бывает, что в мониторинге нет чего-то важного, зато какая-нибудь левая хрень есть. Владимир: Какая система самая распространенная среди ваших клиентов? Алексей: Давайте я попробую ответить, но начну с предыдущего вопроса. Илья говорил, что к нам приходят клиенты, и у них, бывает, мониторинга нет. На самом деле Илья немного приукрашивает ситуацию. Да, приходят клиенты, у которых действительно нет мониторинга... Илья: Я политкорректен. Алексей: Да, ты политкорректен, но всё намного страшнее, чем кажется. (Смеется.) Люди приходят без мониторинга. Либо с мониторингом, но они в него не смотрят.  Иногда мониторинг есть, но мониторится только операционная система, а остальные компоненты инфраструктуры, включая БД, — нет. Используется какой-то дефолтный мониторинг, который шел в комплекте. По поводу того, какая система — самая распространенная. Здесь можно поделить мониторинг на опенсорсный и на закрытый. Если брать именно опенсорсный, то на первом месте Zabbix. Он появился раньше, чем Prometheus, более распространен. Для него больше есть всяких рецептов, плагинов. Он до сих пор хорошо развивается, с каждым релизом много интересных функций выходит. Он постоянно в движении.  На втором месте Prometheus и, как правило, Grafana для отрисовки графиков. Это два основных мониторинга, которые мы чаще всего встречаем. С Zabbix довольно легко начать, потому что у него свой пользовательский интерфейс, своя база знаний внутри, где довольно много решений описано: как что ставить, что мониторить.  С Prometheus чуть сложнее. У него большая экосистема экспортеров. Очень часто экспортеры предлагают базовую функциональность, и расширять ее нужно самому пользователю. Чтобы ее расширить, приходится глубже погружаться в предметную область того объекта, который нужно замониторить. И вот здесь начинаются сложности. Можно, конечно, довериться кому-то из экспертов по Prometheus. Либо можно самому из интернета скачать какие-то дашборды, какие-то темплейты конфигов и их использовать. Но здесь тоже могут быть сюрпризы: скачиваешь что-нибудь этакое, открываешь дашборд в Grafana, но там чего-то не хватает. Потом приходится самому это добавлять, кастомизировать эти дашборды. С Zabbix в этом плане попроще. Владимир: Не сталкивались ли с такой ситуацией, когда система мониторинга вместо того, чтобы приносить пользу, давала какую-то большую часть нагрузки на БД? Илья: Нет ли здесь скрытого наезда на Zabbix? (Смеются.) Алексей: Бывало, но такое по пальцам можно пересчитать. Я с таким сталкивался, может, один-два раза. Илья: У нас иногда бывали на поддержке просто базы с Zabbix, которым требовался траблшутинг. Владимир: Я понимаю, о чем идет речь, я видел пару инсталляций, которые собирали метрики с 5-6 тысяч хостов, и Zabbix’у в этом случае было достаточно тяжко. На самом деле это был наезд не на Zabbix. В моей практике мне попадалась достаточно нагруженная БД. Там были экспортеры от Prometheus, один из них немножко аффектил базу. При определенном стечении обстоятельств бывало печально. Алексей: Могу привести пример из своего опыта. В PostgreSQL есть модуль, который называется pg_buffercache. Он показывает утилизацию шаренных буферов. Запросы, которые используют pg_buffercache, раньше были довольно тяжелыми. (Сейчас — не знаю, может ситуация улучшилась.) И когда в мониторинг добавляешь запросы, которые используются в pg_buffercache, это начинает создавать довольно-таки хорошую нагрузку и может привести к проблемам. Я сам наступал на такие грабли, когда делал плагины для Zabbix. Владимир: А есть какой-то топ распространенных ошибок, с которыми вы встречаетесь при построении мониторинга у клиентов? Илья: Наиболее частая проблема — это отсутствие должного мониторинга. То есть мониторинг какой-то стоит, а на график, например, ничего не выведено. Бывает, что вроде бы какая-то информация в системе есть, можно посмотреть, просемплить. Но когда встает вопрос о том, что было вчера в 2 часа ночи, ничего не видно. И главное — не видно тренда, куда ситуация развивается. Очень часто берут дефолтные дашборды и считают, что у них теперь есть мониторинг. При этом зачастую там достаточно бесполезная информация.  Бывает, что не сбрасывают статистику. У Postgres есть есть довольно странный, по историческим причинам, просмотрщик — pg_stat_bgwriter. В силу того, как он сделан, в нем надо периодически скидывать статистику. Если статистика ведется от начала инсталляции базы, смысла в ней довольно мало. Тем не менее бывает, что вроде бы дашборд сделан, выведены графики этих циферок, но они абсолютно неинформативны, потому что статистика просто не скидывалась. Скажу так: мониторинг часто носит на себе следы его неиспользования. Владимир: Расскажите про взаимодействие с Okmeter еще до того, как он стал частью «Фланта». Как вы вообще познакомились, как началось ваше сотрудничество? Илья: Во-первых, мы были знакомы: когда-то давно с одним из основателей Okmeter мы сисадминили в одной конторе. Во-вторых, на самом деле это было очень органичное взаимодействие. Ребята, которые начали делать Okmeter, работали в службе эксплуатации одного из наших клиентов. Их бизнес родился из того, что они просто начали делать свой мониторинг, который бы мониторил всё более комфортно. Поскольку там большая часть инфраструктуры была Postgres’овой, мы им помогали сделать эту часть. Ну, и постепенно это вылилось в такое взаимодействие, когда мы говорили ребятам: мы хотим вот это мониторить. А те говорили: окей, хорошая идея, давайте сделаем. Владимир: Чего, на ваш взгляд, не хватает Okmeter на данный момент — не только в разрезе БД, а в целом? Алексей: В плане развития мониторинговых вещей, которые в Postgres появляются, они появляются с каждым релизом [Okmeter]. Другое дело, что клиенты не всегда используют самый свежий Postgres. Бывает даже так, что есть базы Postgres, которые вышли из поддержки, для них патчи не выпускаются и т. д. Поэтому, конечно, в мониторинг можно добавлять новые фишки, связанные с Postgres, но это не самое основное. Некоторые можно и потом добавить, через несколько лет.  Более насущная проблема Okmeter — это то, что, как правило, не хватает чего-то по мелочи в плане интерфейса или в плане каких-то функций, связанных с самим мониторингом. Но в целом, если говорить о функциях, когда мы делали техзадание на мониторинг PostgreSQL, мы заложили все основные вещи. Okmeter сделал их, и нам до сих пор хватает этого с лихвой. Это и топ-графики, и графики по запросам — то, чего не хватает в том же Zabbix. Если же говорить про интерфейс, то там бывают всякие мелочи — например, работа с датами не всегда удобная. Приходится лишнего накликивать, чтобы получить желаемое. Или, например, с алертами бывает неудобно работать: есть группа DBA, серверы баз данных, и нам нужно алерты только по этим серверам получать. Но мы получаем алерты по всем инстансам. Приходят, скажем, алерты, которые связаны с тем, что контейнера больше не существует. Ну, и бывает, что не хватает документации. Язык свой, его нужно знать, там много функций, операторов. В документации есть примеры использования, примеры запросов. Но какие-то угловые кейсы, использование каких-то экзотических функций — ты их просто не знаешь, а они могли бы где-то облегчить жизнь. Приходится как-то по наитию все это изучать.  Есть всякие неочевидные тонкости типа копирование элемента легенды по тройному клику. Для нас в свое время это было открытием. (Смеются.) Не знали, что такое есть, в документации тоже, по-моему, этот момент не описан. Вполне допускаю, что есть и какие-то другие неочевидные вещи.  То, что я перечислил относится, как правило, к работе с мониторингом, с пользовательским интерфейсом. А в плане мониторинга базы данных, в общем-то, всего хватает.  Владимир: Есть хорошая новость, что в обозримом будущем интерфейс будет существенно улучшен. Мы уже активно делаем новый интерфейс, прямо с нуля. Надеюсь, уже скоро все его смогут попробовать. Алексей: Главное, не отключать старый. Потому что знаете, если пользователям подсовываешь что-то новое, они такие: «У-у, не то. Верните нам старое». Илья: На самом деле, когда Okmeter появился, его интерфейс после Zabbix был вау. Владимир: В процессе работы у вас накапливается какой-то большой объем знаний, опыта. Понятно, что часть своего опыта вы вложили в Okmeter. А все остальное вы как-то внутри агрегируете, делитесь этим с общественностью? Илья: У нас много способов. Во-первых есть свое внутреннее хранилище инцидентов, опыта, набитых шишек, инструкций и так далее — как у всех. Во-вторых, мы стараемся все это активно объяснять людям на всех основных конференциях Postgres-коммьюнити, на коммерческих конференциях, где Postgres — одна из тем. Алексей тоже довольно много делает для того, чтобы этот опыт передать. Принципиальная такая позиция: мы не боимся раскрывать наш опыт.  При этом я должен честно сказать, что идеального способа куда-то эти знания дампить, а потом ресторить кому-нибудь в голову, я пока не придумал.  Сами по себе знания можно сейчас получить откуда угодно. У Postgres хорошая документация, масса справочных материалов. Можно пойти на «Планету», почитать, что там пишет куча умных людей, почитать рассылку «Хакера». Правда это занимает много времени. А для DBA очень важная часть — это опыт, который, в общем-то, не пропьешь. Знать много про PostgreSQL — это одно, а быть хорошим траблшутером Postgres’а — это принципиально другая история.  Владимир: А у вас есть какие-нибудь внутренние тренажеры для тех, кто приходит в компанию? Может быть, какой-то тестовый контур, где вы ломаете базу и просите починить? Илья: Мы несколько раз такие вещи делали. Но с БД в  этом плане сложно. Можно сделать тренировочную БД, но будет понятно, что она тренировочная. Какие-то задачи можно выполнять только на реальных клиентских кейсах, когда что-то происходит. К сожалению, тут очень сложно потренироваться сначала на кошках, а потом делать что-то свое. Хотя в принципе у каждого есть какие-то тестовые места для упражнений. Владимир: Кстати, о траблшутинге… Бывает же, наверное, в процессе вы находите какие-то неприятные баги в самой базе или в каких-нибудь Open Souce-утилитах. Как часто приходится коммитить исправления? И насколько активно компания участвует в жизни Open Source-проектов? Илья: Если говорить о PostgreSQL, то это удивительно стабильный проект, с хорошим качеством кода. Что-то критичное, что надо срочно исправлять, появляется крайне редко. За всё время, пожалуй, всего один раз был очень серьезный баг, который затронул клиента. Баг был зарепорчен и очень быстро исправлен. По-моему, в версии 9.3 поломали репликацию, и при определенных случаях восстановление не происходило. Из бэкапа, соответственно, тоже. По мелочи же это постоянно происходит, потому что на подводные грабли с таким объемом клиентов мы наступаем регулярно.  Коммитить что-то самим и баги находить — это несколько разные вещи, и у нас часто этим занимаются разные люди. Мы очень много репортим багов в баг-рассылку. Потому что репортинг бага — это немножко другая задача, чем просто разработка. Я думаю, что Максим Богук, небезызвестный наш коллега, зарепортил багов больше, чем иные коммитеры за всю историю проекта PostgreSQL. Даже был анекдот, что это не реальный человек, а какая-то группа анонимных хакеров под псевдонимом шлет в баг-рассылку истории. При этом надо понимать, что у нас сложившийся workflow. То есть мы знаем, как описать баг, как его воспроизвести. Примерно знаем, кто обычно работает с этой тематикой в Postgres, кого пнуть на этот счет персонально, если баг завис. Но помимо это мы контрибьютим — как кодинг, так и некодинг. У нас есть ребята, которые постоянно попадают в списки контрибьюторов, потому что что-то делают. Например, Сергей Корнилов и Виктор Егоров. Я со своей стороны решаю некоторые менеджерские задачи сообщества. Поскольку сообщество — большое, таких задач тоже довольно много. Там надо и с людьми взаимодействовать, и организационные вопросы решать — то, чем, например, занимается европейская ассоциация PostgreSQL, где и я сижу. Там огромный список разных вещей, начиная с проведения конференций, заканчивая юридическим сопровождением коммьюнити. Это очень комплексная тема. Владимир: Я даже немного растерялся: никогда не думал, что Open Source-сообщество вокруг баз данных настолько развито и настолько многогранно. В целом для меня БД всегда были немного темным ящиком. Оказывается, здесь гораздо более яркая и активная жизнь, чем кажется со стороны. Владимир: В моем коротком списке остался один вопрос, который я бы хотел обсудить. Не так давно Дима Столяров выступал с докладом «Перестаньте делать Kubernetes». Основная идея в том, что Куб — это очень сложная штука, и каждой компании делать ее очень дорого и сложно. Поэтому намного выгоднее и интереснее отдать ее кому-то на обслуживание, а самому заниматься более интересными задачами. Как вы думаете, насколько этот тезис справедлив по отношению к базам данных и к мониторингу —  в том, чтобы отдать все эти составные кубики куда-то на аутсорсинг? Илья: Сложный вопрос. Старорежимные админы раньше ругались на всякие микросервисы, контейнеры и прочее. Например, у вас есть проблема монолита. Вы разбиваете монолит на 50 маленьких монолитиков, и они должны взаимодействовать между собой. Но вы убрали одну проблему, перенесли ее на другой уровень и добавили новых. В принципе, это не решение первоначальной проблемы.  То есть — да, прикольно сосредоточиться на своем основном бизнесе; например, продавать мороженое на весь мир, его логистику обеспечивать. А ИТ-инфраструктуру такой компании, которая гипотетически будет играть огромную роль, отдать на Managed Kubernetes. Но очень быстро в таких компаниях мы что наблюдаем: что админам и техническим менеджерам, которые там работают, внезапно нужны совершенно другие скиллы. Можно даже взять такой вульгарный пример. Например, мы, не сильно заморачиваясь с тем, как это должно работать, накликиваем в Amazon инфраструктуру компании. Что нам нужно: PostgreSQL, DynamoDB, какие-нибудь файловые хранилища, серверы для приложений и т. д. Во-первых, это будет очень дорого: не зная, можно очень легко пробить любой бюджет, особенно при масштабировании. С другой стороны, мы гарантированно сделаем это неправильно. В лучшем случае накликаем все это от рутового амазоновского пользователя, без правильного понимания политик, без правильного понимания менеджмент-ресурсов. То есть уже нужен специальный человек, который из кубиков что-то умеет составлять. Мы просто сдвигаем то, где у нас админ. Теперь он занимается немного другими вещами, но все равно он нужен. Владимир: Да, все так. В этой ситуации по сути есть два таких рабочих решения. Это либо нанимать в штат специалистов, которые будут хорошо разбираться в предметной области, либо отдавать ее компаниям на аутсорсинг. Раньше компании очень боялись отдавать что-то во вне. И у меня такое ощущение, что в последнее время это очень сильно изменилось. Компании стали нормально к этому относиться, потому что сложность возросла настолько, что невозможно держать такое количество специалистов, просто невыгодно. Илья: С одной стороны, это действительно так. С другой, я бы сказал, что компании научились работать с аутсорсингом, в хорошем смысле. Потому что одна из суровых проблем, с которыми мы сталкиваемся, это когда приходит к тебе, например, клиент — компания со своими поставленными процессами. Эти процессы, чего греха таить, неоптимальны. (Ни у кого нет оптимальных: ни у нас, ни у вас, ни у кого из наших слушателей. Всегда есть что-то индивидуальное, что в процессе изменений, что-то не совсем корректное.) И часто бывает так, что сложность процессов компании несоизмерима с тем, чтобы взять аутсорсинг. Ты хочешь взять DBA на аутсорсинг, а выясняется, что у тебя процедура согласования любого процесса, связанного с БД, включает 50 сотрудников из 20 департаментов. Никакой DBA этим заниматься не будет. А на самом деле тебе нужен DBA с большими скиллами менеджмента и с пониманием процессов именно этой компании.  Многие компании научились с этим работать. То есть, когда стало понятно, что проще держать внешнюю экспертизу, и стали целенаправленно учиться, как с такой экспертизой работать.  В то же время многие поняли, что обнести все колючей проволокой и переживать за свою безопасность без внешних подрядчиков — тоже не вариант. Все равно что-то когда-то рискует утечь. Нужно наращивать серьезную безопасность вместо того, чтобы считать, что мы просто не пускаем никого к себе в контур и поэтому якобы безопасны. Это тоже поменялось. Владимир: Еще один вопрос про современные тенденции. Я все чаще вижу и слышу от коллег-инженеров, что при приеме на работу все больше учитываются не только hard skills, но еще и soft skills. Я знаю, что ряд крупных российских компаний при наличии двух примерно сопоставимых по силам кандидатов выбирают того, у кого сильнее soft skills, даже если слабее hard skills. А в случае с DBA это как-то проявляется? Илья: Проявляется, конечно. Леша не даст соврать, мы иногда шутим, что нам нужно уметь не столько даже базу починить, сколько задушевную беседу с клиентом провести. Огромное количество проблем с БД связаны не с ними как таковыми, а с тем, что там какая-то ошибочная настройка, или плохой запрос приехал. Запросы пишут люди, настройки делают тоже люди. Люди делали что-нибудь, как им привычно, может быть, не совсем оптимально, и у них появилась какая-то проблема. Им надо объяснить, что виновата не база, а виноват подход — даже если он 10 лет назад был правильный, даже если вчера был правильный. Просто ситуация изменилась.  Поэтому для DBA умение объяснять на самом деле всегда было очень важным скиллом, а сейчас — особенно, поскольку все усложнилось. С БД работают разные люди из разных технологий. Люди часто гораздо больше ориентированы на продукт. И мне кажется, что soft skills просто всегда были недооцененными у базистов, потому что, дескать, они такие вот совсем системщики, в своей базе сидят и ничего вокруг не замечают. Но это на самом деле не так, и никогда так не было. Алексей: Согласен с Ильей. Soft skills нужны, Всегда нужна способность договариваться с клиентом, самыми разными способами объяснять свою, скажем так, не претензию, а причину проблем. Если он не понимает, нужно с другой стороны зайти и снова как-то объяснить. И это нужно делать оперативно. Эти скиллы очень нужны и без них никуда. Просто потому что в какой-то момент можно зайти в тупик с клиентом: он будет стоять на своей позиции, DBA — на своей. Это будет контрпродуктивно для всех. Илья: Это вообще давняя проблема эксплуатации и разработки. Очень часто бывает, что они сидят по разным окопам и друг с другом враждуют. А по идее, должны делать одно и то же дело. Для DBA, который ответственен за работу БД и считает что, это единственное, за что он ответственен, разработчики — это перманентная головная боль, потому что все время рискуют положить БД. Если заниматься тем, что просто отбиваться от разработчиков, не пытаясь проявить эмпатию, понять, почему они так делают, как они замотивированы, то это путь в никуда. Ты очень быстро начнешь посылать всех, как человек за прилавком. Это неконструктивно и для работы, и для отношений, и для всего прочего. Разработчик придумывал месяцами какую-то фичу, вынашивал разрабатывал, пробовал, ошибался. Тут он приносит тебе ее на ревью перед выкатыванием в бой (и хорошо, если приносит, а не так, что выкатил — и она упала). А ты ему говоришь: «Ну Вася, ты и дурак. Кто ж так делает...» Какой результат у такого диалога будет? (Смеются.) Вопрос из чата: «Что Okmeter использует для хранения метрик?» Владимир: Это отличный вопрос. У Okmeter изначально был разработан свой формат хранения и передачи метрик. Сейчас он использует Cassandra как долгосрочное хранилище. Также у него есть Kafka в качестве буфера, и кэши, которые держат в памяти метрики за 1 час и за 4 часа. Но поскольку, повторюсь, там свой формат передачи метрик и их группировки, это позволяет потреблять не очень много ресурсов при большом объеме данных. Андрей: Планируются ли в Okmeter какие-то интеграции с облачными метриками? Владимир: Да, планируются. Если у вас есть какие-то конкретные пожелания, предложения, напишите мне, мы это зафиксируем. Сейчас мы определились с направлениями, которые мы хотим сделать в первую очередь. У нас точно будет интеграция с большинством облаков. Пока четкого понимания, какие метрики и откуда мы будем забирать, нет, но в планах это есть. А также — автодетекты того, в каком облаке запущен агент, уведомления, если не хватает каких-то доступов, и так далее.  Вячеслав: Привет. Хотел бы поблагодарить Алексея Лесовского за его доклад на предыдущей конференции, которая была в этом чате. С удовольствием послушал. Я один из тех людей, которые сделали свой мониторинг — на базе InfluxDB со сборщиком Telegraf. Причина, по которой я сделал такой мониторинг: InfluxDB был хранилищем метрик, который был под рукой. Почему я продолжаю его использовать: попробовал Prometheus и InfluxDB. В Influx у меня получилось сделать различные retention policies с разным шагом хранения метрик. Метрики хранятся несколько месяцев и потом стираются. А в Prometheus не было такого встроенного механизма, и там они хранятся неделю у нас на стенде. Мы храним сразу в двух местах: неделю в Prometheus и много месяцев в другом хранилище.  По поводу Okmeter хотел узнать какой-то, может быть, секрет, как там всё хранится. Может, какой-то ClickHouse или еще что-то более компактное, производительное. Владимир: Если вам интересно посмотреть, как это реализовано под капотом, на YouTube есть большой доклад Николая Сивко. Он рассказывает как раз о том, как устроено хранилище Okmeter и почему именно такое решение было выбрано. В рамках текущей встречи в двух словах не рассказать, там много нюансов.  К слову, небольшой анонс. В ближайшие полгода, может быть, чуть больше, мы планируем запустить новый вариант хранилища для Okmeter. Как только мы получим первые результаты, мы обязательно ими поделимся. Но нам кажется, мы придумали достаточно интересную историю. Расскажем-покажем, как это будет работать. Дмитрий: Всем привет. Учитывая, что здесь две компании, у меня вопросы к обеим.  Okmeter — достаточно большой комбайн, который мониторит много чего, насколько активно он смотрит в сторону развития мониторинга PostgreSQL, о котором в том числе Алексей Лесовский рассказывал в свое время. Появляются какие-то достаточно интересные дополнения к Postgres, которые, может быть, тоже было бы интересно мониторить — TimescaleDB и что-то еще.  Владимир: По поводу развития мониторинга PostgreSQL мы продолжаем взаимодействовать с коллегами [из Data Egret]. Всё то, что появляется нового в Postgres, и то, что нужно добавлять, мы стараемся дорабатывать. В целом мы сейчас формируем обширный бэклог, который включает как текущие продукты и список того, что нужно доработать, так и новые. Потому что сейчас есть ряд новых, модных баз данных и продуктов, которые набирают популярность, и которые у нас недостаточно еще покрыты. И мы активно занимаемся развитием в этом направлении.  В любом случае система мониторинга — это очень живая вещь, которую нельзя сделать один раз так, чтобы она работала потом 5-10 лет. Ее нужно все время дорабатывать. В частности, поэтому у нас есть отдельная команда, которая занимается исключительно тем, что смотрит, какие метрики нужно еще собирать, как эти метрики формировать в полезные дашборды. Помимо этого, она взаимодействует с большим количеством разных компаний, как внутренних, так и внешних, разбирает реальные кейсы, вытаскивая из них информацию: какие данные еще нужны, как сформировать дашборды таким образом, чтобы можно было еще быстрее находить проблемы; как сформировать алерты таким образом, чтобы в следующий раз не допустить эти проблемы, узнавать о потенциальных проблемах заранее и успеть их предотвратить.  Дмитрий: Будут ли рассматриваться какие-то изменения, кроме технических — например, по коммерческой модели предоставления услуг? Владимир: Это более сложный вопрос. Прошло еще немного времени с момента приобретения Okmeter. У нас есть идеи по тому, как мы изменим коммерческую модель. На данный момент это точно не будет связано с подорожанием [тарифов]. Детальной информации у меня сейчас нет. Но в ближайшие полгода-год позитивные изменения будут. Дмитрий: У меня еще вопрос к Илье. Действительно вы правы по поводу того, что многие приходят с достаточно слабым мониторингом. И мы, в принципе, относимся к таким же компаниям. Ваша команда очень часто рекламирует Okmeter. А вы не думали его сами продавать в комплекте со своими услугами, чтобы клиенту не приходилось куда-то ходить, заключать с кем-то договор? Илья: На самом деле мы так делали: продавали нашим клиентами Okmeter «в коробке» для простоты. Но часто был обратный запрос, и связан он с очень простой технической историей. Как уже прозвучало, Okmeter — это такой комбайн, который много чего другого обслуживает. Мы обслуживаем только БД, а есть еще инфраструктура, с которой работают админы. Довольно неудобно получалось, когда серверы в мониторинг добавлялись через нашу команду. Чисто технически это получалось довольно странно. Как правило, тем, кто это пробовал, нужно было мониторить и что-то, совсем не касающееся PostgreSQL. Поэтому мы теперь клиентов сразу перенаправляем к коллегам. Вячеслав: У меня есть вопрос на коммерческую тему. Раньше у Okmeter было две недели триального срока, что в принципе хорошо, чтобы оценить систему. А сейчас — неделя, и мне кажется, это маловато. Почему такие изменения произошли? Владимир: Изменения произошли чуть раньше того момента, когда Okmeter перешел к «Фланту». И про причины, почему случилось именно так, я вам не смогу ответить. Но я записал себе этот вопрос, мы с коллегами обсудим и подумаем. Возможно, вернутся старые две недели. Илья: У нас есть вопрос в чате по поводу обработки статистики pg_stat_statements: «Как лучше группировать статистику — по queryid, query text, по обработанному query text? И почему?» Алексей: Я пришел к тому, что лучше всего группировать по трем полям: имя БД, имя пользователя и queryid. Потому что queryid не уникальный, и появляются дубликаты. Чтобы эти дубликаты отсечь, нужно группировать еще по userid и dbid. Второй момент — по query text. С ним возникает та же проблема. Понятно, что в production, скорее всего, одинаковые запросы в разных базах данных не появятся. Но если какая-то инсталляция, где и production, и stage, и тестовая базы живут на одном оборудовании, или, например, собираются в одно хранилище, то можно получить одинаковые запросы. Причем одинаковые запросы, которые выполняются в разных базах, с разными пользователями. Нужно это учитывать. И третий пункт — по обработанному query text. Я так подозреваю, что здесь вопрос в том, что нужно как-то предварительно нормализовать этот текст, и уже от него отталкиваться. Тут тоже есть нюанс. Когда мы обрабатываем этот query, получаем какую-то новую сущность. И если раньше у нас была возможность группировки по имени пользователя, имени базы и по queryid, то теперь появляется еще четвертая сущность. И всё становится немного сложнее. Допустим, в мониторинге мы увидели этот обработанный query, и это какой-то идентификатор. Мы должны его сопоставить с оригинальным запросом, который находится в pg_stat_statements. И вот тут могут быть сложности для обратной трансляции. Поэтому на мой взгляд самый лучший вариант — это связка из трех полей: имени пользователя, имени базы и queryid. Вячеслав: Спасибо, Алексей. Я тоже сейчас стал использовать queryid. И когда общался с коллегами из Okmeter на стенде конференции HighLoad, мне рассказывали про специальную пост-обработку, которая позволяет получать статистику по двум похожим запросам, как-то объединить. Алексей: Да, они нормализуют запрос, и потом уже по этому нормализованному запросу отображают статистику. Вообще, нормализация pg_stat_statements не очень оптимальна. Например, запросы с разным количеством параметров в списке будут считаться отдельно. Хотя по факту это один и тот же запрос, просто количество параметров отличается. Они решили эту проблему через свою собственную нормализацию.  Владимир: Хочу добавить, что у Okmeter появился свой чат. Если у кого-то есть вопросы по мониторингу, рады будем ответить.  Дмитрий: У меня еще один вопрос. Есть такая клевая штука в Okmeter, которая называется как-то Prometheus-like-API. В моем случае она мне очень пригодилась. Там, где я сейчас работаю, довольно много разных мониторингов. И это удобно собирать с разных систем: что-то одна система лучше мониторит, что-то — другая. А у Grafana единый интерфейс, и там уже права проще раздать: этот может смотреть это, другой — то. Эта штука как-то будет поддерживаться и развиваться? Владимир: Это хороший вопрос, спасибо. Та функциональность, которая есть, точно будет сохранена, во всяком случае в ближайшее время. Во-вторых, то, о чем идет речь, если я правильно понимаю, — да, будет развиваться. В глобальном роадмапе есть планы настроить совместимость Okmeter с Prometheus. Чтобы его можно было использовать не только как полноценную систему мониторинга, но и как облачное хранилище для метрик, очень быстрое и очень дешевое. Оттуда можно будет читать и туда можно будет писать. По индустриальным стандартам это, скорее всего, будет Prometheus read и Prometheus write. Илья: Всем спасибо. И до новых встреч в эфире. Читайте также в нашем блоге: «Postgres-вторник №5: PostgreSQL и Kubernetes. CI/CD. Автоматизация тестирования»; «Как будет развиваться сервис мониторинга после его покупки „Флантом“»; «Обзор операторов PostgreSQL для Kubernetes. Часть 1: наш выбор и опыт». Ведущий инженер