Из той же оперы: cloudvyzor.com. Зип аплоадишь и ищешь. Или указываешь внешнее хранилище с зипами (шара, S3, Azure Blob). Можно облачную версию юзать, можно скачать поставить себе (Windows, 2.5MB).
Развернуть все, что было от запуска production, не представлялось возможным, т.к. в кластере банально не было столько места. К тому же, доступ к логам из бэкапа требовался уже сейчас. Решение — развернуть временный кластер, в который восстанавливается бэкап, откуда уже и достаются нужные нам логи
Допускаете ли Вы возможность, когда во временный кластер тоже не поместится такое количество снапшотов, которое Вам нужно? Вот в этом комментарии было описано решение от человека, который собирает 5Тб в день: иметь параллельно снапшоты и текстовый архив логов. Если надо восстанавливать точечно — восстанавливаешь снапшоты. Если надо искать вширь — ищешь по текстовым логам. Мы попробовали, — это работает. Только у нас уже было много старых снапшотов, поэтому пришлось использовать отдельный конвертер снапшотов в текст. 60Тб снапшотов конвертировали в 3Тб зазипованных JSON, и в них вполне можно искать определенные нужные вещи за пару лет назад. Не так замечательно как в Эластике, но в [наш] временный кластер по любому 2 года снапшотов не влезает.
ghostinushanka, спасибо за детальный ответ. Обьемы, конечно, смущают. У нас, конечно, не 5TB в день, но все же… Если взять Ваши цифры на секунду…
То есть я правильно Вас понял, что если бы Вам потребовалось провести сложное расследование на всех 14 месяцах, то специалисту по Эластику, при наличии бюджета и за разумный срок (скажем неделя) не составило бы проблемы поднять в облаке Эластик-кластер на 2 петабайта логов?..
Или Вы как раз имели в виду, что чтобы «залить данные за полгода», нужно их иметь в исходном виде json, а не в снапшотах? Если это так, то это имхо, подтверждает необходимость файлового архива.
То можно поднять эластик который либо будет держать бОльший объем данных постоянно.
Этот вариант не рассматривается по причинам высокой стоимости. 4 недели и так уже серьезная стоимость, тем более что их несколько, один на каждый регион.
Либо поднимаем временный кластер в облаке заливаем в него данные за полгода, проводим анализ и убиваем кластер. Слава богу облака сегодня позволяют это делать быстро и недорого.
Этот вариант интересный, спасибо. надо будет оценить размер и стоимость такого кластера в облаке. Я правильно понимаю, что Эластик сможет как-то автоматически смерджить данные из этих 26 снапшотов, без дупликатов?
Спасибо. При этом под «бэкапом» понимается зип, в котором лежит текстовый файл с экспортированными в json всеми документами за определенный период времени или что-то другое?
Вопрос не праздный, я поясню. Была сереьезная разборка, когда внешний компонент одной уважаемой компании, при определенных обстоятельствах, мог отдать респонс не на твой запрос, а на совсем другой запрос, сделанный параллельно. Мы конечно сами виноваты что недостаточно изолировали, но как говорится «кто без греха...». Такое случалось очень редко, но могло сильно навредить. После закрытия дыры, надо было посмотреть «кого за это время могло задеть». Для этого, надо было в логах за полгода 1) найти все «плохие сессии» по признаку повышенного количества в них определенных ошибок 2) для каждой такой сессии найти соседние сессии, которые происходили на этом же хосте в это же время. 3) для 1) и 2) вынуть идентификаторы клиентов из определнных эвентов в сессии. Мы сделали это скриптами по архиву текстовых логов.
Сейчас у девопсов появился Эластик, в него влезает 4 недели и делаются ежедневные снапшоты штатными средствами. Теперь вопрос: может ли Эластик + снапшоты эффективно решить проблему выше? Или нам все же нужно параллельно держать текстовый архив, чтобы иметь возможность искать там скриптами или, в простом случае, логпадом. Нам кажется, что это имеет смысл, ищем подтверждения.
Я правильно, что в Вашем случае, как раз у Вас организован похожий архив?
ghostinushanka чем ищете в бэкапах, если не секрет? Скриптами? Или это вообще никогда не бывает надо? Нам тут как-то понадобилось пойти на полгода назад, посмотреть каких кастомеров потенциально могло зацепить одной редкой проблемой…
Допускаете ли Вы возможность, когда во временный кластер тоже не поместится такое количество снапшотов, которое Вам нужно? Вот в этом комментарии было описано решение от человека, который собирает 5Тб в день: иметь параллельно снапшоты и текстовый архив логов. Если надо восстанавливать точечно — восстанавливаешь снапшоты. Если надо искать вширь — ищешь по текстовым логам. Мы попробовали, — это работает. Только у нас уже было много старых снапшотов, поэтому пришлось использовать отдельный конвертер снапшотов в текст. 60Тб снапшотов конвертировали в 3Тб зазипованных JSON, и в них вполне можно искать определенные нужные вещи за пару лет назад. Не так замечательно как в Эластике, но в [наш] временный кластер по любому 2 года снапшотов не влезает.
То есть я правильно Вас понял, что если бы Вам потребовалось провести сложное расследование на всех 14 месяцах, то специалисту по Эластику, при наличии бюджета и за разумный срок (скажем неделя) не составило бы проблемы поднять в облаке Эластик-кластер на 2 петабайта логов?..
Или Вы как раз имели в виду, что чтобы «залить данные за полгода», нужно их иметь в исходном виде json, а не в снапшотах? Если это так, то это имхо, подтверждает необходимость файлового архива.
Этот вариант не рассматривается по причинам высокой стоимости. 4 недели и так уже серьезная стоимость, тем более что их несколько, один на каждый регион.
Этот вариант интересный, спасибо. надо будет оценить размер и стоимость такого кластера в облаке. Я правильно понимаю, что Эластик сможет как-то автоматически смерджить данные из этих 26 снапшотов, без дупликатов?
Вопрос не праздный, я поясню. Была сереьезная разборка, когда внешний компонент одной уважаемой компании, при определенных обстоятельствах, мог отдать респонс не на твой запрос, а на совсем другой запрос, сделанный параллельно. Мы конечно сами виноваты что недостаточно изолировали, но как говорится «кто без греха...». Такое случалось очень редко, но могло сильно навредить. После закрытия дыры, надо было посмотреть «кого за это время могло задеть». Для этого, надо было в логах за полгода 1) найти все «плохие сессии» по признаку повышенного количества в них определенных ошибок 2) для каждой такой сессии найти соседние сессии, которые происходили на этом же хосте в это же время. 3) для 1) и 2) вынуть идентификаторы клиентов из определнных эвентов в сессии. Мы сделали это скриптами по архиву текстовых логов.
Сейчас у девопсов появился Эластик, в него влезает 4 недели и делаются ежедневные снапшоты штатными средствами. Теперь вопрос: может ли Эластик + снапшоты эффективно решить проблему выше? Или нам все же нужно параллельно держать текстовый архив, чтобы иметь возможность искать там скриптами или, в простом случае, логпадом. Нам кажется, что это имеет смысл, ищем подтверждения.
Я правильно, что в Вашем случае, как раз у Вас организован похожий архив?