> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/on-premise/ru/on-premise/how-to-guide/troubleshooting/tracking-data-export.md). # Экспорт данных мониторинга Экспортируйте необработанные данные мониторинга из базы данных Navixy On-Premise. Описаны как организация базы данных по структуре бакетов, так и файловая организация с примерами SQL-запросов. По мере работы устройств мониторинга их данные отправляются в базу данных платформы Navixy и сохраняются в ней, поэтому вы можете просматривать поездки в мониторинге и создавать отчеты по поездкам. Однако могут возникнуть ситуации, когда необходимо выгрузить всю записанную информацию мониторинга в виде точек геолокации. Обычно это необходимо для анализа данных в спорных ситуациях. В этом случае вы можете запросить такую информацию непосредственно из базы данных. {% hint style="info" %} Этот метод позволяет получать данные в более подробном и «техническом» виде, чем в мониторинге. Однако важно понимать, что для появления в базе данных данные должны быть фактически переданы устройством мониторинга, и восстановить таким способом поездки, полностью отсутствующие в мониторинге, не получится. {% endhint %} Вам потребуется **прямой доступ к базе данных MySQL** для получения данных мониторинга, что означает, что ваши клиенты не имеют прав на выполнение этой операции, а необходимые полномочия есть только у технических специалистов с доступом к серверу. Данные мониторинга хранятся в ***мониторинга*** базе данных. В зависимости от того, когда и как был развернут экземпляр вашей платформы, возможны два принципиально разных способа организации структуры базы данных. * **Структура с бакетами**. В этом случае данные мониторинга разделяются на несколько бакетов (по умолчанию — 16). * **Пофайловая структура**, где каждый трекер соответствует отдельной таблице, названной по его IMEI. Тип организации данных, который вы используете, легко проверить, просто открыв каталог хранения файлов базы данных — например, в Linux это `/var/lib/mysql/Мониторинг` по умолчанию. Внутри вы найдете либо файлы, разбитые на разделы, с именами вида `bucket_****.ibd`, или несколько `ibd` и `frm` файлы, названные по IMEI устройства. {% hint style="danger" %} Не существует общепринятого способа перевести базу данных из пофайлового хранения в бакеты или наоборот, поскольку для этого пришлось бы перестраивать всю базу данных. После развертывания база данных продолжает существовать в своей первоначальной структуре. {% endhint %} ## Структура с бакетами Это современный способ организации базы данных, при котором для оптимизации производительности данные хранятся не в отдельных таблицах для каждого трекера, а в так называемых бакетах. По умолчанию их 16, трекеры помещаются в них случайным образом. У каждого трекера есть свой `storage_id`, по которому можно найти нужный бакет. Чтобы запросить данные, вам нужен IMEI трекера (в этом примере мы используем фиктивный IMEI 987654321012345), а также внутренний идентификатор устройства под названием `source_id`. Узнайте `source_id` и `storage_id` с помощью этого запроса: ``` SELECT storage_id, source_id FROM google.sources WHERE source_imei='987654321012345'; ``` Полученный `storage_id` начинается с номера бакета — от 1 до 16. Например, *storage\_id=**2**01000* означает *bucket\_**2*** и *storage\_id=**13**01000* означает *bucket\_**13***. В следующем запросе нам нужны и номер бакета, и source\_id. С помощью этого запроса мы запрашиваем данные мониторинга за нужный период и выгружаем их в CSV-файл. Обратите внимание: * мы используем `source_id` и `бакет` номер, найденный предыдущим запросом. * `get_time` — это время записи данных устройством, оно указывается в UTC+0 независимо от часового пояса учетной записи пользователя. * У MySQL должны быть права на запись в папку, указанную в запросе. Сам SQL-запрос выглядит следующим образом: ``` SELECT 'ID','ID трека','Время сервера','Время трекера','Долгота','Широта','Скорость','Высота','Спутники','Статус','Курс','ID события','Длительность','Пробег','Входы','Выходы','Адрес' UNION ALL SELECT id, track_id, actual_time, get_time, lng, lat, speed, alt, satellites, status, heading, event_id, duration, Пробег, input_status, output_status, address FROM Мониторинг.bucket_2 where source_id=12345 and get_time between '2024-07-20 20:11:00' and '2024-07-20 20:13:00' INTO OUTFILE "/var/lib/mysql-files/987654321012345.csv" ПОЛЯ РАЗДЕЛЯЮТСЯ ',' Заключены в '"' строки Завершаются '\n'; ``` Для Windows путь выглядит так: ``` В файл "C:/ProgramData/MySQL/MySQL Server 8.0/Uploads/987654321012345.csv" ``` ## Пофайловая структура Это более старый способ организации структуры базы данных, который, однако, остается актуальным для многих экземпляров Navixy с многолетней историей. Чтобы запросить данные в этом случае, вам нужен только IMEI трекера (в этом примере мы используем фиктивный IMEI 987654321012345). Обратите внимание: * `get_time` — это время записи данных устройством, оно указывается в UTC+0 независимо от часового пояса учетной записи пользователя. * У MySQL должны быть права на запись в папку, указанную в запросе. SQL-запрос выглядит так: ``` SELECT 'ID','ID трека','Время сервера','Время трекера','Долгота','Широта','Скорость','Высота','Спутники','Статус','Курс','ID события','Длительность','Пробег','Входы','Выходы','Адрес' UNION ALL SELECT id, track_id, actual_time, get_time, point_y, point_x, speed, altitude, satellites, status, heading, event_id, duration, Пробег, input_status, output_status, address FROM Мониторинг.987654321012345 where get_time between '2024-07-20 20:11:00' and '2024-07-20 20:13:00' INTO OUTFILE "/var/lib/mysql-files/987654321012345.csv" ПОЛЯ РАЗДЕЛЯЮТСЯ ',' Заключены в '"' строки Завершаются '\n'; ``` Для Windows путь выглядит так: ``` В файл "C:/ProgramData/MySQL/MySQL Server 8.0/Uploads/987654321012345.csv" ``` ## Вывод данных Приведенный выше SQL-запрос сгенерирует CSV-файл, содержащий все точки мониторинга, записанные для устройства. Этот файл можно импортировать в Excel или использовать в любой внутренней разработке. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://navixy.com/docs/on-premise/ru/on-premise/how-to-guide/troubleshooting/tracking-data-export.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.