🔔 Bash: Уведомление в Telegram при входе по SSH

Хотите знать, если кто-то (или вы сами) зашел на критический сервер? Простой скрипт, который отправляет алерт в Telegram при каждой успешной SSH-сессии.

1. Создаем скрипт /usr/local/bin/ssh-alert.sh:

#!/bin/bash
TOKEN="ВАШ_БОТ_ТОКЕН"
CHAT_ID="ВАШ_ID"
URL="https://api.telegram.org/bot$TOKEN/sendMessage"
MSG="🚨 SSH Login: $USER from $SSH_CLIENT on $(hostname) at $(date)"

curl -s -X POST $URL -d chat_id=$CHAT_ID -d text="$MSG" > /dev/null

Не забудьте: chmod +x /usr/local/bin/ssh-alert.sh

2. Добавляем в глобальный профиль: Открываем /etc/profile (сработает для всех юзеров) и добавляем в конец:

/usr/local/bin/ssh-alert.sh

Теперь, если кто-то подберет пароль или украдет ключ — вы узнаете об этом первым (и успеете дернуть рубильник).

#linux #security #ssh #telegram #scripting #monitoring

🕰 Linux: Кто убил сервер в 3 часа ночи? (atop)

Утро понедельника. Сервер перезагрузился ночью. Мониторинг показывает дырку в графиках. top и htop показывают текущую картину, где всё спокойно. Как узнать, что произошло в прошлом?

Ваш спаситель — atop. В отличие от htop, он умеет работать как демон и записывать состояние системы (снапшоты) каждые 10 минут.

Как отправиться в прошлое:

# Читаем лог за сегодня (или выберите файл за вчера)
atop -r /var/log/atop/atop_20251215

Управление машиной времени:
* t — шаг вперед на 10 минут.
* T — шаг назад.
* b — прыгнуть к конкретному времени (например, 02:55).

Вы увидите полную картину того момента: какой процесс съел CPU, закончилась ли память (OOM) или диск ушел в полку по IOPS.

Если atop не стоит, ставьте прямо сейчас. Когда сервер упадет в следующий раз, вы скажете себе спасибо.

#linux #troubleshooting #atop #monitoring #debug #logs

🐻 Uptime Kuma: Твой личный Status Page

У тебя дома крутится Home Assistant, Plex, NAS и VPN. Как узнать, что VPN упал, пока ты в кафе? Zabbix для дома — это оверхед. Поставь Uptime Kuma.

Это невероятно красивый и простой инструмент для мониторинга, который выглядит как профессиональные статус-страницы (StatusPage.io).

Что умеет: ✅ Пинговать HTTP(s), TCP, Ping, DNS. ✅ Проверять срок действия SSL-сертификатов (напомнит заранее!). ✅ Слать уведомления в Telegram, Discord, Slack. ✅ Рисовать красивые графики аптайма ("сердечный ритм").

Запуск в Docker (одной командой):

docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1

Заходи на http://localhost:3001, настрой за 5 минут и чувствуй себя спокойным.

#homelab #monitoring #uptimekuma #docker #selfhosted #tools

🛸 btop: Твой терминал — пульт управления звездолетом

Забудьте про старый добрый htop. Он хороший, но выглядит как бухгалтерская ведомость. Если вы хотите, чтобы мониторинг ресурсов выглядел так, будто вы управляете серверами Пентагона из голливудского фильма, вам нужен btop.

Почему он лучший:

Скорость: Написан на C++, работает молниеносно даже на слабых машинах.

Визуал: Графики CPU, диаграммы использования дисков, дерево процессов — всё анимировано и выглядит потрясающе.

Управление: Полная поддержка мыши! Можно кликать по процессам, чтобы убить их, или скроллить графики колесиком.

Поставьте его на второй монитор в серверной, выберите тему поярче, и любой входящий поймет — здесь работают серьезные люди.

#linux #monitoring #btop #cli #terminal #devops #cyberpunk

⚡ Netdata: Мониторинг, который устанавливается за 10 секунд

Zabbix нужно настраивать неделю. Prometheus + Grafana — три дня. А что, если нужно увидеть всё и прямо сейчас?

Ставь Netdata.

Это агент мониторинга, который не требует настройки. Вообще. Ты запускаешь одну команду, и через минуту у тебя на порту :19999 открывается дашборд уровня Бог:

* Тысячи метрик (CPU, RAM, Disks, Network, Nginx, MySQL, Docker).

* Секундная детализация (Real-time).

* Красивые темные графики, которые можно зумить мышкой.

Установка (One-liner):

wget -O /tmp/netdata-kickstart.sh https://my-netdata.io/kickstart.sh && sh /tmp/netdata-kickstart.sh

Идеально для диагностики "здесь и сейчас", когда нет времени писать конфиги, а сервер умирает.

#monitoring #netdata #devops #dashboard #tools #realtime

🪟 PowerShell: Краткая сводка происшествий за праздники

Листать Event Viewer за 10 дней выходных — это боль. Вам нужно знать только одно: были ли критические ошибки?

Скрипт, который покажет только "Красные" события (Errors & Critical) за время праздников, сгруппированные по источникам.

Команда:

# Проверяем последние 7 дней
$Date = (Get-Date).AddDays(-7)

Get-WinEvent -FilterHashtable @{LogName='System'; Level=1,2; StartTime=$Date} -ErrorAction SilentlyContinue | 
Group-Object ProviderName | 
Select-Object Count, Name | 
Sort-Object Count -Descending | 
Format-Table -AutoSize

Результат: Вы увидите таблицу вроде:

* Disk — 5 ошибок (Стоит проверить RAID!)

* TermService — 1 ошибка (Ерунда)

Экономит часы кликанья мышкой.

#windows #powershell #eventlog #audit #monitoring #scripting

⏱️ PowerShell: Сколько сервер не перезагружался?

Босс спрашивает: "Когда последний раз патчили Exchange?" или "Почему сервер тормозит, может память утекла за месяц?". Заходить на каждый сервер по RDP, чтобы открыть диспетчер задач — это путь джуна.

Скрипт Архитектора, который покажет Uptime сразу по списку машин.

Скрипт:

$Servers = "SRV-DC01", "SRV-SQL01", "PC-Admin"

foreach ($S in $Servers) {
    $OS = Get-CimInstance Win32_OperatingSystem -ComputerName $S -ErrorAction SilentlyContinue
    if ($OS) {
        $Uptime = (Get-Date) - $OS.LastBootUpTime
        Write-Host "$S : $($Uptime.Days) дн. $($Uptime.Hours) ч." -ForegroundColor Green
    } else {
        Write-Host "$S : Недоступен" -ForegroundColor Red
    }
}

Результат: SRV-DC01 : 45 дн. 12 ч. SRV-SQL01 : 0 дн. 4 ч.

Быстро, чисто, без лишних движений.

#windows #powershell #uptime #monitoring #scripting #adminlife

🐧 Linux: Load Average врёт. Смотри на PSI (Pressure Stall Information)

Админы десятилетиями смотрели на load average.
Но что значит LA 4.0 на 4-ядерном CPU?
Это процессы, которые считают?
Или те, которые ждут диск?
Или ждут память?

Load Average смешивает всё в кучу.

В современных ядрах (Linux 4.20+) есть PSI — метрика, которая показывает реальную боль системы.
Она говорит: «Процессы тупили 15% времени, потому что ждали, пока диск прочитает данные».

Куда смотреть:

/proc/pressure/cpu 
/proc/pressure/io 
/proc/pressure/memory

Как читать:

cat /proc/pressure/io 

Вывод: some avg10=0.00 avg60=0.00 avg300=0.00 total=0 Если avg10 (среднее за 10 сек) равно 20.00, значит, 20% времени ваши задачи просто висели и ждали ввода-вывода. Это точный диагноз тормозов, в отличие от размытого Load Avg.

#linux #performance #psi #kernel #monitoring #troubleshooting #sysadmin

🔍 ELK vs Loki: Как не утонуть в логах и не разорить компанию на дисках

Логи — это «черный ящик» твоего сервера. Но когда серверов 50, а контейнеров 500, смотреть их по отдельности невозможно.
Нужно решение, которое соберет всё в одну кучу и даст удобный поиск.

🏛️ ELK Stack (Elasticsearch, Logstash, Kibana)

Это «золотой стандарт» индустрии.

* Философия: Индексируем абсолютно каждое слово в каждой строке лога.
* Плюсы: Мгновенный полнотекстовый поиск. Мощнейшая аналитика и визуализация. Ты можешь найти ошибку в конкретном запросе среди миллиарда записей за доли секунды.
* Минусы: Прожорливость. Elasticsearch обожает оперативную память (RAM) и «кушает» её гигабайтами. Индексы занимают много места на диске.

Пример конфига Logstash (Input/Filter):

input {
  beats { port => 5044 }
}
filter {
  grok { match => { "message" => "%{COMBINEDAPACHELOG}" } }
}
output {
  elasticsearch { hosts => ["localhost:9200"] }
}

⚡ Grafana Loki

«Prometheus для логов». В 2026 году Loki стал выбором номер один для Kubernetes и облачных сред.

* Философия: Мы не индексируем текст. Мы индексируем только метаданные (метки: имя сервера, имя контейнера, уровень лога). Сами логи сжимаются и лежат в дешевом объектном хранилище (S3).
* Плюсы: Потребляет в 10 раз меньше ресурсов, чем Elasticsearch. Идеально интегрируется в Grafana рядом с метриками. Хранение стоит копейки.
* Минусы: Поиск по самому тексту лога (grep) медленнее, чем в ELK, так как системе приходится «на лету» распаковывать чанки данных.

Пример конфига Promtail (агент Loki):

scrape_configs:
- job_name: system
  static_configs:
  - targets: [localhost]
    labels:
      job: varlogs
      __path__: /var/log/*.log

---

📊 Что выбрать сисадмину?

| Характеристика | ELK (Elasticsearch) | Loki |
| --- | --- | --- |
| Индексация | Полный текст (Full-text) | Только метки (Labels) |
| Потребление RAM | Очень высокое | Низкое |
| Стоимость хранения | Дорого (нужны быстрые диски) | Дешево (S3/MinIO) |
| Сложность настройки | Высокая | Средняя |
| Лучшее применение | Анализ бизнес-данных, аудит | Технический мониторинг, K8s |

Вердикт Admin Future: Если тебе нужно быстро грепать логи из контейнеров и ты не хочешь тратить на сервер мониторинга больше ресурсов, чем на сами сервисы — ставь Loki. Если же ты работаешь в банке или крупном e-commerce, где нужно строить сложные дашборды по каждой транзакции — твой выбор ELK.

#logging #elk #loki #grafana #devops #sysadmin #monitoring #admin_future

🛡️ Security: Рентген для ядра. eBPF вместо гадания на логах

В 2026-м копаться в `strace` или `tcpdump` на высоконагруженном сервере — это как пытаться замерить пульс у бегущего спринтера, вставляя ему палки в колеса. Сервис либо упадет от оверхеда, либо вы утонете в гигабайтах мусора. Когда база «лагает», а сеть «тупит», нам нужны точные ответы, а не догадки.

Техническая суть:
Используем eBPF (Extended Berkeley Packet Filter). Это технология, которая позволяет запускать микропрограммы прямо внутри ядра Linux без его пересборки или загрузки модулей.

Под капотом: Мы вешаем «хуки» на системные вызовы (kprobes) или функции в пользовательском пространстве (uprobes). eBPF-программа собирает статистику в реальном времени с нулевым влиянием на производительность. Вы видите всё: от задержек записи на диск конкретным процессом до того, какой именно микросервис рвет TCP-сессию.

Практика:
Используем bpftrace, чтобы мгновенно найти, кто «насилует» диск медленными запросами (более 10 мс):

# Запускаем однострочник, который строит гистограмму задержек I/O
bpftrace -e 'kprobe:vfs_read { @start[tid] = nsecs; } 
             kretprobe:vfs_read /@start[tid]/ { 
                 $lat = (nsecs - @start[tid]) / 1000000; 
                 if ($lat > 10) { @[comm] = lhist($lat, 0, 100, 10); }
                 delete(@start[tid]); 
             }'

# На выходе получаем четкую картину:
# @[postgres]:
# [10, 20)      |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| 152
# [20, 30)      |@@@@                                | 18
# [50, 60)      |@                                   | 2

Зачем это нужно:

Обнаруживаем «невидимые» проблемы: блокировки в ядре, микро-всплески трафика или утечки дескрипторов. В эпоху Cloud-Native и сложных распределенных систем это единственный способ не сойти с ума при поиске иголки в стоге сена.

#security #ebpf #linux #performance #monitoring #admin_future

🐧 Linux: lnav — Когда логов больше, чем времени на жизнь

Привет, коллеги! Среда, 18 марта. В 2026-м наши ARM-ноды генерируют столько логов, что обычный tail -f превращается в бессмысленный поток символов, от которого рябит в глазах.

Если ты до сих пор пытаешься выцепить ошибку в консоли, просто надеясь на свою реакцию — остановись. Твои глаза заслуживают лучшего.

Используй lnav (The Log File Navigator). Это продвинутый вьювер, который понимает структуру логов «из коробки».

Почему это мастхэв:

• Слияние логов: access.log, error.log и системные логи в одной временной ленте
• Подсветка: ошибки — красным, предупреждения — желтым
• Фильтрация: нажал /, ввел паттерн — убрал шум

Установка и запуск:

sudo apt install lnav
# Открываем папку с логами
lnav /var/log/nginx/

Pro Tip: нажми i — увидишь гистограмму. Резкий красный пик = момент, когда всё сломалось.

#linux #tools #lnav #logs #monitoring #admin_future

🔋 Windows: Как не «потухнуть» вместе с ИБП

Коллеги, стабильность питания — штука капризная. Даже в самом крутом ДЦ может случиться скачок, который проверит твой ИБП (UPS) на прочность. Если твой сервер не знает, в каком состоянии его батареи, он просто «умрет» в самый неподходящий момент, оставив тебя наедине с битой файловой системой и гневными письмами от юзеров.

Используй PowerShell для контроля состояния питания. В большинстве случаев достаточно нативного WMI/CIM доступа.

Скрипт для проверки статуса (копируй и запускай):

# Получаем данные о батарее через CIM
$Battery = Get-CimInstance -ClassName Win32_Battery

if ($Battery) {
    $Status = switch ($Battery.BatteryStatus) {
        1 {"Разряжается"}
        2 {"Питание от сети (ОК)"}
        3 {"Полностью заряжена"}
        default {"Ошибка или Неизвестно"}
    }
    Write-Output "Статус ИБП: $Status"
    Write-Output "Заряд: $($Battery.EstimatedChargeRemaining)%"
} else {
    Write-Warning "ИБП не обнаружен в системе. Проверь USB/COM кабель."
}

Зачем это нужно:

Для настройки скриптов автоматического завершения работы. Если заряд падает ниже 10%, сервер должен сам потушить тяжелые базы данных и корректно выключиться, а не просто дождаться обрыва питания.

#windows #powershell #ups #monitoring #hardware #admin_future

🪟 Windows: Кто съел мою память? (PowerShell)

Коллеги, ситуация: сервер начал подтормаживать, а лезть в тяжелый Диспетчер задач через RDP лень или канал слишком узкий. Нам нужно быстро понять, какой процесс «отъел» всю оперативную память, и желательно в мегабайтах, а не в непонятных байтах.

PowerShell позволяет сделать это одной строкой, отсортировав процессы по реальному потреблению (WorkingSet).

Скрипт для поиска виновных:

# Топ-10 процессов по потреблению памяти в Мб
Get-Process | Sort-Object WorkingSet -Descending | Select-Object -First 10 Name, @{Name='RAM_MB'; Expression={[math]::round($_.WorkingSet / 1mb, 2)}} | Format-Table -AutoSize

Зачем это нужно:
Для оперативного реагирования. Ты сразу видишь, что это: утечка в браузере, разросшаяся база или «зависшее» приложение. Зная имя процесса, его можно тут же перезапустить или изучить подробнее, не тратя время на графику.

#windows #powershell #performance #monitoring #sysadmin #admin_future

🪟 Windows: Sysmon стал встроенным — и это меняет мониторинг всего флота

Коллеги, новость которая тихо пришла в марте и уже начала раскатываться — и которую стоит понять до того, как оно появится у вас само.

Microsoft интегрирует Sysmon нативно в Windows 11 и Windows Server 2025. Теперь это Optional Feature — включается стандартным механизмом ОС, обновляется через Windows Update, без ручной загрузки бинарей с Sysinternals.

Что это означает практически: существующие конфигурационные файлы из community-репозиториев (SwiftOnSecurity, sysmon-modular) поддерживаются. Event IDs, XML-конфиги, канал Microsoft-Windows-Sysmon/Operational — всё остаётся как есть.

# Включаем native Sysmon через Optional Features (WS2025 / Win11):
# Вариант 1 — через GUI:
# Settings -> System -> Optional Features -> Add feature -> Sysmon

# Вариант 2 — через PowerShell:
Add-WindowsCapability -Online -Name "Sysmon~~~~0.0.1.0"

# Проверяем статус:
Get-WindowsCapability -Online | Where-Object {$_.Name -like "*Sysmon*"}

# Применяем конфиг (синтаксис тот же что и у standalone):
sysmon -i sysmon-config.xml

# Используем готовый community-конфиг SwiftOnSecurity:
# github.com/SwiftOnSecurity/sysmon-config
Invoke-WebRequest -Uri "https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml" `
    -OutFile "sysmon-config.xml"
sysmon -c sysmon-config.xml

# Проверяем что события пишутся:
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 10 |
    Select-Object TimeCreated, Id, Message |
    Format-List

# Массовое включение через GPO + DISM:
# Computer Config -> Software Settings -> Software Installation
# или через Intune: Add feature -> Sysmon

# Ключевые Event IDs для первичного мониторинга:
# 1  — Process Create (с хэшами и командной строкой)
# 3  — Network Connection
# 7  — Image Load (подозрительные DLL)
# 10 — Process Access (lsass dump!)
# 22 — DNS Query

Важное предупреждение: если у вас уже развёрнут standalone Sysmon — возможны двойное логирование и конфликты политик. Нужно спланировать миграцию: убедиться в совместимости конфигов, скоординировать с вендором SIEM, обновить правила парсинга.

Зачем это важно:
Раньше Sysmon требовал координации установки на тысячах endpoint, управления конфигами через GPO и отдельного контроля обновлений. Нативная интеграция убирает эту операционную нагрузку — каждая машина под управлением WS2025/Win11 может иметь богатую телеметрию без дополнительных агентов.

Итог: если у тебя нет Sysmon сейчас — самое время начать. Если есть — начни планировать переход на native версию до того как она появится сама.

#windows #sysmon #security #monitoring #siem #sysadmin #admin_future

🧠 Skills: Усталость от алертов. Как Zabbix убивает вашу внимательность

Коллеги, если в вашей дежурной группе в Telegram каждый день сыпятся десятки сообщений "CPU Load is > 80%" или "Disk space < 20%", и вы их просто смахиваете, не читая — у вас серьезная проблема. Это называется Alert Fatigue (усталость от предупреждений).

В 2026 году мониторинг не должен быть логом событий. Алерт должен приходить ТОЛЬКО тогда, когда требуется немедленное действие живого человека.

Внедряем правило 3 вопросов для настройки любого триггера:

Это влияет на бизнес прямо сейчас?

Я должен бросить свой кофе и чинить это немедленно?

Если я проигнорирую это до завтрашнего утра, кто-то заметит?

Если хотя бы на один вопрос ответ "Нет" — смело переводим этот триггер в разрез инфо-дашбордов или утренних отчетов. Никаких пуш-уведомлений и красных значков.

Зачем это нужно:
Когда случится настоящий сбой (например, дропнется RAID-массив в проде), вы можете просто пропустить этот критический алерт между пятьюдесятью рядовыми сообщениями о высокой загрузке процессора на тестовом контуре. Тишина в канале мониторинга — это признак здоровой инфраструктуры и здоровой психики администратора.

#skills #monitoring #zabbix #management #sysadmin #admin_future