Как оцениваются данные на основе журналов в Google Stackdriver?

Question

Я оцениваю решения для регистрации приложений, и я не понимаю, как оценивать стеки.

Сейчас мой протоколирование node.js apps ->fluentd server -> принимал elasticsearch ->kibana

В моих приложениях, я вхожу события в json, индивидуальный ключ на eventType поле, например,

{ 
    eventType: 'ARBITRARY_JOB_COMPLETE', 
    field2: 'etc' 
    //... 
} 

Затем, в Kibana, это тривиальное дело сделать queries на этих событиях для фильтрации/подсчета/и т. Д. и создавать информационные панели. В целом, я сейчас подсчитываю ~ 30 различных событий для панелей.

Я пытаюсь перевести это на модель ценообразования stackdriver. В соответствии с их текущим pricing page (курсива акцента является моим):

Basic Tier: $ 0,10 за время серии/месяц, и $ 1,00 за метрический дескриптор/месяц.

Чтобы понять надельное и великовозрастное обвинение, вы должны понимать, как Stackdriver использует метрические дескрипторы и временные ряды:

метрики дескриптор определяет тип метрики и любую связанную с ними метку , используемой для параметрирования метрики. Единым метрическим дескриптором может быть , отвечающий за любое количество временных рядов. Например, только один дескриптор необходим для данных временных рядов со всех ваших экземпляров VM .

временные ряды хранит данные с временными метками для комбинации метрического типа, контролируемого ресурса, такого как, например VM или базы данных, а также для любых значений меток метрика определяет. Точки данных в временные ряды истекают по истечении срока их хранения. A метрика на основе журналов - это собственный метрический дескриптор, созданный Stackdriver Регистрация. Он подсчитывает количество записей журнала, соответствующих фильтру.

Для Например, предположим, что вы есть 180 экземпляров виртуальных машин, и вы хотите, чтобы написать пользовательские измерения для каждого из них каждую минуту. Вы определяете собственный метрический дескриптор , custom.googleapis.com/my_measurement. На каждом экземпляре VM каждую минуту вы записываете точку данных в эту метрику, с указанием имени метрики и имени экземпляра виртуальной машины. Это создаст отдельный временной ряд для каждого экземпляра виртуальной машины. В Premium Tier вы использовали один временной ряд (из 500) в каждом из ваших 180 платных ресурсов и один метрический дескриптор (из 250) в вашем проекте. В базовом ярусе стоимость перегрузки для этого товара составляет $ 19,00 в месяц: $ 1,00 для метрического дескриптора и $ 18,00 для 180 временных рядов. Если вы прекратите записывать данные в метрику, все временные ряды со временем истекут, и вы останетесь с $ 1.00 за месяц за дескриптор, который вы можете удалить.

В примере рассматриваются виртуальные машины, поэтому его трудно применить к моему варианту использования. Я могу думать о 2 возможных интерпретаций:

1. Каждый eventType Рассчитываю стоит $ 1,10/месяц ($ 1 за дескриптором $ 0,10 для результирующего временного ряда). Так, 30 событий = $ 33,00/мес
2. Каждый eventType я считаю, считается отдельной time series, в результате чего в $ 1/месяц за descriptor и $ 0,10 * 30 для каждого eventType «s time-series.

Номер 2 представляется разумной интерпретацией, учитывая пример виртуальной машины (то есть 1 'дескриптор' и 180 'рядов', 1 для каждой виртуальной машины), но я знаю, что могу просто быть оптимистом в своем чтении ,

Answer 1

Я - премьер-министр в команде Stackdriver. Если я правильно понимаю - вы хотите создать метрику из фильтра, чтобы для каждого разрозненного значения EventType вы получали отдельные таймсерии.

Сегодня каждый из них будет представлять собой различный метрический дескриптор и временные ряды. Мы активно работаем над поддержкой меток, поэтому в будущем у вас может быть один метрический дескриптор с меткой eventType, чтобы вы могли получать различные таймсерии с этим единственным дескриптором.

Также обратите внимание на то, что: 1. Сегодня нет никакой платы за какие-либо метрики, основанные на логах или определяемые пользователем, в целом до конца Q1. 2. В классе Premium они будут включены до 250 метрических дескрипторов (как вы указываете выше).

Спасибо, Дипак