PostgreSQL посмотреть права на Sequence в бд

Для того чтобы посмотреть права выданные в бд на sequences (последовательности) нужно выполнить запрос:

SELECT relname, relacl
FROM pg_class
WHERE relkind = 'S'
AND relacl is not null
AND relnamespace IN (
SELECT oid
FROM pg_namespace
WHERE nspname NOT LIKE 'pg_%'
AND nspname != 'information_schema'
);

Документация
relkind: r = обычная таблица, i = индекс (index), S = последовательность (sequence), v = представление (view), m = материализованное представление (materialized view), c = составной тип (composite), t = таблица TOAST, f = сторонняя таблица (foreign)

0

PostgreSQL поиск недостающих индексов

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

SELECT schemaname, relname, seq_scan-idx_scan AS too_much_seq, case when
seq_scan-idx_scan>0
THEN 'Missing Index?' ELSE 'OK' END, pg_relation_size(format('%I.%I',
schemaname, relname)::regclass) AS rel_size, seq_scan, idx_scan
FROM pg_stat_user_tables
WHERE pg_relation_size(format('%I.%I', schemaname,
relname)::regclass)>100000 ORDER BY too_much_seq DESC;

Скрипт проверяет таблицы на предмет многочисленных полных сканирований (ислючая небольшие таблицы, содержащие менее 100 тыс записей, т.к. даже при наличии индексов, планировщик запросов PostgreSQL предпочитает выполнять полное сканирование таблицы — на малых таблицах это быстрее поиска по индексу). В случае если полных сканирований значительно больше сканирваний — стоит проанализировать таблицу и запросы к ней на предмет недостающих индексов.

0

Zabbix и RabbitMq — автообнаружение очередей сообщений

Данная статья описывает мониторинг только количества сообщений в очередях RabbitMq. Если вам нужен мощный комбайн для мониторинга RabbitMq «со всех сторон» лучше воспользоваться уже написанным шаблоном от jasonmcintosh.
Для решения моей задачи данный шаблон и скрипты показались избыточными и сильно нагружающими сервер ненужными лично мне проверками. Поэтому пришлось допиливать решение ниже.

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

  1. Необходимо включить web-интерфейс RabbitMq активировав плагин, который входит в дистрибутив:
    rabbitmq-plugins enable rabbitmq_management
    после этого так же станет доступен API к которому можно обращаться.
  2. Создать отдельного пользователя в rabbitmq для доступа к очередям сообщений, с разрешением только на чтение. Сделать это можно как через веб-интерфейс так и из cli:
    rabbitmqctl add_user zabbix zabbixpassword
    rabbitmqctl set_user_tags zabbix monitoring
    rabbitmqctl set_permissions -p / zabbix "" "" ".*"
  3. В конфиге zabbix агента /etc/zabbix/zabbix_agentd.conf на хосте с RabbitMq добавить ключ:
    AllowRoot=1
    и после этого перезапустить zabbix агент. Ключ позволит агенту работать из под рута и выполнять команды rabbitmqctl.

Читать далее

0

Автозагрузка putty pageant с ключами

Для запуска pageant сразу с ключами создаем ярлык для pageant.exe и в поле «Объект» после пробела вводим путь (полный путь обрамлять кавычками) до ключа .ppt. Если необходимо загрузить несколько ключей их пути разделяем пробелами. После этого при необходимости можно link добавить в автозагрузку.

0

Zabbix — несколько значений из одного файла

Задача — имеется некоторый файл, в котором значения выглядят примерно вот так:

value1 = 645;
value2 = 444;

Значения в этом файле могут изменяться любым сторонним скриптом.
Нам необходимо получить в отдельные элементы данных каждое значение — 645 и 444 в данном случае.
Читать далее

0
Запись опубликована автором в рубрике Zabbix.

Elasticsearch. Работа с curator_cli для фильтрации вывода индексов.

В прошлой статье о архивации индексов в Elasticsearch мы использовали инструмент Curator. Согласно официальной документации, Curator умеет фильтровать вывод индексов согласно заданным параметрам.

В этот рам мы рассмотрим несколько примеров фильтрации curator_cli.

Как говорилось ранее, мы использовали запрос выводящий список всех индексов старше N-дней. Рассмотрим подробнее, что делает этот запрос:

curator_cli --host localhost --port 9200 show_indices --filter_list "[{\"filtertype\":\"age\",\"source\":\"creation_date\",\"direction\":\"older\",\"unit\":\"days\",\"unit_count\":\"$DAYS\"},{\"filtertype\":\"kibana\",\"exclude\":\"True\"},{\"filtertype\":\"pattern\",\"kind\":\"regex\",\"value\":\"elastalert_status\",\"exclude\":\"True\"}]"

Мы запросили список всех индексов у Elasticsearch:

{\"filtertype\":\"age\",\"source\":\"creation_date\",\"direction\":\"older\",\"unit\":\"days\",\"unit_count\":\"$DAYS\"}

  • Параметр filtertype равный  age означает, что выборка индексов осуществляется на основе возраста(времени создания).
  • Параметр source равный creation_date — выбираем по дате создания.
  • Параметр direction равный older — этот параметр используется для определения того, являются ли индексы более старыми или младшими, чем контрольный момент времени, определяемый единицей, unit_count.
  • Параметр unit равный days — определяем параметр для unit_count. В нашем случаем мы ищем по дням (поиск возможен по другим временным единицам)
  • Параметр unit_count равный $DAYS — задаем множитель, старше кого дня ищем индексы.

Исключив из этого списка сервисный индекс .kibana в котором хранятся логи Kibana:

{\"filtertype\":\"kibana\",\"exclude\":\"True\"}

  • Параметр filtertype равный  kibana означает, что мы обращаемся к сервисному логу Kibana.
  • Параметр exclude равный True означает, что мы игнорируем данные индексы.

И исключив журнал запросов Elasticsearch:

{\"filtertype\":\"pattern\",\"kind\":\"regex\",\"value\":\"elastalert_status\",\"exclude\":\"True\"}

  • Параметр filtertype равный pattern означает, что данный тип фильтра будет перебирать список действий и сопоставлять индексы, соответствующие заданному шаблону.
  • Параметр kind равный regex — Этот параметр сообщает шаблону, что мы используем регулярное выражение.
  • Параметр value равный elastalert_status — значение kind, в нашем случаем мы обращаемся к журнал запросов Elasticsearch.
  • Параметр exclude равный True означает, что мы игнорируем данные индексы.

Немного о совмещении разных типов  filtertype

Если в Elasticsearch хранятся индексы с разным именем и назначением, то объединяя разные параметры поиска мы можем гибко фильтровать индексы.

На пример совместив filtertype pattern и age мы можем более точно выводить список индексов. Предположим в Elasticsearch два типа индексов с именами auditbeat-6.5.2-YYYY.MM.DD для хранения логов аудита и filebeat-6.2.3-YYYY.MM.DD для хранение логов сторонних сервисов.

#curator_cli --host localhost --port 9200 show_indices --filter_list "[{\"filtertype\":\"age\",\"source\":\"creation_date\",\"direction\":\"older\",\"unit\":\"days\",\"unit_count\":\"0\"},{\"filtertype\":\"kibana\",\"exclude\":\"True\"},{\"filtertype\":\"pattern\",\"kind\":\"regex\",\"value\":\"elastalert_status\",\"exclude\":\"True\"}]"

auditbeat-6.5.2-2019.02.18
auditbeat-6.5.2-2019.02.19
filebeat-6.2.3-2019.02.18
filebeat-6.2.3-2019.02.19

Объединив  filtertype pattern и age мы можем вывести отдельно список индексов auditbeat старше 1 (одного) дня:

#curator_cli --host localhost --port 9200 show_indices --filter_list "[{\"filtertype\":\"pattern\",\"kind\":\"prefix\",\"value\":\"auditbeat-\"},{\"filtertype\":\"age\",\"source\":\"creation_date\",\"direction\":\"older\",\"unit\":\"days\",\"unit_count\":\"1\"},{\"filtertype\":\"kibana\",\"exclude\":\"True\"},{\"filtertype\":\"pattern\",\"kind\":\"regex\",\"value\":\"elastalert_status\",\"exclude\":\"True\"}]"

auditbeat-6.5.2-2019.02.18

Как видим, для filtertype = pattern ми использовали регулярное выражение с шаблоном  value равному auditbeat-

Официальная документация: https://www.elastic.co/guide/en/elasticsearch/client/curator/5.5/filters.html

4+

Linux — выполнение команды в фоне

Порой возникает необходимость выполнять команду в фоне и не зависеть от происходящего в сессии. Чтобы выполнить любую задачу в фоне необходимо создать bash скрипт. В примере я запускаю tcpdump и пишу результаты в файл.

Создадим скрипт:

[root@server /]# nano script.sh

Содержимое скрипта:

#!bin/bash
tcpdump -i ens33 dst port 5332 -w dump.cap >& /dev/null &
echo $! > script.pid

В скрипте мы выполняем стандартную команду tcpdump, которая имеет вывод информации в сессию и дополнительно пишет результаты в файл. Нужно заменить на то, что необходимо лично вам. Вывод в сессию мы перенаправляем в dev/null. PID запущенного нами скрипта пишем в файл.

Делаем скрипт исполняемым:

[root@server /]# chmod +x script.sh

Запускаем скрипт:

[root@server /]# ./script.sh

PID читаем из файла:

[root@server /]# cat script.pid
115966

Когда выполнение команды нужно остановить просто убиваем процесс:

[root@server /]# kill 115966

 

1+

Elasticsearch. Архивирование индексов в Elasticsearch

Возникает ситуация, когда необходимо архивировать индексы в Elasticsearch и складывать их на бекапный сервер. 
В таком случае мы прибегнем к elasticsearch-curator,  инструменту для управления вашими индексами и снимками Elasticsearch.

Подготовительный этап ОС.

Для начала нам необходимо установить соответствующее ПО для реализации данного сценария.

Подключим репозитирий Curator [5.5]:

для YUM Repository
https://www.elastic.co/guide/en/elasticsearch/client/curator/5.5/yum-repository.html

#vim /etc/yum.repos.d/elasticsearch-curator.repo
[curator-5]
name=CentOS/RHEL 7 repository for Elasticsearch Curator 5.x packages
baseurl=https://packages.elastic.co/curator/5/centos/7
gpgcheck=1
gpgkey=https://packages.elastic.co/GPG-KEY-elasticsearch
enabled=1

для APT repository
https://www.elastic.co/guide/en/elasticsearch/client/curator/5.5/apt-repository.html

#vim /etc/apt/sources.list.d/elasticsearch-curator.list
deb [arch=amd64] https://packages.elastic.co/curator/5/debian9 stable main

Ставим пакеты curator, NFS и jq:

для Centos 7 

#yum install -y elasticsearch-curator jq nfs

для Debian\Ubuntu

#sudo apt install -y  elasticsearch-curator jq nfs

Теперь создадим общую шару, куда будут иметь доступ наши машины с elasticsearch.
Советую создавать шару на стороннем сервере, можно поднять ее сразу на архивном, и примонтировать к elastic-машинам. 

Настройка NFS (на архивном сервере):

#mkdir -p /var/nfs_elk/snapshots/repository/
#mkdir -p /var/nfs_elk/snapshots/recovery/
#mkdir -p /var/nfs_elk/elasticsearch_backup
#chmod -R 755 /var/nfs_elk/*
#vim /etc/exports
/var/nfs_elk 192.168.1.0/24(rw,sync,no_root_squash)

Монтирование шары (на elastic-машинах):

#mkdir /var/nfs_elk/
#mount -t nfs 192.168.1.10:/var/nfs_elk/ /var/nfs_elk/

Подготовительный этап Elasticsearch.

После установки пакетов и настройки шар приступим к настройки elasticsearch.
Elasticsearch необходимо объявить общую шару и зарегистрировать ее.

В конфиг Elasticsearch.yml на всех машинах добавляем информацию об общей шаре и перезапустить сервис:

#vim /etc/elasticsearch/elasticsearch.yml
path.repo: /var/nfs-elk/snapshots

#systemctl restart elasticsearch

Объявить Elasticsearch на всех машинах о папке, куда будет бекапиться индекс:

curl -XPUT 'http://127.0.0.1:9200/_snapshot/repository' -H 'Content-Type: application/json' -d '{
"type": "fs",
"settings": {
"location": "repository",
"compress": true
}
}'

Объявить Elasticsearch на всех машинах о папке, куда будут складываться временные файлы при восстановлении индекса:

curl -XPUT 'http://127.0.0.1:9200/_snapshot/recovery' -H 'Content-Type: application/json' -d '{
"type": "fs",
"settings": {
"location": "recovery",
"compress": true
}
}'

Настройка архивирования индексов Elasticsearch

Процесс архивации протекает в несколько этапов:

  • Curator выводит список индексов из Elasticsearch согласно описанным правилам.
  • Создание снапшота индекса.
  • Переносим снапшота в ранее созданную директорию repository (/var/nfs_elk/snapshots/repository/).
  • Архивация в tar.gz и перенос архива в папку с бекапами.
  • Удаление индекса и снапшота.
  • Очистка папки repository.

Пример sh скрипта:

#vim backup.sh

#!/bin/bash

DAYS=21 #Количество дней, от текущей даты, старше которого индексы будут архивироваться
SNAPSHOT_DIRECTORY="/var/nfs_elk/snapshots" #Path to snapshot index из elasticsearch.yml
BACKUP_DIR="/var/nfs_elk/elasticsearch_backup" #Папка куда будут ложиться архивные логи
REPOSITORY="repository"
LOG="/var/log/elasticsearch/elasticsearch_backup.log" #Пишем процесс архивации в лог.
DATE=`date`

#Проверим существование папки для архивов и если нет, создадим её
if ! [ -d $BACKUP_DIR ]; then
mkdir -p $BACKUP_DIR
fi

#Получаем массив индексов, которые старше $DAYS
INDICES=`curator_cli --host localhost --port 9200 show_indices --filter_list "[{\"filtertype\":\"age\",\"source\":\"creation_date\",\"direction\":\"older\",\"unit\":\"days\",\"unit_count\":\"$DAYS\"},{\"filtertype\":\"kibana\",\"exclude\":\"True\"},{\"filtertype\":\"pattern\",\"kind\":\"regex\",\"value\":\"elastalert_status\",\"exclude\":\"True\"}]"`

#Проверим, не пустой ли список
TEST_INDICES=`echo $INDICES | grep -q -i "error" && echo 1 || echo 0`

if [ $TEST_INDICES == 1 ]
then
echo "$DATE Не найдено индексов для обработки" >> $LOG
exit
else
# Составляем цикл для каждого индекса в массиве $INDICES
for i in $INDICES
do
# Создаём снапшот для индекса $i
curator_cli --timeout 600 --host localhost --port 9200 snapshot --repository $REPOSITORY --filter_list "{\"filtertype\":\"pattern\",\"kind\":\"regex\",\"value\":\"$i\"}"

# Заносим в переменную имя снапшота для индекса $i
SNAPSHOT=`curator_cli --host localhost --port 9200 show_snapshots --repository $REPOSITORY`

# Архивируем папку репозитория и складываем архив в хранилище
cd $SNAPSHOT_DIRECTORY/$REPOSITORY && tar -zcvf $BACKUP_DIR"/"$i".tar.gz" ./*

# Удаляем snapshot
curator_cli --host localhost --port 9200 delete_snapshots --repository $REPOSITORY --filter_list "{\"filtertype\":\"pattern\",\"kind\":\"regex\",\"value\":\"$SNAPSHOT\"}"

# Удаляем индекс
curator_cli --host localhost --port 9200 delete_indices --filter_list "{\"filtertype\":\"pattern\",\"kind\":\"regex\",\"value\":\"$i\"}"

# Очищаем папку репозитория
rm -rf $SNAPSHOT_DIRECTORY/$REPOSITORY/*
done
fi

Подробнее о шаблонах фильтрации в этой статье

Ключ —host с параметром localhost возможно использовать только в том случае, если мы указали elasticsearch случать этот адрес. Если elasticsearch слушает порт 9200 только на одном адресе, то указать корректные данные.

После создания скрипта, добавим его выполнение в cron каждый день в час ночь (01:00 РМ):

#crontab -e
0 1 * * * /bin/bash /root/backup.sh >> /var/log/elasticsearch/elasticsearch_backup.log

Первоисточник: https://habr.com/ru/company/true_engineering/blog/349192/

3+

Исполняем BAT скрипт без окна CMD

При выполнении скрипта неизбежно будет появляться окно CMD — что часто мешает. Поэтому при желании можно .bat вызывать внутри vbs скрипта без графического вывода вообще. Создаем файл .vbs такого содержания:

Set WshShell = CreateObject("WScript.Shell")
WshShell.Run chr(34) & "C:\my.bat" & Chr(34), 0
Set WshShell = Nothing

Путь C:\my.bat необходимо заменить на свой.

2+