\c postgres

CREATE ROLE powa LOGIN PASSWORD '********************';
CREATE DATABASE powa;

GRANT SELECT ON ALL TABLES IN SCHEMA public TO powa;
GRANT SELECT ON pg_statistic TO powa;

\c powa

CREATE EXTENSION pg_stat_statements;
CREATE EXTENSION btree_gist;
CREATE EXTENSION powa;
CREATE EXTENSION pg_qualstats;
CREATE EXTENSION pg_stat_kcache;
CREATE EXTENSION hypopg;

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

Задержка (Latency)

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

Трафик (Traffic)

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

Ошибки (Errors)

Конечно, каждая команда должна следить за ошибками. Независимо от того, вызваны ли ошибки заданной вручную логикой или автономны (вроде неудавшегося HTTP-запроса), SRE-команды должны отслеживать их. Многие SRE-команды используют специальное ПО для управления инцидентами для оповещений о критических ошибках, поиска их причин и проведения работ по устранению последствий.

Насыщенность (Saturation)

Каждая команда должна следить за загруженностью своей системы. Важно задать метрику для насыщенности, которая бы означала, что сервис достиг максимума своих возможностей. Большинство сервисов начинают терять производительность еще до того, как загрузка достигнет 100%, поэтому понимание функциональности вашей собственной системы важно для определения ориентира насыщенности, который имеет смысл.

Белый шум — это причина прокрастинации, в него нас вгоняют искусственно. Если во время спецоперации военный будет в белом шуме — он труп. Именно поэтому для спецназа разработана специальная технология — солдат садится в мягкое кресло, смотрит зомбоящик и когда его сознание падает в белый шум — он получает разряд тока. Через полгода таких тренировок у бойца возникает «аллергия» на белый шум. После такого большинство людей вокруг него — жалкие сонные туши, а он — универсальная машина.

kubectl -n kubernetes-dashboard get secret
kubectl -n kubernetes-dashboard describe secrets kubernetes-dashboard-token-*

kubectl create serviceaccount --namespace kube-system tiller
kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'

$ sudo systemsetup -getremotelogin
Password:
Remote Login: On
$ sudo systemsetup -getremotelogin
Remote Login: Off

OS_DEBUG=1 TF_LOG=DEBUG terraform apply

if [ -z "$PS1" ]; then
   return
fi

git_branch() {
  git branch 2>/dev/null | grep '^*' | colrm 1 2
}

shopt -s checkwinsize

PS1='\[\033[0;32m\]\[\033[0m\033[0;32m\] \D{%H:%M:%S}\[\033[0;36m\] @ \[\033[0;36m\]\w\[\033[0;32m\] [$(git_branch)]\n\[\033[0;32m\]└─\[\033[0m\033[0;32m\] \$\[\033[0m\033[0;32m\] ▶\[\033[0m\] '

[ -r "/etc/bashrc_$TERM_PROGRAM" ] && . "/etc/bashrc_$TERM_PROGRAM"