Документ взят из кэша поисковой машины. Адрес оригинального документа : http://theory.sinp.msu.ru/pipermail/ru-ngi/2011q4/000282.html
Дата изменения: Mon Oct 10 18:53:55 2011
Дата индексирования: Tue Oct 2 02:48:37 2012
Кодировка:
[RU-NGI] regional nagios: текущее состояние и причины

[RU-NGI] regional nagios: текущее состояние и причины

Valery Mitsyn vvm at mammoth.jinr.ru
Mon Oct 10 16:34:37 MSD 2011


Hi Lev,

проблема не "рассосалась", на наших 4-х CE этот тест примерно
через раз выдает critical, то есть, раз -  OK, следующий
запуск - CRITICAL. Правда диагностика теперь другая:

Trying SURL 
srm://lcgsedc01.jinr.ru/pnfs/jinr.ru/data/ops/generated/2011-10-10/filef486e965-9d4e-46b9-b185-cedfa6561912 
...
Source SE type: SRMv2
Source SRM Request Token: -2079224650
Destination SE type: SRMv2
Destination SRM Request Token: 100489f2-1cb9-4335-ae8e-d4c2c0c4b281
srm://lcg59.sinp.msu.ru/dpm/sinp.msu.ru/home/ops/generated/2011-10-10/file34080ee5-9949-4765-8cbe-5d9e62091cc1: 
Invalid argument
lcg_rep: Invalid argument
2011-10-10T11:38:54Z
Failed replication to lcg59.sinp.msu.ru

  Предлагаю использовать наш 2-й SE - lxse-dc01.jinr.ru, пока вопрос
с SE для nagios не будет решен окончательно.

P.S. Проблемы с nagios мне понятны и вполне ожидаемы, после
перехода от EGEE к EGI, разработка всего софта потеряла
единого координатора. Я просматриваю тикеты в GGUS по
софту и вижу, какие обидные проблемы всплывают из-за
недостаточной координации в разработке и внедрении нового
софта именно сейчас. Будет надеяться, что текущий бардак скоро
всем надоест и его ликвидируют. Могу только посочувсвовать
вашему коллективу в нелегком деле ведения регионального
nagios.

P.P.S. Некоторые другие регионы тоже пострадали, к примеру:
https://ggus.eu/ws/ticket_info.php?ticket=75152

On Mon, 10 Oct 2011, Lev Shamardin wrote:

> Привет всем,
>
> tl;dr: тесты переконфигурировали, проблемы должны "рассосаться" за несколько часов.
>
> Теперь подробнее о причинах и текущем состоянии.
>
> Для запуска некоторых тестов на WN используется SE, который должен быть
> во-первых, правильно настроен и доступен, а во-вторых, по хорошему, находиться
> во "внешнем" по отношению к сайту (а лучше и к региону в целом) месте.
>
> Долгое время такие "внешние" SE предоставлялись CERN'овской командой SAM, и их
> адреса вбиты в дефолтные значения всех конфигураций в дистрибутивах Nagios и
> т.п. Более того, долгое время считалось что такое положение вещей является
> правильным, и порядок изменения имен этих SE даже не описывался в документации
> (и на данный момент по-прежнему отсутствует в руководстве по установке
> мониторинга на Nagios).
>
> Некоторое время назад команда SAM решила, что эти SE пора выводить из строя. Они
> каким-то образом "сообщили" об этом намерении администраторам региональных
> nagios'ов, но "сообщили" в кавычках, поскольку через какой канал это было
> сделано не очень понятно. По крайней мере, соответствующих Broadcast'ов или
> тикетов в GGUS не было.
>
> На прошлой неделе по одной из SAM'овских рассылок пришло уведомление в духе
> "всем привет, сервера выключаем, если что, имейте в виду, что вот эти ими
> пользовались, и им станет плохо", и, конечно, мы тоже попали под раздачу.
>
> Появление проблемы заодно наложилось на downtime GGUS'а, поэтому в конечном
> результате занялись ей только в пятницу, и решили только сегодня.
>
> В качестве временного решения для тестов используется один из production SE на
> сайте ru-Moscow-SINP-LCG2, вопрос о том где и как будет развернут
> "окончательный" SE для тестов сейчас в процессе решения.
>
> Полностью согласен со всеми жалобами и считаю ситуацию крайне неприятной.
> Вообще, хотелось бы отметить, что документация к SAM Nagios и координация
> действий, связанных с какими-либо серьезными изменениями в SAM Nagios сейчас
> находятся в очень странном для меня состоянии: документация "размазана" по
> нескольким местам и не полная (а местами и противоречивая), публичные изменения
> о серьезных изменениях, включая даже выход новых версий происходят по не очень
> понятным и не очень надежным каналам, новые версии rpm-пакетов попадают в
> production-репозитории ДО (!) того, как очередной апдейт получает статус
> "Released", иногда с "опережением" на несколько недель (при этом в том месте,
> которое можно считать документацией, стоит статус "Do not install yet").
>
> Короче, имеет место серьезный бардак. Кто и что может с ним сделать - не знаю.
> Но многие наши проблемы вызываются именно наличием этого бардака.
>
> С уважением,
>
> Лев.
> _______________________________________________
> RU-NGI mailing list
> RU-NGI at theory.sinp.msu.ru
> http://theory.sinp.msu.ru/mailman/listinfo/ru-ngi
>

-- 
Best regards,
  Valery Mitsyn


More information about the RU-NGI mailing list