Скажи, кто твой AI, и я скажу, кто ты.

Всем привет.

Популярная фраза теперь звучит так "Скажи, кто твой AI, и я скажу, кто ты." Ажиотаж вокруг AI еще тот. И он оправдан. Вы можете любить или ненавидеть  AI, но с каждым днем его все больше в вашей жизни.

Сегодня процитирю вам АІ-советы от Александра Фролова, начальника отдела информационных технологий МГУ им. адм. Г.И. Невельского.

Нейросети - это мощный инструмент для системных администраторов, который помогает экономить время и решать сложные задачи. Однако важно использовать их с умом: проверять ответы, задавать четкие вопросы и не полагаться на них полностью в критически важных ситуациях. Для сисадминов особенно полезны ChatGPT, GitHub Copilot и Claude, так как они помогают автоматизировать рутинные задачи и находить решения быстрее. 

Для сисадминов (DevOps) особенно полезны ChatGPT, GitHub Copilot и Claude, так как они помогают автоматизировать рутинные задачи и находить решения быстрее.

1. У нас нейросети часто используются в работе, особенно для рутинных задач, поиска информации или генерации идей.

Наиболее популярные инструменты:

⦁ ChatGPT (OpenAI): для генерации скриптов, анализа ошибок, поиска решений, документации.

⦁ GitHub Copilot: для помощи в написании кода и автоматизации задач.

⦁ Perplexity.ai: для поиска информации и быстрого получения ответов на технические вопросы.

⦁ Bard (Google): для сравнения ответов и поиска альтернативных решений.

⦁ Claude (Anthropic): для работы с длинными текстами, например, анализ логов или документации.

Моніторинг ресурсів в GenAI.

Привіт привіт.

Моніторинг ресурсів в GenAI так само важливий як і в інших ІТ-сферах. Особливо якщо у вас локальний GenAI. Сьогодні я покажу вам відомі розширення моніторінгу для ComfyUI та ForgeUI.

Пакет crystool.

https://github.com/crystian/ComfyUI-Crystools

Популярний монітор ресурсів в ComfyUI.

Ви можете бачити ресурси, що використовуються ComfyUI (CPU, GPU, RAM, VRAM, GPU Temp і вільний простір HDD) в рядку меню в режимі реального часу. Без особливих налаштувань, тільки вибір яку опцію показати, а яку ні.

Моя оцінка - 5 з 5.

Моменты Zabbix.

Всем привет.

Моя давняя шпаргалка по рабочим моментам Zabbix, которая скорее всего мне больше не понадобится, а вам как знать.

1) Housekeeper:

Q: Oбязательно ли параметр housekeeper открывать в конфиге Zabbix-а или молча использовать для этого настройки в GUI ?

A: В конфиге этот параметр регулирует частоту запуска houserkeeper'а, а в GUI настраивают сроки очистки данных в БД, которые очищает как раз housekeeper. Если его не запускать, очистки данных у вас не будет какие бы параметры вы не настроили в GUI.

2) Clone vs Full Clone:

Нажатие на Клонировать сохранит все параметры узла сети и все соединения с шаблонами (с сохранением всех объектов из этих шаблонов). 

Полное клонирование дополнительно сохранит все напрямую добавленные объекты (элементы данных, триггеры, графики и группы элементов данных).

Обратите внимание: при клонировании узла сети, он наследует все сущности из шаблонов, как они настроены изначально в шаблонах. Любые сделанные изменения в этих сущностях на уровне узла сети (такие как интервал опроса элементов данных, измененное регулярное выражение или добавленные прототипы к правилу низкоуровневого обнаружения) не будут скопированы в новый узел сети; они останутся так как есть в шаблоне.

3) Service:

cчитается что для мониторинга любого сервиса достаточно следить всего за 4-мя его параметрами:

• Latency -  время, которое занимает обработка запроса. Неплохо бы разделять время для корректных ответов и ошибок.
• Traffic - количество запросов, приходящих к сервису. Например, rps для http-сервисов или bandwidth для стриминга.
• Errors - запросы, обработанные с ошибками.
• Saturation - насколько заполнен сервис. Например, для диска это общий объем и занятое место.

Легкий старт з Prometheus.

Всім привіт.

Моніторинг сьогодні - фактично обов'язкова частина ІТ-інфраструктури для компанії будь-яких розмірів. Але сьогодні я не буду зупинятися на різноманітті програмного забезпечення для моніторингу, а просто покажу як легко можно дати старт такому функціоналу з одним із популярних рішень - пара на основі Prometheus плюс Grafana.

То ж щодо теорії то вам сюди, бо далі сама практика від Дениса Астахова. Піднімемо сервер Prometheus та сервер Grafana, з'єднаємо їх, та запустимо моніторинг на інші сервери.

Інсталюємо сервер Prometheus:

#!/bin/bash

#--------------------------------------------------------------------

# Script to Install Prometheus Server on Linux Ubuntu

# Tested on Ubuntu 22.04, 24.04

# Developed by Denis Astahov in 2024

#--------------------------------------------------------------------

# визначення глобальних констант

PROMETHEUS_VERSION="2.51.1"

PROMETHEUS_FOLDER_CONFIG="/etc/prometheus"

PROMETHEUS_FOLDER_TSDATA="/etc/prometheus/data"

# отримання пакету PROMETHEUS з мережі internet

cd /tmp

wget https://github.com/prometheus/prometheus/releases/download/v$PROMETHEUS_VERSION/prometheus-$PROMETHEUS_VERSION.linux-amd64.tar.gz

tar xvfz prometheus-$PROMETHEUS_VERSION.linux-amd64.tar.gz

cd prometheus-$PROMETHEUS_VERSION.linux-amd64

mv prometheus /usr/bin/

rm -rf /tmp/prometheus*

# створення теки для PROMETHEUS

mkdir -p $PROMETHEUS_FOLDER_CONFIG

mkdir -p $PROMETHEUS_FOLDER_TSDATA

# створення конфігурації для сервера PROMETHEUS

cat <<EOF> $PROMETHEUS_FOLDER_CONFIG/prometheus.yml

global:

  scrape_interval: 15s

scrape_configs:

  - job_name      : "prometheus"

    static_configs:

      - targets: ["localhost:9090"]

EOF

# визначення користувача PROMETHEUS та надання йому відповідних прав

useradd -rs /bin/false prometheus

chown prometheus:prometheus /usr/bin/prometheus

chown prometheus:prometheus $PROMETHEUS_FOLDER_CONFIG

chown prometheus:prometheus $PROMETHEUS_FOLDER_CONFIG/prometheus.yml

chown prometheus:prometheus $PROMETHEUS_FOLDER_TSDATA

# створення конфігурації PROMETHEUS як сервісу Linux

cat <<EOF> /etc/systemd/system/prometheus.service

[Unit]

Description=Prometheus Server

After=network.target

[Service]

User=prometheus

Group=prometheus

Type=simple

Restart=on-failure

ExecStart=/usr/bin/prometheus \

  --config.file       ${PROMETHEUS_FOLDER_CONFIG}/prometheus.yml \

  --storage.tsdb.path ${PROMETHEUS_FOLDER_TSDATA}

[Install]

WantedBy=multi-user.target

EOF

# запуск сервісу PROMETHEUS, перевірка його статусу, та визначення його на автозапуск

systemctl daemon-reload

systemctl start prometheus

systemctl enable prometheus

systemctl status prometheus --no-pager

prometheus --version

Мониторинг температуры в Powershell.

Всем привет.

Возвращаясь к мониторингу температуры решил я попробовать измерить сие напрямую через Powershell. Тем более что в Powershell для этого есть класс MSAcpi_ThermalZoneTemperature. 

Код функции Get-Temperature гуляет по сети не первый год:

 function Get-Temperature {

    $t = Get-WmiObject MSAcpi_ThermalZoneTemperature -Namespace "root/wmi"

    $returntemp = @()

    foreach ($i in 0..($t.Count - 1)) {

        $temperatureInstance = $t[$i]

        $currentTempKelvin = $temperatureInstance.CurrentTemperature / 10

        $currentTempCelsius = $currentTempKelvin - 273.15

        $currentTempCelsius = [math]::Round($currentTempCelsius, 2)

        $currentTempFahrenheit = (9/5) * $currentTempCelsius + 32

        $instanceName = $temperatureInstance.InstanceName

        $returntemp += "$instanceName : $currentTempCelsius C"

    }

    return $returntemp

}

Get-Temperature

А вот и ее вывод:

Invalid arithmetic operator в Zabbix.

Всем привет.

SSL (TLS) сертификаты стали важным компонентом современной инфраструктуры, поэтому администратору нужно следить за тем, чтобы они не истекали и вовремя их обновлять. Удобно отслеживать срок действия SSL сертификатов на ваших сайтах с помощью системы мониторинга Zabbix.

В ранних версиях Zabbix для мониторинга SSL сертификатов приходилось использовать консольные скрипты, которые передают значения в Zabbix через UserParameter. В Zabbix Agent 2 появись возможность получения информации о сертификате с помощью встроенного плагина WebCertificate. 

Вот здесь рассмотрены оба способа мониторинга срока действия SSL.

По второму способу скажу сразу что скрипт автора /usr/lib/zabbix/externalscripts/sslcert_expiration.sh однозначно рабочий:

#!/bin/bash

data=`echo | openssl s_client -servername $1 -connect $1:${2:-443} 2>/dev/null | openssl x509 -noout -enddate | sed -e 's#notAfter=##'`

ssldate=`date -d "${data}" '+%s'`

nowdate=`date '+%s'`

diffdate="$((${ssldate}-${nowdate}))"

echo $((${diffdate}/86400))

Кстати им же можно проверять сертификаты и на сереверах в локальной сети предприятия.

Но есть нюас.) В Linux без них никуда. При его тестировании на моем сервере Zabbix выскочил глюк на определении diffdate, что ему не делал скрипт тут падал в ошибку: «syntax error: invalid arithmetic operator (error token is «.

Решил я прибегнуть к помощи ChatGPT, сейчас это модно. Далее приведу варианты его решения которые он мне предлагал вчера вечером. Показываю только то те строки где он предлагал изменить в исходном коде для устранения ошибки:

1)

data=$(echo | openssl s_client -servername "$1" -connect "$1":${2:-443} 2>/dev/null | openssl x509 -noout -enddate | awk -F '=' '{print $2}')

2)

diffdate=$((`date -d "$ssldate" '+%s'`- `date -d "$nowdate" '+%s'`))

3)

# Using Python to calculate the difference in seconds

diffdate=$(python -c "from datetime import datetime; print(int((datetime.strptime('$data', '%b %d %H:%M:%S %Y %Z') - datetime.now()).total_seconds()))")

4)

# Retrieve the SSL certificate end date

data=$(echo | openssl s_client -servername "$1" -connect "$1":${2:-443} 2>/dev/null | openssl x509 -noout -dates | grep 'notAfter' | cut -d '=' -f 2)

5)

# Calculate the difference in seconds using 'bc' command

diffdate=$(echo "$ssldate - $nowdate" | bc)

Проверка решений своим поиском по Google привела к тем же вариантам, так что ChatGPT не соврал. Но увы, ни один из способов к успеху не привел. Видно хорошо был сформатирован код моего Zabbix appliance.

Надеюсь вам повезет больше. Удачи.

Правка состояния MS VMM.

Привет всем.

В последнее время были случаи когда в MS VMM по одному из серверов Hyper V показало что все его ВМ дружно находяться в нерабочем состоянии. Но поскольку жалоб от пользователей сервиса не поступало я понял что проблема скорее в самом отображении состояния  ВМ в VMM.

Итак первое что следовало проверить запущена ли служба "System Center Virtual Machine Manager Agent" на наблюдаемом сервере Hyper V. Если не запущена, то стартуем ее, если запущена то перезапускаем ее.

Однако вчера и это не помогло.

Тогда смотрим следующее - нередко после обновлений и ребута ОС сервера сетевой профиль падает в состояние "Общедоступный" и значок сетевого соединнеия  показывает его как "Неопознанная сеть".  Лечиться такое быстро - следует перестартовать службу "Служба сведений о подключенных сетях", она же "Network Lоcation Awareness".

После следует перестартовать службу "System Center Virtual Machine Manager Agent"  еще разок.

Если служба работает и сеть определяется правильно следует подождать пару минут пока  VMM обновит свою картинку. 

Контроль за состоянием критических служб можно возложить на Zabbix или на MS SCOM.

Удачи.

Мониторинг температуры с помощью MS SCOM.

Всем привет.

После ввода в эксплуатацию дополнительной стойки серверов НР опять подняли вопрос о контроле температуры в серверной комнате. В принципе я ее уже давно мониторю через Zabbix.

Но вчера я решил сравнить как же может с этим справиться MS System Center Operations Manager 2016 (SCOM), т.е. было решено уже в нем промониторить температуру серверной в которой находиться наш НР через  iLO SNMP.

В SCOM есть понятия монитора и правила. Это несколько разные вещи. Монитор – это некий датчик, отслеживающий изменение параметра и сигнализирующий администратору об отклонениях. Правило – визуализация значений датчика.

Как создавать монитор и правило для НР iLO SNMP рассказано здесь и здесь с рисунками.

Чтобы мониторить обьект через SNMP прежде всего необходимо знать в каком OID зашито значение температуры окружения нашей версии НР iLO. Я знаю, так как нужное значение OID уже указано в моем Zabbix:

1.3.6.1.4.1.232.6.2.6.1.0

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

1. Прежде всего необходимо добавить сетевое устройство (iLO серверa) в SCOM в "Administration/Network Management". Для этого надо определить новое Discovery Rule, или добавить изменения в существующее.

И запустить  Discovery-правило на выполнение. После успешного определения устройства сервер появится в списке сетевых устройств в "Network Devices".

Тестирование инфраструктуры с Testinfra #1.

Всем привет.

Создание модульных тестов для тестирования инфраструктуры - замечательная идея. Главное найти подхоящий инструмент с низким порогом вхождения. Я таких знаю два - это Testinfra  (Python) и Pester (Powershell). Разумеется оба бесплатны, но более простым для старта я считаю первый. Так что сегодня будет Testinfra.

С проектом Testinfra мы можем качественно улучшить наши приложения, которые мы используем в промышленной эксплуатации. Давайте выполним подключение к разным хостам и выполним несколько проверочных тестов.

Пожалуй начнем. Создайте новую виртуальную среду и активируйте ее:

$ python3 -m venv validator

$ source validator/bin/activate

Установите  pytest:

(validator) $ pip3 install pytest

Установите testinfra:

(validator) $ pip3 install pytest-testinfra

Установите paramiko:

(validator) $ pip3 install paramiko

Фикстуры pytest предоставляют всю тестовую функциональность проекта Testinfra.  Чтобы извлечь пользу из этого, вам необходимо правильно указать тип соединения. Поскольку  существуют различные типы соединений прикладных частей, то, если соединение не указано непосредственно, Testinfra использует определенные типы по умолчанию. Лучше указывать тип соединения явным образом в командной строке.

Вот список поддерживаемых Testinfra соединений на сегодня:

-local

$ py.test --sudo test_myinfra.py

-Paramiko (SSH-реализация на Python)

$ py.test --ssh-config=/path/to/ssh_config --hosts=server

-Docker;

$ py.test --hosts='docker://[user@]container_id_or_name'

-SSH;

$ py.test --ssh-config=/path/to/ssh_config --hosts='ssh://server'

-Podman;

$ py.test --hosts='podman://[user@]container_id_or_name'

-Salt;

$ py.test --hosts='salt://*'

-Ansible;

$ py.test --hosts='ansible://all' # tests all inventory hosts

-Kubernetes (через утилиту kubectl);

$ py.test --hosts='kubectl://mypod-a1b2c3'

-OpenShift;

$ py.test --hosts='openshift://mypod-a1b2c3'

-WinRM;

$ py.test --hosts='winrm://vagrant@127.0.0.1:2200?no_ssl=true&no_verify_ssl=true'

-LXC/LXD

$ py.test --hosts='lxc://container_name'

IPMI-функция мониторинга в Zabbix.

Всем привет.

IPMI (Intelligent Platform Management Interface) - интеллектуальный интерфейс управления платформой, предназначенный для автономного мониторинга и управления функциями, встроенными непосредственно в аппаратное и микропрограммное обеспечения серверных платформ. IPMI реализуется в виде отдельного контроллера сервера, который не зависит от операционной системы, BIOS, CPU севера и позволяет удаленно управлять физическим оборудованием.

Можно ли использовать функцию мониторинга IPMI в Zabbix? Можно, но предварительно надо выполнить несколько шагов по настройке IPMI, на примере НР iLO.

В НР iLO.

1. Создаем пользователя с правами администратора. С другими правами не работает (получим ошибки соединения IPMI в zabbix).

2. Активируем IPMI. По умолчанию он отключен.

В Zabbix.

1.  Нам нужно установить пакет IPMITOOL, чтобы сам Zabbix мог выполнять проверки IPMI. После используйте следующую команду, чтобы получить список доступных IPMI-датчиков на вашем устройстве iLO:

# ipmitool -I lanplus -H 192.168.1.220 -U admin -P adminpsw sensor

2. Обязательно установить StartIPMIPollers=5 в zabbix_server.conf. Перезапустить сервис Zabbix. У вас количество IPMI-полеров может быть другим.

Пользовательский интервал в Zabbix.

Всем привет.

Бывают случаи когда некий узел в Zabbix надо мониторить в зависимости от времени суток. Например если он регулярно выключается на выходные или на ночь, то и собирать лишние алерты от триггеров нет смысла. Как это можно реализовать?

Я знаю три варианта.

1. Использование функции time в условии триггера. 

Пишем условие так: item.last>0 И (item.time > 080000 И item.time < 170000) 

2. Настроить период обслуживания на ваш узел. 

Вам следует указать период обслуживания и выбрать типа обслуживания "без сбора данных". А чтобы узел не маячил на панели после надо отключить отображение обслуживаемых узлов фильтром панели.

3. И вариант с пользовательским интервалом в элементе данных.

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

- гибкие интервалы (flexible), который позволяет переопределить интервал обновления по умолчанию, 

- по расписанию (scheduling), посредством чего элемент данных может быть опрошен в конкретное время или последовательность времени.

Например если задать для гибкого интервала значение 1m с периодом "1-5,08:00-17:00" то элемент будет опрашиваться с частотой в 1 минуту только в рабочее время.

А если указать значение 0 с периодом "6-7,00:00-24:00" то элемент данных НЕ будет опрашиваться по выходным.

Выбор за вами.

Слава Украине!

Варианты обмена данными c Zabbix.

Всем привет.  

Zabbix - это популярное средство мониторинга в компьютерных сетях. Основными принципами работы программы заключается во взаимодействии сервера и агентов устанавливающиеся на хосты. В Zabbix доступны и другие инструменты, которые позволяют запускать скрипты, в том числе и Powershell. Такой подход позволяет добавлять в Zabbix нужные для вас данные или вести дополнительную аналитику получая данные с сервера. Итак, помимо штатного мониторинга из коробки существуют следующие варианты получения и отправки данных в Zabbix.

Передача данных на Zabbix-сервер:

- zabbix_sender

- UserParameter

- передача дополнительных параметров

- Discovery Rules и Item Prototype

- любой скрипт с system.run

Получение данных от Zabbix-сервера:

- получаем данные через zabbix_get

- получение данных с API.

Инструменты с помощью которых мы обмениваемся данными в  Zabbix можно разделить на серверные и клиентские. 

Из них создающиеся или хранящиеся на сервере Zabbix:

• скрипты (Scripts) -  это скрипты, которые можно использовать в веб-интерфейсе Zabbix. Визуально это пункты меню;
• External Scripts - папка обычно "/usr/lib/zabbix/externalscripts", в которую можно поместить скрипт и привязать его к какому-то хосту;
• API - HTTP интерфейс, к которому можно обращаться получая большую часть данных или создавать/редактировать существующие элементы.

И клиентские инструменты, которые чаще всего используются на клиентах:

• zabbix_sender - отдельная программа, которая отправляет данные на сервер Zabbix;
• zabbix_get - отдельная программа для получения данных с хостов, на которых установлен zabbix_agent. Обычно используется для тестирования;
• UserParameter - параметр в конфигурации агента на хосте. С помощью его так же можно отправить данные на сервер.
• system.run -  параметр в конфигурации агента на хосте. В отличие от UserParameter позволяет выполнять любой скрипт на клиенте. Хотя и для UserParameter я особых ограничений не заметил, например так UserParameter=admin.local[*],powershell -File "GetAdmins.ps1"

Еще раз про SELKS.

Всем привет.

Анализ пакетов - это ключевой компонент для реализации систем обнаружения сетевых вторжений (IDS) и для мониторинга безопасности сети. Доступны разные средства с открытым исходным кодом для обнаружения сетевых вторжений, которые обрабатывают запись пакетов для поиска известных сигнатур потенциальных сетевых вторжений и вредоносных действий. Используя функцию записи пакетов службы наблюдения за сетями, вы можете анализировать сеть для поиска вредоносных вторжений и уязвимостей.

В числе средств с открытым исходным кодом на слуху система обнаружения сетевых вторжений Suricata, которая использует наборы правил формата Snort для отслеживания сетевого трафика и создает оповещения при обнаружении подозрительных событий. Механизм Suricata является многопоточным, что позволяет еще быстрее и эффективнее выполнять анализ сетевого трафика. 

Дополнительные сведения о системе Suricata и ее возможностях можно узнать на веб-сайте https://suricata-ids.org/.

Но неплохо бы иметь под рукой также схему хранения и анализа пакетов перехваченных Suricata. Следуя принципу open source на эту роль напрашивается ELK стек. Suricata предоставляет возможность записи пакетов, которая используется для обнаружения сетевых вторжений. Suricata обрабатывает запись пакетов и формирует оповещения, если обнаруживает пакеты, соответствующие наборы правил для известных угроз. Эти предупреждения сохраняются в файле журнала на локальном компьютере. А Elastic Stack позволяет индексировать журналы, созданные Suricata, и использовать их для создания панели мониторинга в Kibana, которая визуализирует информацию из журналов для быстрого анализа потенциальных уязвимостей сети.

В принципе в интернет есть большое количество сценариев настройки среды для обнаружения сетевых вторжений с помощью Suricata и Elastic Stack. Вам будет интересно попробовать все сделать вручную и очень удобно для полного управления процессом. Как вы понимаете, я так не делал. По разным причинам. Одна из них это наличие в интернет пакета SELKS. Это тот же ELK-стек плюс Suricata, плюс еще два полезных инструмента мониторинга от компании Stamus. 

Напомню, что SELKS состоит из 6-ти компонентов:

S - Suricata IDPS - http://suricata-ids.org/

E - Elasticsearch - https://www.elastic.co/products/elasticsearch

L - Logstash - https://www.elastic.co/products/logstash

K - Kibana - https://www.elastic.co/products/kibana

S - Scirius - https://github.com/StamusNetworks/scirius

EveBox - https://evebox.org/

Макросы в Zabbix.

Всем привет.

Макросы в Zabbix могут быть удобны для умного использования. Известно что макросы в Zabbix определяются на нескольких уровнях, более локальный перекрывает предыдущий по ниспадающей:

глобальный макрос

{$PROC_NUM} = 200

Его перекрывает макрос уровня шаблона 

{$PROC_NUM} = 300

А его перекрывает макрос уровня узла сети

{$PROC_NUM} = 500

Например, можно использовать {$USER_MACROS} в качестве порогового значения для таких элементов данных как загрузка CPU, размер свободной памяти, количества процессов и т.д.

{Template OS: system.cpu.load[percpu,avg1].avg(5m)}>{$CPU_LOAD}

{Template OS: vm.memory.size[available].last(0)}<{$MEMORY_FREE}

{Template OS: proc.num[].avg(5m)}>{$PROC_NUM}

Где макрос уровня шаблона: 

{$PROC_NUM} = 300

А макрос уровня узла сети разделить по нагруженности:

- обычный узел сети

{$PROC_NUM} = 300

- сильно нагруженный узел сети

{$PROC_NUM} = 500

- менее загруженный узел сети

{$PROC_NUM} = 200

Полигон ELK.

Всем привет.

Использование rsyslog для хранения log-сообщений сетевого оборудования, и loganalyzer для их отображения, обозначило необходимость поиска, соответствующей современным требованиям, альтернативы. В результате анализа различных решений был сделан выбор в пользу open-source компонентов стека ELK. Был ли этот выбор полностью осознанным - скорее нет, ибо популярность ELK стека бьет все рекорды. Поэтому не пощупать его своими руками было бы неразумно. Тем более у меня была давняя задача разобраться с IDS SELKS изнутри, где ELK, как вы заметили, является основой.

Итак, основными элементами ELK являются: Elasticsearch (search engine – для хранения и быстрого поиска структурированных данных), Logstash (collector – для приема в различном формате данных, их фильтрации и преобразования, и последующей отправки в различные базы данных) и Kibana (инструмент для визуализации), которые и составляют акроним ELK. Это в классическом варианте исходя из названия, но в последнее время сюда активно подмешивают Filebeat, который идет как в в паре с Logstash, так и вместо него.

Подробное описание работы этих компонентов не планировалось в рамках данной статьи. Интересующая информация по стеку очень хорошо представлена на официальном сайте, в т.ч. в виде подробной документации, а также в огромном количестве статей и публикаций. Именно по ним я поднимал весь стек пошагово. За основу была взята подробная инструкция здесь, ему помагал материал отсюда и отсюда. Каждый автор решал свою практичечкую задачу поэтому мне пришлось компилировать нужное по ходу. Обычно ELK разворачивают на одном сервере  (как с SELKS), но я решил что это будет слишком просто, поэтому  в моем полигоне Elasticsearch один хост, Kibana второй хост, и Logstash+FileBeat третий. До кластера руки не дошли, но я уверен, что это будет создать не так уж и трудно.

В ходе работ было проведено: 

• установка Elasticsearch
• установка Kibana
• установка Logstash
• установка Filebeat для отправки логов в Logstash
• установка и настройка Winlogbeat
• установка плагина Filebeat для отправки netflow Cisco
• настройка безопасности и авторизация в Kibana (несколько вариантов)
• проксирование подключений к Kibana через Nginx
• автоматическая очистка индексов в elasticsearch.

А теперь мои шаги:

1) Проверить для всех хостов стека с Ubuntu 

sudo timedatectl set-timezone Europe/Kiev

sudo apt-get install --reinstall systemd

2) Установить для всех хостов ELK стека

sudo apt-get install apt-transport-https

sudo wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -

echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee -a  /etc/apt/sources.list.d/elastic-7.x.list

# Также ставим JDK for Elasticsearch (Host0) & Logstash (Host1)

sudo apt install default-jdk -y

java -version

3) Настройка Elasticsearch (Host0, IP 192.168.1.11, port 9200,9300) 

- /etc/elasticsearch/elasticsearch.yml:

network.host: 0.0.0.0 (or 192.168.1.11)

http.port: 9200

transport.host: localhost

transport.tcp.port: 9300

Варианты мониторинга температуры в серверной.

Всем привет.

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

Где же взять сами датчики темпратуры? Можно закупить специализированное оборудование типа NetPing-a, и мониторить его через Zabbix. А можно пойти по более простому пути.

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

Я например, обратил свое внимание на HP iLO, которая имеет целую матрицу тепературных датчиков по всей основной плате. И что логически оказалось - есть среди них и датчик Ambient Temperature. Получить его OID для мониторинга по SNMP в Zabbix оказалось не трудно.

После создаем график на созданную метрику.

Обновление Zabbix 4.4 до 5.0.

Всем привет. 

Историческая необходимость заставила нас пойти на апгрейд Zabbix-а до версии 5.  Но я вам настоятельно рекомендую ознакомиться со статьей одного автора прежде чем обновляться самим. Обязательно сначала прочитайте всю статью до конца, более того, загляните в комментарии к той статье, там много полезного, важные замечания, шишки и боль.

В 5-й версии очень много изменений, как в настройках, так и в интерфейсе. Обновлять без подготовки не рекомендую. Если у вас несколько серверов, начните с самого простого и незанятого.

Еще один момент  - в новых версиях часто обновляются стандартные шаблоны, но вы их не увидите при обновлении. У вас останутся работать старые версии. Новые нужно вручную переносить из свежих установок и подключать к хостам. С одной стороны это плюс, так как шаблоны зачастую меняются очень сильно. Нужен ручной контроль. А с другой стороны неудобно вручную обновлять все шаблоны, которые еще и зависимости свои имеют. 

Последний нюанс - минимальные системные требования к версии PHP для Zabbix 5 - 7.2 Так что прежде чем обновлять сам сервер мониторинга, убедитесь, что у вас стоит подходящая версия php. Обращаю ваше внимание на это ибо у меня один сервер уперся именно в версию PHP и хотя сам zabbix продолжал работать доступ к фронтенду был утерян. 

Приступаем к обновлению сервера мониторинг Zabbix версии 4.4 до 5.0. Итак имеем Centos 8 и zabbix 4.4.7.

Подключаем репозиторий версии zabbix 5.0:

# rpm -Uvh https://repo.zabbix.com/zabbix/5.0/rhel/8/x86_64/zabbix-release-5.0-1.el8.noarch.rpm

Старый репозиторий от версии 4.4 будет автоматически удален.

Очищаем и пересоздаем кэш yum:

# yum clean all

# yum makecache

Устанавливаем само обновление zabbix на сервер Centos следующей командой:

# yum upgrade zabbix-server-mysql zabbix-web-mysql zabbix-web zabbix-agent

Меняем max_connections для MySQL.

Всем привет.

При экспериментах с буфером в Zabbix получил неожиданно ошибку "...too many connections". При этом фронтенд Zabbix-а был доступен, но сам сервис благополучно отдыхал от своей работы. Оказалось что текущие настройки pooler-a Zabbix требуют себе больше количество разрешенных коннектов при доступе к базе данных MySQL. Как известно, за это отвечает параметр MySQL max_connections, который по умолчанию равен 200.

Вроде все просто - идем в файл /etc/mysql.cnf и меняем лимит подключения:

[mysqld]

max_connections = 1000

Перезапускаем сервис MySQL

systemctl restart mysql

и проверяем SQL-запросом show variables like "max_connections"; текущее значение max_connections и... понимаем что ничего не изменилось.

А дело в том что в связи с переходом Ubuntu с Upstart на Systemd с версии 15.04 и выше, не соблюдаются ограничения выставленные в /etc/security/limits.conf для системных служб. Эти ограничения теперь применяются только к пользовательским сеансам. Пределы для службы MySQL определены в файле конфигурации Systemd, который мы должны скопировать из своего местоположения по умолчанию в /etc/systemd, а затем отредактировать копию:

sudo cp /lib/systemd/system/mysql.service /etc/systemd/system/

sudo nano /etc/systemd/system/mysql.service

Добавляем следующие строки в конец файла:

LimitNOFILE=infinity

LimitMEMLOCK=infinity

И перегружаем конфигурацию Systemd с помощью:

sudo systemctl daemon-reload

Перезапускаем еще раз MySQL

systemctl restart mysql

и вот только теперь он будет подчиняться нашей директиве max_connections.

Также советуют указать большие значения параметров для max_user_connections  и max_connect_error.

Успехов.

Прячем Grafana за Nginx.

Всем привет. 

Задача №1 - спрятать Grafana за Nginx по ссылке http://myserver1. Полагаем что наш Nginx по умолчанию отдает index.html.

Переходим в папку Nginx sites-enabled:

cd /etc/nginx/sites-enabled

Создаем новую конфигурацию Nginx для Grafana:

sudo nano myserver1.conf

Название файла конфигурации точно такое же как и сайта, в моем случае "myserver1".

Указываем в нем следующее:

server {

    listen 80;

    listen [::]:80;

    server_name  myserver1;

    location / {

        proxy_pass http://localhost:3000/;

    }

}

Сохраняем и провереям созданный конфиг:

>Nginx -t 

Перезапускаем nginx:

sudo service nginx restart

sudo service nginx status

Имеем Grafana по адресу:

http://myserver1

Это хорошо работает если Grafana на отдельном сервере. Если она на том же сервер что и Zabbix,  то лучше добавить немного безопасности для Grafana. Поэтому ставим следующую задачу.

Про Algorius Net Viewer.

Всем привет.

Коллеги дали попробовать крутой инструмент - Algorius Net Viewer.

Algorius Net Viewer - это программа, которая позволит администраторам сети просматривать, управлять, контролировать, проводить инвентаризацию и получать уведомления на происходящие события. 

Одна из его основных функций - визуализация! Благодаря этому программному обеспечению мы можем удобно просматривать инфраструктуру нашей сети и легко перемещаться по ней. В этом смысле у нас есть редактор схем компьютерных сетей, и мы даже можем легко создать карту нашей сети. Кроме того, он позволяет создавать географические карты, которые позволяют размещать устройства с географической привязкой и четко видеть их географическое положение (OpenStreetMap), а также импортировать и экспортировать документ формата MS Visio.

Еще одна его функция - мониторинг с визуальным отслеживанием маршрута, в котором с интегрированным Тraceroute он покажет нам маршрут к устройству визуально на карте и в виде текста. Он также позволяет сканировать порты, а с помощью встроенной утилиты Wake-On-Lan мы можем включать компьютеры удаленно. Встроенные браузеры SNMP и WMI позволяют просматривать детальную информацию об устройствах, таблицы сетевых интерфейсов, соединений, т.е. упрощается выбор OID и написание WQL выражений для настройки мониторинга.

Algorius Net Viewer осуществлет мониторинг, используя различные протоколы и технологии: ICMP, UDP, TCP, SNMP, WMI, PowerShell, SSH, ARP, DNS, NETBIOS, HTTP(s), FTP(s), SQL, POP3, IMAP, SMTP. Это дает возможность контролировать практически любой аспект работы служб, серверов и других сетевых устройств.

Основные способы опроса (SNMP, PING, WMI) реализованы, как плагины на базе общего API. Это позволяет сторонним разработчикам расширять функционал приложения, создавая дополнительные плагины, адаптированные под собственные потребности.