We build our own. All events are published on Tank( https://github.com/phaistos-networks/TANK https://github.com/phaistos-networks/TANK ) , and we have a bunch

We build our own. All events are published on Tank( https://github.com/phaistos-networks/TANK https://github.com/phaistos-networks/TANK ) , and we have a bunch of consumers that consume from various Tank topics. They process the data and either publish to other Tank topics(to be consumed by other services), or they update state on various services. - For data exploration, we use memSQL. We keep the last day’s worth of data there(we DELETE rows to keep the memory footprint down), and because most of the time it’s about understanding something that has happened recently, it’s almost always sufficient. Each row contains the event’s representation as JSON, and we also have a few more columns for faster lookup. memSQL’s JSON support is great(we used mySQL for that but it was too slow), so we can take advantage of joins, aggregations, windowing etc. - For data visualisation, we use ELK (but it’s pretty slow), a tool our ops folks built (“otinanai”: https://github.com/phaistos-networks/otinanai https://github.com/phaistos-networks/otinanai) and we have a few smaller systems that generate graphs and reports. - For alerts and tickets, our ops folk built another tool that monitors all those events, filters them and executes domain-specific logic that deals with outliers, notifications routing, and more. This solves most of our needs, but we plan to improve this setup further, by monitoring even more resources and introducing more tools(Tank consumers) to get more out of our data.