Комментарии 8
Я так понимаю, autovacuum тоже подкрутили или вообще отключили? Можете рассказать на каких настройках остановились?
0
Сборщик логов лезет по ssh и читает логи, используя tail -f? Шта? rsyslog — не не слышали?
Получение данных с сервера БД — проброс порта с использованием SSH и затем выполнение запроса «локально»? Нахуа? Вы не умеете настраивать pg_hba.conf? И еще, если я все правильно понимаю, то у какого-то софта есть возможность ползать по продуктивным серверам БД с использованием SSH? А у вас там есть отдел или служба ИБ, или тоже не слышали?
И вишенкой на торте будет попытка впихнуть невпихуемое. Я ведь все правильно понимаю, Вы берете неструктурированные данные (логи ведь не являются структурированными данными), пихаете их в реляционную СУБД, при этом, чтобы работало, Вы просто убираете ключи, тем самым, хороня с ходу все то, что делает реляционную БД реляционной. Сверху вы прикручиваете балансировщик, который балансирует запись в БД.
А у вас в команде есть PostgreSQL dba? который вам попытался или не попытался сообщить, что вы занимаетесь фигней… Хотя глупый вопрос, если вы это реализовали, то конечно же PostgreSQL dba в команде отсутствует, либо он не dba.
Я смотрю, что по изобретению велосипедов вы прям впереди планеты. Есть ли еще какие-то велосипеды, которые вы еще пока не изобрели? Или может быть поделитесь планами на будущее по изобретению велосипедов?
Кроме шуток. Мне очень интересно, сколько ресурсов вы затрачиваете на обсуживание всего этого, ну и поток данных, который вы обрабатываете? или может быть есть результаты нагрузочного тестирования? Я просто хочу сравнить с нашими объемами, быть может все то, что Вы сделали, действительно жрет меньше, обходится дешевле, и я просто ничего не понимаю в реализации обработки логов.
Получение данных с сервера БД — проброс порта с использованием SSH и затем выполнение запроса «локально»? Нахуа? Вы не умеете настраивать pg_hba.conf? И еще, если я все правильно понимаю, то у какого-то софта есть возможность ползать по продуктивным серверам БД с использованием SSH? А у вас там есть отдел или служба ИБ, или тоже не слышали?
И вишенкой на торте будет попытка впихнуть невпихуемое. Я ведь все правильно понимаю, Вы берете неструктурированные данные (логи ведь не являются структурированными данными), пихаете их в реляционную СУБД, при этом, чтобы работало, Вы просто убираете ключи, тем самым, хороня с ходу все то, что делает реляционную БД реляционной. Сверху вы прикручиваете балансировщик, который балансирует запись в БД.
А у вас в команде есть PostgreSQL dba? который вам попытался или не попытался сообщить, что вы занимаетесь фигней… Хотя глупый вопрос, если вы это реализовали, то конечно же PostgreSQL dba в команде отсутствует, либо он не dba.
Я смотрю, что по изобретению велосипедов вы прям впереди планеты. Есть ли еще какие-то велосипеды, которые вы еще пока не изобрели? Или может быть поделитесь планами на будущее по изобретению велосипедов?
Кроме шуток. Мне очень интересно, сколько ресурсов вы затрачиваете на обсуживание всего этого, ну и поток данных, который вы обрабатываете? или может быть есть результаты нагрузочного тестирования? Я просто хочу сравнить с нашими объемами, быть может все то, что Вы сделали, действительно жрет меньше, обходится дешевле, и я просто ничего не понимаю в реализации обработки логов.
0
Немного лирики…
Почему-то некоторые искренне веруют, что есть один и только один «правильный» путь решения задачи. Не в том смысле, что «вот смотри, это решение проще и эффективнее», а именно «неканон!»
Собирать логи? Только Kafka + ElasticSearch! Мониторинг? Только Grafana и агент! Хранилище со статистикой? Только ClickHouse! Система очередей? Только RabbitMQ!
Почему-то очень редко после этого возникает мысль «А ведь это просто один из возможных инструментов. А у тех есть свои недостатки.» — и если другой инструмент решает задачу и делает это хорошо и эффективно — почему нет?
А теперь по делу:
Почему-то некоторые искренне веруют, что есть один и только один «правильный» путь решения задачи. Не в том смысле, что «вот смотри, это решение проще и эффективнее», а именно «неканон!»
Собирать логи? Только Kafka + ElasticSearch! Мониторинг? Только Grafana и агент! Хранилище со статистикой? Только ClickHouse! Система очередей? Только RabbitMQ!
Почему-то очень редко после этого возникает мысль «А ведь это просто один из возможных инструментов. А у тех есть свои недостатки.» — и если другой инструмент решает задачу и делает это хорошо и эффективно — почему нет?
А теперь по делу:
- под мониторингом сейчас стоит примерно 1500 PG-хостов
- «сырых» логов генерируется суммарно примерно 230GB/сутки
- обработанной аналитики еще примерно 250GB/сутки
- суммарный формируемый в базу поток порядка 15-20K rows/sec или 200-250Mbps
- нагрузка на единственном сервере БД: CPU 5-7% (56 core), 2-3Kiops, 60MB/s
- нагрузка на паре коллекторов: CPU 25-40% (8 core)
Я смотрю, что по изобретению велосипедов вы прям впереди планеты. Есть ли еще какие-то велосипеды, которые вы еще пока не изобрели? Или может быть поделитесь планами на будущее по изобретению велосипедов?Мы любим велосипеды, как и другие компании. Потом из них появляются, например, такие вещи как React, Bootstrap, Chrome, AWS.
0
1500 PG-хостов и 15-20К rows/sec — это всего 10-13,(3) rows/sec с одного PG-хоста, при этом 200-250Mbps, т.е. на 1 row приходится около 1,5-3MB данных???
56 ядер на сервер БД, правда нагрузка всего 5-7% — непозволительная роскошь.
Непонятна мне Ваша лирика.
Да и меня смущает другое, зачем Вы используете то, что не предназначено для этой задачи?
56 ядер на сервер БД, правда нагрузка всего 5-7% — непозволительная роскошь.
Почему-то некоторые искренне веруют, что есть один и только один «правильный» путь решения задачи. Не в том смысле, что «вот смотри, это решение проще и эффективнее», а именно «неканон!»Это Ваш личный девиз или Вы лично следуете этому постулату? Или это чье-то высказывание? не вижу копирайта.
Непонятна мне Ваша лирика.
Да и меня смущает другое, зачем Вы используете то, что не предназначено для этой задачи?
0
56 ядер на сервер БД, правда нагрузка всего 5-7% — непозволительная роскошь.Да, но это получилось удачно взять «на вырост». Но несколько рефакторингов с тех пор снизили нагрузку кратно, несмотря на увеличение количества анализируемых хостов, поэтому продолжаем жить на том же железе.
tail -f? Шта? rsyslog — не не слышали?
Вы просто убираете ключи, тем самым, хороня с ходу все то, что делает реляционную БД реляционной
если вы это реализовали, то конечно же PostgreSQL dba в команде отсутствуетМожет, мне показалось, но это явно прозвучало как «неканон!»
на 1 row приходится около 1,5-3MB данных???200Mbps / 15Krps =~ 13.3Kb/row =~ 1.7KB/row
0
Может, мне показалось, но это явно прозвучало как «неканон!»Я не знаю, что значит «неканон», но я знаю, что есть более яркий пример — шуруп и молоток, т.е. все знают, что шурупы закручивают/заворачивают/ввинчивают, знают даже какой отверткой, шлицевая или крестовая, в зависимости от головки, но есть те, кто упорно пытаются забить шуруп молотком. Почему они это делают? Скорее всего потому, что умеют пользоваться только молотком, либо у них нет отверток. Конечно это можно сделать и молотком, но это потребует больше усилий, да и результат будет явно не такой, какой ожидается от вкрученного шурупа.
Но вы, конечно же, можете забивать шурупы молотком, объясняя свое поведение тем, что это просто иной, более прогрессивный, подход.
0
это потребует больше усилий, да и результат будет явно не такой, какой ожидается от вкрученного шурупаВот это я и имел в виду под «смотри, вот так можно эффективнее!»
Наши цифры приведены выше. PostgreSQL отлично себя показывает как хранилище структурированной информации с большой пропускной способностью на запись. При этом мы по-прежнему располагаем всем функционалом PG-экосистемы. В частности, имеем к нему SQL-доступ и практически мгновенную отзывчивость по всем отчетам в заранее заданных разрезах.
Если Ваше решение эффективнее — расскажите о нем, будет очень интересно сравнить. Потому что пока совсем непонятно, какой именно результат Вы ожидаете от «шурупа», и что с чем сравниваете, потому что пока выглядит как утверждение «все шурупы надо завинчивать только крестовой отверткой».
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Телепортация тонн данных в PostgreSQL