Агрегирование статистики по старым и новым событиям
Мы хотели бы подавать журналы CDN в Graphite и находить там совокупные числа (количество различных кодов состояния HTTP, средний размер ответов, средний коэффициент попадания в кэш и т. Д.)
Однако журналы загружаются нам только изредка, а иногда даже не в порядке - время от времени утренний журнал может быть загружен вечером, спустя часы после того, как дневной журнал был загружен и обработан. Кроме того, поскольку CDN (очевидно) имеет несколько серверов и центров обработки данных, различные журналы могут охватывать перекрывающиеся периоды.
Это означает, что любой агрегатор должен поддерживать доступ ко всем более ранним статистическим данным, чтобы иметь возможность увеличивать агрегаты при обработке нового журнала...
Что - если что - может сделать это? И как мне настроить logstash для подачи в него? Спасибо!
1 ответ
Это сложная проблема, как вы хорошо знаете. Вы отметили Logstash в своем вопросе, так что я собираюсь предположить, что у вас это есть.
Загрузка журналов - это то, что делает Logstash. Имеет file {}
входной плагин только для этого:
input {
file {
path => [ '/opt/export/cdn_logs/*.csv'
tags => [ 'cdnlogs' ]
}
}
И csv {}
фильтр для облегчения приема данных CSV.
filter {
if 'cdnlogs' in [tags] {
csv {
source => "message"
columns => [
'cdndate',
'host_server',
[...]
'response_time' ]
}
}
}
Если у вас нет данных CSV, возможно, эти строки в довольно нормальном формате Apache, еще не все потеряно. Возможно, вам придется провести время с Гроком. Это своя вещь.
Упорядочение дат - не проблема, если вы заботитесь о сохранении своих временных меток и не используете statsd, который явно не сохраняет их. Если вы еще этого не сделали, Logstash может взять дату в файле журнала и сделать ее отметкой даты / времени события.
filter {
date {
match => [ "cdndate", "ISO8601" ]
}
}
Это получает метку даты / времени логлайн как метку времени события. Круто, теперь, чтобы получить что-то полезное
Исходным хранилищем данных для Logstash является эластичный поиск, который Elastic (компания) старается выставить в качестве столь же хорошего хранилища временных рядов, как и специализированные инструменты, такие как InfluxDB или OpenTSDB. Может быть, хотя, по моему опыту, специально построенные работают лучше. Все они могут, при условии, что вы правильно ввели их, сохранять события в неправильном порядке в правильном порядке, чтобы последующие запросы могли ассимилировать новую информацию.
graphite {}
Выходные данные Logstash сохранят временные метки, что позволяет вам использовать графит в качестве резервного хранилища для этого, если хотите.
influxdb {}
а также opentsdb {}
выходные плагины существуют и доставят ваши данные в настоящую базу данных временных рядов.
Оттуда агрегирование / суммирование краткосрочных данных (через несколько дней после вашего объяснения) должно выполняться во время запроса. Такой инструмент, как графана, может отображать несколько таких хранилищ данных и упрощает отображение. Пройдя зону риска для поступления журналов, вы можете запустить более поздний процесс ETL, чтобы сгенерировать агрегирование / суммирование в базе данных на основе полного набора данных. А затем очистите журналы с полной детализацией по мере необходимости.
Одним словом, метод:
- Загружает файлы, используя Logstash.
- Использует фильтрацию для извлечения полей из лог-файлов CDN.
- Использует
date {}
фильтр, чтобы вытянуть метку времени журнала в метку времени события. - Экспортирует данные в нечто (эластичное, графитовое или в другую базу данных временных рядов)
- Инструменты отображения используют запросы агрегирования в реальном времени для отображения данных для потребителей, по крайней мере, для краткосрочных данных.
- Через некоторое время, возможно, пару дней, сценарий или другой автоматизированный процесс генерирует агрегаты и вводит их в хранилище данных.
- Через некоторое время данные с полным разрешением удаляются, оставляя только агрегированные данные.