Работать сисадмином - как это

описание

Публикую свои мысли о работе админом. 10 лет в ИТ с уклоном в сети Я на пикабу: https://pikabu.ru/@virrasha Мой сайт: https://virrasha.ru

← к каналу @sysadmin_how_it_is

225

подписчиков

Охват к подписчикам

182,7%

ERR

Реакции к просмотрам

2,92%

240 на 20 постов

Пересылки к просмотрам

0,41%

Постов в день

0,0

всего 20

Где отзываются чаще

доля реакций к просмотрам

14 авг. 2025 г.Про мониторинг и не только. Спасибо всем, кто не отписался! Сегодня поговорим про то, как происходит трансформация подхода к мониторингу. На моём примере. Кто помнит, я в посте "заббикс в первый раз" рассказывала как я когда-то в древности поднимала нам мониторинг. С тех пор прошло много времени. Какие-то попытки прийти к более приемлемой работе с инцидентами у меня были года два назад и тогда они не увенчались успехом. Но попробуем по порядку. Заббикс у нас мониторит серваки и сетевое оборудование. И вроде всё хорошо. Но с ростом инфраструктуры мы получили несколько проблем (помимо того, что параметры запуска его БД надо подкручивать с увеличением базы). Проблема первая: слишком много сообщений. У меня было около 70 тысяч непрочитанных сообщений от заббикса за три месяца. Да, можно подкрутить шаблоны, повыключать алерты, разметить группы, чем я частично и занялась.. Но мы подходим ко второй проблеме: сообщения не информативны для понимания состояния работоспособности инфраструктуры. Ну то есть, сообщение "меньше 5ГБ осталось на диске D сервера s00-db01". Вообще не говорит нам о том, что у нас навернулся или НЕ навернулся корпоративный портал. А такое же сообщение про диск G - это не критично, потому что "не обращайте внимания, это temp db". Или, например, "туннель с Роутером1 Вологды недоступен". Тут сразу вопрос: а с роутером2 доступен? Ну то есть, сеть филиала видна, всё ок, резерв работает. Или, например, недоступны все туннели с Вологдой. Плохо это? Ну как бы да, филиал недоступен. Но, допустим, время сейчас 3 утра субботы, филиал не работает. А может время рабочее, но они прислали письмо "у нас авария на электроподстанции, полгорода без света". Уже сразу критичность инцидента понижается - потому что не нужна связь или сделать со своей стороны ничего не можем. И третья проблема: а непонятно, как определять критичность, как определить ответственных, кто должен добавить там места или посмотреть что с туннелями. И непонятно, что считать за "хорошее состояние системы". Можно начать писать инструкцию на каждый сервер, но сервера прибавляются быстрее, чем ты пишешь инструкции. То есть, есть у нас гора алертов заббикса, есть круглосуточная поддержка в виде одного человека единовременно, который пырится в этот мониторнг и пытается понять, а что с этим делать. И у которого записки "на это не обращать внимания, а вот это важно, писать туда". Я тут сходила в мае на LinkMeetUp, послушала тематические доклады и, наверное, смогла лучше сформулировать то, что нам надо. А может, компания дозрела до перемен. А теперь забываем все перечисленные проблемы. Потому что это такие, ит-шные мелкие проблемки. Ставим вопрос по другому: а что важно для бизнеса? Для бизнеса важно понимать, что не сломался бизнес-процесс. Сайтик крутится, лавэха мутится, как говорится. И приходим к мониторингу сервисов, а не серверов. Тут надо поймать баланс между ИТ-метриками и бизнес-метриками, конечно. А в идеале мониторить и то и другое. Много чего нужно в идеале и я про что-то попробую рассказать в будущих постах. Но мы помним, компания не рождается гуглом и яндексом. Из имеющихся сил - примерно я. А мониторинг - отнюдь не единственная область, которой я занимаюсь в компании. Поэтому я начала с малого: веб сервисы. Это достаточно просто и наглядно, плюс должно сильно уменьшить время реакции на важные инциденты. Да, то, что веб страничка возвращает 200 ОК не означает, что сервис прямо таки работает. Но лучше такой мониторинг, чем "а зайди проверь, говорят, портал чёт упал". Продолжение в следующих сериях. Там будет про написание инструкций, prometheus, grafana, а также поучаствуют нейросети.8,80%
15 авг. 2025 г.Продолжаем про мониторинг. Серия 2 из нескольких. Началось всё на самом деле с "поговорить". Пришла к начальнику и попыталась выянить, а какие сервисы у нас важны с точки зрения бизнеса. Ну вот, за что мы денег либо потеряем, либо недоприобретём. А какие просто важные и хотелось бы следить, потому что неприятно, когда падает, а мы (ИТ) узнаём об этом не первыми. Слово за слово, провели пяток совещаний и поняли с чего начать. Начальник ещё посоветовал почитать приказ "об обеспечении непрерывности деятельности" - сто страниц чистого восторга! Там написано примерно всё то, что я хотела делать. Правда, относится он в основном ко всяким пожарам, наводнениям и прочим прорывам дамб, но натягивается на нужную область как родной. Второй момент: я попыталась донести, что мало мониторить сервисы, надо к ним при постановке на мониторинг писать сопроводиловку, где будет указано: - "нормальное" состояние системы (у нас есть сервис, который виснет на ответах каждые несколько минут и это его нормальное состояние - всех устраивает доступность 94% в час) - уровень отклонений, когда работают алерты - уровень критичности (будить ночью ответственного или потерпит) - собственно список ответственных (не по документам, а по факту - кто может диагностировать и починить) - желательно, простые шаги диагностики, которые может выполнить поддержка - желательно, простые шаги для починки, котоые может выполнить поддержка перед эскалацией (типа, выполни скрипт, ребутни службу, ребутни сервер) - ну и путь эскалации И вот всё это не на 57 страниц приказа, а понятным языком во внутренней вики и по единой схеме. Ну чтоб люди в момент, когда упало, не читали многотомник канцелярщины, а имели простые и понятные шаги для диагностики и выполнения. Потом, очень потом, сюда добавятся группы реагирования, анализ инцидентов и прочее. В идеале ещё бы иметь схему зависимости сервисов, которая может разворачиваться и углубляться до серверов. Обновляемую. Вообще, задача "а давайте внедрим SRE" выглядит масштабно до одури. Но у меня есть опыт переваривания больших задач, которые делались годами. Так что послушаем умных людей и примем, что SRE начинается с правильного мониторинга. Заббикс я решила не трогать - мониторить, где там место кончилось, тоже надо. В планах потом сильно уменьшить от него поток оповещений. В общем, заббикс остаётся как низкоуровневый мониторинг и как мониторинг с длительной историей (год). А параллельно поднимаю prometheus, victoriametrics и графану. Это будет оперативный мониторинг. И начала я с blackbox exporter, который проверяет у меня отклик от веб страничкек. Поднять по инструкции - в целом, проблем не вызвало. А вот дальше меня ждало то, что всегда бывает, когда начинаешь изучать что-то прям для себя новое. В yaml я ни в зуб ногой, синтаксис незнакомый, promql тоже как бы. Что там должно подняться, где конфиги и где метрики - тоже надо изучать. Как сделать так, чтобы 401 unauthorized было валидным ответом и т.д. Обычно как: чет гуглишь, настраиваешь, не работает, изучаешь логи, гуглишь ещё и так до победного. А тут я внезапно сходила на ещё одну конфу, где был очень искренний доклад сетевого инженера о том, что нейросети реально могут помочь, и вообще лучше, чем мы, старпёры, думаем. И я пошла общаться с deepseek. Писала ему примерно как ТЗ для тупенького админа, который обязательно твоё ТЗ извратит. Это, чёрт возьми, работает. И очень, прям очень помогает сломать первую стену непонимания работы системы. Да, потом он пошёл врать, уже на шаблонах алертменеджера. Да, надо быть внимательным и перепроверять. Да, он советует китайские дашборды к графане. Да, надо понимать, что нельзя в него копипастить корпоративные данные. Но насколько же это охрененно, когда deepseek мне сократил время до начала работы системы в приемлемом виде раз в семь! Продолжение следует.6,64%
13 февр. 2025 г.Про запросы Прошло много времени с моего последнего поста. Я так и не собралась опубликовать код своей бэкапилки сетевого оборудования на питоне, хотя она исправно работает, в том числе с новыми свичами от Maipu. Когда-нибудь, да.. Сегодня про прикольную задачку от моего любимого колл-центра. Нужен им был отчет, чтоб и сводный, и с процентами, и суммировал и показывал много чего. А у них всегда есть два варианта: или отчет делаю я, или они заказывают у вендора доработку системы за немного денежек (кстати, обычно, вменяемо, не как крыло от самолёта). Но к деньгам надо писать 100500 служебок, четыре согласования, адекватное ТЗ и ждать неизвестно сколько. В общем, они любят, когда отчёты делаю я и даже готовы ждать, когда у меня появится время. А я как-то для своих надобностей обычно работаю с базами данных на одну-три таблички, без фанатизма. Ну, знаете, select * from netdev where ip like "10.78%"; обычно мой предел. А тут в одной базе статистики 76 табличек, во второй тоже хватает. Описания структуры БД, конечно, нет (есть, но ооочень лаконичное). Так что я вначале погрузилась в мир текущих отчетов и маленьких селектов в PGAdmin, чтоб понять, откуда вообще тащить данные. Потом попыталась всё это склеить. Получилось, но не то. Дернула нашего гуру sql, он дал совет. Получилось и то, но это была только четверть отчёта. В общем, теперь я умею делать запросы в 4 тблицы в двух разных БД, а также делать LEFT JOIN на FULL JOIN на LEFT JOIN на ещё один LEFT JOIN. Надо просто не жалеть скобочек, оказывается. А ещё узнала, что можно сделать select *, что-то_ещё То есть, выбрать больше, чем звёздочка. Ну ладно-ладно, мне ещё раз помог наш гуру по SQL. Но только советами 🤯 (я периодически говорила "а что, так можно было?"). Попутно нашла, что делать при делении на ноль (проценты беспощадны!), а также обошла странную штуку при сравнении времени через свойства самой системы отчётности. Развлекалась, короче, на все деньги. Заказчик результатом доволен :) Попутно изучила пару отчётов, которые нам писали когда-то сотрудники вендора. Называть промежуточную таблицу просто t в запросе на 300 строк - это надо иметь особую ненависть к тому, кто будет отчеты разбирать после них. Потому что по ctrl+f найти одну английскую буковку t в нужном месте довольно нетривиально. Чтоб они спали спокойно после этого. Спасибо подписавшимся, да и отписавшимся тоже: какая-то движуха тут без меня происходила, прикольно)4,82%
1 нояб.И снова мониторинг: prometheus, grafana, alertmanager. Наплывами возвращаюсь к теме мониторинга. Мониторнг работает, нам раздобыли списанный огромный телевизор и теперь там куча цветных табличек и графиков - красиво, можно показать какому-нибудь залётному руководству. Ну и так, быстрее реально стали замечать, что что-то упало. Одни разрабы подкинули задачу - парсить выводимый json со странички и писать статус сервиса в зависимости от выводимого. Ну типа: есть ссылка, у которой динамическая часть - код региона и дата. Каждая ссылка возвращает в json, помимо прочего, количество загруженных в систему данных по указанному региону и на указанную дату. Если данных ноль - это ошибка. Если положительное число, то всё ок. Механизм чуть осложняется тем, что переход по ссылке напрягает систему, которая считает каждый раз точное число (оно нужно для другого). Поэтому состояние нужно проверять раз в сутки. И снова я выбрала писать эспортёр - прокладку. Он ходит и дёргает странички раз в сутки в указанное время и парсит данные. Потом выводит статус по регионам в формате, понятном прометеусу, ну и дату последнего обновления публикует на всякий случай. А прометеус уже смотрит на публикуемые данные и сохраняет раз в 30 минут у себя - да, они одинаковы на протяжении суток, ну и что. Другая задачка тоже прикольная. При срабатывании алерта нужно менять конфиг nginx на другом сервере. Ну, освоила webhook в alertmanager. А на сервере nginx'а сидит служба, слушает порт и разбирает пришедший json. Если пришёл определенный алерт со статусом firing - меняет конфиг определённым образом, проверяет его и делает reload nginx'у. А если resolved, то меняет всё взад. Оттестировано, но в прод пока не запущено, ждём отмашки. Вообще, питон, некоторые навыки программирования, нейросетки и прометеус дают очень гибкий инструмент для всяких таких штук, мне прям нравится. И да, я пишу в нашу вики описание по каждому запущенному экспортёру или скрипту. И складываю код в git.3,96%
14 нояб.Вот фоточка того, что получилось, для привлечения внимания. Ух, вот это эпопея костылинга у меня случилась с графаной, сейчас расскажу!3,67%
14 апр. 2025 г.Автобэкапы На прошлой неделе коллега из дружественной организации тоже заинтересовался моим скриптом автобэкапа сетевого оборудования, так что я собралась с силами и его выложила проектом Я уже кучу раз в постах на пикабу писала почему не "ваше любимое готовое решение". Но повторю: 1) потому что я хочу понимать, что происходит. 2) потому что я на основе своего решения уже имею, например, анализатор занятых портов на свичах в рамках филиала. А в целом имею возможность выполнить любые команды и проанализировать вывод. 3) Ну и вообще: моё решение с шахматами и поэтэссами умеет делать ровно то, что мне надо, таким образом, как мне надо. Плохо что ли? Хорошо! И немного истории: Про то, как я боролась с ключами ssh на хуавее я уже писала, но вспоминаю, что это было непросто. Ну и к идее хранения конфигов в системе контроля версий пришла давно, ещё когда у нас были D-Link DFL, и также давно мы переехали с svn на git (в gitea). Был у меня скрипт на bash, а хотелось его переписать на python. Потому что стильно-модно-молодёжно, понятнее к восприятию и можно накрутить всякого. Первый затык был в параллельность. Ну потому что 300 бэкапов, да по 1 минуте на каждый минимум - это уже 5 часов. Как бы питон это не Си и просто fork-exec это немного не то, что нужно. И не bash, где можно просто в конце амперсанд написать. В результе пришла к subprocess. Но тут как бы... триста питон процессов все разом запускать - мой бедный сервер с одним гигом памяти немного может не справиться. Так что надо запускать их параллельно, но не все. Тут муж немного мне помог с логикой карусели процессов. Запускаем N в параллель, отслеживаем завершение, потом как один бэкап кончился - запускаем следующий. Всё круто, но появились зависшие процессы, пришлось сделать таймаут и отстреливать. Потом хотелось сделать одну суперфункцию на всё. Но нет, пришла к выводу, что лучше по своей функции на каждый тип устройств, несмотря на большую часть копирования кода. Естественно, нужно было оценить успешность бэкапа. А если есть оценка успешности - почему бы не запустить повторный бэкап на неуспешные устройства с увеличенным таймаутом? А, да, пыталась я использовать все эти модули - netmiko, paramiko и чёт там ещё. В результате оставила только paramiko и только в части открытия ssh сессии и то не на все устройства. Потому что это грёбаный пипец - то одно не работает, то второе, то не так считывает, то исключения нет и оно падает с ошибкой. В результате, конечно, не кроссплатформенно, а под debian получилось. Зато работает как надо, а не как бог на душу положил разработчикам, которые сетевые девайсы в глаза не видели и бэкапы с них не делали. Потом нам зарубили отправку почты без авторизации внутри домена. Всё, что я нашла для авторизации на exchange это swaks. Это вообще инструмент тестирования и я немного гвозди микроскопом забиваю, но как есть. После этого, нам пришли новые коммутаторы maipu, но тут, спасибо мне, они включились в систему добавлением одной функции и одного if'a. Сейчас вот пришли новые хуавеи с новой прошивкой (там другая ОС!) И у них изменилось сообщение об успешном бэкапе. Придётся зводить их с новым тегом видимо. Такая вот длинная история. В целом система пару лет работает и очень в жизни помогает. Код по ссылке в начале. Readme я сделала на английском, а комменты остались частично на русском. Ну, переводчиком все пользоваться умеют. Надеюсь, кому-то пригодится. Ну а нет - так нет)3,46%
7 мар. 2025 г.Линукс или сетевая железка? Иногда смотришь на энтерпрайз железки с тоской и думаешь, ну ёпрст, а не взять ли мне говнокомп, вкатить туда debian с iptables и радоваться жизни за ценник на порядки меньше.. Сегодня у нас пятничные размышления, возможно, немного наивные. Давайте выкинем случай с ЦОДом, или очень нагруженной инфраструктурой, где действительно чипы и процессоры в железках, заточенных под маршрутизацию или коммутацию, играют большую роль. Рассмотрим обычный вариант малого офиса или филиала, где канал 100 мегабит, ну на край гигабит. Пара серваков, сотня компов. Роутер немножк фильтрует трафик между сетями и в инет, держит до пары десятков vpn-каналов, NAT'ит трафик в инет, пробрасывает внутрь пару портов, ну и может dhcp раздаёт. И встаёт выбор: кинетик/микротик/хуавей/циска или комп/сервер/виртуалка на линухе. Считаем, что производительности условного компа хватит на то, что делает роутер. Почему роутер на линухе это плохо: 1) нет единого конфига. Уася поставил рандомный firewall поиграться, сложил конфиги неизвестно куда, обмазал скриптами на питоне и, конечно же, не задокументировал. Уася уволился или его переехала машина и вы получили чёрный ящик. А может он ещё и диск зашифровал, чтоб никто не догадался, что там в конфигах. В сетевых же железках всё структурировано, шаг влево, шаг вправо и уже ничего нельзя сделать иначе. 2) бэкапы из-за пункта 1 могут быть неполными, чтобы вернуть систему в то же самое состояние нужно прям поебаться. Это не раскатать бэкап с одной циски на другую такую же. Это если вообще кто-то подумал про бэкапы. 3) чтоб нанять замену вашему кулибину, нужно найти достаточно компетентного чувака. Это вам не пройти мастер на кинетике в виде далее-далее-готово и даже не поковыряться внутри микротика по менюшкам. Тут нужны какие-то дополнительные знания. 4) если у вас два офиса, привет два абсолютно разных конфига. Даже если написан регламент как надо. 5) размер имеет значение иногда - маленькая коробочка или десктоп куда-то деть. 6) держать штуку, обеспечивающую доступ к инфраструктуре, внутри этой самой инфраструктуры - ну, не особо безопасно. Это примерно как ставить получение адреса по dhcp на хост-машине, при том что dhcp без failover'а крутится виртуалкой на этой же хост-машине. 7) бывает, нужно ставить сертифицированное решение и, обычно, это железка, тут уж никуда не деться. На самом деле, почти все эти пункты можно победить. Об этом в конце. Почему роутер на линухе это хорошо: 1) он правда умеет всё, что вам надо. А если не умеет, вы поставите дополнительный пакет. Или напишете свой. 2) он отлично скриптуется, можно реализовывать самые извращённые сценарии, вроде работы vpn только в будни по производственному календарю с 7 до 16 с отсылкой напоминаний в телеграм. 3) не справляется? Докиньте оперативки. Короче, худо-бедно по производительности можно менять. А можно вообще масштабировать на несколько.. ладно, мы всё еще про маленький офис, не будем об этом. 4) это стоит мало денег. Ну, типа говнокомп или заначенный маленький сервак есть у каждого админа. И быстро! Не надо играть тендер, ждать согласования.. Минусы в плюсы И если лет пять назад я безальтернативно говорила "только сетевые железки, иначе потом не разгребёте", то сейчас я начиталась про автоматизацию и появились варианты. Если у вас единственный офис с единственним админом, всё ещё условный кинетик - ваш выбор. А вот если у вас много офисов с более-менее едиными условиями и центральным управлением, то можно заняться девопсом: даже без всяких контейнеров грамотно всё загнать в Ansible и вот вы уже получите единое управление, массовую безопасную раскатку изменений, автодокументирование, быструю воспроизводимость и единообразие. И нужно вам не 40 линуксоидов в 40 филиалов, а один сетевик-немножко-девопс (ладно, два). Ну, купить компы в маленьком корпусе (+запас) или обеспечить отказоустойчивый кластер с виртуалками - это уже по деньгам переплюнет маленькие сетевые железки, конечно. Но всё-таки, варианты появляются.3,45%
27 мар. 2025 г.Поленись/не поленись Где-то раз в год возникает задача обновить список почтовых контактов сторонних организаций в AD. Новый список попадает ко мне в виде csv'шки. Задача удалить те контакты, которые не актуальны, залить новые, а те, что остались - поправить (у кого должность сменилась, а у кого-то почта). Просто пачкой удалить всё и залить новое нельзя, потому что тогда при выборе контакта из кэша в outlook полезут ошибки. Контактов около 8 тысяч. Ну понятно, что это powershell. Раньше это было несколько скриптов - сначала просто на компе (где AD обвеска стоит), потом на почтовике, потому что только там есть почтовая оснастка. И много допиливания напильником - тёзки, одинаковая почта (alias'ы) с нашими пользователями, другие ошибки создания. Ну прям человек 200 набегало таких. В этот раз я предстваила страдания и пошла писать скрипты с нормальными проверками, с условиями и прочим таким. Ну потому что надоело страдать. Потом подумала, что я мучаюсь и пошла сразу всё с почтовика делать. Всё равно три прогона получается - один удаление, второй создание, а третий обновление. Потому что в создании почтового контакта нельзя сразу должность впихнуть, а если сразу на него начать делать get-adObject, ад-шка не успевает отсинхронизироваться и в половине случаев говорит, что объект не найден. Поэтому сначала все создать, а потом у старых и новых обновить данные по должностям/почтам. Неплохо получилось, всего 6 контактов с ошибками, требующими ручной доработки. Меньше 0,1%. Лень - двигатель прогресса)) Для новых подписчиков: я стараюсь писать свои впечатления от работы, истории, байки, немного философских мыслей. Каналов типа "приёмы работы bash/linux/windows которые вы не знали" и так много, среди них есть прям хорошие, так что я с ними не конкурирую))3,32%
2 сент. 2025 г.Продолжаем про мониторинг, серия 5 из нескольких. В прошлый раз я обещала рассказать про интересную задачку, которая была в процессе решения. И вот я на прошлой неделе доделала её. Итак, есть задача по мониторингу веб-сервисов. Сервисы представляют собой ссылку вида https://srvNN/otchet?date1=YYYYMMDD где NN код филиала, ну а YYYYMMDD это очевидно дата. Сервисов такого вида штук 20, где-то дата меняется каждый день, где-то ежемесячно, где-то два параметра даты (отдельно год, отдельно число). Ну и филиалов около 60. То есть, нехитрым умножением получаем 1200 ссылок, которые динамически меняются ежедневно и/или ежемесячно. У меня так 😳 глаза вылупились и я пошла разговаривать: а точно ли надо каждый день новую дату проверять, нельзя ли всё в одну ссылку впихнуть, ну или хоть в 60 по количеству филиалов? Оказалось нет, по ссылке на дату строится отчет и сломать могут вот конкретный отчет в конкретную дату. Всё, что предложил мне интернет: менять cron'ом файл с target'ами, то есть, с объектами мониторинга. И программисты тоже предлагали примерно это. На что я им объяснила: для мониторинга разные ссылки являются разными сервисами. То есть, ночью у вас N сервисов из мониторинга пропадёт, а другие N появялся. Никакого сквозного мониторинга не ждите, это будут разные сервисы. Понятное дело, это никого не устроило. Задачка была отложена в дальний угол. Но после серии 4, где я поковырялась с мониторингом учеток в AD, до меня дошло, что экспортер - просто сервис, публикующий данные в определенном формате на веб страничке. Почему бы мне не написать свой web экспортёр с шахматами и поэтессами, который будет проверять ссылки по определённой схеме, меняя их когда надо, а публиковать данные по обрезанному кусочку ссылки типа https://srvNN/otchet к тому же с добавление каких угодно данных, которые я могу потом пихать в переменные в графане? Когда я смутно понимала задачу, то и дипсик мне решение не выдавал. А вот по ТЗ он мне наваял экспортёр на питоне, который заработал с минимальными правками. Я влюблённо посмотрела на простыню публикуемых данных и тут поняла, что чёт они медленно обновляются. Каждая ссылка - это отчёт, он формируется прям не мгновенно. От первой до последней ссылки минут 7-8 проходило. Нехорошо. В общем, "deepseek перепиши мне на async/await". И вы знаете, переписал, вообще без вопросов. А вот с дашбордом в гарафане он уже не в первый раз не справился. Пришлось ваять вручную - сводный и подробный. После чего уже было продолжение в виде "ипать оно нагрузило систему, меняй на раз в 10 минут запросы" и "а добавим вариативности, может не каждый сервис в каждом филиале, а добавим параметров", но это уже другая история. Давно я не делала что-то такое наглядно-полезное для коллег - добавляет, конечно, дофаминчика))3,26%
18 авг. 2025 г.Продолжаем про мониторинг, серия 3 из нескольких. Итак, прошлая серия закончилась на том, что я решила начать с веб-сервисов и blackbox exporter. Дальше с помощью deepseek и матерных выражений склеила два шаблона в графане во что-то приличное. Поняла, что сервисы, требующие авторизации, требуют подкручивания. Подкрутила. Дальше черёд был за алертами. Спросила нейросетку: что лучше? Она ответила: алерты графаны типа попроще и есть веб-интерфейс, а алерты от алертменеджера более гибкие в настройке, но только yaml. Честно скажу: от графановских алертов я исплевалась. Про простоту настройки - это им сильно польстили. Через пару часов свернула насилие над собой и поставила алерт-менеджер. Потом с временем реагировния, с уровнями алертов поигралась, пока не пришла к чему-то удобоваримому. Кстати, оффтопик. Как отладить работу алертов доступности (веб странички) без того, чтобы ронять сервис? Просто в hosts на сервере мониторинга прописываете типа 192.168.10.2 myservice.mydomain.ru (Меняете на любой серый адрес, которого нет в вашей сети). И всё, для мониторинга сервис недоступен. А для всех остальных пользователей ничего не поменялось. Это, конечно, не отследит какую там ошибку сервер отдаёт, когда падает, но для первичной настройки - самое то. И вот, когда я показала народу первый результат, на который можно попыриться на большом экране, начались параллельно несколько следующих этапов. Первый - следить за алертами и подкручивать "наживую" - чтоб понять, что есть "нормальная работы системы". Кстати, сразу прям стала видна ненормальная работы одной из систем, на что программеры сказали "знаем, только полностью ререписывать код, ща времени нет, некритично, терпите". Они вот знали, а кто-то и не знал.. Второй этап - написать хоть на какие-то сервисы ту самую "сопроводиловку", определив её формат. Выглядит это примерно так: сервис такой-то, общее название "окошки". Критичность низкая. Нормальные показатели: ответ 200, сертификат сроком действия больше нуля, доступность 98% в час или более 0% за 2 последних минуты. Как проверить: зайти по ссылке, должен мелким текстом показаться json такого-то вида. Валиден любой текст, кроме ошибки. Как лечить: перезапустить iis на сервере Х. Кто может починить, если не помогло? Вася П. Пока я в процессе формирования всего этого, нужно ещё обмазывать табличку в вики регламентом реакции на инциденты. Третий этап - стребовать сопроводиловку на уже заведённые в мониторинг сервисы. Ну, я их добавляла по велению души и начальника. Типа мы прикинули, помимо критичных сервисов, на что нам тут жаловались последнее время - то и загнали. Это прям самый непростой пункт - народ сопротивляется как может. Четвертый этап: эй все, присылайте сервисы с сопроводиловкой. Будем добавлять. Ну и там маленько бюрократии: создать сервис в хэлпдеске под такие заявки, например. Ещё оттестировать алерты на почту. Deepseek прям вообще не может в шаблоны алертменеджера, сразу врёт напропалую. Не сразу догадалась попросить его прямую ссылку на кусок документации - тогда и стронулось дело. На самом деле, из пройденных этапов осталось рассказать ещё про маленькую интересную задачку, ну и может пару слов про шаблоны алерт-менеджера. А потом серия продолжится уже только сильно позже, с новыми результатами.3,01%
14 нояб.Карта, часть 2/2 Так, CORS есть, данные есть, карта отобразилась. Теперь я захотела потестить изменение данных. Ну, не буду же я укладывать филиал, забанила на сервере прометеуса в iptables пару хостов. Пинга нет, а данные не меняются. Полезла в json - не меняются, полезла в прометеус, а он говорит, что пинг есть. А пинга нет, ну не глюки же уменя. Забанила помимо INPUT ещё OUTPUT - не помогло. Blackbox exporter оказывается, работает от пользователя prometheus. Всем, кто не root запрещены raw сокеты. Экспортер пробует, нет прав, запускает утилиту пинг, она обходит iptables. Мне ещё надо погуглить, чтоб понять почему (да, бывает, пробел знаний). Надо добавить экспортёру права на raw socket, вот так: stcap cap_net_raw+ep /usr/local/bin/blackbox_exporter Ура, данные в json теперь обновляются. А в графане нет, блять. Потому что графана считает json статическим объектом и не видит смысла его обновлять. И всякие добавления к ссылке в конце переменных автообнлвления не изменяют её мнение, она эти переменные не парсит и страницу не презапрашивает. В этом месте я подумала, что может быть, идея написать свой сайт с пинг-понгом и профурсетками для отображения карты не лишена привлекательности. Но мы не ищем лёгких путей. Qwen говорит, а давай добавим панель типа TEXT, в ней выберем html и всадим туда javascript с автообнолвлением станицы каждые 15 секунд! Ну, гулять так гулять, это уже, простите, вызов! Не работает. Я теперь уже умею немного в дебаг веб-страниц даже. В графане запрещён запуск скриптов по безопасности. Да, спасибо, разрешите, перезапуск графаны. Ооо, работает! Круто, зашибись, но 9 мегабайт гонять каждые 15 секунд - ну, не очень. Нужно упростить полигоны. Нашла прогу QGIS, она упрощает отлично. Пару раз тыкнула, если что, в настройках оптимизации 0,2 градуса поставила и меня устроило. 197 килобайт однако. Заодно Чукотку, которая с 2gis почему-то полостатая пришла, перерисовала с того первого json'a. Графана перестала отображать порезанный json. QGIS выпилил мне поле id и забыл добавить точки городов - скрипт не сходился, id везде стал null. Поправила. Дальше небольшая косметика, например, правильно расставить правила раскраски. Никакого встроенного Threshold там не работает. Идут правила "если, то", причем как только правило применилось, дальше они не проверяются. Есть только больше, меньше и равно. Например диапазон типа "больше 0 и меньше 0.5" задать нельзя. Поэтому порядок правил такой: 1) если == 0, то зеленый 2) если == 1, то красный 3) если больше 0.01, то желтый Тогда правильно отрабатывает. Ну и там, карту приблизить, всякое по мелочи. Итог: карта есть, красится правильно, обновляется раз в 15 секунд. Из того, что не хватает - подписи регионов всплывают только при наведении мышкой, как их отображать всегда - пока не разобралась. Автообнлвление средствами графаны бесполезно и на захардкоженные 15 секунд не влияет. В целом, симпатично. Можно задуматься о выводе разных данных и попробовать чего-нить замутить. В графане, оказывается, в бете есть geojson dynamic. И он правда динамик, не нужен костыль с обновлением страницы. Но походу в нём нельзя покрасить области по условию даже так урезанно как раньше - всаживай цвет внутрь json'a видимо. Узнала много нового. Заколебалась, но довольна) По логике, сейчас кто-то должен написать "да всё это было легко сделать вот этим встроенным инструментом в два клика" 😂2,86%
10 сент. 2025 г.Сказка со счастливым концом. Было у нас несколько стоек в ЦОД, достались по наследству. А в ЦОДе была сеть на cisco, дорого-богато. А ядром сети был nexus 7000 серии, коммутатор такой, L3, юнитов эдак на 11. И вот, отыгран тендер в стиле "замените вражеское оборудование на дружеское". Вместо nexus'a куплен другой коммутатор, две штуки, дорого-богато, на те же 11 юнитов каждый. Начинает интегратор переключать всё и говорит: "а вот тут не получится". "Вот тут" оказался blade шасси от HP, который включался в тот самый nexus. Забит он был не полностью, но 6 лезвий - это 6 лезвий, убрать их - и сильно просядет производительнось. Ща попробую рассказать по простому, а в конце дам пару ссылок. Подключалось к сети шасси хитрым образом: в нём стоит коммутационная плата, которая при подключении к cisco nexus делает магию и в цисковском коммутаторе появляется виртуальный коммутатор внутри. Ну как будто туда линейку портов ещё засунули. Магия работает только с nexus 7k и 9k. Если воткнуть эту плату в любой другой коммутатор, то линков нет, извините, вжух не работает. А других сетевых портов в HP тоже нет. Платы две - по одной на каждую половинку шасси. И вот у нас стоит высокопроизводительный коммутор размером с холодильник и работает просто L2 свичом. А надо заметить, аренда стоек в цоде не бесплатная и лишние 11 юнитов отнюдь как бы не лишние. Были дела поважнее, но настало время и мы стали думать, а что можно сделать. Если что, вот всё то, что я выше описала, мы не знали. Мы знали "в хуавей воткнуть нельзя". Расследование началось с того, что я вижу в циске 12 портов, подписанных как blade. 12 портов в up. А проводов из шасси 8. Нестыковочка. Найдено было название платы, найден документ с полным описанием. Я закопалась в описание того, как это работает и выяснила вот это всё, что вам рассказала. Нашла плату, которая вроде может быть вставлена вместо этой, подходит по форм-фактору и которая бы работала не как виртуальный коммутатор, а port-to-port. Написала всем знакомым с уточнением, а не знает ли кто, точно ли оно будет работать с любым коммутатором. Все ответили "да х.з., вроде должна". Я облазила весь даташит по этой новой плате и сказала, типа давай попробуем. Нашли у кого заказать такие платы, б/у, чтоб за бюджет не вылезти и не слишком жалко, если не взлетит. Прождали их 3 месяца из Китая. Настал тот день, когда платы пришли. Но чтоб безопасно воткнуть их - надо смигрировать с блейдов виртуалки. А места нет, пока возились кончилось. Прождали ещё три месяца пока приедет новый сервак и начали операцию. И вот мы одну плату вынули, вторую воткнули. Переставили трансиверы со старой на новую. Плата определилась. Прибили порты к лезвиям в управляшке. А линк не горит. Поменяли патч оптический, попробовали все виды трансиверов, какие были под рукой, попробовали насильно прописать скорость на коммутаторе. А линк не горит. Коллега уже закопался в дебри консоли управления шасси, я перечитала первые страницы гугла. И тут мы читаем при очередной инициализации что-то типа "ошибка определения трансивера, не поддерживается". В общем, мы - два умницы - прочитали весь даташит, кроме второй страницы, где черным по белому написано: "поддерживаются трансиверы следующих моделей". И, что характерно, все модели от hp. А в старой плате поддерживались трансиверы cisco, потому что прям на плате написано hp-cisco. Вернули всё как было и пошли искать трансивер от hp. У нас ассортимент китайщины и циски, у знакомых тоже нет дать погонять пару штук (чтоб понять, оно вообще заведётся или нет). Ушли искать, где купить 12 трансиверов от hp, желательно, чтоб по цене не как бюджет скромной африканской страны. Прождали их ещё месяц. И вот наконец сошлись все звёзды: трансиверы есть, плата завелась, линк горит, vlan прописаны, лезвия видятся. Хэппи энд, все дела! И обещанные ссылки: Старая плата Новая плата2,80%