I still have a use case for it. We're looking to make the highest performing enrichment for log ingestion possible.
https://www.elastic.co/blog/elasticsearch-data-enrichment-with-logstash-a-few-security-examples In the use case described above, we aim to enrich as close to real time as possible for log ingestion. Small, light, lookups... non blocking updates for threat and other security related feeds. We're not too concerned about misses since we need to back enrich/compare against data that has already been ingested. Thoughts? Rob On Sat, Mar 17, 2018 at 2:22 PM, dormando <dorma...@rydia.net> wrote: > Not sure how active this list is anymore :P > > Are any of you still listening users of the UDP protocol? If so, mind > reaching out to me (here or privately) to explain your use case? > > I'm thinking around some long term options with it; one is to turn it into > a compile flag, and another is to keep it (and update it with SO_REUSEPORT > and *_mmsg under linux) but restrict responses to single packet. It can > still be useful for fire-and-forget cases (ie; spraying touch's or > fetching flag keys asynchronously), but there isn't much use for it > otherwise these days. > > Thanks, > -Dormando > > -- > > --- > You received this message because you are subscribed to the Google Groups > "memcached" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to memcached+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
