Что хотим решить (все решаем через систему vector.dev и адаптеров к ней):
- Хотим собирать из многих точек поступающие потоки данных логирования, событий, метрик в базы данных, для разных целей в разные базы данных (распределенный вариант или централизованный, а чем лучше/хуже по сравнению с другими решениями на других инструментах )
- Хотим не просто скидывать данные в хранилище, но и предварительно обрабатывать для ускорения чтения и расчетов (возможности и особенности приемников из "коробки")
- Не хотим много писать кода для "подружить" (возможности источников и их особенности)
- Хотим понятный "внутренний голос" (возможности, плюсы и минусы встроенных языков Lua и VRL для описания преобразования данных, особенности обработки данных внутри системы)
- Не хотим конфигурировать через код - даешь декларативный подход! (Описание того, на сколько просто и быстро можно составить сложный граф обработки данных через файлы конфигурации)
- Но и не хотим привязываться к конкретной базе данных или сборщику логов, генератору метрик, событий (Особенности написания адаптеров/коннекторов к системе)
- Хотим управлять "этим" через API! (особенности API системы при конфигурировании системы)
- Не хотим расти только вертикально, можем расти и горизонтально! (различные комбинации агентов/агрегаторов - плюсы и минусы)
- И хочется и колется, и Kafka не велит! (Иногда хочется гарантировать доставку данных до конечной точки, но так система усложняется, что возможно игра не стоит свеч)
- А через что "лить" будем? (UDP, TCP, HTTP(S) - рассмотрим плюсы и минусы, возможности, особенности адаптеров)
- А как на это смотрит отдел К6? (https://github.com/grafana/k6 - по полной нагрузим систему)
- Хлеба и зрелищ! (посмотрим на собранные в prometheus.io графики через grafana)
- Ничего не понятно, но очень интересно. Выводы об использование в своей архитектуре vector.dev