чтобы в случае проблем можно было по session_id проследить как шел запрос и где именно возникли неполадки.
Эту информацию должно генерировать само приложение. Восстанавливать дерево вызовов по логам — жопа. Это неправильно.
Вам нужно искать решение из области Application performance management
И пусть вас не смущает слово performance. Там есть не только это.
Например, для Java приложений море коммерческих и свободных инструментов, которые позволяют посмотреть дерево вызовов для бизнес-транзакций. Легко понять, в каком месте бизнес-операция заняла больше всего времени.
Не выбрасывайте. У Graylog точно так же неудобно читать логи. Интерфейс там аналогичный, больше подходит для аналитики
А может и ребята из Graylog подумают над улучшением своего интерфейса, посмотрев на вашу фичу. Штука крутая.
Расскажите подробнее. Стоит такая же задача. Почему приняли решение отказаться?
Производительность сильно упала по сравнению с syslog? Что, если в ELK отправлять не всё подряд, а наиболее значимую информацию?
для отслеживания ситуации в реальном времени использовать стриминг on demand
Почему же, несмотря на такую активность, это база данных по-прежнему далеко не так распространена
Одну из причин я знаю совершенно точно. Что не ищешь в поисковие по PostgreSQL, попадаешь на дебильные списки рассылок. Кто-то конечно привык, но какой век на дворе? Хочется видеть knowledge base article с описанием симптомов и решением проблемы.
Расскажите подробнее о том моменте, когда вы решили изменить подход. Решение инициировал руководитель проекта? Были ли несогласные с тем, что нужно что-то коренным образом изменить подход?
Думаю, что отсутствие авторизации (в т.ч. и единой), отсутствие URL источника запроса в результатах поиска, поддержка https говорит само за себя. Все остальные меры предосторожности, в виде сокрытия IP адреса уже не относятся к поисковику.
Ну а что вы хотите? Вот я вчера акриловую ванну устанавливал… с ней крепления шли родные. Знаете, сколько там багов?
Слесарь сверлит отверстия тупым сверлом, так, что металл на выходе рвёт.
Заводские отверстия находятся не в том месте, где должны были быть, так что саморезы в них не закрутить
Инструкция одна — комплектющие другие.
Длинна шурупов в инструкции указана такой, что если эту инструкцию соблюдать, то ванную можно продырявить насквозь и выкинуть.
Вобщем, вместо прогнозируемого 1 часа потратил 4
Это наводит на мысли, что проблема не в технологиях, а всё же в людях, а именно, в организации производства продукта.
Владелец фирмы вовсе не заботится о качестве продукта, который его фирма производит. Видимо, прибыль есть и им этого достаточно.
Хотел бы обратить внимание, что наблюдения Loxmatiymamont основаны на его личном опыте. И не стоит считать всех индусов «абсолютно безграмотными». Пишу этот комментарий со знанием дела прямо из Индии, сидя рядом с ребятами из техподдержки. Так что мой комментарий касается скорее не индусов-клиентов, а индусов-инженеров. Мои наблюдения:
1. Из 15 человек выделил только двоих, кто откровенно слаб по техническим навыкам. Такой же процент и в России
2. Некоторые стараются найти проблему «интуитивным» методом, а не логическим. Но и бывают моменты просветления.
3. Есть очень сильные инженеры — не хуже наших. Но их мало.
4. Знание английского в обществе несравнимо выше, чем в России. Несравнимо. Шутка ли — все предметы преподаются на английском. Все учебники на английском. Мойщик посуды в столовой общался со мной на самые. Разные темы, свободно говоря на английском. То же самое было с одним таксистом. В кинотеатре почувствовал себя лошарой, когда не улавливал шутку на английском, а весь зал смеялся.
5. Нам из России не виден тот объем работ, который приходится проделывать нашим коллегам из Индии ежедневно, поэтому мы не замечаем успешных кейсов и акцентируем внимание на фейлах. Поэтому среди русских коллег преобладает точка зрения, что тут все бестолковые и ленивые.
6. Темпы развития страны поразили. Подрастающее поколение будет более конкурентоспособно на мировом рынке по сравнению с нашей страной. Так что ситуация вскоре может измениться.
В отношениях между людьми особенно опасен соблазн объяснять поступки другого человека каким-то одним
фактором или обстоятельством: «Он индус, он русский» Именно наша человеческая склонность легко и не задумываясь клеить друг другу совершенно однозначные ярлыки мешает нам понимать друг друга.
А уж они-то за этим следят. Для наблюдения за полигоном «Кура» на Камчатке США содержат постоянную станцию наблюдения «Eareckson Air Station» (бывшая авиабаза «Shemya») в 935 километрах от полигона, на одном из Алеутских островов Аляски. База оснащена радарами и самолётами для наблюдения попаданий на полигоне. Один из этих радаров, «Cobra Dane», был создан в 1977 году на Shemya специально для этих целей.
Эту информацию должно генерировать само приложение. Восстанавливать дерево вызовов по логам — жопа. Это неправильно.
Вам нужно искать решение из области Application performance management
И пусть вас не смущает слово performance. Там есть не только это.
Например, для Java приложений море коммерческих и свободных инструментов, которые позволяют посмотреть дерево вызовов для бизнес-транзакций. Легко понять, в каком месте бизнес-операция заняла больше всего времени.
А может и ребята из Graylog подумают над улучшением своего интерфейса, посмотрев на вашу фичу. Штука крутая.
Почему приняли решение отказаться?
Производительность сильно упала по сравнению с syslog? Что, если в ELK отправлять не всё подряд, а наиболее значимую информацию?
Как вы это реализуете и с помощью чего?
Мне кажется, потенциально опасное желание. В случае внештатной ситуации на АЭС, под угрозой останутся все ЦОДы Росатома
Одну из причин я знаю совершенно точно. Что не ищешь в поисковие по PostgreSQL, попадаешь на дебильные списки рассылок. Кто-то конечно привык, но какой век на дворе? Хочется видеть knowledge base article с описанием симптомов и решением проблемы.
Вобщем, вместо прогнозируемого 1 часа потратил 4
Это наводит на мысли, что проблема не в технологиях, а всё же в людях, а именно, в организации производства продукта.
Владелец фирмы вовсе не заботится о качестве продукта, который его фирма производит. Видимо, прибыль есть и им этого достаточно.
Автору советую посмотреть на это решение https://www.graylog.org/
2. Пожалуйста, не забудьте выложить слайды участников. Зачастую на видео их прохо видно
1. Из 15 человек выделил только двоих, кто откровенно слаб по техническим навыкам. Такой же процент и в России
2. Некоторые стараются найти проблему «интуитивным» методом, а не логическим. Но и бывают моменты просветления.
3. Есть очень сильные инженеры — не хуже наших. Но их мало.
4. Знание английского в обществе несравнимо выше, чем в России. Несравнимо. Шутка ли — все предметы преподаются на английском. Все учебники на английском. Мойщик посуды в столовой общался со мной на самые. Разные темы, свободно говоря на английском. То же самое было с одним таксистом. В кинотеатре почувствовал себя лошарой, когда не улавливал шутку на английском, а весь зал смеялся.
5. Нам из России не виден тот объем работ, который приходится проделывать нашим коллегам из Индии ежедневно, поэтому мы не замечаем успешных кейсов и акцентируем внимание на фейлах. Поэтому среди русских коллег преобладает точка зрения, что тут все бестолковые и ленивые.
6. Темпы развития страны поразили. Подрастающее поколение будет более конкурентоспособно на мировом рынке по сравнению с нашей страной. Так что ситуация вскоре может измениться.
В отношениях между людьми особенно опасен соблазн объяснять поступки другого человека каким-то одним
фактором или обстоятельством: «Он индус, он русский» Именно наша человеческая склонность легко и не задумываясь клеить друг другу совершенно однозначные ярлыки мешает нам понимать друг друга.