Тебе строить отчёты по данным из монги ?

задача такая чтоб получить по данным аналитику отчеты

дада

Есть такая тулза называется redash у нее есть коннектор к монге вроде

Это такой bi для бедных

спасибо, сейчас буду глядеть шо эта

привет всем. есть еще вот такая приблуда: https://github.com/nightw/mikoomi-zabbix-mongodb-monitoring

тарищи, а подскажите пару вопросов по монге. Как называется метрика аналог число select, как в mysql, Только в монге?

в serverStatus ТОлько delete,updateб insert

db.serverStatus()["metrics"]["commands"]["find"]

правда я не помню куда попадает findAndModify, кажется в update

Latest: 3.4.2, Stable: 3.2.12. Пришло время обновлятся до 3.4.1+: https://aphyr.com/posts/338-jepsen-mongodb-3-4-0-rc3

правда я не помню куда попадает findAndModify, кажется в update

ага. спасибо то есть find попадает в opCounters в update?

нет, find это просто команды на чтения. а findAndModify это одна команда на найти и обновить

в opcounters скорее всего ты ищешь query

"query" : 959956, "find" : { "failed" : NumberLong(0), "total" : NumberLong(959913) },

ну близко

Мне скорее нужно понять что делает база, когда я вижу рост чтения на диске и пейджфолты

%)

надо уже сесть и дописать экспортер

Мне скорее нужно понять что делает база, когда я вижу рост чтения на диске и пейджфолты

На свой страх и риск можно попробовать вот это: https://github.com/y8/mongo_collection_exporter

нужен прометей и графана

и jre7/8

и монга 3.2.10+

на 3.0.x/3.2.10- тоже почти всё будет работать, но там не будет метрик по тому как конкретной коллекцией/индексами кеш используются (wt cache usage)

у меня счетчики экспортируются в zabbix траппом, потом через плагин в графане отрисовываюится уже

забикс не умеет собирать статистику по кокнетным коллекциям/индексам afaik

а он сам не собирает, собирает скрипт, а потом уже кидает в айтемы, а из них выводит в графане

тот же серверстатус можно парсить каким-нибудь jq

там не serverStatus пасить надо

а collStats для всех коллекций

а что?

ну ок... какая разница что парсить

иначе толку от того что ты будешь знать что «монга пишет в/из кеша»

ну да, я тебе по твоим симптомам могу сказать что пишет!

это же через mongo -e"collstat()" длается все равно?

больше скажу: монга делает больше io чем может прожевать сторадж!

это же через mongo -e"collstat()" длается все равно?

нет, это делается в три этапа: получить список всех баз

потом получить список коллекций в базе

потом пройти по всем коллекциям

ну праивльно. через LLD в заббикс делаем индекс, потом каждой делаем колстат и в айтем

автообнаружение называется

и сделать db.getCollection(<name>).stats({indexDetails: 1})

а потом парсить каждый документ в стате индексов :)

можешь взять логику из экспортера

пионерам бесполезно предлагать готовое решение :)

да, я именно так и считаю кол-во записей в коллекции

но вобщем развлекайся, мне заббикс не интересен совершенно, я готов на практические вопросы ответить

да не важно, главное понять что считать

всё

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

что-то в духе ~200 метрик на коллекцию + ~200 на каждый индекс (сходу ~400)

потом разобраться в метриках и сделать себе дешборд и алерты на нужные метрики

да сделано уже, просто метрики по файнду добавлю и все. если надо фильтр включу, чтоб только нужные выгружались. Мне надо было просто понять какая метрика за find отвечает, т. к. не нашел ее а оппкаунтерах

да сделано уже, просто метрики по файнду добавлю и все. если надо фильтр включу, чтоб только нужные выгружались. Мне надо было просто понять какая метрика за find отвечает, т. к. не нашел ее а оппкаунтерах

ты меня не слушаешь

тебе от find не холодно и не жарко

тебе serverStatus() тут не поможет

ок. а что мне нужно искать?

это слишком общие метрики, которые ничего кроме «плохо/хорошо» вообще сказать не могут

нужно анализировать метрики из _каждой коллекции_

вот вижу я что растет чтение на диске, растет Iowait, есть всплески педжфолтов. Какая дальше должна быть стратегия?

минимальный набор: программа минимум (ключ wiredtiger в stats(): "cache" : { "bytes currently in the cache" : 710342011, "bytes read into cache" : 496185602, "bytes written from cache" : 161808640, "internal pages evicted" : 0, "modified pages evicted" : 14, "unmodified pages evicted" : 0 } "block-manager" : { "checkpoint size" : 194146304, "file size in bytes" : 185212928, "file bytes available for reuse" : 28672, } "cursor" : { "bulk-loaded cursor-insert calls" : 0, "create calls" : 25, "cursor-insert key and value bytes inserted" : 168862327, "cursor-remove key bytes removed" : 0, "cursor-update value bytes updated" : 0, "insert calls" : 1257539, "next calls" : 11398715, "prev calls" : 1, "remove calls" : 0, "reset calls" : 1812770, "restarted searches" : 10372, "search calls" : 466189, "search near calls" : 89095, "truncate calls" : 0, "update calls" : 0 }

более того, затык может быть в индексах

так что тебе эти данные нужно ещё по _каждому индексу_ в каждой коллекции собирать

(аргумент {indexDetails: 1})

вот вижу я что растет чтение на диске, растет Iowait, есть всплески педжфолтов. Какая дальше должна быть стратегия?

найти какая коллекция или индекс задыхается

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

но обычно по графикам сразу видно примерно что происходит

найти какая коллекция или индекс задыхается

Как понять, что она задыхается? Какие метрики смотреть в статистике?

я тебе выше скинул метрики

кеш - это про то, что коллекция влезает в кеш или нет, я правильно понимаю?

в третий раз повторяю: по всем базам, по всем коллекциям, нужно сделать db.getCollection(<name>).stats({indexDetails: 1}) и распарсить ключ wiredtiger и indexDetails (в котором ключом будет название индекса, а значением будет примерно тоже самое что в wiredtiger)

кеш - это про то, что коллекция влезает в кеш или нет, я правильно понимаю?

не только коллекция

сами документы могут и не влезать в кеш, это не страшно

(в большинстве случаев)

а вот если индексы не влезают — очень страшно

потому что на каждый запрос монга будет проезжать по дереву, а дерево частично будет на диске и оппа, мы упираемся в iops диска сходу

причём упираемся обычно худшим способом: evict modified, а это записать минимум несколько блоков на диск, а потом чтение нужного

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

ты будешь видеть три вещи