У меня Home версия с WLS, пришлось отключать hyper-v в итоге, т.к. без этого vb не работал. Вообще я не исключаю, что возможно где-то перемудрил, но всё же цель была заставить это работать. Если можно сделать проще, то я бы с удовольствием почитал, т.к. развернуть k8s по моему опыту — это основной геморрой когда начинаешь его изучать.
На первый взгляд похоже на пайплайны, которые есть, например, в том же GitLab. Только вот я не очень себе представляю, что может побудить разработчиков перенести сборку и выкладку из уже существующего инструмента, который встроен в тот же GitLab, куда-то в отдельное место.
Если не секрет, как transactional outbox реализуете чуть более подробно? Я так понял, что сразу после коммита достаёте сообщение и пересылаете в очередь, но что происходит если какие-то сообщения не были отправлены? Доотправляете фоном? Как в этом случае несколько экземпляров приложения синхронизируются между собой, чтобы не обрабатывать одни и те же сообщения несколько раз и при этом сохранять порядок отправки сообщений?
Например, если вы собрали контейнер с каким-нибудь сервисом, а потом вам нужно этот контейнер запустить для тестов и подсунуть ему в качестве строки подключения фейковую БД для тестов, которую вы тут же рядом подняли в соседнем контейнере. Через переменные окружения это можно легко переопределить. У нас в связке с gitlab это многие используют.
Опять же передавать всякие секреты в различных окружениях тоже можно.
Каждый обсервер — синглтон, он создаётся один раз на старте приложения, подписывается на DiagnosticListerer.AllListeners, получает и обрабатывает все события.
AsyncLocal<T> это просто класс, который умеет хранить состояние в асинхронном коде (в логическом потоке выполнения, который реально может обрабатываться разными потоками).
Если в начале обработки http запроса установить значение в AsyncLocal, то его можно прочитать где угодно из этого же экземпляра до окончания http запроса. Для разных (параллельно выполняющихся) http запросов это значение будет своё.
github.com/stevejgordon/CorrelationId никак не связан с DiagnosticSource. Я просто привёл альтернативную реализацию этого механизма (CorrelationId) через DiagnosticSource.
Ну вот как раз эту задачу вы можете решить через DiagnosticSource. Нужно сделать наблюдатель, который на входящем http запросе будет проверять необходимость логирования через httpcontext. А на остальных событиях от SqlClient и HttpClinet нужно проверять этот признак и делать логирование. Если я правильно понял.
Для EF с событиями от DiagnosticSource приходит только время выполнения. И я не уверен, что он знает что-нибудь про объем пересылаемых данных.
Вообще, я бы не очень доверял свойству Statistics, у нас с ним были проблемы, что время выполнения там неправильно указывается, и пришлось мерить через Stopwatch.
SqlClient само собой публикует события только с теми параметрами, которые у него есть. Но в обработчике мы можем получить доступ куда угодно, хоть к CorrelationId, хоть к IHttpContextAccessor (через конструктор заинжектить) и там уже можно придумать любую логику.
Связать события публикуемые в DiagnosticSource порожденные «одним конкретным запросом одного конкретного юзера» — как раз таки это и делается в примере с CorrelationId. Т.е. когда в сервис приходит запрос, он помечается CorrelationId (либо через заголовок, либо генерируется новый). Этот CorrelationId доступен через статическое свойство, его можно получить где угодно и он будет отличаться для разных запросов разных пользователей, но будет одинаковый в рамках одного запроса одного пользователя.
И я не понял про «сопоставления логов» только для «пользовательских сообщений» микросервисов. Что понимается под "только пользовательскими сообщениями". Если поясните на примере, то постараюсь более внятно ответить =)
У SqlCommand есть свойство Statistics, можно попробовать там поискать нужное значение для размера трафика. Вот тут есть описание: Provider Statistics for SQL Server.
Кстати, для ASP.NET Core есть неплохой NuGet пакет Ben.BlockingDetector, который позволяет найти блокировки в асинхронном коде в приложении. Бывает полезно при отладке и поиске проблемных мест.
А как предлагается быть с обработкой ошибок? Ведь одно дело, когда мы полностью сформировали какую-то модель, отдали её представлению, и оно её показало. Но в примере выше, например:
<h1>@ArticleService.Get(Model).Name</h1>
Мы отрендерили h1, вызвали ArticleService.Get, получили exception. Клиенту ушёл битый html.
Скажите, какую версию VS вы использовали? Как раз вчера хотел посмотреть эти анализаторы, но не нашёл там таких проектов. Версия VS Community 2015 RC. SDK тоже вроде бы поставил.
Выглядит очень похожим на Flyway
Опять же передавать всякие секреты в различных окружениях тоже можно.
Их нельзя регать на реквест, т.к. каждый обсервер обрабатывает все события по всем реквестам.
Каждый обсервер — синглтон, он создаётся один раз на старте приложения, подписывается на
DiagnosticListerer.AllListeners, получает и обрабатывает все события.AsyncLocal<T>это просто класс, который умеет хранить состояние в асинхронном коде (в логическом потоке выполнения, который реально может обрабатываться разными потоками).Если в начале обработки http запроса установить значение в AsyncLocal, то его можно прочитать где угодно из этого же экземпляра до окончания http запроса. Для разных (параллельно выполняющихся) http запросов это значение будет своё.
Ну вот как раз эту задачу вы можете решить через DiagnosticSource. Нужно сделать наблюдатель, который на входящем http запросе будет проверять необходимость логирования через httpcontext. А на остальных событиях от SqlClient и HttpClinet нужно проверять этот признак и делать логирование. Если я правильно понял.
Вообще, я бы не очень доверял свойству Statistics, у нас с ним были проблемы, что время выполнения там неправильно указывается, и пришлось мерить через Stopwatch.
SqlClient само собой публикует события только с теми параметрами, которые у него есть. Но в обработчике мы можем получить доступ куда угодно, хоть к CorrelationId, хоть к IHttpContextAccessor (через конструктор заинжектить) и там уже можно придумать любую логику.
Зависит от задачи, которую вы хотели бы решить.
Возможно я не совсем правильно понял ваш вопрос.
Связать события публикуемые в DiagnosticSource порожденные «одним конкретным запросом одного конкретного юзера» — как раз таки это и делается в примере с CorrelationId. Т.е. когда в сервис приходит запрос, он помечается CorrelationId (либо через заголовок, либо генерируется новый). Этот CorrelationId доступен через статическое свойство, его можно получить где угодно и он будет отличаться для разных запросов разных пользователей, но будет одинаковый в рамках одного запроса одного пользователя.
И я не понял про «сопоставления логов» только для «пользовательских сообщений» микросервисов. Что понимается под "только пользовательскими сообщениями". Если поясните на примере, то постараюсь более внятно ответить =)
Список событий я привёл во второй части.
У SqlCommand есть свойство Statistics, можно попробовать там поискать нужное значение для размера трафика. Вот тут есть описание: Provider Statistics for SQL Server.
Мы отрендерили h1, вызвали ArticleService.Get, получили exception. Клиенту ушёл битый html.
Книга действительно очень хорошая.
После этого проект начинает открываться и в списке проекты тоже появляются.
Взято отсюда: joshvarty.wordpress.com/2015/04/30/learn-roslyn-now-part-10-introduction-to-analyzers