- Rust 90.8%
- HTML 7.3%
- TypeScript 1%
- HCL 0.2%
- Shell 0.2%
- Other 0.3%
a5ad540a74* aws: use caching DNS resolver for S3 HTTP client to reduce lookup churn The AWS SDK's default HTTP client resolves DNS via hyper's uncached GaiResolver, causing redundant blocking getaddrinfo lookups under high connection churn (e.g. many concurrent S3 range requests). Swap in a Hickory-based resolver with a configurable minimum TTL floor to absorb bursts while still following endpoint IP rotations. * Apply suggestions from code review Co-authored-by: Adrien Guillo <adrien.guillo@gmail.com> * aws: fall back to the OS resolver when the caching DNS resolver misses Hickory only speaks the DNS protocol (plus /etc/hosts), so endpoints resolved through other NSS sources (mDNS, LDAP, custom nsswitch.conf plugins) would otherwise fail to resolve now that it's used for all AWS service configs. * Not using hickory anymore. The main benefit of hickory is: read TTL from DNS entry, but we override that anyway + being really async. The cons was that it does not hit libc based resolve (reading hosts etc.). This commit also adds support for HTTP_PROXY. --------- Co-authored-by: Adrien Guillo <adrien.guillo@gmail.com> |
||
|---|---|---|
| .cargo | ||
| .claude/skills | ||
| .devcontainer | ||
| .github | ||
| .localstack | ||
| build/cross-images | ||
| config | ||
| distribution | ||
| docs | ||
| monitoring | ||
| quickwit | ||
| .dockerignore | ||
| .env.example | ||
| .gitattributes | ||
| .gitignore | ||
| _typos.toml | ||
| CHANGELOG.md | ||
| CLAUDE.md | ||
| CODE_OF_CONDUCT.md | ||
| CODE_STYLE.md | ||
| CONTRIBUTING.md | ||
| docker-compose.yml | ||
| Dockerfile | ||
| install.sh | ||
| LICENSE | ||
| LICENSE-3rdparty.csv | ||
| Makefile | ||
| README.md | ||
| SECURITY.md | ||
Open-source search engine for observability (logs, traces, and soon metrics!).
Quickstart | Docs | Tutorials | Chat | Download
We just released Quickwit 0.8! Read the blog post to learn about the latest powerful features!
Quickwit is the fastest search engine on cloud storage. It's the perfect fit for observability use cases
- Log management
- Distributed tracing
- Metrics support is on the roadmap
🚀 Quickstart
- Search and analytics on Stack Overflow dataset
- Trace analytics with Grafana
- Distributed tracing with Jaeger
💡 Features
- Full-text search and aggregation queries
- Elasticsearch-compatible API, use Quickwit with any Elasticsearch or OpenSearch client
- Jaeger-native
- OTEL-native for logs and traces
- Schemaless or strict schema indexing
- Schemaless analytics
- Sub-second search on cloud storage (Amazon S3, Azure Blob Storage, Google Cloud Storage, …)
- Decoupled compute and storage, stateless indexers & searchers
- Grafana data source
- Kubernetes ready - See our helm-chart
- RESTful API
Enterprise ready
- Multiple data sources Kafka / Kinesis / Pulsar native
- Multi-tenancy: indexing with many indexes and partitioning
- Retention policies
- Delete tasks (for GDPR use cases)
- Distributed and highly available* engine that scales out in seconds (*HA indexing only with Kafka)
📑 Architecture overview
- Architecture overview
- Log management
- Distributed traces
📕 Documentation
📚 Resources
🙋 FAQ
How can I switch from Elasticsearch or OpenSearch to Quickwit?
Quickwit supports a large subset of Elasticsearch/OpenSearch API.
For instance, it has an ES-compatible ingest API to make it easier to migrate your log shippers (Vector, Fluent Bit, Syslog, ...) to Quickwit.
On the search side, the most popular Elasticsearch endpoints, query DSL, and even aggregations are supported.
The list of available endpoints and queries is available here, while the list of supported aggregations is available here.
Let us know if part of the API you are using is missing!
If the client you are using is refusing to connect to Quickwit due to missing headers, you can use the extra_headers option in the node configuration to impersonate any compatible version of Elasticsearch or OpenSearch.
How is Quickwit different from traditional search engines like Elasticsearch or Solr?
The core difference and advantage of Quickwit is its architecture built from the ground to search on cloud storage. We optimized IO paths, revamped the index data structures and made search stateless and sub-second on cloud storage.
How does Quickwit compare to Elastic in terms of cost?
We estimate that Quickwit can be up to 10x cheaper on average than Elastic. To understand how, check out our blog post about searching the web on AWS S3.
What license does Quickwit use?
Quickwit is open-source under the Apache License, Version 2.0 - Apache-2.0.
Is it possible to set up Quickwit for a High Availability (HA)?
HA is available for search, for indexing it's available only with a Kafka source.
🤝 Contribute and spread the word
We are always thrilled to receive contributions: code, documentation, issues, or feedback. Here's how you can help us build the future of log management:
- Start by checking out the GitHub issues labeled "Good first issue". These are a great place for newcomers to contribute.
- Read our Contributor Covenant Code of Conduct to understand our community standards.
- Create a fork of Quickwit to have your own copy of the repository where you can make changes.
- To understand how to contribute, read our contributing guide.
- Set up your development environment following our development setup guide.
- Once you've made your changes and tested them, you can contribute by submitting a pull request.
✨ After your contributions are accepted, don't forget to claim your swag by emailing us at hello@quickwit.io. Thank you for contributing!
💬 Join Our Community
We welcome everyone to our community! Whether you're contributing code or just saying hello, we'd love to hear from you. Here's how you can connect with us: