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

Совсем недавно (5-8 лет назад) системный администратор Linux был ограничен в средствах администрирования и автоматизации. Где-то можно было обойтись самописными скриптами на bash, Python, Perl, а где-то уже требовалось решение уровня энтерпрайз от таких гигантов, как IBM, Oracle или RedHat.

С развитием Open Source стала развиваться и автоматизация в администрировании. На замену самописным скриптам и программам пришли готовые решения. Эти средства появились не на пустом месте. Это были решения по автоматизации существующих задач любого системного администратора. Зачастую это решения, развиваемые по принципу KISS (акроним для «Keep it simple, stupid»), которые получали большие перспективы развития и распространения.

Конечно, лет 5-10 назад средства централизованного администрирования в Windows были развиты лучше, чем в Linux. Это было небезосновательно, т.к. Windows был широко распространён как среди домашних пользователей, так и в офисной/серверной среде. Microsoft, похоже, не предполагала что когда-то будет соперничать с Linux в серверном сегменте. Но не будем здесь углубляться в эти застойные времена для Microsoft, когда главой корпорации был Стив Балмер.

Администрирование

Одним из часто используемых средств администрирования мною и коллегами до появления ansible/puppet/chef был cssh (Cluster SSH).

Работа с cssh была проста, не нужно было повторять одни и те же действия на каждом сервере по очереди, всё сводилось к мультиплексированию ввода в терминале на группу SSH подключений. У этого решения, конечно, были очевидные недостатки — необходимо было взаимодействие с администратором, его контроль. Сегодня средства автоматизации ушли намного дальше в своих возможностях и функциональности и зачастую расширяются плагинами.

Одно из наиболее распространённых средств автоматизации в администрировании — Ansible. Оно позволяет автоматизировать практически любые задачи системного администратора. Для работы достаточно SSH доступа к хостам. На сайте есть обзорная статья про Ansible, как его настроить и работать. Проект развивался независимо и вскоре был куплен компанией RedHat.

Мониторинг

После настройки сервера и введения его в эксплуатацию для обеспечения SLA и не только необходимо уделить внимание мониторингу.

Мы часто разделяем мониторинг на два отдельных компонента:

• мониторинг с оповещениями,
• статистика по показателям.

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

1. Zabbix/Nagios/Icinga — используем для получения событий агентами и уведомлений по триггерам.
2. Grafana + InfluxDB — в эту связку входят также Chronograf, Kapacitor, Telegraf.

• InfluxDB — time series база данных, принимает на вход данные с различных источников. Имеет широкий функционал возможностей для работы с данными. Chronograf — веб-панель с дашбордами и система управления Influxdb, Kapacitor.Kapacitor — обработчик событий.Telegraf — агент, отправляет данные с удалённых систем.Grafana — всем известная система построения дашбордов/графиков.

Netdata — это «швейцарский нож» в системе мониторинга, обладает широкой функциональностью, поддержкой модулей на Python, Go и не только.

Централизованное управление пакетами

В качестве централизованного управления набором ПО и его обновлениями мы использовали RedHat Spacewalk.