add wen server monitoring post

content/post/ansible-depend-hash.md

@@ -19,7 +19,7 @@ tags:
   - {ip: &#039;127.0.0.2&#039;, domain: &#039;exemple2.com&#039;}</pre>
 
 Как видно выше &#8212; это конфиг для двух сайтов &#8212; есть переменная nginx, внутри которой находятся два хеша &#8212; собственно конфиги сайтов. Тогда мы можем запустить копирование конфига стандартными методами:
-  
+
 <!--more-->
 
 <pre class="brush: bash; gutter: true; first-line: 1; highlight: []; html-script: false">- name: Coping nginx config for sites
@@ -89,7 +89,7 @@ server {
 В общем у нас есть один когфиг nginx, который превращается в конфиг nginx для ssl когда копируется вторым. При первом обходе переменная не активна и, естественно, строки выше опускаются.
 
 Надеюсь кому-то эта заметка сможет сэкономить час-два времени.
-  
+
 P.S. WordPress почему-то сильно бьет по пробелам и табуляциям &#8212; но, думаю, все понятно и без них.
 
 &nbsp;

content/post/web-server-percentiles.md

@@ -0,0 +1,93 @@
+---
+title: 'Мониторинг времени ответов веб сервера'
+author: ctrlok
+layout: post
+date: 2016-04-18
+categories:
+  - monitoring
+tags:
+  - monitoring
+  - grafana
+---
+
+## Среднее значение и медиана.
+
+**Среднее значение** - это достаточно интересная метрика и при правильном использовании она может сказать нам много чего интересного. К сожалению, большинство людей используют её не к месту и хотят странного.
+
+Среднее получить достаточно просто: надо взять все значения за период, сложить и поделить на их количество. Для нормальных данных всё просто и работает достаточно неплохо:
+
+Предположим, нам за секунду падает 20 реквестов, каждый из которых выполняется около 0.3с (_голубая линия - среднее значение_):
+
+![](/images/mean-1.png)
+
+
+Тогда если среднее время повысится до 0.4, то мы увидим изменение среднего до 0.4, но то ли это изменение, которое мы хотим увидеть? Проблема в том, что мы увидим изменение и в том случае, если к нам придёт пользователь с медленным интернетом. Или два. И не обязательно с медленным интернетом, есть множество разных вещей, которые могут не зависеть от нашего сервера, но зависеть исключительно от пользователя. И это повысит среднее время ответа до, например, 1 секунды, не влияя на реальное положение дел.
+
+![](/images/mean-2.png)
+
+Хуже то, что даже если среднее время для нормальных пользователей вырастет, мы всё равно можем не заметить этого, так как разброс будет достаточно большой. Есть такой пример:
+
+>Предположим, что в одной комнате оказалось 19 бедняков и один миллиардер. Каждый кладёт на стол деньги — бедняки из кармана, а миллиардер — из чемодана. По $5 кладёт каждый бедняк, а миллиардер — $1 млрд (109). В сумме получается $1 000 000 095. Если мы разделим деньги равными долями на 20 человек, то получим $50 000 004,75. Это будет среднее арифметическое значение суммы наличных, которая была у всех 20 человек в этой комнате.
+
+Для более-менее точного поиска можно обратить внимание на **медиану** — число, которое определяется тем, что одна половина выборки больше него, а другая половина – меньше. То есть в примере выша медиана будет 5 долларов, а в нашем примере с веб-сервером обратно вернётся к значению около 0.3
+
+![](/images/mediana-3.png)
+
+Если мы попробуем проанализировать, что такое медиана, то поймём — это максимальное время, за которое может загружаться страница как минимум у половины пользователей. То есть у одной половины пользователей страница будет загружаться гарантированно быстрее 0.3, а у другой половины пользователей - гарантированно медленнее.
+
+Но половина пользователей – это не совсем то количество, которое мы обычно покрываем SLA. Ну по крайней мере в моей компании. Ведь если ты скажешь бизнесу: "Мы гарантируем, что время загрузки страницы будет меньше 0.3 секунды как минимум у половины пользователей", то сразу получишь в лоб вопрос об оставшейся половине.
+
+Соответственно, для получения адекватной метрики стоит узнать, для какого процента пользователей мы хотим гарантировать время загрузки страницы, и потом вычислить это значение.
+
+Например, если нам надо получить время, за которое 99 процентов пользователей гарантировано получат страницу, мы просто должны найти точку, которая больше 99 процентов и меньше 1 процента оставшихся. То есть найти **99-й перцентиль**.
+А медиана, кстати, будет 50-м перцентилем.
+
+Для нахождения перцентилей можно использовать разные средства, но если вы хотите получить метрики в приложения, то отличным выбором будет использовать [какой-то](https://github.com/github/brubeck) . [из](https://github.com/armon/statsite.git) .  [вариантов](https://github.com/vimeo/statsdaemon) . [statsd](https://github.com/etsy/statsd). В любом случае можно сохранять данные в какую-то БД и считать уже оттуда.
+
+Отбрасывая _аномальные_ метрики, мы можем вычислить как максимальное время, за которое какой-то процент пользователей гарантированно получит страницу, так и среднее значение, за которое этот же процент пользователей получает страницу. Стоит обратить внимание на то, что само по себе среднее значение всегда похоже на среднюю температуру по больнице и пусть и отображает среднее время ответа, но не передаёт представление о динамике. Так средняя температура может быть равна 35.5 градусам, если учитывать морг, и 40.1, если учитывать только реанимацию.
+
+Например, у нас есть два периода времени, 99 процентов реквестов для которых выглядят примерно так:
+
+![](/images/perc-5.png)
+
+Соответственно, среднее время загрузки страницы для 99 процентов пользователей в обоих случаях будет 0.3с, в то время как половина пользователей из второго периода будут получать страницу намного дольше. И самое плохое - что мы никак это не увидим, если будем просто смотреть на среднее значение.
+
+Поэтому если вы всё-таки хотите смотреть на среднее значение, то на него стоит смотреть только в паре с [среднеквадратичным отклонением](https://ru.wikipedia.org/wiki/%D0%A1%D1%80%D0%B5%D0%B4%D0%BD%D0%B5%D0%BA%D0%B2%D0%B0%D0%B4%D1%80%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5_%D0%BE%D1%82%D0%BA%D0%BB%D0%BE%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5), которое более-менее неплохо показывает расброс значений в выборке. Оно интерпретируется достаточно просто - чем выше значение отклонения, тем больше разброс значений. Зная среднеквадратичное отклонение, мы можем предположить, какой процент пользователей попадёт в радиус среднее значение (на графике **0**) ± среднеквадратичное отклонение (на графике **σ**)
+
+
+![](https://upload.wikimedia.org/wikipedia/commons/thumb/3/37/Standard_deviation_diagram_%28decimal_comma%29.svg/400px-Standard_deviation_diagram_%28decimal_comma%29.svg.png)
+
+
+## Осторожно с перцентилями
+
+Перцентили - достаточно удобный инструмент, и мы можем много чего сказать, вглядываясь в графики. Но стоит обратить внимание на то, что большинство TSDB агрегируют данные, а перцентили как-то очень плохо подходят для агрегации и для точных значений должны быть пересчитаны.
+
+
+Например, если в один период агрегации к нам пришло 100 запросов, для 99 процентов которых характерно время загрузки 0.3 секунды, и мы высчитали 99 перцентиль равным 0.3 секунды, а в следующий период к нам пришло два запроса, для которых 99-й перцентиль будет равен 10 секунд, то среднее значение после агрегации будет равно 5.1 секунды, в то время как если пересчитать перцентиль сразу для всех значений, то он будет равен 0.3
+
+
+![](/images/perc-4.png)
+
+_красным выделено среднее значение, а синим перцентиль для двух периодов_
+
+Поэтому перцентили надо хранить неагрегированными.
+
+Один из вариантов, как получать более-менeе точные значения и одновременно с этим иметь возможность постагрегации, - сразу писать количество запросов, которые укладываются в определённый интервал.
+
+Например, мы можем разделить все запросы по таким критериям:
+
+* меньше 0.001 секунды
+* от 0.001 до 0.05
+* от 0.05 до 0.1
+* от 0.1 до 0.15
+* ...
+* от 0.5 до 1
+* выше 1
+
+И каждый раз, когда время выполнения запроса укладывается в заданный интервал, писать его в метрику с таким же именем. Как можно предположить, такие данные будут неплохо агрегироваться, так как их можно суммировать и в итоге получать правдивые числа. Но однажды заданные интервалы не могут быть изменены без потери истории, и это существенный минус подобного подхода.
+
+## Определите кто мухи, а кто - котлеты.
+
+В любом случае для любых расчётов важно знать, как и что у вас может работать. Ни в коем случае не стоит пытаться одной метрикой покрыть весь сайт, так как у вас там наверняка много разного контента, который работает по разным законам. И если, например, у вас на каждой странице отдаётся 100 статических файлов, а один запрос динамический, то вероятнее всего этот динамический запрос будет отфильтровываться в 99-м перцентиле и оказывать мало влияния на восприятие любых других графиков.
+
+Таким образом, желательно каждый важный для бизнеса запрос покрывать своими метриками и смотреть исключительно на эти метрики, потому как именно это время показывает, сколько пользователь ждёт до итоговой загрузки страницы.