Ведение журнала клиента выводит NoDB с помощью WebService
У меня есть приложение WPF, которое работает в интрасети, и все коммуникации с БД осуществляются через веб-сервисы REST. Поскольку для целей аудита мне нужно хранить действия пользователей (журналы от информации до журналов фатальных событий) в экземпляре NoDb (Seq или RavenDB). Я видел эту ветку и, кажется, выполняет часть работы. Как я могу отправить эту информацию в Seq /RavenDB? они выставляют API?
Другой вопрос - о надежности. Как, по вашему мнению, лучше всего использовать избыточный / сбалансированный веб-сервис аудита? Лучше иметь конфигурацию, которая не требует слишком больших усилий
Спасибо
1 ответ
1) Если вам нужно использовать веб-сервисы, ваш веб-сервис может публиковать события в Seq через HTTP/S - документы API находятся по адресу: http://docs.getseq.net/docs/posting-raw-events (пакетные события очень рекомендуется в этом сценарии).
2) Если вы можете избежать буквального толкования "веб-службы" и вместо этого просто установить другую конечную точку HTTP на сервере, который предоставляет веб-службы, вы можете установить Seq для прослушивания префикса URL-адреса, например, https://my-server/seq, который позволяет другим сервисам прослушивать другие конечные точки, такие как https://my-server/... Документация по настройке находится здесь: http://docs.getseq.net/docs/storage-paths-and-urls
3) Опять же, в случае с Seq, если вы отправляете события через Serilog, вы можете настроить два сервера Seq и войти на оба из них:
.WriteTo.Seq("https://primary-seq")
.WriteTo.Seq("https://backup-seq")
В этом случае весь ваш поиск в журнале и т. Д. Должен будет выполняться на первичном экземпляре, поскольку данные конфигурации (разрешения и т. Д.) Не будут реплицироваться между ними.
Вы также можете рассмотреть возможность использования bufferBaseFilename для одного или обоих подключений, которые будут локально буферизовывать события в файл, так что допускается некоторое время простоя сервера.
Однако, если ваши требования к аудиту являются транзакционными (т. Е. Юридическими / нормативными), вам, вероятно, все же следует рассмотреть возможность записи этих внутренних транзакций в вашу базу данных SQL, если она у вас есть.