В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Сбор и аналитика системных сообщений

1046 membersпожаловаться на группу
2021 February 03

В

Вадим in Сбор и аналитика системных сообщений
Aleksey Shirokikh
есть что почитать на эту тему ?
time series db наверное поможет понять что как и почему
но имея опыт БД разработки выскажу свое мнение - все должно быть в меру и иметь смысл
в локи например нет смысла плодить метки вообще - зная время инцидента и автоматически добавленные метки - легко при помощи regexp либо распасенного json найти все что нужно
источник
17:36пожаловаться#1

AS

Aleksey Shirokikh in Сбор и аналитика системных сообщений
Вадим
time series db наверное поможет понять что как и почему
но имея опыт БД разработки выскажу свое мнение - все должно быть в меру и иметь смысл
в локи например нет смысла плодить метки вообще - зная время инцидента и автоматически добавленные метки - легко при помощи regexp либо распасенного json найти все что нужно
это всё понятно. почему в проме важны метки и их кардинальность — мне ясно.
не ясно почему большое колво меток плохо для локи.
ведь они позиционируются как раз типа как пром но для логов.
источник
17:41пожаловаться#2

AS

Aleksey Shirokikh in Сбор и аналитика системных сообщений
вот например в гугле меток на каждом логе очень много. и это довольно удобно. можно фильтрануть по кластеру, ворклоаду, региону и команде разработки и прочему.
такое же поведение я перенес на спланк. это тоже довольно удобно. но почему не на локи ?
источник
17:42пожаловаться#3

i

inqfen in Сбор и аналитика системных сообщений
что-то по этой теме тоже читал, там поиск реализован не так же как в проме
источник
17:42пожаловаться#4

i

inqfen in Сбор и аналитика системных сообщений
То есть ты можешь вешать хоть по 100 лейблов, но это поиск нагрузит
источник
17:42пожаловаться#5

i

inqfen in Сбор и аналитика системных сообщений
И поэтому чем их меньше - тем для него лучше
источник
17:42пожаловаться#6

AS

Aleksey Shirokikh in Сбор и аналитика системных сообщений
ну вот я про то где почитать этот момент. особенности реализации стораджа
источник
17:43пожаловаться#7

В

Вадим in Сбор и аналитика системных сообщений
Aleksey Shirokikh
это всё понятно. почему в проме важны метки и их кардинальность — мне ясно.
не ясно почему большое колво меток плохо для локи.
ведь они позиционируются как раз типа как пром но для логов.
смысл в том чтобы индекс был маленьким - этим достигается скорость выборки нужного блока логов из террабайтов а уж грепать этот выбранный кусочек - это пустяки
источник
17:44пожаловаться#8

AS

Aleksey Shirokikh in Сбор и аналитика системных сообщений
полагаться на чьёто мнение в этом месте не хотелось бы.
источник
17:44пожаловаться#9

AS

Aleksey Shirokikh in Сбор и аналитика системных сообщений
Вадим
смысл в том чтобы индекс был маленьким - этим достигается скорость выборки нужного блока логов из террабайтов а уж грепать этот выбранный кусочек - это пустяки
маленьковость индекса это относительное понятие
источник
17:44пожаловаться#10

В

Вадим in Сбор и аналитика системных сообщений
Aleksey Shirokikh
маленьковость индекса это относительное понятие
почитайте введение - они там об этом пишут в абсолютных величинах)
источник
17:45пожаловаться#11

В

Вадим in Сбор и аналитика системных сообщений
все предыдущие системы сбора логов основаны на идеях реляционных баз и для скорости выборок требуют большого количества индексов == железа === денег
источник
17:46пожаловаться#12

AS

Aleksey Shirokikh in Сбор и аналитика системных сообщений
предыдущие системы сбора логов не основаны на реляционных моделях.
источник
17:49пожаловаться#13

AS

Aleksey Shirokikh in Сбор и аналитика системных сообщений
по крайней мере я не знаю кто бы хотел вставлять в условную муську логи.
источник
17:49пожаловаться#14

AS

Aleksey Shirokikh in Сбор и аналитика системных сообщений
их пихали в эластик или монгу а они ну совсем не реляционные.
источник
17:49пожаловаться#15

В

Вадим in Сбор и аналитика системных сообщений
Aleksey Shirokikh
предыдущие системы сбора логов не основаны на реляционных моделях.
идеи !== реализации
источник
17:50пожаловаться#16

AS

Aleksey Shirokikh in Сбор и аналитика системных сообщений
как я вижу для хранения индекса в локи используется
An index for the chunks. This index can be backed by:

   Amazon DynamoDB
   Google Bigtable
   Apache Cassandra
источник
17:50пожаловаться#17

В

Вадим in Сбор и аналитика системных сообщений
Aleksey Shirokikh
их пихали в эластик или монгу а они ну совсем не реляционные.
и в монге и в других БД - основное понятие реляции - связи присутствует между сущностями
источник
17:50пожаловаться#18

AS

Aleksey Shirokikh in Сбор и аналитика системных сообщений
ни один из них не реляционный. и не имеет изместныхмне ограничений на выборки по набору полей
источник
17:50пожаловаться#19

AS

Aleksey Shirokikh in Сбор и аналитика системных сообщений
Вадим
и в монге и в других БД - основное понятие реляции - связи присутствует между сущностями
в монге нет реляций
источник
17:51пожаловаться#20