Statistics/Alarm Reporter - система сбора статистики и генерации тревог
Когда на сервере запускается задача Report, она проверяет в базе Statistics & Events наличие документа Server To Monitor и далее использует в своей работе информацию из этого документа. Первоначально документ Server To Monitor создается при первом запуске задачи Event - посредством копирования документа Server из общей адресной книги с добавлением в него некоторых полей со значениями по умолчанию. Впоследствии администратор может модифицировать этот документ или создать вместо него новый.
Рис. 11.1 Пример документа Server To Monitor
В документе задается интервал сбора статистики - поле с меткой Collection interval... - по умолчанию 60 минут, но может варьироваться от 15 до 1440 минут. Кроме того, задается интервал, с которым по документам, содержащим "разовую статистику", создается сводный отчет - поле с меткой Analysis interval:. Поле с меткой Server name: содержит имя сервера, с которого задача Report "снимает статистику". Поле с меткой Report method: определяет способ, которым задача Report должна доставлять статистику в базу сбора (обычно STATREP.NSF). Возможны два варианта:
· Log to Database - протоколирование в базу - задача записывает документ, содержащий статистику, непосредственно в базу сбора;
· Mail-In Database - задача отправляет документ почтой Notes по адресу почтовой базы сбора статистики.
В случае Log to Database, если база сбора статистики находится на сервере получения статистики, в поле с меткой Enter server name: следует выбрать Local - тогда задача будет записывать информацию непосредственно в базу, имя файла которой указано в поле с меткой Database to receive reports:. Если же база сбора статистики находится на другом сервере, но в той же поименованной сети Notes, что и сервер получения статистики, следует указать имя этого сервера. В случае разных поименованных сетей такой способ невозможен - приходится отправлять статистику почтой
по адресу, содержащемуся в вычисляемом поле с меткой Mail- in database address to receive reports:.
При первом запуске задачи Report в общей адресной книге создается документ Mail-In Database, "провозглашающий" созданную этой же задачей базу STATREP.NSF как базу, имеющую собственный почтовый адрес и способную принимать почту. Формат адреса: имя_сервера Statistics/имя_организации. Однако, поскольку база сбора первоначально находится на сервере получения статистики, по умолчанию статистика доставляется в нее способом протоколирования в локальную базу.
Обратите внимание, что все серверы домена, с которых собирается статистика, "несут" реплику базы EVENTS4.NSF. В то же время база STATREP.NSF не обязательно должна присутствовать на каждом из серверов домена - обычно она присутствует только на сервере сбора статистики. Если статистика должна собираться для группы серверов, включая данный, в базе сбора, расположенной на другом сервере, администратору следует удалить STATREP.NSF на данном сервере. Далее, следует оставить в адресной книге только те документы Mail-In Database, которые относятся к серверам, находящимся в разных поименованных сетях с сервером сбора статистики, согласовав в них местонахождение базы сбора статистики. Позвольте напомнить, что понятие "поименованная сеть" определено в пределах одного домена, и, следовательно, в случае разных доменов приходится использовать доставку почтой. Наконец, нужно обеспечить в документах Server to Monitor или правильный почтовый адрес базы STATREP.NSF, или правильный способ протоколирования в эту базу.
В результате задача Report начинает с заданным интервалом создавать в базе сбора статистики документы формы Statistics Report, содержащие весьма подробную информацию о состоянии сервера на момент сбора статистики. Эти документы представлены в группе видов 1. Statistics Reports... базы STATREP.NSF.
Рис. 11.2 Вид в базе STATREP.NSF, содержащий статистику о работе сервера
Ниже приведен пример одного из таких документов. Обратите внимание, что на самом деле там представлена не вся информация из документа Statistics Report. Как видно из Рис. 11.2, в базе имеется пять видов, в каждом из которых один и тот же документ Statistics Report "отображается" по разной форме, с представлением информации из тех или иных групп полей.
Data file path: f:\notes400\data
Swap file path: Not Applicable
Number of processors: 1
Processor type: Intel Pentium
Server Load Statistics:
Transactions in last minute: 8
Peak transactions per minute: 1 413
Time of last peak transactions per minute: 30.01.97 11:37:13
Total transactions processed: 15 118
Number of current users: 12
Peak number of users: 13
Time of last peak number of users: 30.01.97 13:22:26
Number of sessions dropped in mid-transaction: 0
Number of server tasks: 19
Server Tasks:
Database Server: Perform console commands
Database Server: Listen for connect requests on TCPIP
Database Server: Listen for connect requests on LAN4
Database Server: NetBIOS name server for LAN4
Database Server: Cluster Manager is idle
Database Server: Perform housekeeping chores
Database Server: Idle task
Database Server: Server for Andre A. Linev/InterTrustCorp/SU on LAN4
Database Server: Server for InterTrust/InterTrustCorp/SU on TCPIP
Database Server: Server for Vladimir A. Panov/InterTrustCorp/SU on TCPIP
Database Server: Server for Oleg G. Taranchenko/InterTrustCorp/SU on LAN
Database Server: Server for session B87000E on TCPIP
Database Server: Server for Nikolay N. Iontsev/InterTrustCorp/SU on TCPI
Database Server: Server for Oleg G. Taranchenko/InterTrustCorp/SU on LAN
Database Server: Server for InterTrust/InterTrustCorp/SU on TCPIP
Database Server: Server for Vladimir A. Panov/InterTrustCorp/SU on LAN4
Database Server: Server for NotesSrv400/InterTrustCorp/SU on TCPIP
Database Server: Server for Pavel A. Puchkov/InterTrustCorp/SU on LAN4
Database Server: Server for Alexander M. Savelyev/InterTrustCorp/SU on T
HTTP Web Server: Ready
Indexer: Updating views in mail\ALinev.nsf
SMTPMTA oseshlr0: Idle
WEB Retriever: Process(3): Idle
WEB Retriever: Process(2): Idle
SMTPMTA iseshlr0: Idle
SMTPMTA drt: Idle
SMTPMTA isesctl: Listening on SMTP port 25
SMTPMTA imsgcnv: Idle
SMTPMTA osesctl: Idle
Cluster Replicator: Idle
SMTPMTA omsgcnv: Idle
Event: Idle
Cluster Directory: Idle
Query/Set Handler: Idle
Reflector Agent: Idle
SMTPMTA: Idle
Cluster Directory: Idle
Cluster Replicator: Idle
WEB Retriever: Process(1): Idle
Reporter: Idle
Calendar Connector: Idle
Schedule Manager: Idle
Admin Process: Idle
Agent Manager: Executive '1': Idle
Agent Manager: Idle
Indexer: Updating cldbdir.nsf view '($Pathname)'
Router: Idle
Replicator: Idle
Replicator: Idle
Event Interceptor: Idle
Replication Statistics:
Number of successful replications: 278
Number of replication failures: 133
Number of documents deleted: 357
Number of documents added: 1 065
Number of documents updated: 870
Database Statistics (in bytes):
Buffer control pool used: 91 204
Buffer control pool peak size: 196 218
Buffer pool maximum: 6 291 456
Buffer pool used: 6 264 804
Buffer pool peak: 6 336 000
Extension manager pool used:
Extension manager pool peak:
NSF pool used: 176 468
NSF pool Peak: 327 030
Stats Package Statistics:
Time started: 30.01.97 09:36:37
Agent Statistics:
Hourly agent scheduled runs: 0
Hourly agent triggered runs: 1
Hourly agent unsuccessful runs:
Hourly agent used run time: 13 Seconds
Hourly agent access denials: 0
Daily agent scheduled runs:
Daily agent triggered runs:
Daily agent unsuccessful runs:
Daily agent used run time:
Daily agent access denials:
Хотя в базе STATREP.NSF имеются и другие виды, в том числе "пытающиеся" представить все получаемое "море" информации в псевдографическом виде, всю информацию проанализировать трудно, да и это попросту ненужно.
Вы можете предварительно описать только ситуации, которые действительно достойны вашего внимания - "ситуации, вызывающие тревогу". Для этого в базе Statistics & Events создаются документы Statistic Monitor.
Рис. 11.3 Пример документа Statistics Monitor для контроля свободного пространства на диске
В документе Statistic Monitor содержится следующее.
· Enabled/Disabled:
-
задаче Report разрешено/запрещено "интерпретировать" этот документ.
· Server name:
- имя сервера или список имен серверов, на которые распространяется действие документа.
· Statistic name: - название параметра, значение которого рассматривается при решении вопроса о возникновении тревоги. Эти названия выбираются из списка ключевых слов, который строится по формуле @DbColumn(""; ""; "($Statistics)"; 1) из скрытого вида ($Statistics). Для понимания смысла параметров лучше просмотреть виды 5. Names & Messages\Thresholds и 5. Names & Messages\Statistics Names и, для заинтересовавших вас параметров, соответствующие документы из этих видов.
· Threshold operator: - операция, выполняемая при проверке значения параметра - Less that - меньше чем, Greater that - больше чем, Multiple of - кратно.
· Threshold value: - значение, с которым сравнивается значение параметра.
· Event severity:
- степень серьезности события типа Statistics, возникающего при выполнении условия.
· Comments:
и Description: комментарии и описание - вычисляемые поля. Они пересчитываются по нажатию клавиши F9 или при сохранении документа.
Рис. 11.4 Пример документа Statistics Monitor для контроля наличия "мертвой" почты
Рис. 11.5 В виде представлены все ситуации, "вызывающие тревогу"
Например, согласно документу Statistic Monitor на Рис. 11.3 ситуация, "вызывающая тревогу", возникает, если на диске F
заданного сервера стало меньше 40 Мб свободного пространства. Согласно документу на Рис. 11.4 ситуация, "вызывающая тревогу", возникает, когда на одном из серверов в базе MAIL.BOX появилась "мертвая" почта.
Все, что вы определили, как ситуации, "вызывающие тревогу", будет представлено в виде 3. Statistic\Monitors базы Statistics & Events (Рис. 11.5).
В соответствии с выполненными настройками задача Report при обнаружении "тревожных ситуаций" будет генерировать события типа Statistics заданной степени серьезности. Эти события будут поступать в стандартную очередь событий сервера. Что происходит далее? Задача Event анализирует стандартную очередь событий, отбирает те из них, на которые "ей предписано реагировать", и соответствующим образом протоколирует их. События типа Statistics
обычно протоколируются в базу сбора статистики. В итоге в виде Alarms
базы STATREP.NSF (Рис. 11.6) при возникновении "тревожных ситуаций" станут появляться документы
Alarm (Рис. 11.7).
Рис. 11.6 Вид Alarms содержит документы, описывающие события, "вызвавшие тревогу"
Рис. 11.7 Пример документа Alarm - в MAIL.BOX появилась "мертвая" почта
В результате количество информации, которое вам действительно необходимо просмотреть в базе STATREP.NSF, существенно сократится.
Кроме того, открыв документ Alarm, вы можете кнопкой Create Trouble Ticket создать связанный с ним новый документ - Alarm Trouble Ticket - "карточку аварийной ситуации". По смыслу документ Alarm Trouble Ticket является заданием администратору сервера, на котором возникла неисправность, на ее устранение. Документ Trouble Ticket может быть как сохранен в базе STATREP.NSF, так и направлен письмом (кнопкой Mail Trouble Ticket) тому администратору, которому надлежит устранить возникшую неисправность. Сохраненные документы Trouble Ticket содержатся в базе STATREP.NSF в виде 6. Trouble Tickets\1. Alarm.
Рис. 11.8 Пример "карточки аварийной ситуации"
