Конечно можно и так. Только если мы не хотим отслеживать замену без нашего ведома (утащю ка я диск по тихому). Иначе создаётся отдельный ключ и добавляется в папку scripts то что вы предложили. Данные обновляемого списка сравниваются с disks.cmd. Если данные отличаются — создаётся триггер и по проблеме удалённо запускается DiskInfoGenerationJSON.cmd. Мы обновили список дисков и имеем доказательную базу замены/удаления. К сожалению всё в одно статье не описать. Поэтому приведены только основы для творчества.
Да можете и не использоваеть logstash. По сути он как клиентская нода, в примере, собирает с удалённых серверов данные и выводит всё в elasticsearch с указанием на индекс по tcp, а последний уже представляет её. Если не в elasticsearch, то можно вывести всё в файл, далее в фильтре указать шаблоны которые разбивают содержимое лога по принципу key=value, использовать регулярные выражение и т.д., чтобы сделать его читабельным и порезать ненужное.
remove => [ "blablabla" ] — удалит содержимое с заголовками blablabla.
gsub => [ "ROBOT", "0", "1" ] — в поле ROBOT все нули станут единицами.
pattern => "%{IP:client} " — выведет "client: 10.0.10.123"
Есть дефолтные ориентированные шаблоны. Примеры тут.
В моём примере logstash настроен принимать данные на порт 5044, и выводить данные в elasticsearch по индексу | месяц число год, время | лога. На скринах это первый столбец.
Logstash определяет по каким каналам принимать данные с beats, как отфильтровать эту информацию, и как это вывести (в зависимости от условий). Без logstash, в elasticsearch нужно будет самому сортировать инфу по индексам вручную, через kibana или с помощью http запросов.
По первому ответу не много не понял. Плагины же по факту индексируют нацеленные файлы на основе своего кода, которые анализирует файлы на клиенте и предоставляет их уже elasticsearch, а собственно на сервер идёт обработка их в logstash по загруженным индексам от плагина. В чём негатив чтения в данном случае? Не скажу что у меня много глубокого опыта в этом продукте, поэтому хотелось бы подробней уточнить этот момент.
По поводу графиков, то есть возможность любое событие фильтровать. Соответственно анализируя плагинами логи виртуального хоста, можно сознать планировщики сигналок по нужным индексам (например 404, 423 и т.д.) и у казать их в редакторе визуалайзера Kibana4. в графе фильтр
{
«filter»: []
}
Опять же, глубоко я это не разгребал, не смогу пока что сходу описать код под конкретную задачу. Поэтому буду рад указаниям на мои ошибки, и их разъяснениям =)
Почему не собираете данные напрямую из систем логирования *syslog или journald? Чтение уже записанных файлов не оптимально, да и теряется часть информации.
Именно filebeats этим и занимается. Обновлённая в файле информация моментально поступает на сервер, и только обновлённая (не весь файл целиком). Это могут быть не только динамические файлы, но и, например, конфиги, маунты. А далее плагин watcher ищет в логах то, о чём нам срочно нужно знать (что искать определяется собственными индексами конечно).
Строите ли какие-нибудь сводные графики и чем?
Графики можно строить в визуалайзере Kibana4. В наборе beats-dashboards, который я описывал, есть уже много готовых.
Ну вообще эластикс только предоставляет информацию, и уведомляет о необходимом уровне реакции (например, по шедулеру фильтровать журналы elasticsearch на ошибки, слать тикеты на почту [watcher]).
Если вы имеете ввиду автоматическое устранение проблемы на хосте, при её выявлении, то тут уже однозначно используется код понятный системе, и уровень создания такой автоматической реакции зависит от опыта написания такого кода. Для транспортировки кода можно использовать такие системы как puppet, chef. По мне я люблю salt, т.к. люблю питон.
remove => [ "blablabla" ] — удалит содержимое с заголовками blablabla.
gsub => [ "ROBOT", "0", "1" ] — в поле ROBOT все нули станут единицами.
pattern => "%{IP:client} " — выведет "client: 10.0.10.123"
Есть дефолтные ориентированные шаблоны. Примеры тут.
По поводу графиков, то есть возможность любое событие фильтровать. Соответственно анализируя плагинами логи виртуального хоста, можно сознать планировщики сигналок по нужным индексам (например 404, 423 и т.д.) и у казать их в редакторе визуалайзера Kibana4. в графе фильтр
{
«filter»: []
}
Опять же, глубоко я это не разгребал, не смогу пока что сходу описать код под конкретную задачу. Поэтому буду рад указаниям на мои ошибки, и их разъяснениям =)
Именно filebeats этим и занимается. Обновлённая в файле информация моментально поступает на сервер, и только обновлённая (не весь файл целиком). Это могут быть не только динамические файлы, но и, например, конфиги, маунты. А далее плагин watcher ищет в логах то, о чём нам срочно нужно знать (что искать определяется собственными индексами конечно).
Графики можно строить в визуалайзере Kibana4. В наборе beats-dashboards, который я описывал, есть уже много готовых.
Если вы имеете ввиду автоматическое устранение проблемы на хосте, при её выявлении, то тут уже однозначно используется код понятный системе, и уровень создания такой автоматической реакции зависит от опыта написания такого кода. Для транспортировки кода можно использовать такие системы как puppet, chef. По мне я люблю salt, т.к. люблю питон.