Переключалка не выглядит правильным способом решения проблемы. Скорее всего, HttpClient в связке с CurlHandler должен при неудачном Negotiate-запросе пробовать следующий вариант. Скоро закинем вопрос на github.
Проблема в том, что окружение на test/stage/production серверах может сильно отличаться, что ведет к непредсказуемым ошибкам. С контейнерами можно быть уверенным, что если это работает локально, то также будет и на продакшене.
А вообще Хансельман написал отдельную статью, отвечающую на этот вопрос.
В проекте используется минимальное количество функционала IIS, поэтому по поводу расставания с ним у нас не возникло сомнений. При появлении необходимости будем брать фронтенд-сервер в соответствии с условиями. Какую то часть на себя возьмет Kubernetes (например, балансировщик).
По поводу AD — аутентификация происходит во внешнем для нашего решения сервисе, настройкой аутентификации в данном проекте не занимаемся.
Контейнеров будет несколько — основной мобильный сервис, сервис push уведомлений, сервис управлениями баннерами. Как раз про контейнеры подробно напишем в следующих статьях.
Всем угодил. NLog умеет в .NET Core 2, пока что живем с ним. Но, судя по опыту других наших проектов, интеграция Serilog с ELK происходит прозрачнее и уже успешно используется в production. А как у вас с этим дела?
На одном проекте мы запускали WebApi через Owin. Там есть возможность обогатить контекст логера любыми данными, в данном случае это был просто Guid. Эти данные автоматом прицепляются ко всем сообщениям логгера (обращение к других API в рамках исходного запроса), как только исходный запрос завершается — контекст логера уничтожается.
Про Zabbix: мы создаем периодическую проверку — последовательно выполнять определенные цепочки запросов, это имитирует какой-то из бизнес-процессов. Замеряем успешность и время выполнения. Сбои на каком-то из этапов служат поводом для оповещения специалистов поддержки.
Мы серьёзно рассматривали Seq, но в итоге отказались от него. У нас уже построена инфраструктура, и инженерам техподдержки удобнее работать с этим инструментом (ELK). Держать два инструмента с дублирующимся функциями кажется бессмысленным. И всё перетачивать не Seq не видим смысла. Гораздо удобнее, когда и на Java, и на .NET-проектах используется один и тот же стек ELK.
По регламенту нашего клиента логи в ELK хранятся 2 недели, а мы хотим накапливать данные для анализа за более длительный срок, чтобы иметь возможность, например, сравнивать общую статистику с прошлым годом.
Спасибо. В тексте была неточность. Внесли исправления в статью: перенести данные дорого — вся система завязана на MSSQL. Использовать сторонние сервисы не получится по соображениям информационной безопасности.
Спасибо за конструктивный комментарий. Это отличный метод и мы обязательно его используем, когда будем писать новый проект, и у нас встанет схожая задача. Проблема использовать его сейчас заключается в том, что система уже готова и давно работает. Чтобы на данном этапе сделать это так, как вы описали, нужно перепроектировать архитектуру. К тому же, на данный момент всё решение уже функционирует несколько лет, и там накопилось большое количество информации. Писать своё решение для индексирования её в Elastic при наличии готового тоже как-то не комильфо.
Поскольку Kubernetes для Windows — все еще сомнительная перспектива, мы нацелены на использование Linux.
Ваша новость одновременно и печалит, и радует ;)
Как вы правильно заметили в другом комментарии, заказчик диктует условия, Kerberos не подключен.
Переключалка не выглядит правильным способом решения проблемы. Скорее всего, HttpClient в связке с CurlHandler должен при неудачном Negotiate-запросе пробовать следующий вариант. Скоро закинем вопрос на github.
Проблема в том, что окружение на test/stage/production серверах может сильно отличаться, что ведет к непредсказуемым ошибкам. С контейнерами можно быть уверенным, что если это работает локально, то также будет и на продакшене.
А вообще Хансельман написал отдельную статью, отвечающую на этот вопрос.
В проекте используется минимальное количество функционала IIS, поэтому по поводу расставания с ним у нас не возникло сомнений. При появлении необходимости будем брать фронтенд-сервер в соответствии с условиями. Какую то часть на себя возьмет Kubernetes (например, балансировщик).
По поводу AD — аутентификация происходит во внешнем для нашего решения сервисе, настройкой аутентификации в данном проекте не занимаемся.
Контейнеров будет несколько — основной мобильный сервис, сервис push уведомлений, сервис управлениями баннерами. Как раз про контейнеры подробно напишем в следующих статьях.
Спасибо! Применительно к .NET ELK мы используем как условную аббревиатуру, Logstash там действительно нет.
Спасибо за комментарий. Да, мы собираемся переходить на kubernetes.
Спасибо, проверим.
Всем угодил. NLog умеет в .NET Core 2, пока что живем с ним. Но, судя по опыту других наших проектов, интеграция Serilog с ELK происходит прозрачнее и уже успешно используется в production. А как у вас с этим дела?
Ждите продолжение, там обязательно расскажем.
На одном проекте мы запускали WebApi через Owin. Там есть возможность обогатить контекст логера любыми данными, в данном случае это был просто Guid. Эти данные автоматом прицепляются ко всем сообщениям логгера (обращение к других API в рамках исходного запроса), как только исходный запрос завершается — контекст логера уничтожается.
Про Zabbix: мы создаем периодическую проверку — последовательно выполнять определенные цепочки запросов, это имитирует какой-то из бизнес-процессов. Замеряем успешность и время выполнения. Сбои на каком-то из этапов служат поводом для оповещения специалистов поддержки.
Мы серьёзно рассматривали Seq, но в итоге отказались от него. У нас уже построена инфраструктура, и инженерам техподдержки удобнее работать с этим инструментом (ELK). Держать два инструмента с дублирующимся функциями кажется бессмысленным. И всё перетачивать не Seq не видим смысла. Гораздо удобнее, когда и на Java, и на .NET-проектах используется один и тот же стек ELK.
Спасибо за наводку! Слышали про подобные вещи, но сами не встречали. Будем мониторить и исследовать.
По регламенту нашего клиента логи в ELK хранятся 2 недели, а мы хотим накапливать данные для анализа за более длительный срок, чтобы иметь возможность, например, сравнивать общую статистику с прошлым годом.
ELK расшифровывается как Elasticsearch, Logstash и Kibana.
Используем Excel, который в составе пакета MS Office 2016.
Спасибо. В тексте была неточность. Внесли исправления в статью: перенести данные дорого — вся система завязана на MSSQL. Использовать сторонние сервисы не получится по соображениям информационной безопасности.
Спасибо за конструктивный комментарий. Это отличный метод и мы обязательно его используем, когда будем писать новый проект, и у нас встанет схожая задача. Проблема использовать его сейчас заключается в том, что система уже готова и давно работает. Чтобы на данном этапе сделать это так, как вы описали, нужно перепроектировать архитектуру. К тому же, на данный момент всё решение уже функционирует несколько лет, и там накопилось большое количество информации. Писать своё решение для индексирования её в Elastic при наличии готового тоже как-то не комильфо.
Здесь был дубль ответа :)