Журналы файлов WebServer иногда отсутствуют после обновления проекта WebSite с .NET Framework 3.5 до 4.7. - PullRequest
1 голос
/ 27 июня 2019

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

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

Private Shared Function Log(messageLog As String, fileName As String) As Boolean
    Dim result As Boolean = False
    Using streamWriter As StreamWriter = New StreamWriter(fileName, True)
        streamWriter.WriteLine(messageLog + Environment.NewLine)
        result = True
    End Using
    Return result
End Function

Public Shared Function LogInteraction(accountName As String, logMessage As String) As Boolean
    Dim logName As String = String.Empty
    Dim result As Boolean = False
    Try
        logName = String.Format("{0}_{1}",accountName, DateTime.Now.ToString("yyyyMMdd"))
        result = Log(String.Format("{0}, {1}, {2}", DateTime.Now.ToLongTimeString(), accountName, logMessage), logName)
    Catch ex As Exception
        result = False
        LogError("Could not log activity: " + logMessage + Environment.NewLine + ex.ToString())
    End Try
    Return result
End Function

теперь странная проблема заключается в том, что с тех пор, как мы обновили .NET Framework проекта с 3.5 до 4.7, мы начали видеть странный эффект - иногда веб-серверы не производилифайлы журналов.У нас есть полдюжины веб-серверов, обслуживающих одного клиента, в зависимости от нагрузки, пользователь, пытающийся получить доступ к сайту, будет перенаправлен на определенный веб-сервер.Таким образом, в плохой день более половины серверов имеют нулевые журналы, но, просматривая журналы IIS, мы видим нормальный трафик, поэтому не похоже, что существует проблема с балансировщиком нагрузки, и этот веб-сервер просто перестал получать трафик.

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

Вот некоторые ключевые данные, которые мы собрали, исследуя эту странную проблему:

  • иногда только один сервер пропускает журналы, иногда около половины;
  • не на тех же серверах возникают проблемы.Например: в понедельник на серверах № 3,5 и 9 нет логов.Во вторник серверы 2, 7 и 10 не имеют его;
  • никогда не сталкивался с этой проблемой в .NET Framework 3.5;
  • , в то время как библиотеки DLL, которые это регистрировали, изменялись (пришлось перекомпилироватьпоскольку мы перешли с 3.5 на 4.7), код не был выполнен;
  • сброс / перезапуск пула приложений волшебным образом решает проблему или вызывает ее (у нас был пул приложений для автоматической переработки заданий вскоре в полночь, и мы заметили, что проблема возникает илиисчезают в это точное время)

В настоящее время мы не имеем ни малейшего представления, почему эта проблема происходит или что ее вызывает.Мы перебираем код снова и снова, и он не выглядит как проблема с кодом - опять же, код отлично работает в 3.5.Кто-нибудь испытывал хоть что-нибудь похожее?

Спасибо

1 Ответ

0 голосов
/ 03 июля 2019

Проблема связана с кодом.

В DLL, которая входит в файл, была строка кода, которая в основном добавляла косую черту к пути к файлу журнала каждый раз, когда была запись в журнале. Таким образом, путь к файлу будет выглядеть примерно так: "c: \ mylogpath \\\ logfilename.txt" - что удивительно хорошо работает в Windows.

Этот путь к файлу является общей переменной, поэтому он не сбрасывается естественным образом (необходимо сбросить web.config или перезапустить пул приложений, чтобы веб-сайт сам себя сбросил). С каждой записью журнала косая черта перед logfilename.txt будет увеличиваться, пока переменная file-path не достигнет 32767 символов (до Windows 10), а затем не получит исключение «слишком длинный путь»

...