Обхід обмеження токенів в ChatGPT.

Всім привіт.

Як обійти обмеження токенів та проблеми зберігання історії чатів користувача в ChatGPT? 

ChatGPT автоматично реєструє кожен ваш запит. Ці записи використовуються для подальшого вдосконалення моделі та, можливо, для навчання майбутніх моделей OpenAI. Користувач не може отримати доступ до всіх цих записів. Однак, як обговорювалося раніше, обмежена кількість чатів (запитань і відповідей) зберігається в робочому списку лівої частини інтерфейсу користувача ChatGPT. Щоб найкращим чином використовувати обмежене доступне простір, ви можете видаляти чати, які вам не потрібні для зберігання, копіювати або експортувати дані для зберігання в іншому місці або попросити ChatGPT узагальнити діалог.

ChatGPT пам'ятає, що ви раніше запитували в тому ж чаті, і оперує цим під час спілкування, але тільки до певного моменту. Зокрема, модель пам'ятає до 3000 слів або 4000 токенів діалогу. Вона не може посилатися на інші діалоги, незалежно від того, чи це були раніше діалоги декілька хвилин чи тижнів тому.

Як вже зазначалося, ChatGPT розбиває ваш запит на токени. Проте токени не обов'язково складаються з цілого слова, оскільки пропуски та інша інформація також можуть міститися в токені. OpenAI радить розробникам розглядати токени як "фрагменти слів". Англійська мова більш лаконічна, ніж багато інших мов, і зазвичай вимагає менше токенів для обробки запитань англійською мовою. Нижче подано кілька способів представлення вимірювання токенів в англійській мові:

• 1 токен приблизно дорівнює 4 символам.
• 100 токенів приблизно перетворюються в 75 слів.
• два речення складають приблизно 30 токенів.
• типовий абзац становить близько 100 токенів.
• стаття з 1500 слів коштує приблизно 2048 токенів.

Токени використовуються в розрахунках вартості, а також в обмеженнях вхідних і вихідних даних в ChatGPT. Залежно від моделі штучного інтелекту, весь діалог (чат) від введення до виведення обмежений 4097 токенами. Таким чином, якщо ваш запит дуже довгий, скажімо, 4000 токенів, відповідь, яку ви отримаєте, буде обрізана на 97 токенах, навіть якщо це середина речення.

Мониторинг температуры с помощью 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".

Пользовательский интервал в 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" то элемент данных НЕ будет опрашиваться по выходным.

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

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

Еще раз про 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/

Оптимизация ELK стека.

Всем привет.

Как любая сложная система ELK стек нуждается в оптимизации своей работы, т.е. настроек по умолчанию. Для нормальной работы ELK стека приведенные ниже рекомендации по оптимизации работы Elasticsearch будут одинаково справедливы как для кластерной схемы так и без нее. Что же следует сделать?

1) Установить размер heap size.

Так как Elasticsearch написан на Java, то для работы необходимо настроить размер «кучи» (heap size).  В каталоге установки Elasticsearch имеется файл jvm.options, в котором уже указаны размеры, по умолчанию - это 1 Гб. Однако, для настройки рекомендуется указать новые параметры в файле каталога jvm.options.d, который находится там же.

-Xms16g

-Xmx16g

Пример выше использует минимальный Xms и максимальный Xmx размер heap size, равный 16 Гб. Для настройки данных параметров следует использовать следующие рекомендации:

- установите значения Xmx и Xms не более 50% от имеющейся физической памяти узла. Оставшуюся память Elasticsearch будет использовать для других целей. Чем больше heap size, тем меньше памяти используется под системные кеш. JVM и память: чем больше тем лучше? Не всегда.

Xmx & Xms <= 31Gb

- устанавите значение не более того значения, которое использует JVM для сжатия указателей, он же compressed object pointers. Данное значение составляет около 32 Гб. Стоит также отметить, что рекомендуется ограничивать heap size еще одним параметром JVM, а именно zero-based compressed oops (обычно размер около 26 Гб). 

2) Отключить подкачку.

Подкачка негативно сказывается на производительности и стабильности работы Elasticsearch, ведь система может выгрузить страницы JVM на диск.

Есть несколько вариантов работы с подкачкой:

1. Полное отключение подкачки. Перезапуск Elasticseach при этом не требуется.

sudo swapoff -a

2. Ограничение подкачки через значение vm.swappiness=1 для sysctl.

3. Использование mlockall для блокировки адресного пространства в оперативной памяти.

Чтобы включить mlockall в конфигурации Elasticseach elasticsearch.yml указываем для параметра bootstrap.memory_lock значение true:

bootstrap.memory_lock: true

Перезапускаем Elasticsearch и проверяем настройки через запрос к любому узлу:

curl -X GET "http://192.168.1.10:9200/_nodes?filter_path=**.mlockall&pretty"

Если перезапуск Elasticsearch завершился ошибкой вида:

[1] bootstrap checks failed

[1]: memory locking requested for elasticsearch process but memory is not locked

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

1. Установите значение параметра MAX_LOCKED_MEMORY как unlimited в /etc/sysconfig/elasticsearch для rpm или /etc/default/elasticsearch для dep.

2. Если вы используете systemd для запуска Elasticsearch, то лимиты должны быть указаны через настройку параметра LimitMEMLOCK. Для этого выполните команду:

sudo systemctl edit elasticsearch

и укажите следующее значение:

[Service]

LimitMEMLOCK=infinity

Обновление 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

RunAsDate - манипулируем временем.

Всем привет.

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

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

В обшем то перевод системного времени может негативно повлиять на многое на вашем ПК, т.е. ваш эксперимент того явно не стоит. Поэтому для таких экспериментов и существует  утилита  RunAsDate.

RunAsDate - это маленькая утилита, позволяющая вам устанавливать дату и время для программы. RunAsDate не меняет текущей даты и времени на вашем ПК, она всего лишь устанавливает желаемую дату и время для программы. Вы можете запускать множество приложений одновременно, и каждое приложение будет работать с разными датами и временем, в то время как дата и время вашей системы остаются без изменений.

Как это работает?

RunAsDate перехватывает сигналы ядра API, которые возвращают ткущую дату и время ((GetSystemTime, GetLocalTime, GetSystemTimeAsFileTime) и заменяет текущую дату/время на указанные вами.

Ускоряем Ansible #1.

Всем привет.

Рано или поздно возникает потребность в ускорении выполнения сценариев Ansible. 

Для реализации этого есть несколько путей:

-мультиплексирование SSН, 

-конвейерный режим, 

-кэширование фактов, 

-параллельное выполнения задач, 

-асинхронное выполнения задач.

Рассмотрим их подробнее. В подготовке статьи использовались материалы из книги "Запускаем Ansible" авторов Мозер Р. и Хоштейн Л., 2018.

#1 Мультиплексирование SSH и ControlPersist.

Вы знаете, что в качестве основного транспортного механизма Ansible использует протокол SSH. Поскольку протокол SSH работает поверх протокола TCP, вам потребуется установить новое TCP-соединение с удаленной машиной. Клиент и сервер должны выполнить начальную процедуру установки соединения, прежде чем начать выполнять какие-то фактические действия. Эта процедура занимает некоторое время, хоть и небольшое. Во время выполнения сценариев Ansible устанавливает достаточно много SSH-соединений, например для копирования файлов или выполнения команд. Каждый раз Ansible устанавливает новое SSH-соединение с хостом.

OpenSSH - наиболее распространенная реализация SSH и SSH-клиент по умолчанию, который установлен на вашей локальной машине, если вы работаете в Linux или Mac OS X. OpenSSH поддерживает вид оптимизации с названием мультиплексирование каналов SSH, который также называют ControlPersist. Когда используется мультиплексирование, несколько SSH-сеансов с одним и тем же хостом использует одно и то же TCP-соединение, то есть ТСР­-соединение устанавливается лишь однажды.

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

- при первом подключении к хосту OpenSSH устанавливает основное соединение;

- OpenSSH создает сокет домена Unix (управляющий сокет), связанный с удаленным хостом;

- при следующем подключении к хосту вместо нового ТСР­-подключения OpenSSH использует контрольный сокет.

Основное соединение остается открытым в течение заданного пользователем интервала времени, а затем закрывается SSH-клиентом. По умолчанию Ansible устанавливает интервал, равный 60 секундам.

Zabbix performance tuning #2.

Всем привет.

Сегодня я хочу продолжить тему оптимизации производительности Zabbix. На это раз пройдемся по разделам книги «Zabbix Performance Tuning» от Luciano Alves, издательство Packt Publishing, 2015. Это материал подготовил Евгений Каменев три года тому. С тех пор ничего более подробного на эту тему я не встречал. Так что продолжим.

Zabbix - это платформа, которая состоит из трех компонентов:

1.Сервер Zabbix.

2.База данных Zabbix.

3.Фронтенд Zabbix.

Но в тему оптимизации следует включить еще два дополнительных пункта:

4.Оптимизация операционной системы Linux.

5. Мониторинг состояния Zabbix.

Далее рассмотрим каждый пункт последовательно.

1.Оптимизация Zabbix-сервера.

Использование активных Zabbix-agent проверок вместо пассивных Zabbix-agent проверок (уменьшает нагрузку на Zabbix-сервер и количество TCP-соединений).

При этом на Zabbix-агенте, возможно,есть смысл увеличить дефолтные значения параметров.

Ниже приведены дефолтные значения

BufferSend=5

BufferSize=100

На Zabbix-сервере необходимо увеличить количество процессов Zabbix-trapper, которые принимают входящие соединения активных агентов, Zabbix-sender и активных прокси.

Использование наименее дорогого с точки зрения чтения/записи базы данных типа элемента данных - (numeric(unsigned),numeric (float), character, text, log).

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

Использовать наименее дорогого с точки зрения нагрузки процессора триггера - (функции last(), nodata(), min(), max(), avg())

Например, функции min/max/avg сильнее нагружают процессор в отличии от функций last и nodata.

Время хранения данных в таблицах history,trends,events.

Уменьшаем время хранения истории с дефолтных 90 дней на 7 дней (при создании элемента данных)

Время хранения в таблице trends оставляем дефолтное 365 дней (при создании триггера)(если нет необходимости в просмотре информации за год,то сокращаем время хранения тенденций)

Время хранения событий, генерируемых триггерами, можно уменьшить с дефолтных 365 дней, чтобы не увеличивать размер таблицы events при частых колебаниях/срабатывании триггеров.

Zabbix performance tuning #1.

Hi everybody.

Today I would like to present some ideas about Zabbix performance tuning. The main feature of problem with Zabbix can too many processes by graphs:
- zabbix poller processes more than 75% busy
- zabbix unreachable poller processes more than 75% busy

1. The device that collects data through Zabbix agent is in the state of monitoring, but the machine crashes or other reasons cause the zabbix agent to die. The server cannot obtain data, and the unreachable poller will rise.

2. The device that collects data through Zabbix agent is in the monitoring state, but the server takes too long to obtain data from the agent, often exceeding the server or even the timeout time, at this time the unreachable poller will increase.

So, this article is recopied from the "Gong Xiaoyi" blog, please be sure to keep this source http://gongxiaoyi.blog.51cto.com/7325139/1825492