8682dbaabc
Bumps [zod](https://github.com/colinhacks/zod) from 3.22.2 to 3.22.3. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/colinhacks/zod/releases">zod's releases</a>.</em></p> <blockquote> <h2>v3.22.3</h2> <h2>Commits:</h2> <ul> <li>1e23990bcdd33d1e81b31e40e77a031fcfd87ce1 Commit</li> <li>9bd3879b482f139fd03d5025813ee66a04195cdd docs: remove obsolete text about readonly types (<a href="https://redirect.github.com/colinhacks/zod/issues/2676">#2676</a>)</li> <li>f59be093ec21430d9f32bbcb628d7e39116adf34 clarify datetime ISO 8601 (<a href="https://redirect.github.com/colinhacks/zod/issues/2673">#2673</a>)</li> <li>64dcc8e2b16febe48fa8e3c82c47c92643e6c9e3 Update sponsors</li> <li>18115a8f128680b4526df58ce96deab7dce93b93 Formatting</li> <li>28c19273658b164c53c149785fa7a8187c428ad4 Update sponsors</li> <li>ad2ee9ccf723c4388158ff6b8669c2a6cdc85643 2718 Updated Custom Schemas documentation example to use type narrowing (<a href="https://redirect.github.com/colinhacks/zod/issues/2778">#2778</a>)</li> <li>ae0f7a2c15e7741ee1b23c03a3bfb9acebd86551 docs: update ref to discriminated-unions docs (<a href="https://redirect.github.com/colinhacks/zod/issues/2485">#2485</a>)</li> <li>2ba00fe2377f4d53947a84b8cdb314a63bbd6dd4 [2609] fix ReDoS vulnerability in email regex (<a href="https://redirect.github.com/colinhacks/zod/issues/2824">#2824</a>)</li> <li>1e61d76cdec05de9271fc0df58798ddf9ce94923 3.22.3</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|---|---|---|
| .changeset | ||
| .github | ||
| .husky | ||
| .vscode | ||
| .yarn/releases | ||
| docker | ||
| packages | ||
| .env | ||
| .gitattributes | ||
| .gitignore | ||
| .kodiak.toml | ||
| .nvmrc | ||
| .prettierignore | ||
| .prettierrc | ||
| .yarnrc | ||
| CONTRIBUTING.md | ||
| docker-compose.ci.yml | ||
| docker-compose.dev.yml | ||
| docker-compose.yml | ||
| LICENSE | ||
| Makefile | ||
| nx.json | ||
| package.json | ||
| README.md | ||
| version.sh | ||
| yarn.lock | ||
HyperDX
HyperDX helps engineers figure out why production is broken faster by centralizing and correlating logs, metrics, traces, exceptions and session replays in one place. An open source and developer-friendly alternative to Datadog and New Relic.
Documentation • Chat on Discord • Live Demo • Bug Reports • Contributing
- 🕵️ Correlate end to end, go from browser session replay to logs and traces in just a few clicks
- 🔥 Blazing fast performance powered by Clickhouse
- 🔍 Intuitive full-text search and property search syntax (ex.
level:err) - 🤖 Automatically cluster event patterns from billions of events
- 📈 Dashboard high cardinality events without a complex query language
- 🔔 Set up alerts in just a few clicks
{Automatic JSON/structured log parsing- 🔭 OpenTelemetry native
Additional Screenshots
📈 Dashboards
🤖 Automatic Event Pattern Clustering
🖥️ Session Replay & RUM
Spinning Up HyperDX
The HyperDX stack ingests, stores, and searches/graphs your telemetry data. After standing up the Docker Compose stack, you'll want to instrument your app to send data over to HyperDX.
You can get started by deploying a complete stack via Docker Compose. After cloning this repository, simply start the stack with:
docker compose up -d
Afterwards, you can visit http://localhost:8080 to access the HyperDX UI.
If your server is behind a firewall, you'll need to open/forward port 8080, 8000 and 4318 on your firewall for the UI, API and OTel collector respectively.
We recommend at least 4GB of RAM and 2 cores for testing.
Enabling Self-instrumentation/Demo Logs
To get a quick preview of HyperDX, you can enable self-instrumentation and demo
logs by setting the HYPERDX_API_KEY to your ingestion key (go to
http://localhost:8080/team after creating your
account) and then restart the stack.
This will redirect internal telemetry from the frontend app, API, host metrics and demo logs to your new HyperDX instance.
ex.
HYPERDX_API_KEY=<YOUR_INGESTION_KEY> docker compose up -d
If you need to use
sudofor docker, make sure to forward the environment variable with the-Eflag:HYPERDX_API_KEY=<YOUR_KEY> sudo -E docker compose up -d
Changing Hostname and Port
By default, HyperDX app/api will run on localhost with port 8080/8000. You
can change this by updating HYPERDX_APP_** and HYPERDX_API_** variables in
the .env file. After making your changes, rebuild images with
make build-local.
Hosted Cloud
HyperDX is also available as a hosted cloud service at hyperdx.io. You can sign up for a free account and start sending data in minutes.
Instrumenting Your App
To get logs, metrics, traces, session replay, etc into HyperDX, you'll need to instrument your app to collect and send telemetry data over to your HyperDX instance.
We provide a set of SDKs and integration options to make it easier to get started with HyperDX, such as Browser, Node.js, and Python
You can find the full list in our docs.
OpenTelemetry
Additionally, HyperDX is compatible with OpenTelemetry, a vendor-neutral standard for instrumenting your application backed by CNCF. Supported languages/platforms include:
- Kubernetes
- Javascript
- Python
- Java
- Go
- Ruby
- PHP
- .NET
- Elixir
- Rust
(Full list here)
Once HyperDX is running, you can point your OpenTelemetry SDK to the
OpenTelemetry collector spun up at http://localhost:4318.
Contributing
We welcome all contributions! There's many ways to contribute to the project, including but not limited to:
- Opening a PR (Contribution Guide)
- Submitting feature requests or bugs
- Improving our product or contribution documentation
- Voting on open issues or contributing use cases to a feature request
Motivation
Our mission is to help engineers ship reliable software. To enable that, we believe every engineer needs to be able to easily leverage production telemetry to quickly solve burning production issues.
However, in our experience, the existing tools we've used tend to fall short in a few ways:
- They're expensive, and the pricing has failed to scale with TBs of telemetry becoming the norm, leading to teams aggressively cutting the amount of data they can collect.
- They're hard to use, requiring full-time SREs to set up, and domain experts to use confidently.
- They requiring hopping from tool to tool (logs, session replay, APM, exceptions, etc.) to stitch together the clues yourself.
We're still early on in our journey, but are building in the open to solve these key issues in observability. We hope you give HyperDX a try and let us know how we're doing!
Open Source vs Hosted Cloud
HyperDX is open core, with most of our features available here under an MIT license. We have a cloud-hosted version available at hyperdx.io with a few additional features beyond what's offered in the open source version.
Our cloud hosted version exists so that we can build a sustainable business and continue building HyperDX as an open source platform. We hope to have more comprehensive documentation on how we balance between cloud-only and open source features in the future. In the meantime, we're highly aligned with Gitlab's stewardship model.
Frequently Asked Questions
How to suppress all logs from HyperDX itself ?
To suppress logs of a service, you can comment out the HYPERDX_API_KEY
environment variable in the docker-compose.yml file. The alternative is to set
the HYPERDX_LOG_LEVEL environment variable to 'error' to only log errors.