{ "componentChunkName": "component---src-templates-issues-tsx", "path": "/issues/235", "result": {"data":{"issuesJson":{"id":"4f50429d-6d25-5213-ae90-99177b4acffc","title":"hyperdxio/hyperdx: 一个开源可观察性平台，统一会话重放、日志、指标、跟踪和错误","number":235,"bodyHTML":"

\n

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

Repos	hyperdxio/hyperdx
Views	$\"views\"$
Stars	$\"stars\"$
Forks	$\"forks\"$
License	$\"license\"$
UpdatedAt	$\"last-commit\"$
CreatedAt	$\"create-at\"$

\n\n

\n

\n

\n

\n \n \n \n $\"hyperdx$ \n \n \n

\n

\n

HyperDX

\n

HyperDX helps engineers quickly figure out why production is
\nbroken by centralizing and correlating logs, metrics, traces, exceptions
\nand session replays in one place. An open source and developer-friendly
\nalternative to Datadog and New Relic.

\n

\n Documentation • Chat on Discord • Live Demo • Bug Reports • Contributing\n

\n

🕵️ Correlate end to end, go from browser session replay to logs and traces in
\njust a few clicks
🔥 Blazing fast performance powered by Clickhouse
🔍 Intuitive full-text search and property search syntax (ex. level:err)
⏱️ Monitor health and performance from HTTP requests to DB queries (APM)
🤖 Automatically cluster event patterns from billions of events
📈 Dashboard high cardinality events without a complex query language
🔔 Set up alerts on logs, metrics, or traces in just a few clicks
{ Automatic JSON/structured log parsing
🔭 OpenTelemetry native

\n
\n

\n

Additional Screenshots

\n

\n

📈 Dashboards

\n $\"Dashboard\"$ \n

\n

\n

🤖 Automatic Event Pattern Clustering

\n $\"Event$ \n

\n

\n

🖥️ Session Replay & RUM

\n $\"Event$ \n

\n

Spinning Up HyperDX

\n

The HyperDX stack ingests, stores, and searches/graphs your telemetry data.
\nAfter standing up the Docker Compose stack, you'll want to instrument your app
\nto send data over to HyperDX.

\n

You can get started by deploying a complete stack via Docker Compose. After
\ncloning this repository, simply start the stack with:

\n

docker compose up -d

\n

Afterwards, you can visit http://localhost:8080 to access the HyperDX UI.

\n

\n
If your server is behind a firewall, you'll need to open/forward port 8080,
\n8000 and 4318 on your firewall for the UI, API and OTel collector
\nrespectively.
\n

\n

\n
We recommend at least 4GB of RAM and 2 cores for testing.
\n

\n

Enabling Self-instrumentation/Demo Logs

\n

To get a quick preview of HyperDX, you can enable self-instrumentation and demo
\nlogs by setting the HYPERDX_API_KEY to your ingestion key (go to
\nhttp://localhost:8080/team after creating your
\naccount) and then restart the stack.

\n

This will redirect internal telemetry from the frontend app, API, host metrics
\nand demo logs to your new HyperDX instance.

\n

ex.

\n

HYPERDX_API_KEY=<YOUR_INGESTION_KEY> docker compose up -d

\n

\n
If you need to use sudo for docker, make sure to forward the environment
\nvariable with the -E flag:
\nHYPERDX_API_KEY=<YOUR_KEY> sudo -E docker compose up -d
\n

\n

Changing Hostname and Port

\n

By default, HyperDX app/api will run on localhost with port 8080/8000. You
\ncan change this by updating HYPERDX_APP_** and HYPERDX_API_** variables in
\nthe .env file. After making your changes, rebuild images with
\nmake build-local.

\n

DB Migration

\n

Before running the migration, you'll need to install the migration tools:

\n

Install local dependencies with make.
Install
\ngolang-migrate
\nCLI.

\n

You can initiate the DB migration process by executing make dev-migrate-db.
\nThis will run the migration scripts in /packages/api/migrations against the
\nlocal DB.

\n

Hosted Cloud

\n

HyperDX is also available as a hosted cloud service at
\nhyperdx.io. You can sign up for a free account and start
\nsending data in minutes.

\n

Instrumenting Your App

\n

To get logs, metrics, traces, session replay, etc into HyperDX, you'll need to
\ninstrument your app to collect and send telemetry data over to your HyperDX
\ninstance.

\n

We provide a set of SDKs and integration options to make it easier to get
\nstarted with HyperDX, such as
\nBrowser,
\nNode.js, and
\nPython

\n

You can find the full list in our docs.

\n

OpenTelemetry

\n

Additionally, HyperDX is compatible with
\nOpenTelemetry, a vendor-neutral standard for
\ninstrumenting your application backed by CNCF. Supported languages/platforms
\ninclude:

\n

Kubernetes
Javascript
Python
Java
Go
Ruby
PHP
.NET
Elixir
Rust

\n

(Full list here)

\n

Once HyperDX is running, you can point your OpenTelemetry SDK to the
\nOpenTelemetry collector spun up at http://localhost:4318.

\n

Local Mode

\n

Interested in using HyperDX for local development and debugging? Check out HyperDX Local, a single container local-optimized version of HyperDX that allows you to pipe OpenTelemetry telemetry (logs, metrics, traces) to a local instance of HyperDX running on your own machine.

\n

Get started with HyperDX Local by running the following Docker command:

\n

docker run -p 8000:8000 -p 4318:4318 -p 4317:4317 -p 8080:8080 -p 8002:8002 hyperdx/hyperdx-local

\n

Read more about HyperDX Local

\n

Contributing

\n

We welcome all contributions! There's many ways to contribute to the project,
\nincluding but not limited to:

\n

Opening a PR (Contribution Guide)
Submitting feature requests or bugs
Improving our product or contribution documentation
Voting on open issues or
\ncontributing use cases to a feature request

\n

Motivation

\n

Our mission is to help engineers ship reliable software. To enable that, we
\nbelieve every engineer needs to be able to easily leverage production telemetry
\nto quickly solve burning production issues.

\n

However, in our experience, the existing tools we've used tend to fall short in
\na few ways:

\n

They're expensive, and the pricing has failed to scale with TBs of telemetry
\nbecoming the norm, leading to teams aggressively cutting the amount of data
\nthey can collect.
They're hard to use, requiring full-time SREs to set up, and domain experts
\nto use confidently.
They requiring hopping from tool to tool (logs, session replay, APM,
\nexceptions, etc.) to stitch together the clues yourself.

\n

We're still early on in our journey, but are building in the open to solve these
\nkey issues in observability. We hope you give HyperDX a try and let us know how
\nwe're doing!

\n

Open Source vs Hosted Cloud

\n

HyperDX is open core, with most of our features available here under an MIT
\nlicense. We have a cloud-hosted version available at
\nhyperdx.io with a few
\nadditional features beyond what's
\noffered in the open source version.

\n

Our cloud hosted version exists so that we can build a sustainable business and
\ncontinue building HyperDX as an open source platform. We hope to have more
\ncomprehensive documentation on how we balance between cloud-only and open source
\nfeatures in the future. In the meantime, we're highly aligned with Gitlab's
\nstewardship model.

\n

Frequently Asked Questions

\n

How to suppress all logs from HyperDX itself ?

\n

To suppress logs of a service, you can comment out the HYPERDX_API_KEY
\nenvironment variable in the docker-compose.yml file. The alternative is to set
\nthe HYPERDX_LOG_LEVEL environment variable to 'error' to only log errors.

\n

Contact

\n

\n

License

\n

","updatedAt":"2025-05-21T16:02:25Z","upvoteCount":null,"author":{"login":"eryajf","avatarUrl":"https://avatars.githubusercontent.com/u/33259379?u=e4a4090a38ac2473aaed4ef9945233636776c6c3&v=4","url":"https://github.com/eryajf"},"category":null,"labels":{"edges":[{"node":{"name":"更多","color":"25B472"}},{"node":{"name":"Monitor","color":"533a1e"}},{"node":{"name":"hyperdxio","color":"873e55"}}]},"comments":{"edges":[]}}},"pageContext":{"number":235,"previous":{"title":"cilium/hubble: Hubble - 使用 eBPF 的 Kubernetes 网络、服务和安全可观测性","number":234},"next":{"title":"alibaba/ilogtail: 轻量级、高性能、自动化配置的遥测数据(logs, traces, metrics)采集工具","number":236}}}, "staticQueryHashes": ["151096407","2861350382"]}