VMware Log Insight offline logs analysis

Бекапы делают трусы (с)

...а лог коллекторы настраивают неудачники, у которых все постоянно ломается. Настоящим инженерам, руководствующимся в своей практике лучшими рекомендациями вендоров, лог сервера не нужны.

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

При всем этом, Log Insight предназначен для онлайн агрегирования логов из добавленных источников, но никак не для offline анализа не инспектируемых логов. Говоря по-простому: если вы предварительно добавили ESXi хосты, vCenter, то на Log Insight попадут только логи с момента добавления, и если после добавления что-то сломалось, то вся аналитическая мощь Log Insight к вашим услугам. Если не добавили, то, естественно, ковырять вам логи в поисках счастья  в текстовом редакторе. Попробуем эту несправедливость исправить.

На старте есть самая отвратительная ситуация: централизованное логирование на хостах настроено не было (даже в виде vSphere Syslog Collector). В наличие у нас есть стандартный набор логов, хранившийся в /scratch/log. А это куча лог файлом непонятного назначения. Разобраться с назначением каждого из логов можно здесь.

Для эффективного анализа всего это мусора на понадобится:
VMware Log Insight - 1 шт.
Datаgram SyslogAgent - 1 шт.
vm c Windows на борту - 1 шт.

1. Выгружаем логи из /scratch/log на vm c Windows.
2. Настраиваем Datаgram SyslogAgent:

Datаgram SyslogAgent имеет одну особенность. Если мы сразу настроим его на уже заполненные файлы с логами, он ничего не отправит на Log Insight, поэтому в начальных настройках указываем пустые файлы с необходимыми нам именами.

Создаем новое Application, выбираем тип лога Static, указываем путь к пустому файлу.

Если получаем ошибку, значит все идет хорошо:

Добавляем парсинг даты и времени и для удобства идентификации имя процесса:

3. Рестартуем лог агента. Ждем пока агент обработает пустой файл.
4. Копипастим в пустой файл содержимое реального лога, анализ которого хотим провести.
5. Идем на Log Insight и видим дивное диво: Log Insight скушал наши 21388 offline событий:

Теперь в их можно эффективно искать, фильтровать и анализировать. О создании фильтров я писал здесь на примере анализа курсов валют НБРБ.

Однако, как оказалось, Log Insight и сам молодец. В горе мусора, которую мы в него загрузили, он смог самостоятельно найти errors, warnings специфические для ESXi. Эти находки он нам и показал на вкладке VMware - vSphere General- Problems:

Менюшечка эта совершенно интерактивная, а значит, выбрав для необходимого типа ошибок пункт Interactive Analytics:

мы получим всю информацию по всем ошибкам данного типа:

 P.S> желтенький треугольник с восклицательным знаком, присутствующий на многих картинка, обозначает, что одна или несколько нод кластера  Log Insight в данный момент недоступна. Но об этом потом ;)

VMware vCenter Log Insight делегирование прав

Что всегда компания VMware умела делать "хорошо" ? именно то, что написано в теме.

VMware vCenter Log Insight не стал исключением, благо хотя бы в 1.5 была добавлена интеграция с ActiveDirectory. Но на этом с настройками для удобного управления правами и доступом было покончено. В версии 2.0 ничего не изменилось.
Мы имеем целых 2 различных типа доступа: Normal и admin
Методом исключений предполагаем, что те, кто попадает под гордое название "Admin" совсем "ненормал". Группы отличаются лишь отсутствием вкладки Administration для группы Normal User. Т.е., как и ожидалось, делегирования прав нет. Можно, конечно, настраивать вид с помощью "Dashboards", однако это никак не спасает от самой возможности смотреть все. Наличие большого числа Content Packs для различных устройств и сервисов усугубляет печальность ситуации.
Интеграция с AD проходит достаточно просто и прозрачно (необходимо и достаточно учетной записи с правами только на чтение)
До интеграции с AD:
...после:

печали добавляет как отсутствие поиска по AD, так и отсутствие проверки наличия группы\пользователя в AD.

Достаточно странное исполнение с учетом позиционирования продукта. =(

VMware vCenter Log Insight Agent


Совсем недавно VMware выкатила в публичный доступ v.2.0 Log Insight. Оно стало быстрее, толще, умнее. О всех новых плюшечках и рюшечках можно почитать здесь. Вскоре последовал давно ожидаемый Windows Content Pack, а вместе с ним и VMware vCenter Log Insight Agent. Появилась надежда, что больше колдовать с Datagram SyslogAgent не придется.
Некое смятение в ощущение полной и нераздельной радости внесло емкое сообщение при инсталляции агента:
Разумная политика VMware нелюбви с некрофилам идет в разрез с удовлетворение хотелок пользователей. К сожалению, даже port, созданный средствами ThinApp не заведется на w2k3 и хр.

Скачать Windows Content Pack можно здесь. Установка достаточно прозрачна и происходит через меню Log Insight>Content Packs>Import Content Pack
После импорта вы получите доступ к всяческой служебной информации с описанием ошибок, уведомлений и т.п.
Дальше необходимо установить VMware-vCenter-Log-Insight-Agent-2.0.3-1879692 на сервера с Windows, указав при этом адрес Log Insight server.
Если все прошло хорошо (для дружбы агента и сервера используется порт за номером 9000), то вскоре вы увидите:
а потом и вот такую красоту
и всякие разные другие красивости и полезности.

Наибольший интерес представляет поле "Agent Configuratiom" в меню Agents. Естественно, за нас подумали и про автоматизацию настроек клиентов. Только вот нигде не написали про синтаксис этого Agent Configuratiom. Но тут все просто, примерно так:
[server]
proto=cfapi
hostname=192.168.3.244
port=9000
; Force reconnect agent every 30 minutes.
reconnect=30

[storage]
max_disk_buffer=200

[logging]
; The level of debug messages to enable: 0..2
debug_level=0

[winlog|Application]
channel=Application

[winlog|Security]
channel=Security

[winlog|System]
channel=System
и т.д. в зависимости от ваших хотелок.

ну и напоследок: 
 логи агента хранятся c:\ProgramData\VMware\Log Insight Agent\log\


vFabric Application Director import blueprints

Есть у VMware такая хорошая штука с названием vFabric Application Director.
Предназначен он для автоматизации развертывания многоуровневых приложений в облаке (в том числе и в Amazon EC2). В общем, продуктом можно творить чистейший AAAS.
Из коробки он поддерживает кучу разных ОС и DB и APP, а при должном желании достаточно легко автоматизируется деплой и кастомизация, не попавших в список счастливчиков, компонент.
Выглядит vFabric Application Director так:

Продукт совершенно не популярный на нашем рынке, впрочем, как и на рынке ближайших соседей. Однако, в последнее время сотрудники русскоязычного офиса VMware с завидным постоянством устраивают по данному продукту обзорные экскурсии. Связано это, вероятно, с тем, что vFabric Application Director получил неплохую интеграцию с VCAC, а о кораблях, сопровождающих флагман, врагам нужно знать. Наиболее частые вопросы из зала после таких экскурсий: про прозрачный переход с версии 5 на 5.2 и импорт шаблонов.

На импорте шаблонов и остановимся:
1. Подключаемся к vFabric App Director по ssh под учетной записью root.
2. >cd/home/darwin/tools - там лежит "правильная", соответствующая установленной версии Darwin-cli.jar. Это не значит, что нельзя туда положить "неправильную" от прошлой версии (зачем и как этим воспользоваться как-нибудь потом)
3. Делаем >java-jar darwin-cli


4. Делаем логин на в vFabric App Director средствами Darwin-cli.jar под встроенной учеткой admin >login --serverUrl https://<IP>:8443/darwin/ --Username admin  --password xyz
      5. Потом делаем импорт с ключем check для проверки наличия  в развернутом vFabric App Director всех используемых в импортированном blueprint компонент:
      > import-package --importFilePath /home/darwin_user/appd-Clustere-Apache-Hadoop-testimport.xml --conflictResolutionAction  CHECK

Для примера я использовал template для Cluster Apache+Hadoop. Все компоненты есть, а ожидаемо не найденный deployment_profile создадим вручную (на скорость и дальность полета это не влияет)
6. Пропускаем не найденный deployment_profile и делаем импорт с ключом skip
> import-package --importFilePath /home/darwin_user/appd-Clustere-Apache-Hadoop-testimport.xml --conflictResolutionAction  SKIP
7. Готово. Идем на https://<IP>:8443/darwin/ и видим наш импортированный и готовый к деплою blueprint.

Для примера эффекта от использования vFabric App Director:
Развертывание "правильного" пятинодового Oracle Weblogic 12 c учетом всех рекомендаций Oracle у меня заняло 31 минуту и происходило так:

deploy 5xCentOS - 8m 30s

apache install - 40s 427ms
apache configure - 292ms
apache start - 548ms
setup WLClusterLB - 48s 120ms


MSWL install 16m 10s 29 ms
ManagedServer - 1m 6 s 196 ms
UnpackDomain - 1m 21s 120 ms
SMS install - 2m 17 s 956 ms

ASWebLogic install - 15m 43s 908ms
AdminServer install - 5m 3s 227ms
PackDomain install - 17s 741ms
DeployDB - 1m 8s 543ms

MySQL install - 43s 410ms
MySQL configure - 3s 446ms
initialize_db - 648ms

Кто может быстрее ? =)


ESXi root password reset

Иногда я забываю теряю пароль от root для ESXi. Такое бывает, хостов много разных для разных целей, а привычки "одного пароля на все" у меня нет.
Обычно в такой ситуации я переустанавливаю ESXi, колдую с помощью host profiles и все готово - быстро и надежно. Но иногда случаются ситуации, когда пароль все таки необходимо сбросить без переустановки.
Не смотря на все старания VMware, ESXi все еще остается Linuxом, а значит будем действовать старым и проверенным способом.

1. Качаем Linux LiveCD. В моем случае - он народный 
2. Подключаем диск с LiveCD к серверу с ESXi и грузимся с него.
3. В подложке ESXi у нас будет лежать GPT, поэтому не заморачиваясь с fdisk сразу идем в gparted

4. У ESXi жизнь на диске происходит так:
system boot - загрузочный системный раздел
bootbank - системный образ ESXi, именно оно и копируется в оперативную память при загрузке.
altbootbank - резервный для bootbank (на случай беды при обновлении)
vmkDiagnostic - дампы памяти при blue screen purple screen
store - образы VMware Tools
scratch - такой есть если диск больше 5 Гб и туда падают всяческие логи.
5. /dev/sda5 - это то, что нам надо. Монтируем и смотрим что же там есть.

6. А надо нам state.tgz. Закинем его в tmp и распакуем.

7. Теперь нам надо local.tgz

8. Теперь принимаемся за shadow. Делаем из некрасивого shadow:

красивый:



9. Обновляем старый state.tgz до нового state.tgz

10. Отмонтируем /mnt и перегружаем хост.
11. Пароля нет.

P.S> и да, оно работает в 5.5
P.S2> а кто-то говорил, что не бывает ESXi c пустым root паролем...