Opensearch has been great so far, no issues ever since deploying the very initial forked version. Neither of those links seem like dealbreakers, am I missing something? Is the idea that opensearch is not usable in production because of missing autocomplete?
> Is the idea that opensearch is not usable in production
No one said it's not usable in production.
> because of missing autocomplete?
We have an operations team that wants to do searches across 200+ fields for an embedded device's logs. The engine supports it just fine, but what kind of UX is it to expect them to do manual lookups of the fields available?
People with simple use cases of course can't imagine how important discovery features are.
Of course those aren't all the parity gaps, a random sampling of the ones I banged my head against:
- No Log Stream view, also critical for observability operations with any semblance of a reasonable UX
- No wildcard type, critical for machine generated logs having sane searchability. Searches are literally broken otherwise by false negatives.
- No nested fields in visualizations, can't visualize properly structured logs.
- Can't change indexes on visualizations, need to recreate the entire visualization.
- Can't use underscores at the start of a field name.
- Doesn't support auto refreshing fields which again, is terrible for embedding device logging
Elastic moved past basic search since the days OS forked it at, and now it's a genuinely nice choice for observability.
There's a literal report I wrote on the gaps there to justify going to Elastic before giving up on our slow RFP process. Every gap no matter how small is representative of what's wrong with OpenSearch: they don't have 1/10th the incentive to actually put comparable resources to Elastic behind it.
Especially when you have people lining up to make excuses based on the fact they're clueless about the gaps between them. Literal droves of people using it to provide a middling search experience to their users just don't see anything wrong with it.
