Серверное администрирование *

«Доставляем в Kubernetes. Непрерывно и по-своему», Евгений Дехтярёв, 2ГИС

В предыдущих статьях про сниффер на PowerShell и сбор данных о загрузке с удаленного сервера я уже немного писал про возможности ETW (Event Tracing for Windows). Сегодня я хочу подробнее рассказать про эту технологию.

Заодно покажу на примере разбора HTTPS и создания кейлоггера на PowerShell, как ее можно использовать во благо. Или не совсем во благо.

В комментариях к предыдущей статье вспомнили про учет в Excel вместо 1С. Что ж, проверим, насколько вы знаете Excel. Сегодня я покажу, как получать данные из Active Directory и работать с ними без макросов и PowerShell — только штатными механизмами Office. Например, можно запросто получить аналитику по использованию операционных систем в организации, если у вас еще нет чего-либо вроде Microsoft SCOM. Ну, или просто размяться и отвлечься от скриптов.

Мониторинг — это главное, что есть у админа. Админы нужны для мониторинга, а мониторинг нужен для админов.

За последние несколько лет поменялась сама парадигма мониторинга. Новая эра уже наступила, и если сейчас вы мониторите инфраструктуру как набор серверов — вы не мониторите почти ничего. Потому что теперь "инфраструктура" — это многоуровневая архитектура, и для мониторинга каждого уровня есть свои инструменты.

Кроме проблем типа "упал сервер", "надо заменить винт в рейде", теперь надо понимать проблемы уровня приложения и уровня бизнеса: "взаимодействие с микросервисом таким-то замедлилось", "в очереди слишком мало сообщений для текущего времени", "время выполнения запросов к бд в приложении растет, запросы — такие-то".

У нас на поддержке около пяти тысяч серверов, в самых разных конфигурациях: от систем из трех серверов с кастомными докеровскими сетками, до больших проектов с сотнями серверов в Kubernetes. И за всем этим надо как-то следить, вовремя понимать, что что-то сломалось и быстро чинить. Для этого надо понять что такое мониторинг, как он строится в современных реалиях, как его проектировать и что он должен делать. Об этом и хотелось бы рассказать.

Мои ощущения от процесса работы

Недавно я решил заняться ускорением восстановления нашей базы данных в dev-окружении. Как и во многих других проектах, база вначале была небольшой, но со временем значительно выросла. Когда мы начинали, ее размер было всего несколько мегабайт. Теперь упакованная база занимает почти 2 ГБ (несжатая — 30 ГБ ). Мы восстанавливаем dev-окружение в среднем раз в неделю. Старый способ проведения операции перестал нас устраивать, а вовремя подвернувшаяся в Slack-канале картинка “DB restore foos?” побудила меня к действию.

Ниже описано, как я ускорял операцию восстановления базы данных.

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

1. Сколько уникальных исходящих TCP-соединений установили ваши серверы за последний час?
2. Какие процессы и пользователи инициировали установку этих соединений?

Если вы в состоянии ответить на оба вопроса, отлично — дальше можете не читать. А если ответа нет, то получить эту информацию поможет go-audit.

Я искал self-hosted мониторинговое решение с открытым кодом, которое может предоставить хранилище метрик, визуализацию и оповещение для физических серверов, виртуальных машин, контейнеров и сервисов, действующих внутри контейнеров. Опробовав Elastic Beats, Graphite и Prometheus, я остановился на Prometheus. В первую очередь меня привлекли поддержка многомерных метрик и несложный в овладении язык запросов. Возможность использования одного и того же языка для графических изображений и уведомления сильно упрощает задачу мониторинга. Prometheus осуществляет тестирование по методу как черного, так и белого ящика, это означает, что вы можете тестировать инфраструктуру, а также контролировать внутреннее состояние своих приложений.

Немаловажный пункт, который очень часто упускают из вида разработчики — это эксплуатация проекта. Как выбрать дата-центр? Как прогнозировать угрозы? Что может произойти на уровне фронтенда? Как балансировать фронтенд? Как мониторить? Как настраивать логи? Какие нужны метрики?

И ведь это только фронтенд, а есть ещё бекенд и база данных. Везде разные законы и логика. Подробнее об эксплуатации highload-проектов в докладе Николая Сивко (okmeter.io) с конференции HighLoad++ Junior.

Привет Хабр! С вами снова ServerFlow, и сегодня мы хотим поговорить об удалённом доступе к графическим приложениям на Linux-серверах. Тема эта стала особенно актуальной в последнее время – всё больше задач требует работы с GPU на удалённых машинах. Будь то рендеринг в Blender на мощном сервере, работа с нейросетями или даже облачный гейминг.

Обо всё этом в новой статье ниже.

Продолжаем цикл статей об организации мониторинга. В первом материале разбирали, как и куда вообще имеет смысл навешивать алерты. Теперь поговорим о мониторинге базового серверного ПО, которое встречается в работе практически любого веб-проекта. Хочу поделиться метриками и алертами, которые мы в ITSumma используем для мониторинга виртуальных машин, docker/LXC-контейнеров, web- и application-серверов, supervisor’а, кастомных сервисов, а также ping-url’ов, SSL-сертификатов и доменных имен.