Сервер
API Vordel позволяет вам устанавливать данные, которые будут регистрироваться в его различных местах назначения журналов: файлы журналов, базы данных, системный журнал и т. Д. Очень часто полезно регистрировать данные в определенном формате для таких инструментов обработки журналов, как Splunk, для обработки. Вот как это сделать:
В разделе «Настройки» конфигурации API-сервера в Policy Studio есть вкладка «Журнал аудита». На скриншоте ниже я устанавливаю формат того, что помещается в текстовые журналы. Вы можете видеть, что я выбрал это, чтобы быть:
${timestamp},${id},'${text}'
Так что же означает «$ {timestamp}, $ {id}, ‘$ {text}’»? Это означает, что я записываю метку времени, идентификатор сообщения (который генерируется автоматически для каждого сообщения) и текст каждого фильтра регистрации. Я решил разделить их запятой. Итак, следующий вопрос: что входит в $ {text}?
Ответ можно увидеть, если вы посмотрите на какой-либо фильтр в политике в Policy Studio и нажмете «Далее». Здесь вы настраиваете то, что регистрируется. Записывается то, что входит в это значение $ {text}. В приведенном ниже примере у меня есть фильтр, который регистрирует следующее при условии «Успех»:
${authentication.subject.id} accessed the API
Если вы выполняете аутентификацию в своей политике, то значение $ {authentication.subject.id} автоматически заполняется идентифицированным идентификатором клиента. Обратите внимание, что я переопределяю настройки ведения журнала по умолчанию (где регистрируется только случай «Отказ»). Я хочу, чтобы информация по делу «Успех» зашла в журнал. Это то, что я хочу перейти к $ {text} части $ {timestamp}, $ {id}, ‘$ {text}’
Файлы журнала для сервера API v7 записываются в каталог \ groups \ group-n \ instance-m \ logs \ audit, где n и m относятся к группе, в которой находится сервер API, и к самому серверу API.
Итак, теперь, когда я смотрю на записываемый файл журнала, я вижу это:
# ProductName=apiserver1 7.0.0-2012-07-07 (Windows) # CurrentDate=Tue, 11 Sep 2012 17:58:16 -0500 # CurrentDateUTC=1347400696 # TZ=Eastern Daylight Time 09.11.2012 22:59:11,884,Id-0599f187504fb42f112c0c5d,'JoeDeveloper accessed the API' 09.11.2012 22:59:11,916,Id-58e1fd41504fb42f06110000,'JaneDeveloper accessed the API' 09.11.2012 22:59:12,070,Id-ab634e7c504fb430152c0c5d,'JoeDeveloper accessed the API'
Для такого инструмента, как Splunk, это просто.
Пока мы смотрим на настройки ведения журнала, давайте посмотрим на ведение журнала базы данных. На скриншоте ниже видно, что я захожу в базу данных:
Тот же контент,
$ {authentication.subject.id}, который получил доступ к API, заносится в базу данных. Это можно найти в Аналитике API-сервера в журнале аудита. На скриншоте ниже вы можете увидеть вид Audit Trail, показывающий записи. Это та же информация, что записана в текстовом журнале. На самом деле, если я тоже выберу запись в Syslog (скажем), то там тоже будет написана та же информация.
Нажав на любую из этих записей, я вижу идентификатор сообщения и фильтр, который записал этот текст журнала. Если многие фильтры в моей политике записывают данные журнала для одного и того же сообщения, то здесь я вижу путь через политику, фильтр по фильтру.
I can also search the Audit Log here. Let’s say I am only interested in the API accesses by «Joe Developer». Here in the screenshot below I construct a search looking for lines which contain «Joe»:
So in summary, there is great flexibility in the Vordel API Server for both the format (e.g. comma-separated) and content (e.g. insert Client IDs) of logged data.