Сообщений в теме: 17

[Case]

Мониторинг и повышение эффективности информационных систем: подход Embarcadero
Владимир Дудченко, 11/05/2005

Проблемы повышения эффективности ИТ при экстенсивном пути наращивания информационных ресурсов известны сегодня уже очень многим руководителям ИТ структур. Стоимость серверных платформ, СУБД и прочих инфраструктурных компонент по-прежнему высока, однако результаты больших вложений в наращивание их мощности не всегда соответствуют ожиданиям — производительность, надежность, время реакции на запросы пользователей, устойчивость в условиях пиковых нагрузок зачастую не достигают значений, диктуемых требованиями бизнеса, и не оправдывают сделанных инвестиций.

Читать полностью: http://software-test.../monitoring.htm

[Dmitry_NJ]

Хоть статья и заявлена как "мониторинг и повышение эффективности информационных систем", но по сути все свелось к "задаче мониторинга и администрирования баз данных, лежащих в основе информационных систем и являющихся их наиболее критическими элементами".

Во-первых, позволю себе не согласиться с тем, что БД в современных информационных системах это "наиболее критический элемент". Давно уже прошли времена классических двухзвенок, оставив на back-end части минимальную логику, поэтому большинство БД сейчас это главным образом data storage и не более того. Элемент безусловно важный, но уж никак не более критический, чем скажем application server.

Во-вторых, в очередной раз предлагается подход к мониторингу информационных систем как мониторинг какой-то одной составляющей таких систем (в данном случае БД). В итоге применения подобных подходов очень часто можно наблюдать классическую silo situation. Когда каждый кулик (DB/app.server/web server/network admins etc.) прекрасно знает, что происходит на его болоте, но никто не может понять а почему конечные пользователи жалуются на работу системы.

Как же "руководители ИТ структур" могут судить об эффективности информационной системы, не зная как она функционирует с точки зрения конечных пользователей? Доступны ли для пользователей критические бизнес-процессы системы? Какова производительность их работы? В случае возникновения проблем как узнать в чем же была причина? Можем ли мы мониторить всю нашу инфраструктуру - switches, routers, firewalls, network, app.servers, web servers, load balancers etc., а не только БД? Можем ли мы представить всю эту информацию обо всех компонентах инфраструктуры в едином dashboard, не используя кучу разных графиков из разных тулов для разных компонент? Можем ли мы скоррелировать проблемы, испытываемые конечными пользователями (а значит и проблемы нашего бизнеса), с тем что происходит во всей нашей инфраструктуре, т.е. выполнить элементарный root-cause analysis и в максимально короткие сроки устранить проблему?

Ни на один из этих вопросов, которые являются важными для мониторинга именно "систем", а не отдельных ее компонент, ответа в данной статье я не нашел. Просто предлагается еще один (возможно даже и хороший) тул для узких спецов, отвечающих за эксплуатацию баз данных.

[Spy]

Можем ли мы мониторить всю нашу инфраструктуру - switches, routers, firewalls, network, app.servers, web servers, load balancers etc., а не только БД?

Мы у себя используем ряд продуктов от компании Computer Associates центральным из которых является Unicenter NSM 3.11.
Софт позволяет мониторить множество универсальных параметров гетерогеннных сред (со множеством различного сетевого оборудования, большого парка версий ОС и т.д.).
Основные конкуренты этого продукта IBM Tivoli, HP OpenView.

Однако наш опыт показывает, что всё равно хороший мониторинг организовать сложно. Универсальных метрик явно недостаточно. Необходима интеграция функций мониторинга в прикладное ПО, используемое в АС.
Более того заказчики (как обычно) не знают, что нужно мониторить на их ресурсах. А когда АС повисит час-два - так сразу виновата система мониторинга -- почему не усмотрела?
А почему нас не предупредили, что так нельзя ? ;)

[Spy]

Судя по сайту компании, в которой работает автор статьи (http://www.softbcom.ru/) они продают эту софтинку, по картинкам из статьи видно, что глубже рекламной макулатуры автор не рыл.

[Dmitry_NJ]

Мы у себя используем ряд продуктов от компании Computer Associates центральным из которых является Unicenter NSM 3.11...Основные конкуренты этого продукта IBM Tivoli, HP OpenView.

Вы забыли про BMC Patrol и Mercury Business Availability Center (a.k.a. Topaz & SiteScope).

Более того заказчики (как обычно) не знают, что нужно мониторить на их ресурсах. А когда АС повисит час-два - так сразу виновата система мониторинга -- почему не усмотрела?

Потому что недостаточно мониторить инфраструктуру. Надо еще мониторить сами приложения - доступность и производительность выполнения критических бизнес-процессов. Причем не со стороны серверов, а с точки зрения конечных пользователей. И мониторить надо proactive, чтобы знать о проблемах заранее, а не тогда, когда пользователи начинают жаловаться.

[Spy]

Вы забыли про BMC Patrol и Mercury Business Availability Center (a.k.a. Topaz & SiteScope).

У нас в Беларуси нет их дилеров, а следовательно и поддержки, а звать специалистов с забугра накладно, а ещё нам нужна интеграция с IBM mainframe на базе OS/390, так что выбор уменьшается...

Потому что недостаточно мониторить инфраструктуру. Надо еще мониторить сами приложения - доступность и производительность выполнения критических бизнес-процессов.

Звучит хорошо, но как мониторить сами приложения, если это не было заложено в их ТЗ? Повторюсь у Unicenter тоже есть куча универсальных метрих для ОСов (её ресурсы), функционального ПО (IBM MQSeries, IBM DB2, MS SQL Server и т.д.), но наше прикладное ПО охвачено им еле-еле (наличие запущенных процессов, их число), а надо бы, чтобы наше прикладное ПО (а желательно и системное) фиксировала свои проблемы в такой софтине как Unicenter - вот тогда и будет централизованный мониторинг, попытки анализировать журналы ОС и приложений - дают максимальный эффект, но не все проблемы фиксируются в этих журналах. Вот, например, ОС/390 почти все свои проблемы через свой журнал ведёт - её относительно легко мониторить, но фишка в том, что её не надо мониторить - с мэйнфреймом проблем нет. А вот IBM Communication Center, IBM MQSeries ведут кривые логи, а в системный журнал ОС Windows вообще фигню пишут, так что когда они лягут никто не в курсе из-за чего это произошло. Зато прикладной программист, когда работает через API с тем же MQSeries точно знает какой код ошибки он получил, но не сознается, а просто сделает "return (-1)" - и что здесь мониторить?

А ещё беда - не согласованность персонала, у нас над одной АС работают 5 юридических лиц, так что если одно ковырнёт, четыре остальных узнают только через час.
Итог: систему мониторинга нужно было закладывать в ТЗ при разработке АС, а не присобачивать её, когда уже всё на ходу, а если присобачивать, так через API, а не путём покупки универсальных ПО.
Наиболее эффективные средства мониторинга у нас - те что мы сами писали, используя бизнес-представления Unicenter за базу.

Причем не со стороны серверов, а с точки зрения конечных пользователей. И мониторить надо proactive, чтобы знать о проблемах заранее, а не тогда, когда пользователи начинают жаловаться.

Легко сказать... У конечных пользователей точки зрения очень не чёткие, proactive у нас по сути мониториться только производительность сети, ОС, доступность системных ресурсов (где можем), но с производительностью траблов мало - машины мощные, сеть не загружена, число клиентов АС не велико: ресурсов до фига, а вот ошибки ПО мониторятся только по факту.

Или может у ваших решений есть "серебрянная пуля" для этих случаев, мы бы рассмотрели, конечно, но шото мне слабо верится...

[Dmitry_NJ]

Вы забыли про BMC Patrol и Mercury Business Availability Center (a.k.a. Topaz & SiteScope).

У нас в Беларуси нет их дилеров, а следовательно и поддержки, а звать специалистов с забугра накладно, а ещё нам нужна интеграция с IBM mainframe на базе OS/390, так что выбор уменьшается...

При упомянании основных конкурентов вы не указывали, что это конкуренты именно в Белоруссии. Как вы понимаете, я понятия не имею о белорусской специфике рынка подобных систем. А если брать worldwide, то BMC и Mercury вполне успешно конкурируют с CA, HP и IBM.

Причем не со стороны серверов, а с точки зрения конечных пользователей. И мониторить надо proactive, чтобы знать о проблемах заранее, а не тогда, когда пользователи начинают жаловаться.

Легко сказать... У конечных пользователей точки зрения очень не чёткие, proactive у нас по сути мониториться только производительность сети, ОС, доступность системных ресурсов (где можем), но с производительностью траблов мало - машины мощные, сеть не загружена, число клиентов АС не велико: ресурсов до фига, а вот ошибки ПО мониторятся только по факту

Вы не поняли что я имел в виду под мониторингом с точки зрения конечного пользователя. И для этого абсолютно не надо что-то заранее закладывать в ТЗ, мониторить логи, журналы и пр. То есть это, конечно, все нужно мониторить безусловно, но это все инфраструктура. Это не end-user experience.

Конечный пользователь работает с приложением. Он в общем случае знать ничего не знает ни о каких MQSeries, серверах приложений, базах данных и пр. С его точки зрения система работает если он может выполнять какие-то свои процессы в ней. И не просто выполнять, а выполнять за приемлемое время. Вот это и надо мониторить. Иными словами, выбираются критические бизнес-процессы в приложении, ну например, ввод заказа, генерация каких-то отчетов и пр. (все равно что, зависит от того, что для пользователя является критичным). Ставится своего рода виртуальный пользователь (желательно как можно ближе к реальным пользователям с точки зрения топологии сети), и этот виртуальный пользователь без перерыва на обед, без отпуска и выходных в режиме 24х7 (например, каждые 15 минут) начинает выполнять эти самые бизнес-процессы, замеряя время их выполнения. И такой мониторинг будет proactive, потому что вы постоянно будете в курсе того как себя чувствует система именно с точки зрения конечного пользователя. Даже, например, ночью, когда никто из реальных пользователей с системой не работает, вы все равно ее мониторите и если возникают проблемы, то вы узнаете об этом заранее и у вас будет время их устранить до того, как вернутся к работе пользователи реальные.

Поскольку параллельно вы мониторите еще и инфраструктуру, то у вас получается полная картина того, что происходит с системой, и проблемы у пользователя всегда могут быть скоррелированы с проблемами в инфраструктуре для того, чтобы в кратчайшие сроки их устранить.

[Spy]

[quote name='Dmitry_NJ' date='May 13 2005, 08:16 PM']
При упомянании основных конкурентов вы не указывали, что это конкуренты именно в Белоруссии.[quote]
Согласен, обзор был несколько предвзятым с моей строны.

[quote name='Dmitry_NJ' date='May 13 2005, 08:16 PM']
Вы не поняли что я имел в виду под мониторингом с точки зрения конечного пользователя. И для этого абсолютно не надо что-то заранее закладывать в ТЗ, мониторить логи, журналы и пр.[/quote]
Теперь более понятно. Однако интересно как это организуется и насколько это переносимо. Приложения у нас представляют собой GUI под Windows, службы NetWare, Windows, задания на ОС/390, трудно представить себе как технически можно организовать такой мониторинг. Ведь нужно не просто вирутальному юзеру нажимать случайные пимпы, а в идеале моделировать настоящего юзера, а юзер действует в соответствии, хоть и не сложной, но всё таки нетривальной логики. А не могли бы вы привести линк, где можно поподробнее почитать про технические подробности такой реализации?

Ну и коль речь зашла о мониторинге, я поинтересуюсь какие решения предлагают BMC и Mercury для мониторинга безопасности в АС есть, что почитать на енту тему?

[Dmitry_NJ]

Теперь более понятно. Однако интересно как это организуется и насколько это переносимо. Приложения у нас представляют собой GUI под Windows, службы NetWare, Windows, задания на ОС/390, трудно представить себе как технически можно организовать такой мониторинг.

С технической точки зрения реализация мониторинга end-user experience (про инфраструктуру тоже не забываем, но это отдельная тема) осуществляется так же, как осуществляется нагрузочное тестирование LoadRunner'ом. Только в этом случае никто не генерирует никакой нагрузки и терминология несколько иная используется (Business Process Monitor (BPM) вместо Load Generator). To есть в принципе вы можете абсолютно теже скрипты, что вы создавали на этапе нагрузочного тестирования в LoadRunner использовать для их запуска с BPM. Это позволяет вам сэкономить массу времени, хотя никто не мешает и новые скрипты написать. Такие скрипты с определенной периодичностью запускаются с разных BPM (эмулируют таким образом работу с вашим приложением пользователей, находящихся в разных географически разделенных точках). Замеряется время выполнения критичных для приложения бизнес-процессов, далее эта информация попадает в единую БД, где всевозможным образом препарируется для отображения ее в различного рода графиках, отчетах, проведения анализа трендов и пр. Ну это уже детали.

Ведь нужно не просто вирутальному юзеру нажимать случайные пимпы, а в идеале моделировать настоящего юзера, а юзер действует в соответствии, хоть и не сложной, но всё таки нетривальной логики.

Если вы можете логику работы пользователя отразить в скрипте, значит вы можете ее эмулировать. Сложность реализуемой логики будет определять сложность создаваемых скриптов. Наверное, можно придумать такую логику, которую реализовать в скрипте будет или невозможно, или трудоемкость этой операции будет неоправданно высокой. Лично я с таким еще не сталкивался, но допускаю, что такое может быть. Для таких случаев надо искать какие-то альтернативные варианты.

А не могли бы вы привести линк, где можно поподробнее почитать про технические подробности такой реализации?

Вот здесь можно посмотреть всякие брошюры и white papers на тему end-user monitoring: http://www.mercury.c...ser-monitoring/ Не знаю, правда, насколько это подробно именно с технической точки зрения. Но с какими-то глубокими техническими вопросами можно ко мне обращаться.

Ну и коль речь зашла о мониторинге, я поинтересуюсь какие решения предлагают BMC и Mercury для мониторинга безопасности в АС есть, что почитать на енту тему?

Мониторинг безопасности это слишком общий термин (по крайней мере для меня - неспециалиста в этой области). Если вы можете детализировать что конкретно и как должно мониториться для этого, я смогу сказать можно или нельзя реализовать это имеющимися у нас средствами. Про BMC ничего не скажу, ибо с их системой не работаю и деталей не знаю.

[Spy]

To есть в принципе вы можете абсолютно теже скрипты, что вы создавали на этапе нагрузочного тестирования в LoadRunner использовать для их запуска с BPM. Это позволяет вам сэкономить массу времени, хотя никто не мешает и новые скрипты написать.

У нас сие продукты не использовались и не используется, так что остаётся только вариант написания скриптов с нуля под готовое ПО, при чём не только под то, что разрабатывалось нами.

Мониторинг безопасности это слишком общий термин...

Согласен, я специально спрашивал так общо. Обычно, если продукт может использоваться как средство мониторинга безопасности - так об этом в каждой брошюре через строчку. Так, например, любое напоминание слова безопасность в присутствии дилера CA сразу приводит к туче эмоций о силе серии продуктов eTrust.

В мониторинге безопасности в нашем случае нас интересует:

- автоматизированное обнаружение неизвестных IP адресов в ЛВС АС;

- иметь возможность определять (получать извещения), какой пользователь в данный момент работает на данной машине (желательно по возможности, как можно больше знать о том, вносит ли он какие-либо серьёзные административные изменения: создание новый пользователей, модификация имеющего ПО, установка нового ПО и т.д.);

- иметь возможность определять, какие пользователи работали на данной машине и в какое время в период с такого-то числа по такое (для анализа проблем функционирования вычислительного узла), также желательно подробнее знать, какие изменения они вносили;

- автоматизированный мониторинг целостности используемого функционального ПО (ФПО), реестров и данных: контроль целостности (путём вычисления hash-сумм или crc-кодов) для критических модулей ФПО (системные dll, модули DB2, MQSeries, собственного ПО и т.д.);

- автоматизированный мониторинг установки нового ПО;

- автоматизированный мониторинг учётных записей машины, обладающих административными полномочиями (удаление, появление новых и т.д.);

- автоматизированный анализ журналов (особенно безопасности) машин и ФПО (IBM DB2, IBM MQSeries, IBM Communication Server);

Под машинами подразумеваются персональные машины под управление ОС Windows 2000 Professional, Server и выше, Novell NetWare и сетевое оборудование Cisco.
Мэйнфрейм у нас мониторится специальной софтиной RACF (часть ОС/390) - так что особо его мониторить нам нет надобности.

[Dmitry_NJ]

Обычно, если продукт может использоваться как средство мониторинга безопасности - так об этом в каждой брошюре через строчку.

Я потому и спросил, что ничего специально заточенного под мониторинг безопасности мы не делаем. Что-то (автоматизированное обнаружение IP адресов, нового софта; мониторинг разнообразных логов) мы делаем. Что-то (вычисление hash-сумм или crc-кодов) точно не делаем. Насчет остального (на какой машине, когда и что именно делал и делает пользователь) ничего конкретного сказать не могу, поскольку не понимаю как этот мониторинг реализуется. Если с помощью каких-то специальных утилит, установленных на машинах и следящих за действиями пользователей, то таких утилит у нас нет. Если все действия пользователя в итоге протоколируются в каких-то лог файлах, БД и пр., то тогда эти действия мы тоже можем мониторить.

DB2, MQSeries, Novell, Windows, Cisco - со всем этим мы работаем.

[Spy]

А про мониторинг учётных записей (добавление, удаление, изменение)?
Ещё хотелось бы узнать насколько это всё автоматизировано...

Например, продукты Советской Армии (СА) мы-таки забраковали:
Мониторинг логов для безопасности у них специальная заточка eTrust Audit, но

1) все уведомления приходят на централизованную административную GUI этой софтины, без звукового сопровождения.
А енто не гут. Потому что у нас мониторингом занимаются операторы - у них прав по минимуму - ставить им администативную GUI - не есть карашо. А админ как раз за софтинами в реал-тайме не сидит, а занимается другими делами. Операторов у нас больше одного и каждому нужна своя софтинка для мониторинга, а у них уведомления централизованы.
Если не ошибаюсь там даже нельзя собственную реакцию настроить на событие, софтина сама фиксирует и обрабатывает сообщение.

В идеале нам, конечно, интеграция с уже имеющимся у нас (посылать туда трапы) Enterprise Event Management (часть NSM 3.11), чего даже у СА нет, а если есть то ущербная... :unsure:

2) отчёты у них в собственном формате, конечно, на ангельской мове.
Т.е. чтобы начальнику, который сидит в другой сети показать этот отчёт - нужно ему ставить енту софтину, т.к. только она понимает этот отчёт. К тому же большие босы ангельский не долюбливают ;), а средств чтобы хотя бы ручками перевести нет - всё зашито в софтину и в формат. Локализовывать свои продукты под руссиш СА явно не собирается.

Мониторинг учётных записей. У СА - eTrust Admin
Трабла в том, что нам нужен только мониторинг - управлением безопасность и учётными записями в нашей АС занимается другое юридическое лицо. А ента софтина по дефолту подразумевает и управление учётными записями, мониторинг из неё без управления не выбьешь.

Мониторинг установки ПО - енто у них делает АМО
Максимум что автоматизировано, когда обнаруживается новое ПО и создаётся для неё запись в базе - софтина может слать уведомления.
А нам надо всякий раз как что-то ставится, удаляется - енто дело фиксировать. И чтобы оно само нас уведомляло, а не лазить через их ГУИ и смотреть что там есть, а чего нет.
Отчёты в АМО не сохраняются даже в собственном формате - тока через ГУИ.

[Dmitry_NJ]

А про мониторинг учётных записей (добавление, удаление, изменение)?
Ещё хотелось бы узнать насколько это всё автоматизировано...

Тоже самое. Если все эти действия где-то протоколируются (лог файлы, БД), то все это мы умеем мониторить. Насчет степени автоматизации я не очень понял вопроса. Понятное дело, что не вручную все это делается. Можно задавать regular expressions, чтобы находить именно ту информацию, которая нужна. И с заданным интервалом, например, 10 минут логи будут сканироваться. Для Windows Event Log у нас специальная поддержка есть (отличная от мониторинга любых других лог файлов).

1) все уведомления приходят на централизованную административную GUI этой софтины, без звукового сопровождения.

Наше решение полностью web-овское, поэтому вопрос инсталляции какого софта на машины операторов просто не стоит. Опять же пялиться на экран тоже необходимости нет, поскольку при возникновении условий, при которых генерируется alert, нотификация всех заинтересованных лиц может настраиваться различными способами. Самый распространенный способ - посылка email с информацией о проблеме. Можно также посылать информацию на pager, на мобильный телефон (в виде SMS). Можно послать SNMP Trap, выполнить какой-нубудь скрипт, записать что-то в БД или Windows Event Log. Вобщем вариантов масса.

В идеале нам, конечно, интеграция с уже имеющимся у нас (посылать туда трапы) Enterprise Event Management (часть NSM 3.11)...

Для наиболее популярных систем (HP OpenView, IBM Tivoli, CA UniCenter, BMC Patrol) у нас есть готовая интеграция. В частности если говорить о CA UniCenter, то мы поддерживаем версии 2.x (a.k.a. TNG - The New Generation) и 3.x (TND - The New Dimension) на уровне получения events из CA UniCenter в наш BAC и посылки events из BAC в CA UniCenter (через SNMP Traps или путем запуска какого-нибудь исполняемого файла). Есть интеграция и на уровне метрик и конфигураций, но там свои нюансы.

2) отчёты у них в собственном формате, конечно, на ангельской мове.
Т.е. чтобы начальнику, который сидит в другой сети показать этот отчёт - нужно ему ставить енту софтину, т.к. только она понимает этот отчёт.

Oтчеты дело тонкое. У нас можно их настраивать до определенной степени. Одним клиентам этого достаточно, другим нет. Опять же никакой софтины специальной не нужно, чтобы начальнику показывать - браузера достаточно. А можно вообще отчеты по email получать по заранее выбранному расписанию. Язык отчетов, естественно, английский.

К тому же большие босы ангельский не долюбливают ;)

Я в курсе. Сам с такими не раз сталкивался, работая в Москве. Как правило, дяденьки не первой молодости из тех времен, когда жили за железным занавесом и кроме русского владеют только русским матерным.

Локализовывать свои продукты под руссиш СА явно не собирается.

Мы тоже. Проблема общая - русскоязычный рынок пока мизерный.

Мониторинг учётных записей. У СА - eTrust Admin. Трабла в том, что нам нужен только мониторинг - управлением безопасность и учётными записями в нашей АС занимается другое юридическое лицо. А ента софтина по дефолту подразумевает и управление учётными записями, мониторинг из неё без управления не выбьешь.

Мы занимаемся только мониторингом. Принципиально. Никакого управления никакими сетевыми ресурсами мы не делаем.

Максимум что автоматизировано, когда обнаруживается новое ПО и создаётся для неё запись в базе - софтина может слать уведомления.
А нам надо всякий раз как что-то ставится, удаляется - енто дело фиксировать. И чтобы оно само нас уведомляло, а не лазить через их ГУИ и смотреть что там есть, а чего нет.

Ну на это вроде ответил. Лазить никуда не надо - можно по email уведомление получить.

[Spy]

А как вы дружите с мэйнфреймами?
А с дилерами в Республике Беларусь у вас совсем туго?

[Spy]

Тоже самое. Если все эти действия где-то протоколируются (лог файлы, БД), то все это мы умеем мониторить. Насчет степени автоматизации я не очень понял вопроса.

Т.е. на каждый тип сообщений и на каждый источник (Виндовые логи, Тваревские, Cisco-Syslog) нужно настраивать свои реакции? Так мы и сами можем в Enterprise Management Log.

А хотелось бы так:
получить все сообщения UserLogon для машины МАШИНА в период с ... по ...

И софтина (не спрашивая а машина виндовая? а машина тваревская? а может она фурычит на Cisco IOS?) - просто берёт и гонит список:

На данной машине логинились: первый тогда-то, просидел стока, второй - тогда-то...

Вот собственно енту лажу мы собираемся реализовать в своём собственном приложении, на базе Unicenter. Кстати, решение у нас тоже будет вебовское на ASP.NET + Crystal Reports

русскоязычный рынок пока мизерный

Не понятная трабла в том, что у СА есть локализации для ряда стран (Японии, Германии и т.д.). Мы понадеялись, что у них локализация и софт (как и должно быть у умных девелоперов) разделены. Послали им запрос: покажите какие файлы надо править и мы сами переведём. Нам же нужно только интерфейс перевести, хелпы переводить нам не надо: технический английский - родной для любого админа. Но Ирландия ответила: клешни прочь от СА (советской армии ;) ) - если чё троните, мы отказываемся от поддержки...
Насколько я понял, интерфейсные тексты у них зашиты в exe, dll-файлы. Так что мы оставили свои попытки помочь их продвижению на русскоязычном рынке

[Dmitry_NJ]

Т.е. на каждый тип сообщений и на каждый источник (Виндовые логи, Тваревские, Cisco-Syslog) нужно настраивать свои реакции?

Нет, реакция может быть одна на всех. Но вот мониторы на каждый лог будут свои.

А хотелось бы так:
получить все сообщения UserLogon для машины МАШИНА в период с ... по ...
И софтина (не спрашивая а машина виндовая? а машина тваревская? а может она фурычит на Cisco IOS?) - просто берёт и гонит список:
На данной машине логинились: первый тогда-то, просидел стока, второй - тогда-то...

Типичный customer request на кастомизацию (чем вы, собственно, и собираетесь заняться). Out-of-the-box решения, естественно, нет, поскольку все это сильно заточено под вашу специфику.

Не понятная трабла в том, что у СА есть локализации для ряда стран (Японии, Германии и т.д.).

У нас тоже есть (Япония, Китай, Корея). Только русскоязычным от этого ни тепло ни холодно.

Мы понадеялись, что у них локализация и софт (как и должно быть у умных девелоперов) разделены. Послали им запрос: покажите какие файлы надо править и мы сами переведём. Нам же нужно только интерфейс перевести, хелпы переводить нам не надо: технический английский - родной для любого админа. Но Ирландия ответила: клешни прочь от СА (советской армии ;) ) - если чё троните, мы отказываемся от поддержки...

Не важно как реализована локализация. Ни один вменяемый вендор не будет раскрывать особенности внутренней кухни своей системы обычным пользователям. Да потом еще и поддерживать то, что эти пользователи могут сделать с ней. Все в этом мире стоит денег, так что в том, что вам ответили из Ирландии, нет ничего удивительного.

[Dmitry_NJ]

А как вы дружите с мэйнфреймами?

Ничего специально заточенного под мэйнфреймы на данный момент у нас нет (хотя я знаю, что над этим работают). Если есть необходимость мониторить мэйнфреймы, то используются, как правило, различного рода родные утилиты типа RMF Performance Monitoring (для z/OS или OS/390) или OpenVMS System Utilities. А забирать информацию от них (например, парсить output каких-нибудь системных команд) мы умеем.

А с дилерами в Республике Беларусь у вас совсем туго?

На всей территории бывшего СССР у нас есть только 1 дилер в Латвии (в Риге) и 4 дилера в России (все в Москве). В Белоруссии дилеров нет. У нас работают двое ребят в Москве (не дилеры, а непосредственно на Mercury работают), один из которых родом из Минска. Так что вам, наверное, с ним будет легко общий язык найти :)

[Spy]

В целом картина ясна. Спасибо за интересную дискуссию. В последующих разработках технических решений постараемся максимально учесть возможность применения решений компании Mercury Interactive Corporation.