Cyberflow

Мониторинг Dmesg

| Comments

Задача

Необходимо организовать централизованный сбор логов, в частности сообщений ядра dmesg и реакции на них со стороны событийного мониторинга (например nagios).

Передача сообщений ядра на сервер логов

Для передачи сообщения ядра можно использовать модуль netconsole. Он позволяет передавать сообщения журнала ядра (dmesg) на удаленный компьютер по сети, без участия пространства пользователя (например, syslogd). Для сбора данных можно использовать, например logstash.

Netconsole может быть встроен в ядро, так и загружен как модуль. Я использую загрузка модуля после загрузки системы, чтобы гарантировать, что сеть уже работает настроена.

1
2
# dmesg -n 7
# modprobe netconsole netconsole="6665@10.13.77.99/eth1,6666@10.13.77.1/d4:ae:52:cf:33:96"

Первая команда устанавливает уровень логирования для dmesg. Вторая загружает модуль netconsole с параметрами, где:

Erchef No_connect Error

| Comments

Предпосылки

Столкнулся с тем, что при большом количестве нод в chef-server версий 11.0.4 и 11.0.8 поставленных из omnibus пакетов для Ubuntu, он с большой периодичностью стал отдавать 500 Internal server error нодам при выполнении куска рецепта, который делает поиск по data_bag’ам. При изучении логов выяснилось следующее: В логах nginx’a видно, что запросы на поиск отправляются на бэкэнд erchef’а (ядро chef-server написанное на эрланге) и в ответ получаем 500:

1
192.168.1.111 - - [27/May/2014:11:45:28 +0000] "GET /search/databag1?q=id:node1&sort=X_CHEF_id_CHEF_X%20asc&start=0&rows=1000 HTTP/1.1" 500 "0.051" 36 "-" "Chef Client/11.6.0 (ruby-1.9.3-p429; ohai-6.18.0; x86_64-linux; +http://opscode.com)" "127.0.0.1:8000" "500" "0.046" "11.6.0" "algorithm=sha1;version=1.0;" "auth1" "2014-05-27T11:45:28Z" "2jmj7l5rSw0yVb/vlWAYkK/YBwk=" 1011 

Смотрим далее в логи erchef:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
=ERROR REPORT==== 27-May-2014::11:45:28 ===
webmachine error: path="/search/databag1"
{error,
    {error,function_clause,
        [{chef_wm_search,'-make_bulk_get_fun/5-lc$^1/1-2-',
             [{error,no_connections},
             <<"databag1">>],
             [{file,"src/chef_wm_search.erl"},{line,233}]},
         {chef_wm_search,fetch_result_rows,4,
             [{file,"src/chef_wm_search.erl"},{line,351}]},
         {chef_wm_search,make_search_results,5,
             [{file,"src/chef_wm_search.erl"},{line,324}]},
         {chef_wm_search,to_json,2,
             [{file,"src/chef_wm_search.erl"},{line,130}]},
         {webmachine_resource,resource_call,3,
             [{file,"src/webmachine_resource.erl"},{line,166}]},
         {webmachine_resource,do,3,
             [{file,"src/webmachine_resource.erl"},{line,125}]},
         {webmachine_decision_core,resource_call,1,
             [{file,"src/webmachine_decision_core.erl"},{line,48}]},
         {webmachine_decision_core,decision,1,
             [{file,"src/webmachine_decision_core.erl"},{line,532}]}]}}

К сожалению то, что erchef пишет в свой лог не информативно. Однако путём длительного перебора удалось понять, что проблема в соединении к базе.

Трюки с Ssh Config

| Comments

Конфиг ssh очень полезная и удобная штука. Пользуюсь им давно, но недавно открыл ещё несколько замечательных возможностей. Решил поделиться парой полезных фич и рассказать об одном маленьком лайфхаке.

Шаринг соединений

Часто бывает необходимо по работе держать много консолей с ssh на один сервер. Для упрощения такой работы (с точки зрения компьютера) в OpenSSH есть возможность шарить соединения. Т.е. если вы зашли на сервер, то в системе создается ControlSocket и все последующие соединения на этот сервер будут использовать уже созданный сокет, а не создавать новое подключение. И если при первом соединении сервер спрашивает у вас пароль, то при повторном использовании уже сокета авторизация не потребуется.

Для настройки Connection sharing необходимо добавить следующие строчки в начало конфига ssh:

1
2
ControlMaster auto
ControlPath /tmp/ssh_%h_%p_%r

Проброс соединений через сервер

Другая не менее полезная штука - это возможность настроить соединение через сервер. Т.е. вместо двух команд: ssh server1 и потом уже оттуда ssh server2, можно сразу в конфиге всё прописать и ходить одной командой.

Установка Slave Mysql-percona сервера

| Comments

Хочу сразу заметить, что способов развернуть slave сервер существует масса. Я хочу рассказать лишь об одном из них. Во-первых для себя, т.к. я часто применяю его в работе. Во-вторых для тех, у кого стоит задача по развертыванию независимого (поясню: это значит что перенос файлов базы с одного сервера на другой не подходит, как в моём случае) slave и при этом репликация производиться только над некоторыми БД, а не над всем, что есть.

Подразумевается, что уже есть мастер сервер, на котором крутятся БД и настроен для репликации.

Теперь надо сделать dump баз данных, при этом будем использовать атрибуты add-drop-database для добавление в dump строчки удаляющей базу перед её созданием и master-data для добавления информации о бин-логах и их позиции на момент создания dump’a. Так же, чтобы избежать переноса служебных баз, формируем список баз для переноса исключив из них все служебные базы mysql (в список можно добавить и другие базы по аналогии). После создания dump’a переносим его на slave сервер.

1
2
3
# DATABASE_LIST=$(mysql -NBe 'show schemas' | grep -wv 'mysql\|performance_schema\|information_schema')
# mysqldump  --databases $DATABASE_LIST --add-drop-database --master-data -u root -p > dbdump.db
# scp dbdump.db mysql-slave-host:~/

На slave сервере добавляем необходиму информацию для репликации. Это можно сделать и после развертывания dump’a. Так же я пропущу описание настройки репликации в конфигурации mysql.

1
2
# mysql
mysql> CHANGE MASTER TO MASTER_HOST='mysql-master-host', MASTER_USER='$replica_user', MASTER_PASSWORD='$slavepass';

Теперь можно залить сделанный dump и после этого включить репликацию.

1
2
3
# mysql -p < ~/dbdump.db
# mysql
mysql> slave start;

Репликация таблиц базы Chef-server

| Comments

Intro

В данной статье я расскажу как настроить два сервера chef-server версии 11 с репликацией части таблиц базы postgresql для обеспечения отказоустойчивости. Основная цель репликации это хранения данных о клиентах и нодах для прозрачного доступа нод к любому из chef серверов и возможности работы без перерегистрации. Предлагаемое opscode решение репликации данных через DRBD показалось мне не самым удобным и, главное, надёжным. По сему было принято решение искать альтернативные пути. Так как реплицировать все данные из всех таблиц нет необходимости, то было решено посмотреть в сторону skytools и londiste, которые позволяют реплицировать только определенные таблицы БД.

Однако не обошлось без сюрпризов. Opscode распространяет shef-server 11 по средствам уже собранных omnibus пакетов, в котором свой postgres 9.2. Этот постгрес собран урезанным и не работает с skytools. В итоге в этой статье будет описано как поставить chef-server из omnibus пакета на дистрибутивный postgres 9.2 и прикрутить репликацию через londiste.

Мы будем устанавливать всё на debian 7. Будет 2 сервера: chef-master и chef-slave соответственно.

Добавление репозитория; Установка postgresql 9.2

К сожалению в дистрибутивном репозитории debian нет postgresql 9.2. По этому будем использовать не родной. Добавляем репозиторий для установки postgres-a и skytools и устанавливаем на обоих серверах:

1
2
3
4
root@chef-master:~# wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -
root@chef-master:~# echo "deb http://apt.postgresql.org/pub/repos/apt/ wheezy-pgdg main" > /etc/apt/sources.list.d/postgresql.list
root@chef-master:~# aptitude update
root@chef-master:~# aptitude install skytools-modules-9.2 skytools3 skytools3-ticker skytools3-walmgr

Logstash, ротация логов в Elasticsearch

| Comments

Небольшая заметка как организовать ротацию логов, собирающихся при помощи logstash в elasticsearch.

В крон добавляем:

cat <<'EOF' > /etc/cron.daily/logstash
#!/bin/bash
logdate=$(date -d'-15 days' +"%Y.%m.%d")
curl -XDELETE "http://localhost:9200/logstash-${logdate}"
EOF

Этот скрипт будет запускаться ежедневно и удалять все логи из elasticsearch 15-дневной давности.

По мотивам статьи

Hyperdb to Wordpress

| Comments

Hyperdb - это замена стандартоного класса wpdb, позволяющая использовать несколько баз данных. В данной статье я опишу настройку hyperdb для распределенной инфраструктуры, состоящей из двух frontend серверов и двух серверов баз данных на базе дистрибутивов Debian 6, в качестве основной задачи ставилось не только распределение запросов на чтение между серверами БД, но и отслеживания отставаний слэйв сервера и, в случае отставания, чтение актуальных данных с мастера.

Настройка самих фронтендов оставим за кадром, т.к. это выходит за рамки данной статьи. Что касается серверов БД, то мы будем использовать мастер-слэйв репликацию и mk-heartbeat для отслеживания lag-ов на слэйве. Сервера геораспределены и каждый сервер БД располагается в отдельном ДЦ в паре с фронтендом. На настройке баз я остановлючь подробнее:

Настройка репликации DB:

Здесь не описано ничего принципиально нового. Используется стандартная репликация Мастер-Слэйв средствами MySql.

Все, описанные ниже команды выполнялись под пользователем root, что является не безопасным. Будьте осторожны, при работе под суперпользователем.

Устанавливаем сервер баз данных и пакет с mk-hertbeat:

1
# aptitude install mysql-server maatkit

Добавление Facebook комментариев к Octopress

| Comments

В этой небольшой статья я опишу как добавить комментарии facebook к блогу на octopress. В octopress есть поддержка комментариев с использованием disqus, но мне ближе facebook.

Для начала необходимо зарегистрировать приложение на facebook для своего блога. Когда регистрация пройдена facebook должен выдать app id. Теперь можно приступить к настройке. Добавим facebook app id и параметры отображения комментариев в файл конфигурации _config.yml

_config.yml
1
2
3
4
5
6
# Facebook comments
facebook:
  appid: 222612811167194
  num_post: 5 
  width: 789
  colorscheme: light

Следующим шагом добавим facebook javascript API на нашу страницу. Для этого можно воспользоваться уже имеющимся в octopress функционалом facebook like. И так, открываем siurce/_includes/facebook_like.html и меняем строчку содержащую js.src= заменив в ней цифры на app id полученный от facebook.

1
js.src = "//connect.facebook.net/en_US/all.js#appId=222612811167194&xfbml=1";

Теперь переходим к добавлению комментариев на страницы блога. Создаём файл source/_includes/post/facebook_comments.html и добавляем в него следующее:

facebook_comments.html
1
2
3
4
5
6
7
<noscript>Please enable JavaScript to view the comments powered by facebook</a></noscript>
<div
  class="fb-comments"
  data-href="{{ site.url }}{{ page.url }}"
  data-num-posts="{{ site.facebook.num_post }}"
  data-width="{{ site.facebook.width }}"
  data-colorscheme="{{ site.facebook.colorscheme }}" ></div>

Этот шаблон теперь можно вставлять в любое место блога, где вам хочется добавить комментарии. Осталось добавить их в посты и страницы блога. Страницы и посты строятся на основе post.html и page.html файлов из директории source/.layouts. ДОбавляем в них следующий код до или после блока кода, отвечающего за комментарии disqus:

1
2
3
4
5
6
7
8
{% if site.facebook.appid and page.comments == true %}
  <section>
    <h1>Comments</h1>
    <div id="facebook_comments" aria-live="polite">
      {% include post/facebook_comments.html %}
    </div>
  </section>
{% endif %}

В целом это всё, что необходимо для добавления комментариев. Однако есть ещ> одна полезная вещь - добавление модерации. Для этого можно добавить следующую строку в файл source/includes/custom/head.html:

1
2
3
{% if site.facebook.appid %}
<meta property="fb:app_id" content="{{ site.facebook.appid }}" />
{% endif %}

Это должно разрешить модерацию всем админ пользователям вашего преложения в facebook.

В статье использовались материалы с сайта blog.grambo.me.uk

Настраиваем сервера на Clodo через Opscode Chef

| Comments

Данная статья описывает возможность автоматической настройки виртуальных серверов (на примере хостинга clodo) с помощью chef.

Заводим аккаунт в opscode

Добавляем free хостинг на 5 серверов.

При создании необходимо скачать ключик валидотора и конфиг для knife и поместить в ~/.chef/knife.rb.

current_dir = File.dirname(__FILE__)
log_level                :info
log_location             STDOUT
node_name                "cyberflow"
client_key               "#{current_dir}/cyberflow.pem"
validation_client_name   "clodo-test-validator"
validation_key           "#{current_dir}/clodo-test-validator.pem"
chef_server_url          "https://api.opscode.com/organizations/clodo-test"
cache_type               'BasicFile'
cache_options( :path => "#{ENV['HOME']}/.chef/checksums" )
cookbook_path            ["#{current_dir}/../cookbooks"]

Далее идём в opscode, заводим клиента, и ключик для клиента кладём так же в ~/.chef/.

Github Pages, Jekyll и Custom Plugins

| Comments

Не секрет, что jekyll отличный движок для блогинга. Так же не секрет, что многие пользователи jekyll используют в качестве хостинга github pages. Однако, как всегда, есть нюансы. В случае с github pages это отсутствие поддержки custom plugins, коих для jekyll имеется в количестве. Есть масса вариантов хостить статику, но в этой статье речь пойдёт о том, как можно продолжать хоститься на github pages и использовать при этом плагины.

Собственно и в этом вопросе не обошлось без вариантов, но лично для себя я выбрал вариант, который предложил Alexandre Rademaker. Суть этого решения заключается в том, чтобы отказаться от генерации статики на стороне github, а генерить её локально. Однако красота метода заключается в том, что при этом все исходные данные продолжают находиться под контролем git-a.

Теперь по сути:

Мы будем использовать branch source для хранения сырых данных и самой начинки jekyll, тогда как в master бранче будет только статика, которая и будет раздаваться по средствам github pages.

Далее предполагается, что у нас уже есть репозиторий на github, где в мастер ветке лежит jekyll и сырые данные без статики. Теперь создаём новый branch:

$ git branch source
$ git push origin source
$ git checkout source

Теперь создаём что нам надо, добавляем плагины и т.п.

$ git status / git add / git commit

Запускаем jekyll:

$ jekyll

Всё готово для выкладки на github pages:

$ checkout master
$ cp -r _site/* . && rm -rf _site/ && touch .nojekyll
$ git status > git add > git commit
$ git push -all origin

В статье используются материалы с сайта: http://arademaker.github.com