Лучшее место для файлов журналов в собственной ИТ-среде

Question

Все мои пользователи находятся в нескольких минутах ходьбы по коридору, и все мои программы работают на рабочих станциях в одной локальной сети. Несколько лет назад я велел сотрудникам записывать файлы журналов для всех своих программ в иерархию общих папок, называя каждый файл журнала после имени машины в подкаталоге, названном в честь приложения.

Но эта договоренность не была такой уж хорошей, поскольку, если файловый сервер вышел из строя, ни одна из программ нигде не могла записывать логи. Тем не менее, ведение журналов локально для каждой рабочей станции затруднит чтение их всякий раз, когда нам приходится отлаживать проблему.

Мы попытались создать псевдоним DNS для файлового сервера журналов, чтобы при необходимости указывать его на резервную машину, но псевдонимы DNS не работают с общими файловыми ресурсами Windows.

Указывать путь к папке общего журнала в каждой программе не очень хорошо - даже если она настраивается в полевых условиях - потому что у нас десятки программ на десятках машин.

Мы также изучили использование распределенной файловой системы Microsoft, но цена смешная.

Мне бы хотелось собрать один журнал для многих программ в локальной сети, чтобы я мог отслеживать и анализировать их, не посещая удаленный компьютер. Мы используем .Net для всех наших программ.

Редактировать: Я бы не хотел настраивать общий файловый ресурс на рабочей станции каждого пользователя или решения, которые тралят журналы каждую ночь, так как я хочу иметь возможность читать свежие журналы по требованию, или через несколько минут после сообщения о проблеме.

Answer 1

В ИТ-среде, с которой я работал несколько лет назад, у каждой машины была локальная запись файлов журналов и их очистка каждые пять дней. Сервер будет входить в систему каждую ночь, чтобы получать последние журналы с каждой машины. Если сервер выйдет из строя, он просто заберет у всех журналы за два дня. Если клиент не работает, его журнал может быть получен и на следующий день.

Answer 2

Мы используем подход регистрации в известном месте локально, который является общим. После этого второй процесс может легко извлечь эти журналы для последующей обработки (выгрузка в базу данных, сбор и архивирование и т. Д.). Если процесс сбора данных умирает, то на самом деле это никак не влияет.

Убедитесь, что у вас нет центральной точки отказа. Я видел примеры этого, в которых использовалась центральная база данных журналов, от которой зависели все приложения, и когда она выходила из строя, все остальное делало тоже. Не умный.

Answer 3

Наш магазин имеет хороший опыт хранения журналов в таблице базы данных. Вы можете запланировать очистку как задание базы данных, когда захотите, чтобы она не стала слишком большой.

Answer 4

Вы можете использовать MSMQ . Запишите свои журналы в очередь MSMQ, а затем получите службу, которая собирает эти журналы и помещает их в базу данных или в файл в центральном расположении, если хотите. Он не будет мгновенным, но вы можете указать, чтобы он запускался всякий раз, когда вы хотите получить новые записи в журнале. Плюс это было бы надежно, так как он использует MSMQ.

Answer 5

Я согласен с комментарием craigb . В среде локальной сети следует избегать создания дополнительных точек сбоя.

Я предпочитаю, чтобы клиенты регистрировались локально, а затем копировали эти файлы журналов в центральное место. В этом случае, если ваш сервер журналов падает, серьезных перебоев не будет. Кроме того, иногда запись файла журнала в сеть может стать узким местом для производительности.

Другая проблема с центральным сервером журналов заключается в том, что если одно приложение ведет себя плохо, оно может удалить все приложения. Я видел бесчисленные ошибки, которые, когда встречаются, приводят к тому, что программа входит в бесконечный цикл и издает сообщения журнала, пока устройство не заполняется.

Если вы действительно хотите централизованное ведение журнала, по причинам соответствия или что-то еще, я бы либо записал на сетевой диск, либо записал бы в сокет в стиле syslogd . Так как syslogd довольно стандартный, у вас не должно возникнуть проблем с его настройкой на сервере, и есть множество примеров кода и библиотек для его записи. Можно даже настроить баланс аппаратной нагрузки так, чтобы он располагался перед двумя или более серверами syslogd, обеспечивая более высокую доступность службы.

Answer 6

запись в базу данных также (например, CALM ), так что вам придется троллить файлы журнала только когда база данных не работает

Answer 7

DFS входит в состав Windows Server, и вы можете regedit , чтобы включить NetBIOS с CNAME.

Я также пробовал Splunk для извлечения и анализа файлов журналов, но это немного загружает процессор, и я не мог сэкономить лошадиные силы. В остальном, тем не менее, это был довольно хороший продукт.

Answer 8

Мы написали одно приложение, в котором размещаются другие приложения (архитектура подключаемых модулей). При возникновении исключения необходимая информация записывается в файл XML на компьютере пользователя (который называется .xml). Либо по нашему запросу, либо когда приложение закрывается, оно отправляет XML в веб-службу, где записывает файлы в место, где мы можем их проверить и проверить.

Если веб-служба не работает, это не представляет особой проблемы, поскольку файл XML все еще находится на компьютере пользователя и будет загружен при следующем запуске приложения.

Answer 9

А как насчет регистрации вашего приложения в качестве абонентского сервиса (с использованием удаленного взаимодействия). Затем внедрите LogServers, которые подписываются на приложение. Когда приложению есть что зарегистрировать, оно отправляет его подписчикам. Если есть проблема, например, абонент не отвечает / не работает, и у вас нет работающих подписчиков, напишите локально, но подайте сигнал тревоги. Например. мультимашинная версия классов TraceListener и Debug.

Вы почти наверняка захотите, чтобы приложение отправляло сообщения журнала из другого потока в остальную часть приложения.

Answer 10

Можно ли записать файлы журнала на локальный компьютер пользователя, а затем создать сценарий, который перенаправляет их на общий файловый сервер в виде пакетного задания на ночь?